[patch] glibc-2.15

Zbigniew Luszpinski zbiggy at o2.pl
Sun Apr 15 22:21:45 CEST 2012


> > Hi,
> > 
> > for brave testers: glibc-2.15. Enjoy.
> > As usually I expect someone will test this.
> > 
> > I tested it on 3 32bit lunars - update from 2.14.1.
> > Build clean, reboot clean, lunar fix - clean, nothing was needed to 
> > rebuild. I also implemented support for linux-stable (problem reported 
by 
> > wdp) - this one not tested I do not use linux-stable.
> > 
> > Highlights:
> > * works and builds fine with march=native and other.
> > *if you have recent cpu glibc will use sse2, ssse3 up to sse4.2 and 
avx to 
> > accelerate processing both on 32/64bit. 
> > 
> Bumping glibc and calling it good is not sufficient given the things you 
> tested. Did you actually do a lunar rebuild? Sure in the past this module 
> bump has compiled fine but til you start recompiling installed modules 
> you'll never know just what it will effect. The last bump of this is a 
> good example. Why do you think I was adding things like "CFLAGS=" -lm" to 
> a lot of the BUILD files.

It is good for testing (clean build and do not break anything so far on 
KDE Lunar desktop which usually have many modules installed as deps).
That is why I posted what was tested and how many machines.
That is why it is posted here for testing - not commited.

Pushing such 'early access' module to dev ML saves resources and time
because other dev can pick it up instead  of working from base.
Even if they would like to start working from base module always can
diff base with this one and consider my changes.

The Lunar iso is old. When I will find some time will start working on new 
one. Then will do fresh build with new glibc and other base module all 
fresh on iso. Now build, collect and test core modules for such iso 
update. Also post such updates here (glibc/udev/patches for lunar tools) 
so anyone can look and comment. We should release a new iso always when 
new major kernel release appears because with such release new hardware 
support is added. This matters when you install Linux on you new PC - if 
iso is up to date then you have less compatibility gap between iso and 
moonbase. Less effort needed to keep it in sync because newcomers have 
recent codebase when they connect to moonbase for first time. I would like 
to create such up to date developer/experimental isos which could be 
available in parallel to official releases. It could be recommended for 
those who would like to try lunar but can not install it because official 
iso does not support their hardware yet or breaks during lunar update 
because there is too big compatibility gap.

How about recycling former devs as testers? If they do not have time for 
developing maybe they will find time for testing?


More information about the Lunar-dev mailing list