La incompetencia de los developers de ArchLinux expuesta | The ArchLinux decadency exposed

El dia de hoy, decidi darle una patada en el culo a ArchLinux, o como dice un amigo "garchilinux", esta distro que tanto idolatran sin saber realmente. El que tiene un poco mas de conocimiento, se puede dar cuenta que es una reverenda basura, y no son solo palabras, voy a hacer algo que me venia callando, pero hoy es el dia en que me harte, mi paciencia se colmo y llego un punto donde no puedo dejar de mostrar al mundo las respuestas de estos tipos y sobre todo como cierran los bug (que saben que son reales y por SU culpa) rapidamente antes de que alguien mas los vea, pero se joden, porque aca los posteo. Me importa nada si luego asocian el user con el texto en el blog, es real, y el que quiera ocultarlo, puede comentar, refutar, que no sera censurado, tiene derecho a replica; y si no entiende español, que se pele el culo como yo usando Google Translate para entender -si realmente le interesa-.

Todo comenzo cuando reporte un bug sobre xfce y le digo a Andreas Radke que se debia a las librerias de GCC, dado que habia visto eso mismo en muchos foros, y me contesta para mi sorpresa, el mismo empaquetador, él, que no recuerda con que version de gcc lo compilo, increible no?.
Luego toma partido un tal Rémy, donde me borra los link que habia posteado sobre undefined symbols relacionados a gcc 4.6 y me explica muy amablemente los pasos a seguir y que como ya habia dictaminado yo, no ellos, que era el paquete xfce4-goodies, que probara uno a uno a ver cual era el fallado, ahora, no es trabajo de un "developer" hacer eso aunque mas no sea en una virtual machine?, es broma?.
Sumo a esto que dias mas tarde tras un update de la muerte, como suelen ser los de archlinux, del paquete libxfce4ui version 4.8.0-2, me quedo sin desktop y tarda mas de 10 segundos en iniciar el mismo luego de startx, para hacer un downgrade y ver que el error se corregia.
Noto al momento que esa version pertenece a Debian Sid, o sea, unstable, y es donde pregunto en el mismo bugtracker, quien toma las decisiones, si existe un equipo de control de calidad, a lo que me responde Rémy que no, que las cosas pasan de testing a stable cuando nadie reporta bugs; es decir, los usuarios de testing, a ver si entendemos este punto, son los que si reportan se ve y si no reportan, pasa derecho, asi es como existe gnome shell con memory leak, mismo articulo en este blog.
A ver, señores, todos los usuarios no son coder ni yo mismo lo soy al nivel que necesita una distro, y tampoco reportan todo como yo, sinceramente es bastante denso estar cada 2 dias reportando bugs una y otra vez, por tanto, la confianza de que todo ande bien depende de si los usuarios desean reportarlo, increible nuevamente el proceso de testeo, comparado con Gentoo que tambien es rolling pero los ports son altamente probados y ademas se usan parches, cosa que la gente de ArchLinux no usa, no se si porque es su filosofia, porque no saben o porque les da alergia el comando patch.
Todo culmina cuando el gcc se upgradea a 4.6.0-5 y no logro compilar un solo kernel, a ver señores, llevo al menos 2 años compilando kernel's, mejorandolos, haciendo hacking en sus makefile, usando flags donde no debo y jamas tuve problemas, asi que evidentemente esto no es un problema mio, asi que busque el problema y di con el.
Aclaro, que uso kernel propios porque se me hace mejor un kernel con mis modulos y solo con mis cosas, a mi gusto, con mis parches y con las cosas empotradas y no modulares, vamos, que no ando cambiando el chipset cada semana!.
Doy con el problema, y resulta que lo veo en una lista de bug report de Debian Sid, con el gcc 4.6, hago los test que se describen alli y veo que el gcc de ArchLinux se comporta de igual forma en todos los casos (no por el hecho de devolver 0 o 1, sino por el exceso de warning que conlleva a no compilar), es decir, mal, por tanto concluyo que el problema es ese, el gcc, no yo, no el kernel, no la pc, no la presion atmosferica.
En base a esto, con mis mejores ganas, porque hay gente que ni ganas tiene, me pongo a probar y reportar para que mejoren el tema y poder volver a tener un sistema estable como tenia antes. Claro, ahora ya es tarde para volver al gcc 4.5.2 no pueden, aunque quisieran, porque todo lo que esta en los repos esta compilado con el 4.6 y lo que posee mucha gente en sus PC, por tanto si cambian las librerias harian la distro inservible.
Paso a pegar los bug report, y luego comentare al final, pero lean por favor los bug report:

FS#24355 - [gcc 4.6.0-5] [-Wunused-but-set-variable] 

Details

Description:

gcc 4.6.0-5 not finish compile a vanilla kernel with steps:

make menuconfig (previous .config from slackware 13.37 with gcc 4.5.2 and work fine)
make bzImage - Fail at finish time with various errors

I see an error in debian bug list, and the _same_ error i can reproduce in x86 and x86_64 system ArchLinux (have 1 notebook and 1 desktop)

Test it:

test.c:
----------------------------------------------------------
#include <stdio.h>

int main(void)
{
int x;
x = printf("hello, world\n");
return 0;
}
-----------------------------------------------------------
gcc -Wall -Werror test.c; echo $?

test.c: En la función ‘main’:
test.c:5:13: error: se define la variable ‘x’ pero no se usa [-Werror=unused-but-set-variable]
cc1: todos los avisos se tratan como errores

1

------------------------------------------------------------

gcc -Werror=unused-but-set-variable test.c; echo $?

test.c: En la función ‘main’:
test.c:5:13: error: se define la variable ‘x’ pero no se usa [-Werror=unused-but-set-variable]
cc1: algunos avisos se tratan como errores

1
-------------------------------------------------------------
gcc -Werror=unused-but-set-variable test.c; echo $?

test.c: En la función ‘main’:
test.c:5:13: error: se define la variable ‘x’ pero no se usa [-Werror=unused-but-set-variable]
cc1: algunos avisos se tratan como errores

1
--------------------------------------------------------------

The same problem is reported in debian, reference:

http://lists.debian.org/debian-gcc/2011/02/msg00107.html


Additional info:
* package version(s)
* config and/or log files etc.
System up to date, archlinux_x86 stable and archlinux_x86_64 stable, the same error. Using xfce or kde in both machines.

note: if you need me to translate the texts in Spanish just ask him

Steps to reproduce:

This task depends upon

Closed by  Andreas Radke (AndyRTR)
Friday, 20 May 2011, 05:22 GMT-3
Reason for closing:  Not a bug
Additional comments about closing:  The kernel does compile with our safe preset flags in makepkg.conf. Using custom flags is your fun (probably has to be fixed in the kernel code).

Request re-open

• Comments (1)
• Related Tasks (0/0)
• History