Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 247553 (glibc-2.8-stable) - [tracker] sys-libs/glibc 2.8 stabilization
Summary: [tracker] sys-libs/glibc 2.8 stabilization
Status: RESOLVED FIXED
Alias: glibc-2.8-stable
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords: STABLEREQ, Tracker
Depends on: glibc-2.8 242270 243374 249273 250892 258253 258256 258258 258260 258261 258262 258264 258265 258269 258556 261630 263405
Blocks: gcc-4.3-stable
  Show dependency tree
 
Reported: 2008-11-19 09:41 UTC by Christian Faulhammer (RETIRED)
Modified: 2009-09-24 00:50 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Faulhammer (RETIRED) gentoo-dev 2008-11-19 09:41:51 UTC
This bug will be used to track all packages that must be stabilized before
glibc-2.8.

- Please file a NEW bug for each package that needs to be stabilized and have
it BLOCK this one.

- The bug should be assigned to the maintainer of the package, not gcc-porting or toolchain

- Please don't add toolchain/gcc-porting to the CC list.  The amount of mail we get on these things is already scary.

- DO NOT use this bug for any problems with Glibc 2.8 itself.  Instead, file a
NEW bug describing your issue and assign it to toolchain.

Thanks.
Comment 1 Ryan Hill (RETIRED) gentoo-dev 2008-11-19 19:04:54 UTC
i'll follow this through the toolchain alias.
Comment 2 SpanKY gentoo-dev 2009-02-08 23:46:24 UTC
let's get moving finally on this.  glibc-2.8_p20080602-r1 is the target.
Comment 3 Christian Faulhammer (RETIRED) gentoo-dev 2009-02-09 00:03:25 UTC
Please wait a bit until the needed stabilisations for bug 225459 are handled
Comment 4 SpanKY gentoo-dev 2009-02-09 00:08:09 UTC
i see no actual movement there.  we cant sit around and wait forever on bugs that arent actually going to be closed out.
Comment 5 Christian Faulhammer (RETIRED) gentoo-dev 2009-02-09 01:22:04 UTC
(In reply to comment #4)
> i see no actual movement there.  we cant sit around and wait forever on bugs
> that arent actually going to be closed out.

At the moment this break stable users of Mono (bug 225409) and KDE (bug 225727).
Comment 6 Christian Faulhammer (RETIRED) gentoo-dev 2009-02-09 01:45:53 UTC
(In reply to comment #4)
> i see no actual movement there.  we cant sit around and wait forever on bugs
> that arent actually going to be closed out.

 All fixed bugs have been handled stabilisation-wise, only Mono is missing...Peter, you can tell something here?
Comment 7 Peter Alfredsen (RETIRED) gentoo-dev 2009-02-09 02:06:13 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > i see no actual movement there.  we cant sit around and wait forever on bugs
> > that arent actually going to be closed out.
> 
>  All fixed bugs have been handled stabilisation-wise, only Mono is
> missing...Peter, you can tell something here?

Believe it or not, Mono is waiting for gnome-2.24 to go stable. I had been assured that it would be stable by now when I chose to go with 2.24.x gnome-sharp and gnome-desktop-sharp tarballs, but no such luck so far. It's mono-2.01-r1 that's the stable target - bug 234305. We're ready to go as soon as 2.24.x gnome goes stable.
The problem is that we have a few applications that will not build with mono-1.2x but will build with 2.0x and vice versa. Banshee IIRC. There are probably others.
I've been unwilling to touch the mono-1.2x stuff since I'm only me and myself maintaining a mountain of packages and mono-1.2.x is just not very functional. If someone can produce a patch for mono-1.2.x that makes it work with glibc-2.8, they should just apply it.
Comment 8 SpanKY gentoo-dev 2009-02-09 02:08:06 UTC
if not, it'll be broken for a while i guess
Comment 9 Christian Faulhammer (RETIRED) gentoo-dev 2009-02-11 18:33:55 UTC
(In reply to comment #8)
> if not, it'll be broken for a while i guess
 
 And breaks stable Gnome...so no-go.
Comment 10 SpanKY gentoo-dev 2009-02-11 18:54:39 UTC
gnome doesnt rely on mono
Comment 11 Ryan Hill (RETIRED) gentoo-dev 2009-02-11 18:58:46 UTC
what's the problem with mono 1.2?
Comment 13 Ryan Hill (RETIRED) gentoo-dev 2009-02-12 01:24:50 UTC
ok, fixed mono.  are there any other holdups?
Comment 14 Peter Alfredsen (RETIRED) gentoo-dev 2009-02-12 02:11:25 UTC
Arches, please stabilize sys-libs/glibc-2.8_p20080602-r1
Comment 15 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-02-12 02:52:13 UTC
Well, thats unfortunate. In my amd64 stable chroot, make check fails.

Here is the code that died, the call stack is too long to list here.
 * The specific snippet of code:
 *       eblit-${PN}-$1 || die;
 *  The die message:
 *   (no error message)

27M build.log @ http://dev.gentoo.org/~darkside/build.log

Currently testing the current stable to confirm that it isn't a regression. Please advise if this isn't a problem??
Comment 16 SpanKY gentoo-dev 2009-02-12 05:55:06 UTC
if you're talking about `make check` in glibc failing, there are many known failures.  i suggest you search and see if the issue you're hitting already has an open bug.  i'm fairly certain glibc-2.6 has make check failures as well.
Comment 17 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-02-12 18:14:33 UTC
(In reply to comment #16)
> if you're talking about `make check` in glibc failing, there are many known
> failures.  i suggest you search and see if the issue you're hitting already has
> an open bug.  i'm fairly certain glibc-2.6 has make check failures as well.
> 

Correct, looks like not a regression. amd64 team is expected to mark this stable within 24 hours here.
Comment 18 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-02-13 01:03:50 UTC
3 amd64 devs have looked at this, thanks tanderson & Ken. Looks good for amd64.
Comment 19 Tobias Klausmann (RETIRED) gentoo-dev 2009-02-18 18:01:56 UTC
The glibc test suite is a mess: it always has been failing at least since 2.6 and it's nealry impossible to coax it into actually *printing* which tests failed. So I'll stabilize on alpha since we have tested it on live systems successfully.
Comment 20 Tom Gall (RETIRED) gentoo-dev 2009-02-19 19:49:11 UTC
stable on ppc64
Comment 21 toto 2009-02-20 15:55:00 UTC
Hi all,
After install sys-libs/glibc-2.8_p20080602-r1 USE="gd (multilib) nls -debug -glibc-compat20 -glibc-omitfp (-hardened) -profile (-selinux) -vanilla" i get problem with apache.
in log:
Feb 20 21:51:44 darkside __ratelimit: 118 callbacks suppressed
Feb 20 21:51:44 darkside apache2[10437]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]
Feb 20 21:51:44 darkside apache2[10438]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]
Feb 20 21:51:44 darkside apache2[10439]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]
Feb 20 21:51:44 darkside apache2[10440]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]
Feb 20 21:51:44 darkside apache2[10441]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]
Feb 20 21:51:44 darkside apache2[10442]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]
Feb 20 21:51:44 darkside apache2[10443]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]
Feb 20 21:51:44 darkside apache2[10444]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]
Feb 20 21:51:44 darkside apache2[10445]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]
Feb 20 21:51:44 darkside apache2[10446]: segfault at e8a37dd4 ip 00007fdae877afe7 sp 00007ffff2b20aa0 error 4 in l
ibc-2.8.so[7fdae86f1000+13f000]

Before all was be cool =]

Portage 2.1.6.4 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.8_p20080602-r1, 2.6.27-gentoo-r8 x86_64)
=================================================================
System uname: Linux-2.6.27-gentoo-r8-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4000+-with-glibc2.2.5
Timestamp of tree: Thu, 19 Feb 2009 19:30:16 +0000
app-shells/bash:     3.2_p39
dev-java/java-config: 1.3.7-r1, 2.1.6-r1
dev-lang/python:     2.5.2-r7
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.63
sys-devel/automake:  1.4_p6, 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-march=athlon64 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://mail.darkside.tomsk.ru"
LANG="ru_RU.koi8r"
LC_ALL=""
LDFLAGS="-Wl,-O1"
LINGUAS="en ru"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://mail.darkside.tomsk.ru/gentoo-portage"
USE="3dnow 3dnowext a52 aac amd64 amrnb amrwb apache2 berkdb bundled-adodb bzip2 cli cracklib crypt curl dri dts encode ffmpeg filter flac fortran ftp gd gdbm geoip gif gmp icecast iconv idn imagemagick imlib innodb isdnlog jpeg lame lcms libwww lm_sensors logrotate lzma mad mhash midi ming mmap mmx mmxext motif mp2 mp3 mpeg mudflap multilib musepack mysql mysqli ncurses nls nptl nptlonly ogg openmp pam pcntl pcre perl php png pppd python quicktime readline reflection reiserfs session snmp spell spl sqlite sse sse2 ssl svg sysfs tcpd tiff truetype unicode usb vhosts vorbis x264 xml xorg xvid zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en ru" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Comment 22 SpanKY gentoo-dev 2009-02-20 19:27:47 UTC
file a sep bug report
Comment 23 toto 2009-02-21 07:59:19 UTC
SpanKY <<
sep is 'Somebody Else's Problem' or what ? =]
btw, in error_log I get:
[Sat Feb 21 13:50:37 2009] [notice] child pid 17365 exit signal Segmentation fault (11)
[Sat Feb 21 13:50:37 2009] [notice] child pid 17366 exit signal Segmentation fault (11)
[Sat Feb 21 13:50:37 2009] [notice] child pid 17367 exit signal Segmentation fault (11)
and mod_whatkilledus says:
[Fri Feb 20 21:37:51 2009] pid 1943 mod_whatkilledus sig 11 crash
[Fri Feb 20 21:37:51 2009] pid 1943 mod_whatkilledus no active connection at crash
[Fri Feb 20 21:37:51 2009] pid 1943 mod_whatkilledus no request active at crash
[Fri Feb 20 21:37:51 2009] pid 1943 mod_whatkilledus end of report
[Fri Feb 20 21:37:51 2009] pid 1938 mod_whatkilledus sig 11 crash
[Fri Feb 20 21:37:51 2009] pid 1938 mod_whatkilledus no active connection at crash
[Fri Feb 20 21:37:51 2009] pid 1938 mod_whatkilledus no request active at crash
[Fri Feb 20 21:37:51 2009] pid 1938 mod_whatkilledus end of report
apache works, but log kill me =/
Comment 24 Raúl Porcel (RETIRED) gentoo-dev 2009-02-22 16:30:39 UTC
(In reply to comment #23)
> SpanKY <<
> sep is 'Somebody Else's Problem' or what ? =]

Separate bug
Comment 25 Raúl Porcel (RETIRED) gentoo-dev 2009-03-07 11:10:40 UTC
ia64/sparc stable
Comment 26 Markus Meier gentoo-dev 2009-03-07 11:22:57 UTC
x86 stable
Comment 27 Benny Pedersen 2009-03-09 16:04:01 UTC
glibc have gd use flag, with will get 

euse -i gd ==> [-    ] gd - Adds support for media-libs/gd (to generate graphics on the fly)

use flag collisions ?

Comment 28 Brent Baude (RETIRED) gentoo-dev 2009-03-19 15:02:05 UTC
ppc done
Comment 29 Jeroen Roovers (RETIRED) gentoo-dev 2009-03-27 18:49:18 UTC
sys-libs/glibc-2.8_p20080602-r1 was keyworded ~hppa on 19 Mar 2009 and might go stable in one month.
Comment 30 Jeroen Roovers (RETIRED) gentoo-dev 2009-04-13 15:18:41 UTC
Stable for HPPA but not closing.
Comment 31 Raffaello D. Di Napoli 2009-09-24 00:50:31 UTC
(In reply to comment #27)
> glibc have gd use flag, with will get 
> 
> euse -i gd ==> [-    ] gd - Adds support for media-libs/gd (to generate
> graphics on the fly)
> 
> use flag collisions ?

I noticed this too. In bug 203856 (two years ago) some guy tried to bring this to someone’s attention, but it was rejected with an explanation that, while it’s true, doesn’t explain why in the world glibc would ever depend on a graphics library.