News aggregator

What: Gentoo contributors get together to help each other fix bugs

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

When: Saturday, January 3, in a timezone near you

What do you need to bring?

• A Gentoo system, an Internet connection and an IRC client
• Your bug. If you don't have one, we will find you one to suit your area of interest and your skills
• Your favorite editor
• A way to test that your bug is fixed (asking people counts!)
• You don't need to know C, C++, or bash

What's a bug? 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.

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. Bugday is more about fixing problems than adding features, but you won't be turned away if you want help with a new feature.

Want to know more about Bugday? 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 Bugday project page for more details.

Bugday is about community spirit. 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.

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.

Discuss this!

Roy Bamford contributed the draft for this announcement.

The time has come! Our release engineers have been refining their automated builds of the minimal CD and stage3 tarballs, and the first builds are uploaded to our mirrors. Select your favorite mirror and navigate to the /experimental/ directory. Under the x86, amd64, ia64, alpha, and sparc64 architectures, the autobuilds directory contains stages. So far, minimal CD images are only available for x86 and amd64.

We're still working to add automated builds for ppc, ppc64 and hppa as well as CD images for architectures lacking them. We built the stage3 tarballs from the latest stable packages. Fresh builds will show up every week, although sometimes we might skip a week if build problems crop up.

Because these builds are automated, they have not been rigorously tested as the old releases. Occasionally, you might run into problems. If that happens, just try a file from a different week.

Please try out these new builds and leave your feedback on the forums. As always, please report any bugs on Bugzilla.

Happy holidays!

Discuss this!

Ben de Groot contributed the draft for this announcement.

The November issue of the Gentoo Monthly Newsletter has been released. In this month's issue: Kernel team, Incognito, Gentoo-wiki returns, and more!

Discuss This!

The September issue of the Gentoo Monthly Newsletter has been released. In this month's issue: EAPI-2 approved, Gentoo-Quebec training, learn to use iotop, and more!

Discuss This!

In future releases, Gentoo will focus on a more back-to-basics approach that will give you up-to-date install media on a regular basis and make much better use of our human resources. We're looking into automated weekly builds of the minimal CDs and stage tarballs as well as maybe an annual LiveCD release. We will keep you updated as we decide on the details of this new approach.

Consequently, we're canceling the 2008.1 release. The release engineering team has to reconsider its priorities—we overstretched our human resources during the prolonged 2008.0 release process. This caused too much stress for our release engineers and multiple postponements of the release.

You can help! The release engineering team is looking for new volunteers because it perpetually has a severe lack of manpower. We are particularly looking for people with a good grasp of ebuild development and the ability to debug/fix problems that crop up during building and testing of the stage tarballs and ISO images. We will update the staffing needs page with more details.

Discuss this!

Ben de Groot contributed the draft for this announcement.

What: Gentoo contributors get together to help each other fix bugs

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

When: Saturday, September 6, in a timezone near you

What do you need to bring?

• A Gentoo system, an Internet connection and an IRC client
• Your bug. If you don't have one, we will find you one to suit your area of interest and your skills
• Your favorite editor
• A way to test that your bug is fixed (asking people counts!)
• You don't need to know C, C++, or bash

What's a bug? 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.

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. Bugday is more about fixing problems than adding features, but you won't be turned away if you want help with a new feature.

Want to know more about Bugday? 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 Bugday project page for more details.

Bugday is about community spirit. 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.

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.

Discuss this!

Roy Bamford contributed the draft for this announcement.

The August issue of the Gentoo Monthly Newsletter has been released. In this month's issue: PHP4 removal, GSOC interview, new Gentoo-based distributions, and more!

Discuss This!

The July issue of the Gentoo Monthly Newsletter has been released. In this month's issue: 2008.0 release, Gentoo at Peel Fresco Music Lounge and more!

Discuss This!

For those unfortunate souls who couldn't boot or burn the LiveCD, we've provided the 2008.0-r1 revision bump. It fixes these specific problems:

• Bug #230998: 2008.0 LiveCD for x86/amd64 messes up when copying kernel/initramfs into tmpfs
• Bug #231024: LiveCD AMD64 image does not fit on ordinary 700MB CD

We apologize if you encountered one of these problems. We fixed them as quickly as we could after hearing about them. Get the new 2008.0-r1 revision from our "Get Gentoo!" page.

Discuss this!

The 2008.0 final release is out! Code-named "It's got what plants crave," this release contains numerous new features including an updated installer, improved hardware support, a complete rework of profiles, and a move to Xfce instead of GNOME on the LiveCD. LiveDVDs are not available for x86 or amd64, although they may become available in the future. The 2008.0 release also includes updated versions of many packages already available in your ebuild tree.

• Updated installer: The installer now only performs networkless installations using the packages and ebuild tree on the LiveCD. It also contains numerous fixes for extended and logical partitions.
• Improved hardware support: Moving to the 2.6.24 kernel added many new drivers for hardware released since the 2007.0 release.
• Complete rework of profiles: Restructuring profiles allowed significant cleanup of redundancies, reducing developer maintenance and confusion. The difference for you is that profiles now appear in /usr/portage/profiles/ under default/linux/ instead of default-linux/. See the upgrading guide for more details.
• Xfce instead of GNOME on the LiveCD: To save space, the LiveCDs switched to the smaller Xfce environment. This means that a binary installation using the LiveCD will install Xfce, but you're still free to build GNOME or KDE from source.
• No LiveDVDs on x86 or amd64: In the interest of getting the release out, the release engineering team decided to postpone LiveDVDs because of problems in their generation. They may show up later—if so, we'll let you know.
• Updated packages: Highlights of the 2008.0 release include Portage 2.1.4.4, a 2.6.24 kernel, Xfce 4.4.2, gcc 4.1.2 and glibc 2.6.1.

A big thanks goes out to our release engineering team members for their hard work over many months to turn 2008.0 into reality.

Get the new release from our "Get Gentoo!" page.

Discuss this!

Não faz muito tempo que lançaram o Fedora 10 e já está aberta a votação para a escolha do codinome do Fedora 11, infelizmente apenas os embaixadores do Fedora podem votar, mas parece que essa eleição vai ser bem disputada. Entre as opções há uma surpresa, o codinome "Brasília" está no meio, esse codinome foi sugerido pelo Tulio Macedo (Teseu). As opções são essas:

1 - Blarney

2 - Brasília

3 - Claypool

4 - Duchess

5 - Euryalus

6 - Indomitable

7 - Leonidas

8 - Zampone

Qual você acha que deve ser o codinome da próxima versão? Deixe um comentário.

Jérémy Bobbio suggested that I should explain how I looked for packages affected by a compiler bug (Debian bug 506713; gcc bug 38287). I don't claim that this is a particularly good way to do it, but here it is:

First, I identified a pattern to search for. Unfortunately I don't really understand the cause or fix for the bug, but I did have the example which led to this bug report: Debian bug 490999. The bad code was a stack-pointer-relative load immediately after a stack allocation (SPARC save instruction) where the offset was not adjusted for the stack allocation:

where offset1 + offset2 < 0. Of course, this may be valid if the intervening instructions include a restore, branch or store to the effective stack location that the last instruction loads from. I ended up allowing up to 10 intervening instructions and examining a disassembly to work out which cases were valid.

I looked up the instruction encoding for these two instructions. Thankfully SPARC is RISC so they are simple and regular:

• save %sp, offset1, sp is encoded as 0x9de3a000 | offset1 & 0x1fff
• ld [ %sp + offset2 ], register is encoded as 0xc003a000 | reg << 25 | offset2 & 0x1fff

I took the dumb but effective approach of scanning entire files for this pattern rather than only scanning their code sections. This seemed to work - I got no false hits for non-code - but might not work for other patterns that could match ASCII text.

I wrote the scanning program in Python, which is my default choice of language unless I know it's going to be too slow. I was hoping to be able to read the code files into arrays, but unfortunately the Python array type only supports the native byte-order (SPARC is big-endian and I was intending to use an x86 which is little-endian). I tried reading into a tuple using struct.unpack, which does support explicit byte-ordering, but this used so much memory for larger files that the program swapped to a crawl. So finally I resorted to reading the file into a string, doing a string search for '\x9d\xe3', rejecting matches that weren't appropriately aligned, then unpacking and comparing the code words from the point of the string match. (In Python 3.0 I would have to use the bytes type for this, as str is a Unicode string type.)

So that's how I scanned single files. The next step was to find, unpack and scan all the SPARC shared libraries in the archive. (This particular code generation bug is understood to affect only PIC code, and that is normally only used in shared libraries.) I wrote functions to search Contents-sparc for shared library files - assumed to match the pattern ([^\s]*/lib[^/\s]+\.so(?:\.[^/\s]*)?) - and to parse Packages to find the filenames for the packages containing those files. The latter uses the debian_bundle.deb822 module from python-debian. The last key function downloads and unpacks a package using wget and dpkg-deb. I could have used the httplib module for downloading but I correctly anticipated that I'd need to restart the script several times so I wanted to cache the packages which was easier to do using wget.

So, that's the explanation. If you really want to see it, here's the code.