16 Dec 2014

feedPlanet Gentoo

Anthony Basile: Lilblue Linux: release 20141212. dlclose() is a problem.

I pushed out another version of Lilblue Linux a few days ago but I don't feel as good about this release as previous ones. If you haven't been following my posts, Lilblue is a fully featured amd64, hardened, XFCE4 desktop that uses uClibc instead of glibc as its standard C library. The name is a bit misleading because Lilblue is Gentoo but departs from the mainstream in this one respect only. In fact, I strive to make it as close to mainstream Gentoo as possible so that everything will "just work". I've been maintaining Lilblue for years as a way of pushing the limits of uClibc, which is mainly intended for embedded systems, to see where it breaks and fix or improve it.

As with all releases, there are always a few minor problems, little annoyances that are not exactly show stopper. One minor oversight that I found after releasing was that I hadn't configured smplayer correctly. That's the gui front end to mplayer that you'll find on the toolbar on the bottom of the desktop. It works, just not out-of-the-box. In the preferences, you need to switch from mplayer2 to mplayer and set the video out to x11. I'll add that to the build scripts to make sure its in the next release [1]. I've also been migrating away from gnome-centered applications which have been pulling in more and more bloat. A couple of releases ago I switched from gnome-terminal to xfce4-terminal, and for this release, I finally made the leap from epiphany to midori as the main browser. I like midori better although it isn't as popular as epiphany. I hope others approve of the choice.

But there is one issue I hit which is serious. It seems with every release I hit at least one of those. This time it was in uClibc's implementation of dlclose(). Along with dlopen() and dlsym(), this is how shared objects can be loaded into a running program during execution rather than at load time. This is probably more familiar to people as "plugins" which are just shared objects loaded while the program is running. When building the latest Lilblue image, gnome-base/librsvg segfaulted while running gdk-pixbuf-query-loaders [2]. The later links against glib and calls g_module_open() and g_module_close() on many shared objects as it constructs a cache of of loadable objects. g_module_{open,close} are just glib's wrappers to dlopen() and dlclose() on systems that provide them, like Linux. A preliminary backtrace obtained by running gdb on `/usr/bin/gdk-pixbuf-query-loaders ./libpixbufloader-svg.la` pointed to the segfault happening in gcc's __deregister_frame_info() in unwind-dw2-fde.c, which didn't sound right. I rebuilt the entire system with CFLAGS+="-fno-omit-frame-pointer -O1 -ggdb" and turned on uClibc's SUPPORT_LD_DEBUG=y, which emits debugging info to stderr when running with LD_DEBUG=y, and DODEBUG=y which prevents symbol stripping in uClibc's libraries. A more complete backtrace gave:

Program received signal SIGSEGV, Segmentation fault.
__deregister_frame_info (begin=0x7ffff22d96e0) at /var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libgcc/unwind-dw2-fde.c:222
222 /var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libgcc/unwind-dw2-fde.c: No such file or directory.
(gdb) bt
#0 __deregister_frame_info (begin=0x7ffff22d96e0) at /var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libgcc/unwind-dw2-fde.c:222
#1 0x00007ffff22c281e in __do_global_dtors_aux () from /lib/libbz2.so.1
#2 0x0000555555770da0 in ?? ()
#3 0x0000555555770da0 in ?? ()
#4 0x00007fffffffdde0 in ?? ()
#5 0x00007ffff22d8a2f in _fini () from /lib/libbz2.so.1
#6 0x00007fffffffdde0 in ?? ()
#7 0x00007ffff6f8018d in do_dlclose (vhandle=0x7ffff764a420 <__malloc_lock>, need_fini=32767) at ldso/libdl/libdl.c:860
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The problem occurred when running the global destructors in dlclose()-ing libbz2.so.1. Line 860 of libdl.c has DL_CALL_FUNC_AT_ADDR (dl_elf_fini, tpnt->loadaddr, (int (*)(void))); which is a macro that calls a function at address dl_elf_fini with signature int(*)(void). If you're not familiar with ctor's and dtor's, these are the global constructors/destructors whose code lives in the .ctor and .dtor sections of an ELF object which you see when doing readelf -S <obj>. The ctors are run when a library is first linked or opened via dlopen() and similarly the dtors are run when dlclose()-ing. Here's some code to demonstrate this:

# Makefile
all: tmp.so test
tmp.o: tmp.c
        gcc -fPIC -c $^
tmp.so: tmp.o
        gcc -shared -Wl,-soname,$@ -o $@ $
test: test-dlopen.c
        gcc -o $@ $^ -ldl
        rm -f *.so *.o test
// tmp.c
#include <stdio.h>

void my_init() __attribute__ ((constructor));
void my_fini() __attribute__ ((destructor));

void my_init() { printf("Global initialization!\n"); }
void my_fini() { printf("Global cleanup!\n"); }
void doit() { printf("Doing it!\n" ; }
// test-dlopen.c
// This has very bad error handling, sacrificed for readability.
#include <stdio.h>
#include <dlfcn.h>

int main() {
        int (*mydoit)();
        void *handle = NULL;

        handle = dlopen("./tmp.so", RTLD_LAZY);
        mydoit = dlsym(handle, "doit");

        return 0;

When run, this code gives:

# ./test 
Global initialization!
Doing it!
Global cleanup!

So, my_init() is run on dlopen() and my_fini() is run on dlclose(). Basically, upon dlopen()-ing a shared object as you would a plugin, the library is first mmap()-ed into the process's address space using the PT_LOAD addresses which you can see with readelf -l <obj>. Then, one walks through all the global constructors and runs them. Upon dlclose()-ing the opposite process is done. One first walks through the global destructors and runs them, and then one munmap()-s the same mappings.

Figuring I wasn't the only person to see a problem here, I googled and found that Nathan Copa of Alpine Linux hit a similar problem [3] back when Alpine used to use uClibc - it now uses musl. He identified a problematic commit and I wrote a patch which would retain the new behavior introduced by that commit upon setting an environment variable NEW_START, but would otherwise revert to the old behavior if NEW_START is unset. I also added some extra diagnostics to LD_DEBUG to better see what was going on. I'll add my patch to a comment below, but the gist of it is that it toggles between the old and new way of calculating the size of the munmap()-ings by subtracting an end and start address. The old behavior used a mapaddr for the start address that is totally wrong and basically causes every munmap()-ing to fail with EINVAL. This is corrected by the commit as a simple strace -e trace=munmap shows.

My results when running with LD_DEBUG=1 were interesting to say the least. With the old behavior, the segfault was gone:

# LD_DEBUG=1 /usr/bin//gdk-pixbuf-query-loaders libpixbufloader-svg.la
do_dlclose():859: running dtors for library /lib/libbz2.so.1 at 0x7f26bcf39a26
do_dlclose():864: unmapping: /lib/libbz2.so.1
do_dlclose():869: before new start = 0xffffffffffffffff
do_dlclose():877: during new start = (nil), vaddr = (nil), type = 1
do_dlclose():877: during new start = (nil), vaddr = 0x219c90, type = 1
do_dlclose():881: after new start = (nil)
do_dlclose():987: new start = (nil)
do_dlclose():991: old start = 0x7f26bcf22000
do_dlclose():994: dlclose using old start
do_dlclose():998: end = 0x21b000
do_dlclose():1013: removing loaded_modules: /lib/libbz2.so.1
do_dlclose():1031: removing symbol_tables: /lib/libbz2.so.1

Of course, all of the munmap()-ings failed. The dtors were run, but no shared object got unmapped. When running the code with the correct value of start, I got:

# NEW_START=1 LD_DEBUG=1 /usr/bin//gdk-pixbuf-query-loaders libpixbufloader-svg.la
do_dlclose():859: running dtors for library /lib/libbz2.so.1 at 0x7f5df192ba26
Segmentation fault

What's interesting here is that the segfault occurs at DL_CALL_FUNC_AT_ADDR which is before the munmap()-ing and so before any affect that the new value of start should have! This seems utterly mysterious until you realize that there is a whole set of dlopens/dlcloses as gdk-pixbuf-query-loader does its job - I counted 40 in all! This is as far as I've gotten narrowing down this mystery, but I suspect some previous munmap()-ing is breaking the the dtors for libbz2.so.1 and when the call is made to that address, its no longer valid leading to the segfault.

Rich Felker, aka dalias, the developer of musl, made an interesting comment to me in IRC when I told him about this issue. He said that the unmappings are dangerous and that musl actually doesn't do them. For now, I've intentionally left the unmappings in uClibc's dlclose() "broken" in the latest release of Lilblue, so you can't hit this bug, but for the next release I'm going to look carefully at what glibc and musl do and try to get this fix upstream. As I said when I started this post, I'm not totally happy with this release because I didn't nail the issue, I just implemented a workaround. Any hits would be much appreciated!

[1] The build scripts can be found in the releng repository at git://git.overlays.gentoo.org/proj/releng.git under tools-uclibc/desktop. The scripts begin with a <a href="http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64-uclibc-hardened/">hardened amd64 uclibc stage3</a> tarball and build up the desktop.

[2] The purpose of librsvg and gdk-pixbuf is not essential for the problem with dlclose(), but for completeness We state them here: librsvg is a library for rendering scalable vector graphics and gdk-pixbuf is an image loading library for gtk+. gdk-pixbuf-query-loaders reads a libtool .la file and generates cache of loadable shared objects to be consumed by gdk-pixbuf.

[3] See http://lists.uclibc.org/pipermail/uclibc/2012-October/047059.html. He suggested that the following commit was doing evil things: http://git.uclibc.org/uClibc/commit/ldso?h=0.9.33&id=9b42da7d0558884e2a3cc9a8674ccfc752369610

16 Dec 2014 11:16pm GMT

14 Dec 2014

feedPlanet Gentoo

Sven Vermeulen: Handbooks moved

Yesterday the move of the Gentoo Wiki for the Gentoo handbooks (whose most important part are the installation instructions for the various supported architectures) has been concluded, with a last-minute addition being the one-page views so that users who want to can view the installation instructions completely within one view.

Because we use lots of transclusions (i.e. including different wiki articles inside another article) to support a common documentation base for the various architectures, I did hit a limit that prevented me from creating a single-page for the entire handbook (i.e. "Installing Gentoo Linux", "Working with Gentoo", "Working with portage" and "Network configuration" together), but I could settle with one page per part. I think that matches most of the use cases.

With the move now done, it is time to start tackling the various bugs that were reported against the handbook, as well as initiate improvements where needed.

I did make a (probably more - but this one is fresh in my memory) mistake in the move though. I had to do a lot of the following:


Without this, transcluded parts would suddenly show the translation tags as regular text. Only afterwards (I'm talking about more than 400 different pages) did I read that I should transclude the /en pages (like Handbook:Parts/Installation/About/en instead of Handbook:Parts/Installation/About) as those do not have the translation specifics in them. Sigh.

14 Dec 2014 12:42pm GMT

12 Dec 2014

feedPlanet Gentoo

Sven Vermeulen: Gentoo Handbooks almost moved to wiki

Content-wise, the move is done. I've done a few checks on the content to see if the structure still holds, translations are enabled on all pages, the use of partitions is sufficiently consistent for each architecture, and so on. The result can be seen on the gentoo handbook main page, from which the various architectural handbooks are linked.

I sent a sort-of announcement to the gentoo-project mailinglist (which also includes the motivation of the move). If there are no objections, I will update the current handbooks to link to the wiki ones, as well as update the links on the website (and in wiki articles) to point to the wiki.

12 Dec 2014 3:35pm GMT

Andreas K. Hüttel: Gentoo mailing lists down

Since yesterday the host running all Gentoo mailing lists is down. So far there is no information yet available on the nature of the problem. Please check the Gentoo Infrastructure status page, http://infra-status.gentoo.org/, for updates.

[Edit: All fixed.]

This public service announcement has been brought to you by non-infra Andreas.

12 Dec 2014 12:09am GMT

10 Dec 2014

feedPlanet Gentoo

Gentoo Monthly Newsletter: Gentoo Monthly Newsletter: November 2014

Gentoo News

Council News

The Gentoo Council addressed a few miscellaneous matters this month.

The first concerned tinderbox reports to bugs. There was a bit of a back-and-forth in bugzilla with a dispute over whether bugs generated from tinderbox runs that contained logs attached as URLs instead of as files could be closed as INVALID. Normally the use of URLs is discouraged to improve the long-term usability of the bugs. Since efforts were already underway to try to automatically convert linked logs into attached logs it was felt that closing bugs as INVALID was counterproductive.

There was also a proposal to implement a "future.eclass" which would make EAPI6 features available to EAPI5 ebuilds early. In general the Council decided that this was not a good thing to implement in the main tree as it would mean supporting two different implementations of some of the EAPI6 features, which could potentially diverge and cause confusion. Instead it would be preferable to focus on migrating packages to use EAPI6. The Council did encourage using mechanisms like this to do testing in overlays/etc if it was for the purpose of improving future EAPIs, but that this shouldn't be something done in "production."

Several other items came up with no action this month. There was a proposal to allow die withing subshells in EAPI6, but this had not received list discussion and the Council has been requiring this to ensure that all developers are able to properly vet significant changes. The remaining items were follow-ups from previous months which are being tracked but which have not had enough development to
act on yet.

Gentoo Developer Moves


Gentoo is made up of 244 active developers, of which 40 are currently away.
Gentoo has recruited a total of 805 developers since its inception.




This section summarizes the current state of the Gentoo ebuild tree.

Architectures 45
Categories 163
Packages 17849
Ebuilds 37661
Architecture Stable Testing Total % of Packages
alpha 3536 674 4210 23.59%
amd64 10838 6521 17359 97.25%
amd64-fbsd 0 1584 1584 8.87%
arm 2642 1848 4490 25.16%
arm64 549 64 613 3.43%
hppa 3076 529 3605 20.20%
ia64 3093 697 3790 21.23%
m68k 605 118 723 4.05%
mips 0 2422 2422 13.57%
ppc 6741 2549 9290 52.05%
ppc64 4295 1048 5343 29.93%
s390 1410 404 1814 10.16%
sh 1537 524 2061 11.55%
sparc 4033 980 5013 28.09%
sparc-fbsd 0 319 319 1.79%
x86 11483 5448 16931 94.86%
x86-fbsd 0 3205 3205 17.96%



The following GLSAs have been released by the Security Team

GLSA Package Description Bug
201411-11 net-proxy/squid Squid: Multiple vulnerabilities 504176
201411-10 net-misc/asterisk Asterisk: Multiple Vulnerabilities 523216
201411-09 app-admin/ansible Ansible: Privilege escalation 516564
201411-08 net-wireless/aircrack-ng Aircrack-ng: User-assisted execution of arbitrary code 528132
201411-07 net-misc/openswan Openswan: Denial of Service 499870
201411-06 www-plugins/adobe-flash Adobe Flash Player: Multiple vulnerabilities 525430
201411-05 net-misc/wget GNU Wget: Arbitrary code execution 527056
201411-04 dev-lang/php PHP: Multiple vulnerabilities 525960
201411-03 net-misc/tigervnc TigerVNC: User-assisted execution of arbitrary code 505170
201411-02 dev-db/mysql (and 1 more) MySQL, MariaDB: Multiple vulnerabilities 525504
201411-01 media-video/vlc VLC: Multiple vulnerabilities 279340

Package Removals/Additions


Package Developer Date
dev-php/adodb-ext grknight 01 Nov 2014
dev-php/eaccelerator grknight 01 Nov 2014
dev-php/pecl-apc grknight 01 Nov 2014
dev-php/pecl-id3 grknight 01 Nov 2014
dev-php/pecl-mogilefs grknight 01 Nov 2014
dev-php/pecl-sca_sdo grknight 01 Nov 2014
app-text/pastebin dilfridge 02 Nov 2014
sys-devel/libperl dilfridge 08 Nov 2014
dev-perl/Lucene dilfridge 08 Nov 2014
razorqt-base/libqtxdg yngwin 08 Nov 2014
virtual/perl-Version-Requirements dilfridge 08 Nov 2014
perl-core/Version-Requirements dilfridge 08 Nov 2014
dev-python/python-exec mgorny 08 Nov 2014
sys-devel/bfin-toolchain vapier 08 Nov 2014
dev-python/gns3-gui idella4 09 Nov 2014
dev-python/sparqlwrapper idella4 09 Nov 2014
app-accessibility/gnome-mag pacho 13 Nov 2014
app-accessibility/gnome-speech pacho 13 Nov 2014
app-accessibility/gok pacho 13 Nov 2014
app-admin/gnome-system-tools pacho 13 Nov 2014
app-admin/pessulus pacho 13 Nov 2014
app-admin/sabayon pacho 13 Nov 2014
app-crypt/seahorse-plugins pacho 13 Nov 2014
app-pda/gnome-pilot pacho 13 Nov 2014
app-pda/gnome-pilot-conduits pacho 13 Nov 2014
dev-cpp/libgdamm pacho 13 Nov 2014
dev-cpp/libpanelappletmm pacho 13 Nov 2014
dev-python/brasero-python pacho 13 Nov 2014
dev-python/bug-buddy-python pacho 13 Nov 2014
dev-python/evince-python pacho 13 Nov 2014
dev-python/evolution-python pacho 13 Nov 2014
dev-python/gnome-applets-python pacho 13 Nov 2014
dev-python/gnome-desktop-python pacho 13 Nov 2014
dev-python/gnome-media-python pacho 13 Nov 2014
dev-python/libgda-python pacho 13 Nov 2014
dev-python/libgksu-python pacho 13 Nov 2014
dev-python/libgnomeprint-python pacho 13 Nov 2014
dev-python/libgtop-python pacho 13 Nov 2014
dev-python/totem-python pacho 13 Nov 2014
gnome-base/gnome-applets pacho 13 Nov 2014
gnome-base/gnome-fallback pacho 13 Nov 2014
gnome-base/gnome-panel pacho 13 Nov 2014
app-accessibility/morseall pacho 13 Nov 2014
app-accessibility/java-access-bridge pacho 13 Nov 2014
gnome-extra/libgail-gnome pacho 13 Nov 2014
app-accessibility/dasher pacho 13 Nov 2014
gnome-extra/bug-buddy pacho 13 Nov 2014
gnome-extra/deskbar-applet pacho 13 Nov 2014
gnome-extra/evolution-exchange pacho 13 Nov 2014
gnome-extra/evolution-webcal pacho 13 Nov 2014
gnome-extra/fast-user-switch-applet pacho 13 Nov 2014
gnome-extra/gcalctool pacho 13 Nov 2014
gnome-extra/gnome-audio pacho 13 Nov 2014
gnome-extra/gnome-games-extra-data pacho 13 Nov 2014
gnome-extra/gnome-games pacho 13 Nov 2014
gnome-extra/gnome-media pacho 13 Nov 2014
gnome-extra/gnome-screensaver pacho 13 Nov 2014
gnome-extra/gnome-swallow pacho 13 Nov 2014
gnome-extra/hamster-applet pacho 13 Nov 2014
gnome-extra/lock-keys-applet pacho 13 Nov 2014
gnome-extra/nautilus-open-terminal pacho 13 Nov 2014
gnome-extra/panflute pacho 13 Nov 2014
gnome-extra/sensors-applet pacho 13 Nov 2014
gnome-extra/file-browser-applet pacho 13 Nov 2014
gnome-extra/gnome-hdaps-applet pacho 13 Nov 2014
media-gfx/byzanz pacho 13 Nov 2014
net-analyzer/gnome-netstatus pacho 13 Nov 2014
net-analyzer/netspeed_applet pacho 13 Nov 2014
x11-misc/glunarclock pacho 13 Nov 2014
gnome-extra/swfdec-gnome pacho 13 Nov 2014
gnome-extra/tasks pacho 13 Nov 2014
media-gfx/shared-color-profiles pacho 13 Nov 2014
net-libs/gupnp-vala pacho 13 Nov 2014
media-libs/swfdec pacho 13 Nov 2014
net-libs/farsight2 pacho 13 Nov 2014
net-libs/libepc pacho 13 Nov 2014
net-misc/drivel pacho 13 Nov 2014
net-misc/blogtk pacho 13 Nov 2014
net-misc/gnome-blog pacho 13 Nov 2014
net-misc/tsclient pacho 13 Nov 2014
www-client/epiphany-extensions pacho 13 Nov 2014
www-plugins/swfdec-mozilla pacho 13 Nov 2014
x11-themes/gnome-themes pacho 13 Nov 2014
x11-themes/gnome-themes-extras pacho 13 Nov 2014
x11-themes/gtk-engines-cleanice pacho 13 Nov 2014
x11-themes/gtk-engines-dwerg pacho 13 Nov 2014
x11-plugins/wmlife pacho 13 Nov 2014
dev-dotnet/gtkhtml-sharp pacho 13 Nov 2014
dev-util/mono-tools pacho 13 Nov 2014
net-libs/telepathy-farsight pacho 13 Nov 2014
x11-themes/gdm-themes pacho 13 Nov 2014
x11-themes/metacity-themes pacho 13 Nov 2014
x11-wm/metacity pacho 13 Nov 2014
gnome-base/libgdu pacho 13 Nov 2014
rox-base/rox-media pacho 13 Nov 2014
dev-python/gns3-gui patrick 14 Nov 2014
kde-misc/kcm_touchpad mrueg 15 Nov 2014
net-misc/ieee-oui zerochaos 19 Nov 2014
app-shells/zsh-completion radhermit 21 Nov 2014
app-dicts/gnuvd pacho 21 Nov 2014
net-misc/netcomics-cvs pacho 21 Nov 2014
dev-python/kinterbasdb pacho 21 Nov 2014
dev-libs/ibpp pacho 21 Nov 2014
dev-php/PEAR-MDB2_Driver_ibase pacho 21 Nov 2014
net-im/kmess pacho 21 Nov 2014
games-server/halflife-steam pacho 21 Nov 2014
sys-apps/usleep pacho 21 Nov 2014
dev-util/cmockery radhermit 24 Nov 2014
dev-python/pry radhermit 24 Nov 2014
dev-perl/DateTime-Format-DateManip zlogene 26 Nov 2014
www-servers/ocsigen aballier 27 Nov 2014
dev-ml/ocamlduce aballier 27 Nov 2014
dev-perl/Mail-ClamAV zlogene 27 Nov 2014
dev-perl/SVN-Mirror zlogene 27 Nov 2014
dev-embedded/msp430-binutils radhermit 27 Nov 2014
dev-embedded/msp430-gcc radhermit 27 Nov 2014
dev-embedded/msp430-gdb radhermit 27 Nov 2014
dev-embedded/msp430-libc radhermit 27 Nov 2014
dev-embedded/msp430mcu radhermit 27 Nov 2014
mail-filter/spamassassin-fuzzyocr dilfridge 29 Nov 2014


Package Developer Date
dev-python/python-bugzilla dilfridge 01 Nov 2014
app-vim/sudoedit radhermit 01 Nov 2014
dev-java/icedtea-sound caster 01 Nov 2014
dev-perl/Net-Trackback dilfridge 01 Nov 2014
dev-perl/Syntax-Highlight-Engine-Simple dilfridge 01 Nov 2014
dev-perl/Syntax-Highlight-Engine-Simple-Perl dilfridge 01 Nov 2014
app-i18n/fcitx-qt5 yngwin 02 Nov 2014
virtual/postgresql titanofold 02 Nov 2014
dev-python/oslo-i18n alunduil 02 Nov 2014
dev-libs/libltdl vapier 03 Nov 2014
dev-texlive/texlive-langchinese aballier 03 Nov 2014
dev-texlive/texlive-langjapanese aballier 03 Nov 2014
dev-texlive/texlive-langkorean aballier 03 Nov 2014
app-misc/ltunify radhermit 05 Nov 2014
dev-vcs/gitsh jlec 05 Nov 2014
dev-python/pypy3 mgorny 05 Nov 2014
virtual/pypy3 mgorny 05 Nov 2014
dev-php/PEAR-Math_BigInteger grknight 06 Nov 2014
games-rpg/morrowind-data hasufell 06 Nov 2014
games-engines/openmw hasufell 06 Nov 2014
dev-perl/URI-Encode dilfridge 06 Nov 2014
dev-perl/MIME-Base32 dilfridge 08 Nov 2014
dev-libs/libqtxdg yngwin 08 Nov 2014
app-admin/lxqt-admin jauhien 08 Nov 2014
dev-python/oslo-utils alunduil 08 Nov 2014
net-misc/gns3-server idella4 09 Nov 2014
dev-python/gns3-gui idella4 09 Nov 2014
dev-python/pypy3-bin mgorny 09 Nov 2014
dev-python/oslo-serialization alunduil 09 Nov 2014
dev-python/bashate prometheanfire 10 Nov 2014
dev-python/ldappool prometheanfire 10 Nov 2014
dev-python/repoze-who prometheanfire 10 Nov 2014
dev-python/pysaml2 prometheanfire 10 Nov 2014
dev-python/posix_ipc prometheanfire 10 Nov 2014
dev-python/oslo-db prometheanfire 10 Nov 2014
dev-ml/enumerate aballier 10 Nov 2014
dev-ml/core_bench aballier 10 Nov 2014
dev-util/sysdig mgorny 11 Nov 2014
dev-python/singledispatch idella4 12 Nov 2014
dev-tex/biblatex-apa mrueg 12 Nov 2014
app-emacs/multiple-cursors ulm 12 Nov 2014
dev-python/libnacl chutzpah 13 Nov 2014
dev-python/ioflo chutzpah 13 Nov 2014
dev-python/raet chutzpah 13 Nov 2014
dev-qt/qtchooser pesa 13 Nov 2014
dev-python/dicttoxml chutzpah 13 Nov 2014
dev-python/moto chutzpah 13 Nov 2014
dev-python/gns3-gui idella4 13 Nov 2014
x11-plugins/wmlife voyageur 13 Nov 2014
net-misc/gns3-gui patrick 14 Nov 2014
games-rpg/a-bird-story hasufell 14 Nov 2014
virtual/python-singledispatch idella4 15 Nov 2014
dev-python/kiwisolver idella4 15 Nov 2014
app-forensics/afl hanno 16 Nov 2014
games-board/gambit sping 16 Nov 2014
dev-db/pgrouting titanofold 16 Nov 2014
dev-python/atom idella4 16 Nov 2014
dev-embedded/kobs-ng vapier 18 Nov 2014
dev-python/ordereddict prometheanfire 18 Nov 2014
dev-python/WSME prometheanfire 18 Nov 2014
dev-python/retrying prometheanfire 18 Nov 2014
dev-python/osprofiler prometheanfire 18 Nov 2014
dev-python/glance_store prometheanfire 18 Nov 2014
dev-python/python-barbicanclient prometheanfire 18 Nov 2014
dev-python/rfc3986 prometheanfire 19 Nov 2014
sys-cluster/libquo ottxor 19 Nov 2014
dev-python/flask-migrate patrick 20 Nov 2014
media-libs/libde265 dlan 20 Nov 2014
dev-python/pyqtgraph radhermit 20 Nov 2014
app-shells/gentoo-zsh-completions radhermit 21 Nov 2014
app-shells/zsh-completions radhermit 21 Nov 2014
dev-libs/libsecp256k1 blueness 21 Nov 2014
net-libs/libbitcoinconsensus blueness 21 Nov 2014
net-misc/gns3-converter idella4 22 Nov 2014
dev-python/pytest-timeout jlec 22 Nov 2014
net-dns/libidn2 jer 22 Nov 2014
app-emulation/vpcs idella4 23 Nov 2014
dev-libs/libmacaroons patrick 23 Nov 2014
app-vim/emmet radhermit 24 Nov 2014
sci-libs/orocos-bfl aballier 25 Nov 2014
sys-libs/efivar floppym 26 Nov 2014
dev-python/jmespath aballier 26 Nov 2014
net-misc/python-x2go voyageur 27 Nov 2014
net-misc/pyhoca-cli voyageur 27 Nov 2014
dev-python/simplekv aballier 27 Nov 2014
dev-python/Flask-KVSession aballier 27 Nov 2014
net-misc/pyhoca-gui voyageur 27 Nov 2014
dev-libs/fstrm radhermit 27 Nov 2014
sci-libs/fcl aballier 28 Nov 2014
dev-ml/labltk aballier 28 Nov 2014
dev-ml/camlp4 aballier 28 Nov 2014
dev-python/sphinxcontrib-doxylink aballier 28 Nov 2014
dev-util/cpputest radhermit 29 Nov 2014
app-text/groonga grknight 29 Nov 2014
app-text/groonga-normalizer-mysql grknight 29 Nov 2014
app-forensics/volatility chithanh 29 Nov 2014
dev-perl/Test-FailWarnings dilfridge 30 Nov 2014
dev-perl/RedisDB-Parser dilfridge 30 Nov 2014
dev-perl/RedisDB dilfridge 30 Nov 2014
dev-python/nose_fixes idella4 30 Nov 2014
dev-perl/MooX-Types-MooseLike-Numeric dilfridge 30 Nov 2014


The Gentoo community uses Bugzilla to record and track bugs, notifications, suggestions and other interactions with the development team.


The following tables and charts summarize the activity on Bugzilla between 01 November 2014 and 01 December 2014. Not fixed means bugs that were resolved as NEEDINFO, WONTFIX, CANTFIX, INVALID or UPSTREAM.

Bug Activity Number
New 1858
Closed 1151
Not fixed 215
Duplicates 164
Total 6294
Blocker 4
Critical 14
Major 66

Closed bug ranking

The following table outlines the teams and developers with the most bugs resolved during this period

Rank Team/Developer Bug Count
1 Gentoo Security 57
2 Gentoo's Team for Core System packages 54
3 Gentoo Linux Gnome Desktop Team 39
4 Gentoo Perl team 32
5 Tim Harder 30
6 Gentoo Games 29
7 Gentoo KDE team 27
8 Java team 27
9 Gentoo Ruby Team 26
10 Others 829


Assigned bug ranking

The developers and teams who have been assigned the most bugs during this period are as follows.

Rank Team/Developer Bug Count
1 Python Gentoo Team 104
2 Gentoo Linux bug wranglers 97
3 Gentoo Linux Gnome Desktop Team 69
4 Gentoo Security 62
5 Gentoo's Team for Core System packages 56
6 Gentoo KDE team 44
7 Java team 38
8 Default Assignee for New Packages 37
9 Qt Bug Alias 33
10 Others 1317


Tips of the month

(by Alexander Berntsen)
New -alert emerge option

From the emerge(1) manpage

-alert [ y | n ] (-A short option) Add a terminal bell character ('\a') to all interactive prompts. This is especially useful if dependency resolution is taking a long time, and you want emerge to alert you when it is finished. If you use emerge -auAD world, emerge will courteously point out when it has finished calculating the graph.

-alert may be 'y' or 'n'. 'true' and 'false' mean the same thing. Using -alert without an option is the same as using it with 'y'. Try it with 'emerge -aA portage'.

If your terminal emulator is set up to make '\a' into a window manager urgency hint, move your cursor to a different window to get the effect.

Send us your favorite Gentoo script or tip at gmn@gentoo.org

Getting Involved?

Interested in helping out? The GMN relies on volunteers and members of the community for content every month. If you are interested in writing for the GMN or thinking of another way to contribute, please send an e-mail to gmn@gentoo.org.

Comments or Suggestions?

Please head over to this forum post.

10 Dec 2014 8:00pm GMT

Sven Vermeulen: Sometimes I forget how important communication is

Free software (and documentation) developers don't always have all the time they want. Instead, they grab whatever time they have to do what they believe is the most productive - be it documentation editing, programming, updating ebuilds, SELinux policy improvements and what not. But they often don't take the time to communicate. And communication is important.

For one, communication is needed to reach a larger audience than those that follow the commit history in whatever repository work is being done. Yes, there are developers that follow each commit, but development isn't just done for developers, it is also for end users. And end users deserve frequent updates and feedback. Be it through blog posts, Google+ posts, tweets or instragrams (well, I'm not sure how to communicate a software or documentation change through Instagram, but I'm sure people find lots of creative ways to do so), telling the broader world what has changed is important.

Perhaps a (silent or not) user was waiting for this change. Perhaps he or she is even actually trying to fix things himself/herself but is struggling with it, and would really benefit (time-wise) from a quick fix. Without communicating about the change, (s)he does not know that no further attempts are needed, actually reducing the efficiency in overall.

But communication is just one-way. Better is to get feedback as well. In that sense, communication is just one part of the feedback loop - once developers receive feedback on what they are doing (or did recently) they might even improve results faster. With feedback loops, the wisdom of the crowd (in the positive sense) can be used to improve solutions beyond what the developer originally intended. And even a simple "cool" and "I like" is good information for a developer or contributor.

Still, I often forget to do it - or don't have the time to focus on communication. And that's bad. So, let me quickly state what things I forgot to communicate more broadly about:

So, apologies for not communicating sooner, and I promise I'll try to uplift the communication frequency.

10 Dec 2014 6:38pm GMT

08 Dec 2014

feedPlanet Gentoo

Sebastian Pipping: Playing Xiangqi with xboard


Out of the box, xboard is expecting you to play western chess. It does support Xiangqi, but the default setup uses ugly western pieces and western square fields rather than lines:

You can make it look more traditional ..

.. but it is not really trivial to get there. Windows users have WinBoard Xiangqi install as an option but Linux users don't.
You could select board theme "xiangqi" at

MENU / View / Board / # ORIENTAL THEMES / double click on "xiangqi"

but you would end up with broken board scaling (despite xboard 2.8 knowing how to do better) without further tuning.

To summarize you have to teach xboard to

  1. play variant "xiangqi" rather than western chess,
  2. use different graphics, and
  3. get the board scaling right.

The following is a list of related options and how to get board scaling right by using a special symlink.


Command line view

Now some command line parameters need to be passed to xboard:

Tell engine to play chess variant "xiangqi":

-variant xiangqi

Use images for drawing the board:

-useBoardTexture true

Use xqboard-9x10.png for drawing both light and dark fields of the board:

-liteBackTextureFile /usr/share/games/xboard/themes/textures/xqboard-9x10.png
-darkBackTextureFile /usr/share/games/xboard/themes/textures/xqboard-9x10.png

xqboard-9x10.png can be a symlink to xqboard.png. The "-9x10" part is for the filename parser introduced with xboard 2.8. It ensures proper board rendering at any windows size. Without that naming (and with earlier versions), you need to be lucky for proper scaling.

Suppress drawing squares (of default line-width 1px) around fields:

-overrideLineGap 0

Use SVG images of the traditional Xiangqi pieces:

-pieceImageDirectory /usr/share/games/xboard/themes/xiangqi

Suppress grayscale conversion of piece graphics applied by default:

-trueColors true

Use HoiXiangqi for an engine:

-firstChessProgram /usr/games/bin/hoixiangqi

If you are running Gentoo, feel free to

sudo layman -a betagarden
sudo emerge -av games-board/xboard-xiangqi

to make that a little easier.

08 Dec 2014 8:06pm GMT

04 Dec 2014

feedPlanet Gentoo

Remi Cardona: Gentoo, btrfs arrays and systemd: a public service announcement

This week, I upgraded my media center/filer and after a reboot (new kernel), systemd was blocking on my btrfs mount. It's a 3-partition RAID1 array (until upstream says RAID5 is safe). Systemd was somehow waiting on it, with the infamous red spinner. Adding noauto to fstab did allow the machine to boot properly, but the mount itself silently failed: mount /my/mount/point would return 0 but nothing would show up in /proc/mounts nor in the mount point itself.

It turns out that the latest version of systemd reaches the local-fs target faster than earlier releases (at least that's my theory) and the kernel has not yet fully figured out what partitions belong in which array. So what I needed was to tell systemd to run btrfs dev scan before attempting to mount local filesystems.

While searching for clues, I came across this stack exchange question which has the correct answer (though I did make a few changes). I'll reproduce here the correct version for Gentoo, in case anyone runs into this:

$ cat /etc/systemd/system/local-fs-pre.target.wants/btrfs-dev-scan.service
Description=Btrfs scan devices

ExecStart=/sbin/btrfs device scan


I'm not exactly sure why "local-fs-pre.target" needs to be specified three times (twice inside the file, once in the path), but it does the trick: systemd waits for btrfs's device scan to return before mounting file systems. Maybe btrfs-progs should ship such a file…

As a side note, while digging for information, I found out that systemd actually reads the fstab and translates it into unit files at boot time. The generated files are located in /run/systemd/generator/.

One final piece of information: if I had taken the time to read journalctl -b carefully, I would have saved hours. If you have any issues with systemd, read the damn journal.

I'll take the opportunity to thank the kinds folks of #btrfs on FreeNode who promptly helped me.

That's it for tonight, thanks for reading.

04 Dec 2014 11:25pm GMT

02 Dec 2014

feedPlanet Gentoo

Luca Barbato: Track your issues

Issue Trackers

If you are not aware of a problem, you cannot fix it.

Having full awareness of the issues and managing it is the key of success for any kind of project (not just software).

For an open-source project it is essential that the issue tracker focuses on at least 3 areas:
Ease of use: You get reports mainly by casual users, they must spend the least amount of time to understand the tool and to provide the information.
Loudness: It must make problems easy to spot.
Data Mining: It should provide tools to query details, aggregate bugs and manipulate them.

What's available

Right now I tried in different projects many issue trackers, sadly almost none fit the bill, they usually are actually the opposite: limited, cumbersome, hard to configure and horrible to use either to fill bugs or to actually manage them.


It is by far the least bad, it has plugins to provide near-instant access thanks to Mozilla Persona, it has a rich rpc system that could be leveraged to have irc notifiers or side site statistics, importing-exporting data is almost there. As we know in Gentoo, it requires some deep manipulation and if there is nobody around to do that you can get fallouts like this when a single stubborn (and probably distracted) developer (vapier) manages to spoil the result of the goodwill of another and makes the Project overall more frail.


It is still too rich of confusing option but its default splash views are a boon if you are wondering what's the status of your project. No open-id/persona/single-sign-on integration sadly.


Usually not good enough on the reporting side and, even if they are much simpler than Bugzilla, still not good for the untrained user. They integrate with the source repository view and knowledge base (aka wiki) so they can be a good starting point for small organizations.


They have a more encompassing approach than redmine and trac, their issue tracker component is too simple in some cases (with Github not having even support for attachments and gogs not really managing tags yet) or a little too rough (no bug dependencies). But, with its immediate UI and the label-oriented approach, it is already pretty good for a large deal of projects. Sadly not Libav: we do need proper attachments.


Request Tracker is overwhelming. No other words. Do not use it if you do not need to. It is too complex to configure on the admin side and is too annoying to use on the developer side. For users the interface is usually a mailbox so you can't go wrong. Perfect if you have to manage a huge number of paying customer and you want to have detailed billing and other extremely advanced features.


New kid of the block, it is quite simple, way too simple. Its mail rendering makes it not really great but is pretty much a nice concept waiting to bloom. (Will it?)

Suggestion welcome

Do you know any better opensource issue tracker? Please comment down =)

02 Dec 2014 11:45am GMT

30 Nov 2014

feedPlanet Gentoo

Hanno Böck: The Fuzzing Project

This is already a few days old but I haven't announced it here yet. I recently started a little project to improve the state of security in free software apps and libraries:

The Fuzzing Project

This was preceded by a couple of discussions on the mailing list oss-security and findings that basic Unix/Linux tools like strings or less could pose a security risk. Also the availability of powerful tools like Address Sanitizer and american fuzzy lop makes fuzzing easier than ever before.

Fuzzing is a simple and powerful strategy to find bugs in software. It works by feeding a software with a large number of malformed input files usually by taking a small, valid file as a starting point. The sad state of things is that for a large number of software project you can find memory violation bugs within seconds with common fuzzing tools. The goal of the Fuzzing Project is to change that. At its core is currently a list of free software projects and their state of fuzzing robustness. What should follow are easy tutorials to start fuzzing, a collection of small input file samples and probably more ways to get involved (I think about moving the page's source code to github to allow pull requests). My own fuzzing already turned up a number of issues including a security bug in GnuPG.

30 Nov 2014 12:43pm GMT

29 Nov 2014

feedPlanet Gentoo

Kristian Fiskerstrand: Gentoo, qemu+kvm and virt-manager: Automating guest base install

I recently got myself a new server that is, amongst others, intended to use for kvm/qemu virtual machines that I administer using virt-manager. As most of the guest VMs will be running Gentoo linux, and the installation procedure is nice and command-line based it enable quick installation of an up to date system without using an image by utilizing a few simple bash scripts that require a minimum of user interaction during install in order to get a base OS.

It goes like this: After booting the Gentoo live-cd we reset the root password to get a known password and start sshd to allow me to upload the script files.

/etc/init.d/sshd start

Once this is done we upload the script files using scp:

scp *.sh root@

At this stage we edit the config.sh file using nano that is part of the live CD:

nano /config.sh

I rarely change much in the config file, but other users will naturally want to adjust this to their own environment. As for the drive layout I normally default it to
xda1: 5MB - spare for MBR
xda2: 100MB - /boot
xda3: 4096MB - swap
xda4: residual - /

xda is used in place for vda (if Virtio) or sda (if SATA) in this case. The underlying drive is an LVM2 logical volume created using

lvcreate -L 125G -n myVM vg0

A little trick on getting to use the LVM drive directly in virt-manager is to create a storage group for the directory of the volume group (/dev/vg0) which allows me to allocate the logical volumes directly to the drive as a virtio disk.

Attempting to run /host.sh without a drive setup it will naturally abort and we get a warning about missing drive configuration. Once this is configured (I normally use cfdisk /dev/xda) it is time to run:


The first thing that happens then is that the filesystems are configured appropriately (ext4) and a stage3 is downloaded and extracted, along with setting up the necessary mounts to enter the chroot. No more interaction is then necessary until we enter the chroot using:

chroot /mnt/gentoo /bin/bash

At this point the rest of the install instructions are being run, installing a regular gentoo-sources kernel with grub2 and setting up syslog-ng and cronie. Additionally I use Monkeysphere to set up the public keys for logging into the system as my user so this is automated as well as adding the user to wheel group (the latter two steps being optional in config file, but if you haven't looked into Monkeysphere before I recommend doing so)

Once this complete it is just a matter of running


to get of the of the chroot, and


and we have a working base-install of a VM once it gets back up. Then I can start making any adjustments for the service the VM is supposed to provide from here.

As for the actual scripts:

29 Nov 2014 10:28pm GMT

26 Nov 2014

feedPlanet Gentoo

Diego E. Pettenò: The end of an era, the end of the tinderbox

I'm partly sad, but for the most part this is a weight that goes away from my shoulders, so I can't say I'm not at least in part joyful of it, even though the context in which this is happening is not exactly what I expected.

I turned off the Gentoo tinderbox, never to come back. The S3 storage of logs is still running, but I've asked Ian to see if he can attach everything at his pace, so I can turn off the account and be done with it.

Why did this happen? Well, it's a long story. I already stopped running it for a few months because I got tired of Mike behaving like a child, like I already reported in 2012 by closing my bugs because the logs are linked (from S3) rather than attached. I already made my position clear that it's a silly distinction as the logs will not disappear in the middle of nowhere (indeed I'll keep the S3 bucket for them running until they are all attached to Bugzilla), but as he keeps insisting that it's "trivial" to change the behaviour of the whole pipeline, I decided to give up.

Yes, it's only one developer, and yes, lots of other developers took my side (thanks guys!), but it's still aggravating to have somebody who can do whatever he likes without reporting to anybody, ignoring Council resolutions, QA (when I was the lead) and essentially using Gentoo as his personal playground. And the fact that only two people (Michał and Julian) have been pushing for a proper resolution is a bit disappointing.

I know it might feel like I'm taking my toys and going home - well, that's what I'm doing. The tinderbox has been draining on my time (little) and my money (quite more), but those I was willing to part with - draining my motivation due to assholes in the project was not in the plans.

In the past six years that I've been working on this particular project, things evolved:

You can see that it's not that 'm trying to avoid spending time to engineer solutions. It's just that I feel that what Mike is asking is unreasonable, and the way he's asking it makes it unbearable. Especially when he feigns to care about my expenses - as I noted in the previously linked post, S3 is dirty cheap, and indeed it now comes down to $1/month given to Amazon for the logs storage and access, compared to $600/month to rent the cabinet at Hurricane.

Yes, it's true that the server is not doing only tinderboxing - it also is running some fate instances, and I have been using it as a development server for my own projects, mostly open-source ones - but that's the original use for it, and if it wasn't for it I wouldn't be paying so much to rent a cabinet, I'd be renting a single dedicated server off, say, Hetzner.

So here we go, the end of the era of my tinderbox. Patrick and Michael are still continuing their efforts so it's not like Gentoo is left without integration test, but I'm afraid it'll be harder for at least some of the maintainers who leveraged the tinderbox heavily in the past. My contract with Hurricane expires in April; at that point I'll get the hardware out of the cabinet, and will decide what to do with it - it's possible I'll donate the server (minus harddrives) to Gentoo Foundation or someone else who can use it.

My involvement in Gentoo might also suffer from this; I hopefully will be dropping one of the servers I maintain off the net pretty soon, which will be one less system to build packages for, but I still have a few to take care of. For the moment I'm taking a break: I'll soon send an email that it's open season on my packages; I locked my bugzilla account already to avoid providing harsher responses in the bug linked at the top of this post.

26 Nov 2014 3:04am GMT

20 Nov 2014

feedPlanet Gentoo

Alexys Jacob: RIP ns2

Today we did shutdown our now oldest running Gentoo Linux production server : ns2.

Obviously this machine was happily spreading our DNS records around the world but what's remarkable about it is that it has been doing so for 2717 straight days !

$ uptime
 13:00:45 up 2717 days,  2:20,  1 user,  load average: 0.13, 0.04, 0.01

As I mentioned when we did shutdown stabber, our beloved firewall, our company has been running Gentoo Linux servers in production for a long time now and we're always a bit sad when we have to power off one of them.

As usual, I want to take this chance to thank everyone contributing to Gentoo Linux ! Without our collective work, none of this would have been possible.

20 Nov 2014 12:39pm GMT

19 Nov 2014

feedPlanet Gentoo

Aaron W. Swenson: Request Tracker

So, I've kind of taken over Request Tracker (bestpractical.com).

Initially I took it because I'm interested in using RT at work to take track customer service emails. All I did at the time was bump the version and remove old, insecure versions from the tree.

However, as I've finally gotten around to working on getting it setup, I've discovered there were a lot of issues that had gone unreported.

The intention is for RT to run out of its virtual host root, like /var/www/localhost/rt-4.2.9/bin/rt and configured by /var/www/localhost/rt-4.2.9/etc/RT_SiteConfig.pm, and for it to reference any supplementary packages with ${VHOST_ROOT} as its root. However, because of a broken install process and a broken hook script used by webapp-config that didn't happen. Further, the rt_apache.conf included by us was outdated by a few years, too, which in itself isn't a bad thing, except that it was wrong for RT 4+.

I spent much longer than I care to admit trying to figure out why my settings weren't sticking when I edited RT_SiteConfig.pm. I was trying to run RT under its own path rather than on a subdomain, but Set($WebPath, '/rt') wasn't doing what it should.

It also complained about not being able to write to /usr/share/webapps/rt/rt-4.2.9/data/mason_data/obj, which clearly wasn't right.

Once I tried moving RT_SiteConfig.pm to /usr/share/webapps/rt/rt-4.2.9/etc/, and chmod and chown on ../data/mason_data/obj, everything worked as it should.

Knowing this was wrong and that it would prevent anyone using our package from having multiple installation, aka vhosts, I set out to fix it.

It was a descent into madness. Things I expected to happen did not. Things that shouldn't have been a problem were. Much of the trouble I had circled around webapp-config and webapp.eclass.

But, I prevailed, and now you can really have multiple RT installations side-by-side. Also, I've added an article (wiki.gentoo.org) to our wiki with updated instructions on getting RT up and running.

Caveat: I didn't use FastCGI, so that part may be wrong still, but mod_perl is good to go.

19 Nov 2014 3:52pm GMT

16 Nov 2014

feedPlanet Gentoo

Sebastian Pipping: (German) rsync mirror rsync1.de.gentoo.org wieder online

Nach mehreren Wochen downtime - primär durch mich verschuldet - ist rsync1.de.gentoo.org nun wieder online.
Wie vorher wird das komplette Repository aus einer RAM disk ausgeliefert, daher ist der Mirror relativ flott.

# rsync --list-only rsync://rsync1.de.gentoo.org/gentoo-portage/
drwxr-xr-x          3,480 2014/11/16 16:01:19 .
-rw-r--r--            121 2014/01/01 01:31:01 header.txt
-rw-r--r--          3,658 2014/08/18 21:01:02 skel.ChangeLog
-rw-r--r--          8,119 2014/08/30 12:01:02 skel.ebuild
-rw-r--r--          1,231 2014/08/18 21:01:02 skel.metadata.xml
drwxr-xr-x            860 2014/11/16 16:01:02 app-accessibility
drwxr-xr-x          4,800 2014/11/16 16:01:03 app-admin
drwxr-xr-x            100 2014/11/16 16:01:03 app-antivirus
drwxr-xr-x          1,240 2014/11/16 16:01:21 x11-wm
drwxr-xr-x            340 2014/11/16 16:01:21 xfce-base
drwxr-xr-x          1,340 2014/11/16 16:01:21 xfce-extra

Die Hardware darunter ist gesponsort von Manitu.

16 Nov 2014 3:53pm GMT

Sebastian Pipping: Introducing Gambit to Gentoo


I would like to introduce you to Gambit, a rather young Qt-based chess UI with excellent usability and its very own engine.

It has been living in the betagarden overlay while maturing and just hit the Gentoo main repository.
Install through

emerge -av games-board/gambit

as usual.

16 Nov 2014 2:50pm GMT