Bug#552233: locales: cannot map archive header: Invalid argument
Package: locales Version: 2.10.1-2 Severity: serious During a regular upgrade from version 2.9.-25 I got the following error: Generating locales (this might take a while)... en_US.UTF-8...cannot map archive header: Invalid argument done Generation complete. I read #524483, but this looks to be a different issue: $ ls -al /usr/lib/locale/locale-archive ls: cannot access /usr/lib/locale/locale-archive: No such file or directory The system is rarely used, and thus infrequently updated, but has a "clean" unstable installation. The file system is mounted rw and has plenty of space. Manually creating the directory does not fix the problem: if I do that and then run 'dpkg-reconfigure locales', the directory gets deleted... -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: sparc (sparc64) Kernel: Linux 2.6.26-1-sparc64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii libc6 [glibc-2.10-1] 2.10.1-2 GNU C Library: Shared libraries locales recommends no packages. locales suggests no packages. -- debconf information: locales/default_environment_locale: en_US.UTF-8 locales/locales_to_be_generated: en_US.UTF-8 UTF-8 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transition hppa from linuxthreads to nptl is ready to proceed.
Carlos O'Donell wrote: > I have tested the following patches with eglibc_2.10.1-0exp1, the > testing has included the standard glibc regression testing, simulation > of partial upgrades, and heavy chroot testing with Xnest, and several > large multithreaded UI applications (evince, xchat, nautilus, > gnome-session etc). All tests succeeded. Congratulations Carlos. Excellent job! Many thanks to you and all others who have worked (and are working) on this. Cheers, FJP -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa nptl switch
Carlos O'Donell wrote: >> In practice it shouldn't be problem at all. >> Debian should make sure that binary/library compiled >> against NPTL-hppa-glibc will require NPTL-hppa-glibc >> by proper Depends: line like "libc6 (>= 2.10)". > > Does every package have to do this? I'm not very familiar with all the > packaging requirements. It is something that should automatically get done correctly as long as the libc-dev package defines the minimum version that way. The mechanism that determines this is in /var/lib/dpkg/info/libc6.shlibs. Currently this has lines like: libc 6 libc6 (>= 2.9) It's virtually certain that the shlibs file will be updated to read '(>= 2.10)' when the glibc maintainers switch to that version. Cheers, FJP -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541725: eglibc: libc6-udeb is empty causing Debian installs to fail
Package: eglibc Version: 2.9-24 Severity: serious Tags: d-i Justification: Breaks Debian Installer In the latest upload the udebs for all architectures are empty. This breaks installations at the partitioning stage and later as symbols cannot be found: md-devices: mdadm: relocation error: mdadm: symbol nftw64, version GLIBC_2.3.3 not defined in file libc.so.6 with link time reference partman: pvscan: relocation error: pvscan: symbol alphasort64, version GLIBC_2.2 not defined in file libc.so.6 with link time reference $ dpkg -c libc6-udeb_2.9-24_i386.udeb drwxr-xr-x root/root 0 2009-08-11 03:20 ./ -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#474293: glibc: Add udeb: lines in shlibs files to improve udeb dependencies
Sorry for the late reply to this Aurelien. On Sunday 11 May 2008, Aurelien Jarno wrote: > I have just checked-in this patch. Thanks. The results are starting to become visible: http://lists.debian.org/debian-release/2008/06/msg00217.html > For the future, I wonder while those too small udeb are separated from > the main udeb. They are really small compared to the main udeb file. 1) The libc from the main udeb gets reduced by a huge amount by stripping unused symbols when it is included in D-I initrds, although the full version gets loaded later. But the library reduction does make comparing the "normal" sizes incorrect. 2) libnss-dns-udeb is currently included in all initrds, so splitting that out is possibly not needed (anymore). 3) But libnss-files-udeb is only included in a small number of initrds and thus splitting it out helps reduce the size of all other initrds. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474293: glibc: Add udeb: lines in shlibs files to improve udeb dependencies
On Saturday 03 May 2008, Clint Adams wrote: > On Fri, Apr 04, 2008 at 09:43:18PM +0200, Frans Pop wrote: > > We are aware the patch is a bit of a hack and the list of libs in the > > helper script will require some maintenance. We have discussed whether > > this could be implemented in debhelper instead, but this solution was > > preferred: > > Seems reasonable as a stopgap. Thanks Clint. Please let me know if there are questions or if I can help with anything. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474293: glibc: Add udeb: lines in shlibs files to improve udeb dependencies
Package: glibc Version: 2.7-10 Severity: wishlist Tags: d-i patch For Etch we fixed debhelper and most library packages that provide udebs to improve the dependencies generated for udebs, but we skipped glibc then as it's less important when the installer is running (as libc is always included in the D-I initrds anyway and thus pulled in at build time). However, it would be great to have this fixed before Lenny as it will help with the implementation of britney support for udebs. The attached patch will add udeb: lines in the various libc packages, for example for libc6: udeb: ld-linux 2 libc6-udeb (>= 2.7-1) udeb: libm 6 libc6-udeb (>= 2.7-1) udeb: libdl 2 libc6-udeb (>= 2.7-1) udeb: libresolv 2 libc6-udeb (>= 2.7-1) udeb: libc 6 libc6-udeb (>= 2.7-1) udeb: libutil 1 libc6-udeb (>= 2.7-1) udeb: libcrypt 1 libc6-udeb (>= 2.7-1) udeb: librt 1 libc6-udeb (>= 2.7-1) udeb: libpthread 0 libc6-udeb (>= 2.7-1) udeb: libnss_dns 2 libnss-dns-udeb (>= 2.7-1) udeb: libnss_files 2 libnss-files-udeb (>= 2.7-1) Applying the patch should be safe and there are no transition issues. Possibly the change should be checked with Release Masters, but IMO it's not a problem to implement this at this stage of the release of Lenny. After glibc has been uploaded with this patch, I plan to request binNMUs for all D-I packages that depend on libc to get their dependencies fixed. Example of the effect of the patch -- fdisk-udeb_2.13.1-3_i386.udeb currently has: Depends: libc6 (>= 2.7-1) when built against glibc with this patch this becomes: Depends: libc6-udeb (>= 2.7-1) Comments We are aware the patch is a bit of a hack and the list of libs in the helper script will require some maintenance. We have discussed whether this could be implemented in debhelper instead, but this solution was preferred: http://lists.debian.org/debian-boot/2008/02/msg00336.html However, if you see alternative solutions, I'd be more than willing to discuss them and help develop/test them. I removed the commented out dh_makeshlibs line in udebs section of debhelper.mk as I felt that to be better than adding a commented out call to the shlibs-add-udebs script. I have only tested the patch on amd64 and i386, but AFAICT it should work for other arches too. The udeb: lines are only added for libc6 and equivalent packages, and *not* for the "crossarch" packages (libc6-amd64, libc-i386, libc6-xen, etc.). AFAICT udebs should not be compiled against those variants, so adding them there seemed redundant. However, I'm not completely sure that is correct and I'd appreciate your opinion on this. Please consider including this patch with your next upload. Cheers, FJP commit e5619fdd8444d5e48d9cdea223f94df43dfa350f Author: Frans Pop <[EMAIL PROTECTED]> Date: Fri Apr 4 10:23:29 2008 +0200 Add udeb lines in shlibs files Currently onther udebs depend on regular libc packages. This will allow then to correctly depend on the libc udeb instead. diff --git a/debian/rules.d/debhelper.mk b/debian/rules.d/debhelper.mk index fe127dd..96cfb98 100644 --- a/debian/rules.d/debhelper.mk +++ b/debian/rules.d/debhelper.mk @@ -109,6 +109,9 @@ endif -o -regex '.*/libc-.*so' \) \ -exec chmod a+x '{}' ';' dh_makeshlibs -X/usr/lib/debug -p$(curpass) -V "$(call xx,shlib_dep)" + # Add relevant udeb: lines in shlibs files + chmod a+x debian/shlibs-add-udebs + ./debian/shlibs-add-udebs $(curpass) if [ -f debian/$(curpass).lintian ] ; then \ install -d -m 755 -o root -g root debian/$(curpass)/usr/share/lintian/overrides/ ; \ @@ -152,7 +155,6 @@ $(patsubst %,$(stamp)binaryinst_%,$(DEB_UDEB_PACKAGES)): $(stamp)debhelper -o -regex '.*lib[0-9]*/.*libpthread.*so.*' \ -o -regex '.*lib[0-9]*/libc[.-].*so.*' \) \ -exec chmod a+x '{}' ';' - # dh_makeshlibs -X/usr/lib/debug -p$(curpass) -V "$(call xx,shlib_dep)" dh_installdeb -p$(curpass) # dh_shlibdeps -p$(curpass) dh_gencontrol -p$(curpass) diff --git a/debian/shlibs-add-udebs b/debian/shlibs-add-udebs new file mode 100755 index 000..651fb8e --- /dev/null +++ b/debian/shlibs-add-udebs @@ -0,0 +1,51 @@ +#! /bin/sh +set -e + +# This script adds "udeb lines" to shlibs files which allows other udebs +# to get correct dependencies when built against glibc libraries. +# The script was written by Frans Pop <[EMAIL PROTECTED]>. + +package="$1" +shlibs_file="debian/$package/DEBIAN/shlibs" + +# Skip packages that don't have an shlibs file. +# The "cross-subarch" library packages have an shlibs file, but should +# not have udeb lines, so skip those as well. +if [ ! -r "$shlibs_file" ] || \ + echo "$package" | grep -Eq "^libc[0-9.]+-"; then + exit 0 +fi + +# $1: regexp to select libra
Bug#474226: glibc: Segfaults in tst-rfc3484 during compilation
On Friday 04 April 2008, Aurelien Jarno wrote: > > During compilation of glibc I noticed two segfaults in my logs (dmesg): > > ld-linux.so.2[4016]: segfault at 4 ip 80499bc sp ffb9c6fc error 4 in > > tst-rfc3484[8048000+6000] ld-linux.so.2[4030]: segfault at 4 ip 8049a8c > > sp fff2b1e4 error 4 in tst-rfc3484-2[8048000+6000] > > > > Is this an issue in glibc or maybe in the kernel? > > Note that I'm running an upstream 2.6.25-rc8 kernel. > > I guess it's a bug in the test, but I am unable to reproduce the problem. I should probably also have mentioned that this is in an i386 chroot on an amd64 box. Same segfault happened during a second compile, so it looks to be reproducible for me. How can I run the test separately? What additional info do you need and how can I get that? Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474226: glibc: Segfaults in tst-rfc3484 during compilation
Package: glibc Version: 2.7-10 Severity: normal During compilation of glibc I noticed two segfaults in my logs (dmesg): ld-linux.so.2[4016]: segfault at 4 ip 80499bc sp ffb9c6fc error 4 in tst-rfc3484[8048000+6000] ld-linux.so.2[4030]: segfault at 4 ip 8049a8c sp fff2b1e4 error 4 in tst-rfc3484-2[8048000+6000] Is this an issue in glibc or maybe in the kernel? Note that I'm running an upstream 2.6.25-rc8 kernel. Cheers, FJP -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-rc8 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470753: glibc: Should use debconf to prompt for upgrades
# Correcting version info notfound 470753 2.7.6 found 470753 2.7-6 thanks On Thursday 13 March 2008, you wrote: > That's already fixed in version 2.7-9. Closing the bug. Sorry about that. I missed it in the changelog and we really only see this in testing. Thanks for making the change! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464924: glibc: errors during build: object 'libfakeroot-sysv.so' [...] cannot be preloaded
On Saturday 09 February 2008, you wrote: > > Should glibc build depend on fakeroot, or is this completely harmless > > and should it just be ignored? > > This is harmless. I don't know what the locale generation is doing that > breaks the preloading, but it doesn't need to be run under fakeroot > anyway. As I say, I'm just using pbuilder (debuild), and that in its default configuration where it comes to what commands it uses to gain root during the build process: #for pbuilder debuild BUILDSOURCEROOTCMD="fakeroot" PBUILDERROOTCMD="sudo" If you (plural) don't feel this is an environment where building glibc should be possible without these errors, that's fine by me. I just noticed the errors while investigating a possible change for the packaging of the udebs. Thx for the quick replies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#464924: glibc: errors during build: object 'libfakeroot-sysv.so' [...] cannot be preloaded
Package: glibc Version: 2.7-6 Severity: normal While building glibc with pbuilder, I noticed the following errors: make[3]: Entering directory `/tmp/buildd/glibc-2.7/build-tree/glibc-2.7/localedata' ..././scripts/mkinstalldirs /tmp/buildd/glibc-2.7/debian/tmp-libc/usr/lib/locale mkdir /tmp/buildd/glibc-2.7/debian/tmp-libc/usr/lib/locale aa_DJ.UTF-8...ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. done aa_DJ.ISO-8859-1...ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. done aa_ER.UTF-8...ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. done [repeats for loads of locales] Should glibc build depend on fakeroot, or is this completely harmless and should it just be ignored? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438449: tzdata: Failed to preconfigure
Package: tzdata Version: 2007f-11 Severity: important I doubt that this error I got during upgrade just now is intended: Preconfiguring packages ... tzdata failed to preconfigure, with exit status 10 Preparing to replace tzdata 2007f-10 (using .../tzdata_2007f-11_all.deb) ... Unpacking replacement tzdata ... Setting up tzdata (2007f-11) ... Upgrade did not fail because of the error. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-rc3 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.14 Debian configuration management sy tzdata recommends no packages. -- debconf information: tzdata/Zones/Australia: tzdata/Zones/Asia: tzdata/Zones/SystemV: tzdata/Zones/Pacific: tzdata/Zones/Atlantic: tzdata/Zones/Canada: tzdata/Zones/US: tzdata/Zones/Etc: tzdata/Zones/Arctic: tzdata/Zones/Antarctica: * tzdata/Zones/Europe: Amsterdam tzdata/Zones/Africa: tzdata/Zones/America: * tzdata/Areas: Europe tzdata/Zones/Indian: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#424057: libc6: internal error: symidx out of range of fptr table
Package: libc6 Version: 2.5-7 Severity: important Today I saw this error for the second time on my hppa box running the 2.6.18-parisc64-smp kernel: cat: error while loading shared libraries: internal error: symidx out of range of fptr table People on #parisc say that this is a glibc issue: fjp, I have not looked at the current sources in debian glibc, but in general there *are* functions which are supposed to be atomic but are not. These failures can cause a "symidx out of rang of fptr table" error. fjp, The failure is in glibc. fjp, It's using non-atomic implementation of compare and swap. However, the problem is systemic of a kernel that doesn't have atomic helper functions. I'm running 2.6.18-4-parisc64-smp fjp, smp is more likely to trigger the error. fjp, You have the atomic helper routines present in your kernel. fjp, The glibc you have just isn't using them. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 2.6.18-4-parisc64-smp (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash pgpzwYHMTiQdQ.pgp Description: PGP signature
Bug#409516: libc6: error in dpkg --compare-versions call
Looks like it is indeed the postinst. This has: if [ "$type" = "configure" ] then [...] # Add support for /etc/ld.so.conf.d if dpkg --compare-versions $preversion lt 2.3.6-16; then Which is probably not correct on initial installation. pgpzPbSLfDeLB.pgp Description: PGP signature
Bug#409516: libc6: error in dpkg --compare-versions call
Package: libc6 Version: 2.3.6.ds1-10 During a new installation using D-I/debootstrap of testing I noticed the following error in the syslog. It looks like dpkg --compare-versions is not called correctly, possibly because this is an initial installation and not an upgrade. I suspect the error to be in the postinst. Cheers, FJP [...] Setting up dpkg (1.13.25) ... Selecting previously deselected package libc6. (Reading database ... 304 files and directories currently installed.) Unpacking libc6 (from .../libc6_2.3.6.ds1-10_i386.deb) ... Setting up libc6 (2.3.6.ds1-10) ... dpkg: libc6: dependency problems, but configuring anyway as you request: libc6 depends on tzdata; however: Package tzdata is not installed. dpkg: --compare-versions takes three arguments: Type dpkg --help for help about installing and deinstalling packages [*]; Use `dselect' or `aptitude' for user-friendly package management; Type dpkg -Dhelp for a list of dpkg debug flag values; Type dpkg --force-help for a list of forcing options; Type dpkg-deb --help for help about manipulating *.deb files; Type dpkg --license for copyright license and lack of warranty(GNU GPL) [*]. Options marked [*] produce a lot of output - pipe it through `less' or `more' ! Selecting previously deselected package perl-base. [...] pgpPqTlFIeveG.pgp Description: PGP signature
Bug#391529: #391529 Etch installer freezed by tzdata
>Ok, fine that you found it. However, in the meantime, I managed to > setup a basic infrastructure to let me test the latest netinst image > (http://cdimage.debian.org/cdimage/daily-builds/daily/20061008/i386/iso >-cd/debian-testing-i386-netinst.iso with md5sum > f256549427efa2782f0253fc29553caf). The problem won't show up with a daily image. You need a Beta 3 netinst or full CD image to reproduce this. Reason is that daily and other images will already install the latest version of tzdata during debootstrap (base-installer) and so there won't be an upgrade during tasksel (pkgsel). Also, current d-i images have a fix for this issue in that they "configure" tzdata before pkgsel is run, thereby avoiding the question. In beta 3 this happened only at the very end of the installation. Cheers, FJP pgpFFt60xkXbA.pgp Description: PGP signature
Re: Bug#391529: Etch installer freezed by tzdata
reassign 391529 tzdata severity 391529 serious thanks On Sunday 08 October 2006 14:58, Frans Pop wrote: > > I'm trying to install etch beta3 in a server, when the installation > > pass the partitioning process and begin to install & configure the > > base system it was frozen by the configuration of package tzdata... > > Finding a bug... y encountered that the package early come to etch in > > [2006-10-03] tzdata 2006l-1 MIGRATED Aurelien Jarno traced this problem to tzdata asking a non-debconf question on upgrade. This happens because the package installed during base installation (from CD) is upgraded during pkgsel/tasksel (from the mirrors). Note that a change has been committed in D-I component tzsetup (1:0.11) that may prevent this is the future: we now configure the timezone immediately after base installation instead of at the end of the installation. This means it is probably only a temporary problem that will affect some Beta3-based installations (though the most used ones) until the release of D-I RC1. pgpZ8VVO1MICk.pgp Description: PGP signature
Bug#381881: mkfs.xfs: error loading librt.so
reassign 381881 xfsprogs-udeb 2.8.10-1 retitle 381881 Please link librt statically for the udeb (mkfs.xfs) thanks On Tuesday 08 August 2006 19:07, Joey Hess wrote: > Frans Pop wrote: > > On Monday 07 August 2006 17:31, Ionut Georgescu wrote: > > > mkfs.xfs failed with error loading shared library librt.so. Used > > > JFS insted of XFS in the end. > > > > librt is currently not included in the libc6 udeb, but seems to be > > needed to create xfs filesystems. Please add it. > > Could the xfs udeb be statically linked to it? It's 30k that only one > tool (which isn't there in lowmem) needs.. Yes, that is probably better. Reassigning to xfsprogs. Nathan, With your latest upload, mkfs.xfs seems to have gained a dependency on two libraries which it previously was not linked to: $ ldd mkfs.xfs # from testing libuuid.so.1 => /lib/libuuid.so.1 (0x40028000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x4002b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) $ ldd mkfs.xfs # from unstable libuuid.so.1 => /lib/libuuid.so.1 (0x40028000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x4002b000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40033000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x40168000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) libpthread is available in the installer, but librt currently is not and we'd prefer not having to add it. Is it possible for you to link in librt statically for the udeb? Note that if it is not, we will have to keep xfsprogs out of testing until the next release of the installer as otherwise it would break the upcoming Beta 3 release. Thanks, FJP pgpS7g2qzQYgI.pgp Description: PGP signature
Re: Bug#381881: mkfs.xfs: error loading librt.so
reassign 381881 libc6-udeb version 381881 2.3.6-18 retitle 381881 Please add librt to the udeb (needed by mkfs.xfs) severity 381881 important tags 381881 + d-i thanks On Monday 07 August 2006 17:31, Ionut Georgescu wrote: > mkfs.xfs failed with error loading shared library librt.so. Used JFS > insted of XFS in the end. librt is currently not included in the libc6 udeb, but seems to be needed to create xfs filesystems. Please add it. pgpJFn1xj25DC.pgp Description: PGP signature
Bug#362460: glibc: typo in changelog may cause confision
Package: glibc Version: 2.3.6-6 Severity: minor The changelog for this version contains: [ Aurelien Jarno ] * Remove the timezone database from the libc6 package. It is not provided by a separate package called tzdata. I suspect this should read "It is no_w_ provided ..." and suggest to correct that with the next upload as this typo may lead to confusion. pgpprG0jbsQjH.pgp Description: PGP signature
Bug#355916: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Package: locales Version: 2.3.6-3 Severity: normal During an upgrade of locales (S/390, together with quite a few other packages) I noticed the following error: Setting up locales (2.3.6-3) ... Generating locales (this might take a while)... en_US.ISO-8859-1... done en_US.UTF-8.../usr/sbin/locale-gen: line 53: 3273 Killed localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale done Generation complete. On console I had the following lines from the upgrade: INIT: version 2.86 reloading __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) VM: killing process localedef I did a dpkg-reconfigure after that and then the locales generation finished without problems. Not sure if this is a problem in locales, but I thought I'd better report it anyway. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: s390 Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-s390 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages locales depends on: ii debconf [debconf-2.0] 1.4.71 Debian configuration management sy ii libc6 [glibc-2.3.6-2] 2.3.6-3GNU C Library: Shared libraries an locales recommends no packages. -- debconf information: * locales/locales_to_be_generated: en_US ISO-8859-1, en_US.UTF-8 UTF-8 * locales/default_environment_locale: None -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#258956: Processed: Re: Bug#258956: Starting sshd fails because of missing libutil.s0.1
On Wednesday 14 July 2004 19:26, GOTO Masanori wrote: > > debian/tmp-libc/lib/libutil* lib > > It will be in 2.3.2.ds1-14. > Please also add libcrypt as explained in the follow-ups [1] to this report! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=258956
Bug#258956: Processed: Re: Bug#258956: Starting sshd fails because of missing libutil.s0.1
On Wednesday 14 July 2004 19:26, GOTO Masanori wrote: > > debian/tmp-libc/lib/libutil* lib > > It will be in 2.3.2.ds1-14. > Please also add libcrypt as explained in the follow-ups [1] to this report! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=258956 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#243237: Removing tag 'sid'
tags 243237 - sid thanks Removing tag 'sid' as I'm not sure the problem is limited to unstable; it might also affect Sarge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]