I noticed that a lot of graphics card vendors don't know their product as good as they should, esp. since all modern graphics card have a resolution of >=1680x1050...
So you'll have trouble to use a resolution of >1600x1200 when also using the linux framebuffer e.g. uvesafb.
The max. resolution defined by the VESA VBE is 1600x1200, I'm glad to have a XFXForce GF9600GT in my desktop which has a *extended* VBE which allows (take a loot at /sys/devices/platform/uvesafb.0/vbe_modes when using uvesafb) me to use a resolution up to 1680x1050 in my framebuffer.

Intel or other KMS users shouldn't be affected at all, so mainly NVIDIA users are affected.

I also have a brand new card from Zotac but unfortunately limited to max. 1600x1200. I tried to get a new VBIOS from Zotac but they a) don't have BIOS upgrades at all and b) they didn't even get it at all.. So it seems there is no way to get a fixed version from Zotac.

Spock, the uvesafb author, had the idea to write a "patch" similar to 915resolution but my skills in this area are too weak :(.

So I'm writing about this because I'm looking for a new card atm but I do want to have high resolutions supported on the framebuffer as well. XFX doesn't seem to have recent cards and I don't know about the other vendors.

Do you guys know any other vendors besides XFX which have such a extended version of the video bios? It may be a good idea to start creating of a public list of such vendors...

I noticed that we have a lot of "duplicate" accounts in our Bugzilla DB. Did you know that we can merge your old account with your new one? That means the entire history of your old account will be linked with the new one, so that we can remove the old one later.

Just poke me (idl0r) in IRC (#gentoo-infra or #gentoo-bugs) or by mail idl0r AT gentoo DOT org.

*UPDATE*
I totally forgot this part...
It seems many users don't even know that they can simply change their login name/mail address in Bugzilla. Simply change your mail address in the Account tab of your Bugzilla Preferences. So there is no need to create a new account just because you have/want a new mail address for it. :)

I bet the most of you didn't know about those options at all so I'll try to briefly explain some...

We can set a project name for your repository, useful mostly for CIA.vc. In some cases the repository name differs from the CIA.vc project name so it would make sense to specify the right one.

Since CIA.vc notifications are enabled by default for almost all repositories it is also possible to disable CIA.vc notifications for your repository.

We can exclude some files for you to hide those in commit mails (e.g. CIA.vc or gentoo-commits). A good example are "Manifest" files.

If your commits will be send to gentoo-commits AT lists DOT gentoo DOT org and you don't want them to be send to the list anymore then just poke us, we can disable it for you.
We can also add additional mail addresses to where commit mails will be send. (Please request this only for mailinglists or so if you and your teammates want to review your commits)

Last but not least: It is possible to ignore single branches from commit mails, neither CIA.vc notifications nor mails to gentoo-commits or additional specified addresses will be send at all.

The Overlays team can be found in IRC (#gentoo-overlays) or via mail overlays AT gentoo DOT org. Also see Gentoo Overlays Team

If you ever wanted to use Bugzilla's feed to get each bug since your last query? Read on...

Bugzilla has two interesting variables, "chfieldfrom" and "chfieldto" which can be a time value. It can be a timestamp like from: date -u "+%Y-%m-%d+%H:%M".

But a small script is needed to use them properly. Some feed reader may have own variables which you can use directly in the source URL.

Code:

The script stores the date value of your last query and uses it later as "chfieldfrom", "chfieldto" is always "now".

To use it in e.g. Liferea:

Liferea->Subscriptions->New Subscription->Advanced, select Command and choose your script. That's it.

So we finally migrated successfully from gitosis to gitolite. I'll try to explain how to do it easily.

Client side, part 1:

1. Update your local gitosis-admin repository

Server side, part 1:

1. Disable write access to your gitroot by either changing the "git" users homedir (I prefer this method) or by renaming the ~/.ssh/authorized_keys file. This is important to ensure gitolite gets a clean authorized_keys file
2. Make a backup of your gitroot by using rsync, tar or whatever else..
3. Cleanup/Remove your old gitroot
4. Install gitolite
5. Copy the example gitolite.rc into the git users homedir (e.g. ~/.gitolite.rc) and set your settings (Don't forget to chown/chmod it later)
6. Run "gl-setup /path/to/your/pubkey" as "git" user

Client side, part 2:

1. git clone git+ssh://git.yourdomain.tld/gitolite-admin.git
2. Grab my convert script below
3. cd /path/to/gitosis-admin
4. perl ~/convert.pl [/path/to/your/gitosis.conf] >> /path/to/gitolite.conf
5. Commit & Push your changes but DON'T add your old keys from keydir yet!

All repositories will be created after your push, ignore the pubkey warnings for now.

Server side, part 2 (Run commands as user "git"):

1. Create a tmp directory and cd into it
2. git clone -q --bare /path/to/your/gitroot/backup/repository.git
3. cd repository.git
4. GL_BYPASS_UPDATE_HOOK=1 git push -q --mirror /path/to/the/new/gitroot/repository.git

With clone and push --mirror we ensure that we don't keep any old hooks or other stuff from gitosis.

In most cases it might be enough to simply remove the old hooks e.g. by running "find /path/to/gitroot/ -type d -name hooks -exec rm -f {}/* \;", then you could skip the server part 2 and use your old gitroot instead.

I did part 2 to ensure we really have a clean new gitroot. So decide yourself.

If you need to push via ssh, create a migration user in gitolite.conf

Code:

and add the public key as well.

Then start a ssh-agent and ssh-add your public key. Now you don't need to enter the passphrase for each push.

If you have a lot of repositories then just write a small shell script including the git clone/push stuff.

Once you're done: Remove the migration user and its key.

Now add all your old gitosis keys to gitolite. That's it!

If you need the post-update hook from git (update-git-server-info) then just link it into your ~/.gitolite/hooks/common dir.

Code:

Run gl-setup again (as user "git") and you're done.

Each time when you modify your .gitolite.rc, add/change hooks or update gitolite itself then simply run gl-setup. NOTE: Old hooks will not be removed by gitolite/gl-setup!

Gentoo user can choose between the upstream/vanilla version dev-vcs/gitolite or our own fork dev-vcs/gitolite-gentoo.