Bug#1070872: libm.a lost fmod + fmodf on i386 + m68k
Package: libc6-dev Version: 2.38-7 Severity: serious Tags: ftbfs Control: affects -1 src:zsh https://buildd.debian.org/status/logs.php?pkg=zsh=5.9-6%2Bb1 ... gcc -static -o zsh main.o `cat stamp-modobjs` -lpcre2-8 -lgdbm -lcap -lncursesw -ltinfo -ltinfo -lrt -lm -lc ... ./obj-static/Src/../../Src/math.c:1260:(.text+0x1d8e): undefined reference to `fmod' collect2: error: ld returned 1 exit status make[3]: *** [Makefile:228: zsh] Error 1 $ objdump -t /usr/lib/i386-linux-gnu/libm.a | grep fmod w_fmodl_compat.o: file format elf32-i386 w_fmod_compat.o: file format elf32-i386 w_fmodf_compat.o: file format elf32-i386 e_fmodl.o: file format elf32-i386 g F .text 0013 __ieee754_fmodl w_fmodl.o: file format elf32-i386 g F .text 0085 __fmodl *UND* __ieee754_fmodl wF .text 0085 fmodf64x wF .text 0085 fmodl e_fmod.o: file format elf32-i386 g F .text 0013 __ieee754_fmod w_fmod.o: file format elf32-i386 e_fmodf.o: file format elf32-i386 g F .text 0013 __ieee754_fmodf w_fmodf.o: file format elf32-i386 e_fmodf128.o: file format elf32-i386 g F .text 0c9b __ieee754_fmodf128 *UND* __ieee754_fmodf128 *UND* __ieee754_fmodf128 w_fmodf128.o: file format elf32-i386 g F .text 0237 __fmodf128 *UND* __ieee754_fmodf128 wF .text 0237 fmodf128 $ With 2.37-13 this is instead: $ objdump -t /usr/lib/i386-linux-gnu/libm.a | grep fmod w_fmodl_compat.o: file format elf32-i386 w_fmod_compat.o: file format elf32-i386 w_fmodf_compat.o: file format elf32-i386 e_fmodl.o: file format elf32-i386 g F .text 0013 __ieee754_fmodl w_fmodl.o: file format elf32-i386 g F .text 0085 __fmodl *UND* __ieee754_fmodl wF .text 0085 fmodf64x wF .text 0085 fmodl e_fmod.o: file format elf32-i386 g F .text 0013 __ieee754_fmod w_fmod.o: file format elf32-i386 g F .text 006b __fmod *UND* __ieee754_fmod wF .text 006b fmodf32x wF .text 006b fmodf64 wF .text 006b fmod e_fmodf.o: file format elf32-i386 g F .text 0013 __ieee754_fmodf w_fmodf.o: file format elf32-i386 g F .text 0063 __fmodf *UND* __ieee754_fmodf wF .text 0063 fmodf32 wF .text 0063 fmodf e_fmodf128.o: file format elf32-i386 g F .text 0cc5 __ieee754_fmodf128 *UND* __ieee754_fmodf128 *UND* __ieee754_fmodf128 w_fmodf128.o: file format elf32-i386 g F .text 0237 __fmodf128 *UND* __ieee754_fmodf128 wF .text 0237 fmodf128 $
Re: Please give me write access to glibc -security branches
On Mon, May 06, 2024 at 09:22:09PM +0200, Aurelien Jarno wrote: > Hi Adrian, Hi Aurelien, > On 2024-05-06 00:15, Adrian Bunk wrote: > > Hi, > > > > please give me write access to glibc -security branches for pushing > > (E)LTS updates there. > > TTBOMK there is no such things like giving access to some branches only, > so you should no have access to the glibc repository on salsa. Please > use it with care. thanks a lot! > Regards > Aurelien cu Adrian
[Git][glibc-team/glibc] Pushed new tag debian/2.19-18+deb8u13
Adrian Bunk pushed new tag debian/2.19-18+deb8u13 at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/debian/2.19-18+deb8u13 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc][jessie-security] ELA 2.19-18+deb8u13
Adrian Bunk pushed to branch jessie-security at GNU Libc Maintainers / glibc Commits: ab1c6c17 by Adrian Bunk at 2024-05-09T00:20:00+03:00 ELA 2.19-18+deb8u13 - - - - - 6 changed files: - debian/changelog - + debian/patches/all/git-0001-support-Add-TEST_COMPARE-macro.patch - + debian/patches/all/git-0002-Add-support-xm-un-map.c.patch - + debian/patches/all/git-0003-Add-support-xmprotect.c.patch - + debian/patches/all/git-0004-iconv-ISO-2022-CN-EXT-fix-out-of-bound-writes-when-w.patch - debian/patches/series View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/ab1c6c171f27189e5bc18aeb3eb634f4ae42bd50 -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/ab1c6c171f27189e5bc18aeb3eb634f4ae42bd50 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc] Pushed new tag debian/2.24-11+deb9u6
Adrian Bunk pushed new tag debian/2.24-11+deb9u6 at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/debian/2.24-11+deb9u6 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc][stretch-security] ELA 2.24-11+deb9u6
Adrian Bunk pushed to branch stretch-security at GNU Libc Maintainers / glibc Commits: abf65d55 by Adrian Bunk at 2024-05-09T00:06:43+03:00 ELA 2.24-11+deb9u6 - - - - - 8 changed files: - debian/changelog - + debian/patches/all/git-0001-support-Add-TEST_COMPARE-macro.patch - + debian/patches/all/git-0002-support-tst-test_compare-Fix-32-bit-64-bit-expected-.patch - + debian/patches/all/git-0003-Add-support-xmprotect.c.patch - + debian/patches/all/git-0004-iconv-ISO-2022-CN-EXT-fix-out-of-bound-writes-when-w.patch - debian/patches/series - debian/rules.d/build.mk - debian/testsuite-xfail-debian.mk View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/abf65d55189671bea1bb5da25b567b1b2bf446c3 -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/abf65d55189671bea1bb5da25b567b1b2bf446c3 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc] Pushed new tag debian/2.28-10+deb10u3
Adrian Bunk pushed new tag debian/2.28-10+deb10u3 at GNU Libc Maintainers / glibc -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/tree/debian/2.28-10+deb10u3 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/glibc][buster-security] DLA 2.28-10+deb10u3
Adrian Bunk pushed to branch buster-security at GNU Libc Maintainers / glibc Commits: aba33524 by Adrian Bunk at 2024-05-06T00:06:16+03:00 DLA 2.28-10+deb10u3 - - - - - 6 changed files: - debian/changelog - + debian/patches/all/git-0001-iconv-ISO-2022-CN-EXT-fix-out-of-bound-writes-when-w.patch - + debian/patches/all/git-0002-misc-test-errno-linux-Handle-EINVAL-from-quotactl.patch - debian/patches/series - debian/rules.d/build.mk - debian/testsuite-xfail-debian.mk View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/aba335243d379d43b54e5a41aab6c5989be846ae -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/-/commit/aba335243d379d43b54e5a41aab6c5989be846ae You're receiving this email because of your account on salsa.debian.org.
Bug#1070490: libc6: Unpacking libc6:amd64 2.28-10+deb10u3 over 2.28-10+deb10u2 breaks system
On Mon, May 06, 2024 at 05:37:37PM +0100, Adam D. Barratt wrote: > On Mon, 2024-05-06 at 13:02 +0200, Jan Krčmář wrote: > > Package: libc6 > > Version: 2.28-10+deb10u3 > > > > Upgrading the system (Debian 10/Buster) causes corrupted system, > > ending with kernel panic and unbootable system. > > > [...] > > The following packages will be upgraded: > > apt apt-transport-https apt-utils base-files ca-certificates > > The fact that APT is being upgraded here seems strange - APT hasn't > changed in buster for 3 years. What's your base system? There's also > > Unpacking base-files (10.3+deb10u13) over (10.3+deb10u5) ... That's outdated since September 2020. > > Unpacking libc6:amd64 (2.28-10+deb10u3) over (2.28-10+deb10u2) ... > > Replaced by files in installed package libcrypt1:amd64 (1:4.4.18-4) > > ... > > This, on the other hand, looks like you've done something odd to your > system. libcrypt1 doesn't exist until bullseye, so at some point you > have partially upgraded your base system. In conjunction with your pre- > upgrade system apparently having an APT version that's /older/ than the > one in buster, this feels odd. There is related nastiness with partial upgrades from buster to bullseye, see the last two items at [1]. I am not sure whether it is the root cause here, but it's at least plausible that not being able to have the Breaks in libcrypt1 causes problems for such partially upgraded systems. > Regards, > > Adam cu Adrian [1] https://tracker.debian.org/news/1239066/accepted-libxcrypt-14418-3-source-into-unstable/
Please give me write access to glibc -security branches
Hi, please give me write access to glibc -security branches for pushing (E)LTS updates there. Thanks in advance Adrian
Re: Bug#994091: nmu: aide_0.17.3-4
On Sat, Sep 11, 2021 at 03:59:12PM +0200, Marc Haber wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > [this is my first binNMU request, I hope that I did everything right] [ I am not a member of the release team ] > aide is statically linked. With the new glibc, NSS calls get somehow > still some dynamic linking, which causes a reproducible and > unconditional segfault one aide uses an NSS-releated call. A rebuild > fixes this issue. I am currently discussing this issue with upstream to > find out whether we can do things a bit better in the future. AFAIR static glibc linking and NSS is known problematic. > Greetings > Marc > > > nmu aide_0.17.3-4 . ANY . unstable . -m "Rebuild against the new glibc" The dependencies should ensure that apt/dpkg only install a working set of packages. Dependencies like "libc6 (>> 2.32), libc6 (<< 2.33)" might help, but I've added debian-glibc to Cc since I don't know for sure whether this would be sufficient. cu Adrian
Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
On Mon, May 11, 2020 at 08:31:37AM +0200, Mathieu Malaterre wrote: > On Sun, May 10, 2020 at 10:01 PM Paul Gevers wrote: >... > > On 10-05-2020 15:25, Paul Gevers wrote: > > > I'm running another check on "cannot allocate memory in static TLS > > > block" now, will take a while. > > > > Also for this one, only vtkplotter showed up. > > Did you check #951704 ? This affect python3 package using jemalloc. I wrote earlier: On Thu, May 07, 2020 at 01:16:15PM +0300, Adrian Bunk wrote: >... > #951704 looks like a similar but unrelated problem with jemalloc. >... My current knowledge is: The jemalloc problem is a problem affecting all architectures, that will likely need a fix/workaround in jemalloc. The libgomp problem is a problem only on arm64/ppc64/ppc64el where upstreams seem to finally have agreed where it should be fixed (glibc). cu Adrian
Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote: >... > On 07-05-2020 10:07, Adrian Bunk wrote: > > This is a toolchain problem affecting many packages: > > https://sourceware.org/bugzilla/show_bug.cgi?id=25051 > > Do you have any rough estimate how many? >... Other bugs I can quickly find are #930039 and #945878. AFAIR I have seen maintainers adding workarounds for arm64+ppc64el FTBFS caused by this bug that did not have bugs in the BTS. #951704 looks like a similar but unrelated problem with jemalloc. > Is there any way to predict which packages are effected, Anything loading a plugin that is directly or indirectly linked with libgomp might or might not have this problem. Python C extensions are the most frequent ones. Heavy usage of Python code with C extensions tends to be in the more scientific areas of the archive, I'd guess many of these packages have no users at all on ppc64el or arm64 who would report bugs (Raspbian is armhf). python3-vtkplotter -> python3-vtk7 -> libvtk -> FFmpeg libraries -> libsoxr -> libgomp > or to detect which packages are effected? "import vtk" works, but "import vtkplotter" blows up when importing vtk. This is similar to the two different OpenSSL versions in stretch, where module load order might determine whether Apache segfaults or starts. >... > > Is there a non-manual way to express that the autopkgtest must not run > > on arm64 and powerpc64el? > > There is currently not even a manual way except for marking the test as > skippable and exitting with error code 77 on unsupported architectures. > Mind you, I don't think toolchain issues should be marked at the package > level (but maybe you didn't mean that). vtkplotter: flagged for removal in 6.3 days The big hammer would be to remove the autopkgtest... > If we can detect this failure > mode (and similar ones in the future) we can of course generate hints > based on this heuristics and have the failures ignored until the > toolchain issues are fixed. A failing arm64 or ppc64el autopkgtest log containing the string "libgomp.so.1: cannot allocate memory in static TLS block" is this bug. > Paul cu Adrian
Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
On Fri, Mar 06, 2020 at 10:57:20AM +0100, Paul Gevers wrote: >... > However, it fails on arm64. I copied some of the output at the bottom of > this report. > > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the situation and fix it? >... > https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtkplotter/4281870/log.gz > > autopkgtest [12:57:24]: test python3: [--- > Processing test_actors.py script.. > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/vtk/vtkIOFFMPEG.py", line 5, in > > from .vtkIOFFMPEGPython import * > ImportError: /lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory > in static TLS block >... This is a toolchain problem affecting many packages: https://sourceware.org/bugzilla/show_bug.cgi?id=25051 There is nothing a binary-all python module can do to fix architecture-specific toolchain bugs. Is there a non-manual way to express that the autopkgtest must not run on arm64 and powerpc64el? cu Adrian
Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1
On Wed, May 06, 2020 at 01:56:24PM +0100, Steve McIntyre wrote:
>...
> On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote:
> >
> >One solution for this would be to ship the optimized library in the same
> >package as the default library. Now this is not acceptable for embedded
> >systems as they might not need that library and can't remove it. This is
> >even more problematic if we need to add more optimized libraries. I guess
> >this might be the case for arm64 as there are many new extensions in the
> >pipe.
>
> ACK. It's a problem to ship the different things in separate
> packages. If it's really a problem for smaller systems to have all the
> variants because of size, is there maybe another way to do things? How
> about keeping the existing libc and have an extra package
> ("libc-optimised") with all the optimised versions *and* the basic
> version, and have it provide/replace/conflict libc6?
>...
What Noah mentioned for a similar proposal also applies here:
On Mon, May 04, 2020 at 02:45:41PM -0400, Noah Meyerhans wrote:
>...
> I don't know how well dpkg would cope with transitioning
> between providers, which seems like the riskiest side of this kind of
> thing.
I'd guess you could make this an installation-only change with
a few hacks here and there, but once you think that through
with all the followup-hacks required it doesn't sound like
a good idea.
cu
Adrian
Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1
On Mon, May 04, 2020 at 02:45:41PM -0400, Noah Meyerhans wrote: >... > I wonder if it'd make sense for libc to be a virtual package, with > functionality provided by optimized builds and dependencies satisfied > via Provides. I don't know how well dpkg would cope with transitioning > between providers, which seems like the riskiest side of this kind of > thing. What would happens if apt finds a dependency solution when installing or updating packages that involves switching to a libc package that does not run on your device? There are situations where changing the libc package would be the only possible solution of the dependencies. IMHO there are far too many ways how such a virtual package solution could brick devices. > noah cu Adrian
Re: Options for 64-bit time_t support on 32-bit architectures
On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote: > * Adrian Bunk: >... > For comparison, the original plan was to provide a macro, perhaps > -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI > set is used (“dual ABI”). To me this would sound like more trouble than a clear break, similar to the mostly working dual OpenSSL 1.0 and 1.1 support in stretch. "Mostly working" as in Apache segfaulting depending on the load order of its modules - it is really hard to get all special cases like plugins sorted out correctly in such setups. > Similar to the LFS support, with the > additional property that binaries built in either mode should continue > to work on kernels which predate support for the *_time64 system > calls. Debian does not support running on kernels older than the one in the previous stable release. E.g. Qt in Debian 9 unconditionally uses the getrandom syscall that is not in kernel 3.16 in Debian 7. >... > > For i386 the last newly released 32bit-only hardware were some early > > Intel Atoms 10 years ago, and when the AMD Geode goes out of production > > soon there might be no hardware in production left. > > There are still surprisingly many people using Debian on 32bit-only > > hardware, but in 20 years this will have changed. > > You have thankfully edited out the Intel Quark. 8-) >... Support for the Intel Quark was dropped when the i386 baseline was raised from 586 to 686 in stretch, so that's already irrelevant for the Debian i386 port. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Options for 64-bit time_t support on 32-bit architectures
[ only speaking for myself ] On Thu, Jul 18, 2019 at 11:05:53PM +0200, Florian Weimer wrote: >... > The consequence is that in order to build 32-bit-time_t libraries > (Gtk, for example), an old glibc needs to be kept around. In > practice, it would probably mean that it is impossible to maintain a > set of 32-bit-time_t libraries in a classic distribution build > environment (with a unified buildroot and native builds). >... > Do you want to build 32-bit libraries (besides glibc) which are > compatible with legacy applications, with a 32-bit time_t, in the > future? Or is a world where time_t is pretty much always 64 bit > something that would be acceptable? So this is an ABI-incompatible change that would result in new Debian architectures, similar to arm (OABI), armel (EABI softfp) and armhf (EABI hardfp) being different Debian architectures for 32bit little endian ARM? There are two current release architectures where it is at least imaginable that they will still be around closer to the year 2038: i386 and armhf For i386 the last newly released 32bit-only hardware were some early Intel Atoms 10 years ago, and when the AMD Geode goes out of production soon there might be no hardware in production left. There are still surprisingly many people using Debian on 32bit-only hardware, but in 20 years this will have changed. Remaining usecases of i386 will be old binaries, some old Linux binaries but especially old software (including many games) running in Wine. Old Linux binaries will still need the old 32bit time_t. Which options are viable from a Wine point of view? For armhf new hardware might be available long enough to come close to the year 2038, this might require a new architecture at some point. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#918583: libc6: version in nocache Breaks is incorrect
Package: libc6 Version: 2.28-4 Severity: serious Breaks: ..., nocache (<< 1.0-1),... 1.0-1 is the version in stable, so this is basically a nop. It should be Breaks: nocache (<< 1.1-1~)
Bug#915321: Mutex creation failed
Control: unmerge -1 915339 Control: reassign -1 r-cran-later 0.7.4+dfsg-1 Control: retitle -1 r-cran-later: Mutex creation failed with glibc 2.28 Control: forwarded -1 https://github.com/r-lib/later/issues/77 Control: block 915339 by -1 Control: retitle 915339 libc6 needs Conflicts with unfixed r-cran-later On Sun, Dec 02, 2018 at 09:11:06PM +0200, Theodore Lytras wrote: > Package: libc6 > Version: 2.28-1 > Severity: critical > > Just after updating libc6 from 2.27-8 to 2.28-1 in Debian Unstable, loading > package "httpuv" in R leads to a crash: > >bones@equinox2:~$ R > >R version 3.5.1 (2018-07-02) -- "Feather Spray" >Copyright (C) 2018 The R Foundation for Statistical Computing >Platform: x86_64-pc-linux-gnu (64-bit) > >R is free software and comes with ABSOLUTELY NO WARRANTY. >You are welcome to redistribute it under certain conditions. >Type 'license()' or 'licence()' for distribution details. > >R is a collaborative project with many contributors. >Type 'contributors()' for more information and >'citation()' on how to cite R or R packages in publications. > >Type 'demo()' for some demos, 'help()' for on-line help, or >'help.start()' for an HTML browser interface to help. >Type 'q()' to quit R. > >> library(httpuv) >terminate called after throwing an instance of 'std::runtime_error' > what(): Mutex creation failed >Ακυρώθηκε >bones@equinox2:~$ > > From the message I understand this is directly related to libc6 and not R or > httpuv. > Also, there was no update to R or httpuv done recently. The problem started > just as I updated libc6. >... This seems to be a bug in r-cran-later, I'm reassigning this bug there and leave another bug here for adding a Conflicts with the unfixed r-cran-later afterwards. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#889050: dateutils FTBFS with tzdata >= 2018b-1
Source: dateutils Version: 0.4.1-2 Severity: serious https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dateutils.html ... FAIL: dzone.007 === $ dzone --next Asia/Singapore 2014-02-22 --- "expected output 5c83cb99" 2019-03-06 07:12:58.247403471 -1200 +++ "actual output 5c83cb99" 2019-03-06 07:12:58.247403471 -1200 @@ -1 +1 @@ -never -> never Asia/Singapore +never -> 1901-12-15T37:42:47+08:00 Asia/Singapore $? 1 FAIL dzone.007.clit (exit status: 1) Testsuite summary for dateutils 0.4.1 # TOTAL: 808 # PASS: 807 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See test/test-suite.log Please report to https://github.com/hroptatyr/dateutils/issues Makefile:1160: recipe for target 'test-suite.log' failed make[6]: *** [test-suite.log] Error 1
Bug#873097: glibc: FTBFS on *all* architectures except m68k, powerpcspe, sh4
On Thu, Aug 24, 2017 at 04:48:55PM +0200, Thorsten Glaser wrote: > Source: glibc > Version: 2.24-16 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > cf. https://buildd.debian.org/status/package.php?p=glibc > > For over three days now, src:glibc is FTBFS’ing virtually everywhere: > > amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, > s390x, alpha, hppa, hurd-i386, kfreebsd-amd64, kfreebsd-i386, powerpc, > ppc64, sparc64, x32 — the list is so long it doesn’t fit into the > bugreport’s Subject. That's due to the #872846 change. > ... which is probably why the > three slow architectures have been spared. These are buildds that are building with nocheck. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#845523: dar: FTBFS: undefined reference to `__memcpy_chk'
reassign 845521 libc6-dev 2.24-6 reassign 845523 libc6-dev 2.24-6 forcemerge 845521 845523 retitle 845521 libc6-dev: static linking with stack protector fails: undefined reference to `__memcpy_chk' affects 845521 src:dar src:aide thanks On Thu, Nov 24, 2016 at 09:54:34AM +0100, Chris Lamb wrote: > Source: dar > Version: 2.5.7-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Dear Maintainer, > > dar fails to build from source in unstable/amd64: > > […] > > /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 > -fdebug-prefix-map=«BUILDDIR»=. -fstack-protector-strong -Wformat > -Werror=format-security -Wl,-z,relro -o dar_split dar_split.o > ../libdar/libdar64.la -L/usr/lib/x86_64-linux-gnu -lgpgme -lassuan > -lgpg-error -lpthread -lattr -lgcrypt -lgpg-error -llzo2 -lbz2 -lz -ldl > libtool: link: gcc -g -O2 -fdebug-prefix-map=«BUILDDIR»=. > -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -o > .libs/dar_split dar_split.o ../libdar/.libs/libdar64.so > -L/usr/lib/x86_64-linux-gnu -lgpgme -lassuan -lpthread -lattr -lgcrypt > /usr/lib/x86_64-linux-gnu/libgpg-error.so -llzo2 -lbz2 -lz -ldl > /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O2 > -fdebug-prefix-map=«BUILDDIR»=. -fstack-protector-strong -Wformat > -Werror=format-security -all-static -Wl,-z,relro -o dar_static > command_line.o config_file.o dar.o dar_suite.o hide_file.o no_comment.o > shell_interaction.o line_tools.o crit_action_cmd_line.o ../libdar/libdar64.la > -L/usr/lib/x86_64-linux-gnu -lgpgme -lassuan -lgpg-error -lpthread -lattr > -lgcrypt -lgpg-error -llzo2 -lbz2 -lz -ldl > libtool: link: g++ -g -O2 -fdebug-prefix-map=«BUILDDIR»=. > -fstack-protector-strong -Wformat -Werror=format-security -static -Wl,-z > -Wl,relro -o dar_static command_line.o config_file.o dar.o dar_suite.o > hide_file.o no_comment.o shell_interaction.o line_tools.o > crit_action_cmd_line.o ../libdar/.libs/libdar64.a > -L/usr/lib/x86_64-linux-gnu -lgpgme -lassuan -lpthread -lattr -lgcrypt > /usr/lib/x86_64-linux-gnu/libgpg-error.a -llzo2 -lbz2 -lz -ldl > /usr/lib/x86_64-linux-gnu/libgcrypt.a(cipher-ocb.o): In function > `compute_tag_if_needed.part.0': > (.text+0x196): undefined reference to `__memcpy_chk' >... Thanks for your report. This seems to be a problem in the latest glibc, reassigning. > Regards, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#844315: tzdata version breaks dist-upgrade leaving version from oldstable security installed
On Mon, Nov 14, 2016 at 12:54:27PM +0100, Marcel Meckel wrote: > Package: tzdata > Version: 2016i-0+deb7u1 > Severity: critical > > Upgrading a fully updated wheezy system (incl. security repo) to > jessie (incl. security repo) results in tzdata not being updated > because the version in wheezy-security is newer than in jessie. > > Package tzdata on amd64 > > wheezy: 2016d-0+deb7u1 > wheezy-security: 2016i-0+deb7u1 > > jessie: 2016f-0+deb8u1 > jessie-updates: 2016i-0+deb8u1 > jessie-proposed-updates: 2016i-0+deb8u1 > > Using only the main repo + security repo results in tzdata not being > updates since wheezy-securities '2016i-0+deb7u1' is higher than > jessies '2016f-0+deb8u1'. >... What is the "critical" breakage here? If all that "breaks" is that you have the (more recent) 2016i-0+deb7u1 installed until the next point release will update jessie to 2016f-0+deb8u1 (or newer), then this is a purely cosmetical issue. If anything is actually broken, please explain what is broken. Thanks Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Bug#842796: libc recently more aggressive about pthread locks in stable ?
On Sun, Nov 06, 2016 at 08:04:39AM +0100, Petter Reinholdtsen wrote: > [Henrique de Moraes Holschuh] > > And what should we do about Debian stretch, then? > > I believe a good start would be to add an assert() in a test version of > glibc and then run all the autopkgtest scripts on the packages in the > archive to see how widespread the problem is. It will not cover all > packages, but at least a significant portion of the archive. > > I suspect we are too close to the Stretch freeze to try to modify all > the packages affected by the problem, >... This discussion sounds as if all this would be future hardware, but hardware with working (and not disabled) TSX is available in nearly every computer shop in the world for over a year now (the first fixed Intel CPUs were released in 2014). Please don't make it sound as if TSX would be a huge problem for stretch - it is not. Every nontrivial piece of software has bugs. If anyone wants to search specifically for this class of bugs that is appreciated, just like searching for any other class of bugs is appreciated. Running stretch on hardware with TSX available and enabled is working fine for many users for quite some time now. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: libc recently more aggressive about pthread locks in stable ?
On Sun, Nov 06, 2016 at 05:41:34PM -0200, Henrique de Moraes Holschuh wrote: > On Sun, 06 Nov 2016, Ben Hutchings wrote: > > It's worth noting that TSX is broken in 'Haswell' processors and is > > supposed to be disabled via a microcode update. I don't know whether > > glibc avoids using it on these processors if the microcode update is > > not applied. (Linux doesn't appear to hide the feature flags.) > > It does avoid it. For glibc libpthreads, Debian has blacklisted Intel > TSX use [in libpthreads] on all of Haswell and much of Broadwell. > > But anything else *will* attempt to use it, people query cpuid directly > for these things. You need a hypervisor that filters cpuid(). All users who are using intel-microcode from non-free instead of running outdated microcode with known errata should be OK here? Running outdated microcode is a bad idea, and noone is making Debian-specific workarounds for all the other CPU errata. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#382175: cleanup this bug
On Thu, Aug 17, 2006 at 03:16:17PM -0400, Branden Robinson wrote: submitter 382175 Branden Robinson [EMAIL PROTECTED] thanks On Mon, Aug 14, 2006 at 06:45:08PM +, Brian M. Carlson wrote: On Sun, Aug 13, 2006 at 10:51:54PM -0400, Branden Robinson wrote: On Wed, Aug 09, 2006 at 09:56:53PM +, Brian M. Carlson wrote: I agree. However, I am not willing to keep this bug under my name. As I can be somewhat of a hothead, if this issue is important to you, I suggest that you take the status of submitter. I have instructed control@ to handle that, but it may not work. If you are unwilling to take that on, please reassign it to someone else who is willing, or close the bug. I don't mind it being assigned to me if Adrian doesn't want it, either. That's fine. Would you take it, then? If Adrian wants it after that, then you and he can argue it out. I haven't heard anything from Adrain since you sent this, so I'll take it for now. ... Sorry for this, I'm currently a bit busy. It's anyway better that you take this bug since I as an ex-developer are not a good person for asking Sun on behalf of the Debian project for a licence clarification. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#181494: cleanup this bug
tags 181494 -sid clone 181494 -1 retitle 181494 glibc: contains non-free docs retitle -1 glibc: contains possibly non-free code tags -1 -fixed-in-experimental thanks Some cleanups for the bug that should have been done long ago: - remove the wrong sid tag - split the two issues into two bugs - archived bug #181493 already tried to handle the Sun RPC without any result it seems there was a big discussion whether the licence could be interpreted in a way that it does not fail the DFSG, but the only proper solution seems to be tha a Debian developer simply contacts Sun asking for clarification and putting this clarification in debian/copyright flamewar - bug closing - banning people from [EMAIL PROTECTED] why did noone contact Sun and report back instead? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#165921: acknowledged by developer (Re: Bug#165921: libc6: Please use debconf to warn of likely breakage on major upgrade)
On Sun, Oct 10, 2004 at 12:12:17PM +0900, GOTO Masanori wrote: At Sat, 9 Nov 2002 11:56:07 +0100, Adrian Bunk wrote: If you are upgrading to woody, one can also assume you have read the upgrade part of the woody release notes. The libc6 issues would be documented there. Please read my original mail in this bug, my wish was to replace the existing Restarting services question with a debconf question. Managing it through debconf would make it more easy to get a noninteractive upgrade of Debian. Nowadays restarting services question is ready for noninteractive upgrade. We assume Yes at that mode. So if you want to use debconf for noninteractive upgrade, it's already fixed. If you have no objection, I'll close it. You might not like my answer, but to be honest, I still don't like questions being asked during postinst even for interactive upgrades. Regards, -- gotom cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#235759: Comentar on which replacement for German quotes
On Mon, Mar 29, 2004 at 11:02:11PM +0200, Denis Barbier wrote: On Mon, Mar 29, 2004 at 02:47:42AM +0200, Adrian Bunk wrote: [...] I am a bit surprised that this discussion and all patches sent only cover de_DE, although there are altogether three common de_ locales plus two others the locales package supports. If you fix this issue, it should be properly fixed for all de_ locales. All de_* locales include (either directly or indirectly) de_DE in their LC_CTYPE section, so this change propagates to all de_* locales. Thanks for the explanation. This means only cases like the different quote in the Swiss locale need to be handled. Denis cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#235759: Comentar on which replacement for German quotes
Hi, as a German native speaker with some interest on typography but virtually no knowledge on UTF-8 some comments: The common quotes in German today are double open quotes (low position) U201E together with double closed quote (high position) U201C The current conversion ,,text looks strange because the opening quotes don't match the closing quotes. French quotes are relatively uncommon in today's German. If you use them, you also have to be aware that in Swiss German the French closed quotes are used as opening quotes and vice versa. Intuitively, I'd have used the English quotes if German quotes are not available. I am a bit surprised that this discussion and all patches sent only cover de_DE, although there are altogether three common de_ locales plus two others the locales package supports. If you fix this issue, it should be properly fixed for all de_ locales. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#220983: libc6 must conflict with cyrus-imapd ( 1.5.19-15)
Package: libc6 Version: 2.3.2.ds1-10 Severity: grave #219618 is a result of the errno warning message in cyrus-imapd. I'm personally knowing a person who had mail bounces since this error message confused other programs.
Bug#220983: libc6 must conflict with cyrus-imapd ( 1.5.19-15)
Package: libc6 Version: 2.3.2.ds1-10 Severity: grave #219618 is a result of the errno warning message in cyrus-imapd. I'm personally knowing a person who had mail bounces since this error message confused other programs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218717: Wine doesn't work with NPTL
As a note: Wine doesn't seem to work with NPTL. Workaround: LD_ASSUME_KERNEL=2.4.22 wine ... This needs to be handled in Wine, and the conflict of libc6 with Wine will need to be raised after it will be fixed in Wine. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215903: locales installs uncompressed manual pages
Package: locales Version: 2.3.2-8 Severity: normal locales ships the following uncompressed manual pages: /usr/share/man/man8/locale-gen.8 /usr/share/man/man5/locale.alias.5 /usr/share/man/man5/locale.gen.5 Section 12.1. of your policy says: -- snip -- ... Manual pages should be installed compressed using `gzip -9'. ... -- snip -- BTW: lintian gives an error message for this issue.
#213745: dictd doesn't run: Suggestion how to fix this issue
severity 213745 grave thanks First of all, I consider this bug RC since it causes some breakage for users. There should be a solution that doesn't require manual intervention of the user installing dictd. This seems to be a complicated problem: - dictd databases should be UTF-8 encoded - if there's at least one UTF-8 encoded database dictd needs to be started with the --locale option - the --locale option of dictd requires that this locale is available on the system @glibc maintainers: Is there a recommended solution? One possible solution would be to create an /etc/locales directory where packages could put files specifying locales they require and these locales are built additionally to the ones specified in /etc/locale.gen . cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Bug#204643: glibc: Could you add NPTL?
Package: glibc Version: 2.3.2-2 Severity: wishlist Could you add NPTL? Now that kernel 2.6 is coming nearer it would be nice to have it available. TIA Adrian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This problem can be solved from within gcc
reassign 194339 gcc-3.3 retitle 194339 __thread problem with woody backports of gcc 3.3 thanks I had to solve the same problem in my backport of gcc 3.3 to woody [1]. There are no changes to the glibc packages in woody needed, gcc already includes a fix. The problem is that the build of the Debian gcc 3.3 pacakges doesn't include the fixed pthread.h . I suggest one of the following solutions: - include the fixed pthread.h in debian/rules.d/binary-gcc.mk if it was generated (similar to asm/bits/gnu/linux) or - set a build depency on libc*-dev = 2.3 to give backporters a strong hint that caution is needed cu Adrian [1] http://www.fs.tum.de/~bunk/packages/ -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This problem can be solved from within gcc
reassign 194339 gcc-3.3 retitle 194339 __thread problem with woody backports of gcc 3.3 thanks I had to solve the same problem in my backport of gcc 3.3 to woody [1]. There are no changes to the glibc packages in woody needed, gcc already includes a fix. The problem is that the build of the Debian gcc 3.3 pacakges doesn't include the fixed pthread.h . I suggest one of the following solutions: - include the fixed pthread.h in debian/rules.d/binary-gcc.mk if it was generated (similar to asm/bits/gnu/linux) or - set a build depency on libc*-dev = 2.3 to give backporters a strong hint that caution is needed cu Adrian [1] http://www.fs.tum.de/~bunk/packages/ -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Bug#187991: bug#1536: mutt-1.5.4i: Segment fault with long lines when LANG=*.UTF-8
On Sun, Apr 27, 2003 at 05:59:24PM +0200, Anders Helmersson wrote: On Sat, 2003-04-26 at 19:38:11 +0200, Thomas Roessler wrote: With mutt -F your colors -n -f segfault, I can't reproduce this. (Latest CVS checkout; Redhat 7.3.) The problem seems to be related to regex. The segfault occurs in function regexec invoked from line 828 in pager.c with the long line as the buf argument. The buf argument fits just within the 1024 bytes of buf; the last element, buf[1023], is \0. When I compile the latest CVS checkout with --with-regex the problem disappears. Thus, the problem might be in libc.so.6 of my debian installation (libc6 2.3.1-16). I have tried to debug the code (without --with-regex) both with LANG=sv_SE.UTF-8 and LC_CTYPE=sv_SE.UTF-8. I can see no difference between the calls of the regexec. However LANG=sv_SE.UTF-8 produces the segfault, while LC_CTYPE=sv_SE.UTF-8 does not. This might be related to Debian bug #187991 (grep 2.5.1 segfaults in UTF-8 locale) [1]? Anders cu Adrian [1] http://bugs.debian.org/187991 -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Bug#184705: wine in testing is recent enough
Hi Silas, I'm surprised about your bug report. The wine package in testing is recent enough to fulfill the conflict in libc6. The conflict in libc6 is _really_ needed (older Wine packages don't work with libc6 2.3). Are you using apt pinning? If yes please disable apt pinning and test whether the problem is a problem with your apt pinning or a real problem. If not please send the exact command and the exact error message. cu Adrian BTW: Why do you need new a libc6 for a fixed file package? -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Bug#170385: It seems this bug isn't fixed
The changelog of glibc 2.3.1-6 says: - debian/control.in/libc: Conflict against wine ( 0.0.20021007-1) (Closes: #170385) Also conflict against php4 ( 4:4.2.3-5) There seems to be neither a conflict with libwine nor a conflict with php4 in libc6 2.3.1-9. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#170385: libc6 should conflict with wine ( 0.0.20021007-1) and perhaps other packages
Package: libc6 Version: 2.3.1-5 Severity: grave libc6 should conflict with wine ( 0.0.20021007-1) because earlier wine packages don't work with glibc 2.3 (see #165323). Technically the usage of __libc_fork was a bug in Wine. Without a conflict in libc6 many people doing a partial upgrade from Debian 3.0 to Debian 3.1 will have a new libc6 together with an old version of wine installed which will result in a non-working Wine. A conflict in libc6 is the only possible solution to avoid this. If there are other packages with a similar problem similar conflicts are needed. I set the severity to grave since from a user's point of view the new libc6 package breaks wine. If you disagree feel free to lower the severity. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#170385: libc6 should conflict with wine ( 0.0.20021007-1) and perhaps other packages
Package: libc6 Version: 2.3.1-5 Severity: grave libc6 should conflict with wine ( 0.0.20021007-1) because earlier wine packages don't work with glibc 2.3 (see #165323). Technically the usage of __libc_fork was a bug in Wine. Without a conflict in libc6 many people doing a partial upgrade from Debian 3.0 to Debian 3.1 will have a new libc6 together with an old version of wine installed which will result in a non-working Wine. A conflict in libc6 is the only possible solution to avoid this. If there are other packages with a similar problem similar conflicts are needed. I set the severity to grave since from a user's point of view the new libc6 package breaks wine. If you disagree feel free to lower the severity.
Bug#165921: acknowledged by developer (Re: Bug#165921: libc6: Please use debconf to warn of likely breakage on major upgrade)
On Fri, Nov 08, 2002 at 10:12:24AM -0500, Ben Collins wrote: On Fri, Nov 08, 2002 at 01:51:47PM +0100, Adrian Bunk wrote: Technically the following solution should be possible (pseudocode): Not to mention that even if debconf is installed, nothing says that the system (especially during a libc6 upgrade) is in any state to start debconf up. At least in the case when apt-utils is installed on the system the debconf questions are asked at a time when tho libc upgrade hasn't even started. Besides my impression with many libc upgrades on Debian machines is that there's at any time a usable libc installed, or are you thinking of a specific problem I don't know of? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#165921: acknowledged by developer (Re: Bug#165921: libc6: Please use debconf to warn of likely breakage on major upgrade)
reopen 165921 thanks On Fri, Nov 08, 2002 at 10:11:11AM -0500, Ben Collins wrote: On Fri, Nov 08, 2002 at 01:51:47PM +0100, Adrian Bunk wrote: reopen 165921 thanks On Thu, Nov 07, 2002 at 01:18:14PM -0600, Debian Bug Tracking System wrote: ... Sorry, We cannot make libc6 depend on debconf. That would make debconf more essential than libc6. You can see the circular dep problem. These questions are only relevant when upgrading libc6. The vast majority of woody installations has debconf installed due to other packages depending on debconf. If you are upgrading to woody, one can also assume you have read the upgrade part of the woody release notes. The libc6 issues would be documented there. Please read my original mail in this bug, my wish was to replace the existing Restarting services question with a debconf question. Managing it through debconf would make it more easy to get a noninteractive upgrade of Debian. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#165921: acknowledged by developer (Re: Bug#165921: libc6: Please use debconf to warn of likely breakage on major upgrade)
On Fri, Nov 08, 2002 at 10:12:24AM -0500, Ben Collins wrote: On Fri, Nov 08, 2002 at 01:51:47PM +0100, Adrian Bunk wrote: Technically the following solution should be possible (pseudocode): Not to mention that even if debconf is installed, nothing says that the system (especially during a libc6 upgrade) is in any state to start debconf up. At least in the case when apt-utils is installed on the system the debconf questions are asked at a time when tho libc upgrade hasn't even started. Besides my impression with many libc upgrades on Debian machines is that there's at any time a usable libc installed, or are you thinking of a specific problem I don't know of? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Bug#165921: acknowledged by developer (Re: Bug#165921: libc6: Please use debconf to warn of likely breakage on major upgrade)
reopen 165921 thanks On Fri, Nov 08, 2002 at 10:11:11AM -0500, Ben Collins wrote: On Fri, Nov 08, 2002 at 01:51:47PM +0100, Adrian Bunk wrote: reopen 165921 thanks On Thu, Nov 07, 2002 at 01:18:14PM -0600, Debian Bug Tracking System wrote: ... Sorry, We cannot make libc6 depend on debconf. That would make debconf more essential than libc6. You can see the circular dep problem. These questions are only relevant when upgrading libc6. The vast majority of woody installations has debconf installed due to other packages depending on debconf. If you are upgrading to woody, one can also assume you have read the upgrade part of the woody release notes. The libc6 issues would be documented there. Please read my original mail in this bug, my wish was to replace the existing Restarting services question with a debconf question. Managing it through debconf would make it more easy to get a noninteractive upgrade of Debian. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Bug#165921: acknowledged by developer (Re: Bug#165921: libc6: Please use debconf to warn of likely breakage on major upgrade)
reopen 165921 thanks On Thu, Nov 07, 2002 at 01:18:14PM -0600, Debian Bug Tracking System wrote: ... Sorry, We cannot make libc6 depend on debconf. That would make debconf more essential than libc6. You can see the circular dep problem. These questions are only relevant when upgrading libc6. The vast majority of woody installations has debconf installed due to other packages depending on debconf. Technically the following solution should be possible (pseudocode): if debconf installed use debconf else ask/warn without debconf (e.g. the current Restarting services question) Ben cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#165921: acknowledged by developer (Re: Bug#165921: libc6: Please use debconf to warn of likely breakage on major upgrade)
reopen 165921 thanks On Thu, Nov 07, 2002 at 01:18:14PM -0600, Debian Bug Tracking System wrote: ... Sorry, We cannot make libc6 depend on debconf. That would make debconf more essential than libc6. You can see the circular dep problem. These questions are only relevant when upgrading libc6. The vast majority of woody installations has debconf installed due to other packages depending on debconf. Technically the following solution should be possible (pseudocode): if debconf installed use debconf else ask/warn without debconf (e.g. the current Restarting services question) Ben cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Bug#165921: libc6: Please use debconf for the Restarting services question
Package: libc6 Version: 2.3.1-3 Severity: wishlist When upgrading from an older version libc6 asks the Restarting services question. It would be nice if this would be asked via debconf to make automated upgrades easier. TIA Adrian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#155939: The dependencies of libc6 must handle packages that break without db1
On Fri, 9 Aug 2002, Ben Collins wrote: I don't see a way how this could be handled outside the dependencies of libc6. One possible solution is to create a libdb1g package in oldlibs and let the libc6 in sarge depend on this package (the dependency can be dropped after sarge is released). Sounds like a good idea. Someone has already offered to do exactly this (and please don't use the g extension, it dates back to hamm, and serves no good purpose nowadays). Or are you volunteering to do this? I'm sorry but I'm no longer a Debian developer and I don't plan to become one again. cu Adrian -- You only think this is a free country. Like the US the UK spends a lot of time explaining its a free country because its a police state. Alan Cox -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#64074: This bug seems to be RC
severity 64074 important thanks This bug seems to be RC. The submitter said: However, neither apache nor ssh run afterwards. Since one might try to upgrade with only ssh connection to the box this can be a major problem (Severity: important??) I can see no comment on this bug in the BTS, and it might be a problem if it is not solved in potato. cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Bug#55615: libc6-bin-2.1.2-11 conflicts with locales_2.0.7.19981211-6
Package: libc6-bin Version: 2.1.2-11 Hi, libc6-bin-2.1.2-11 conflicts with locales_2.0.7.19981211-6 because they both ship a /usr/bin/locale . You have to update locales before (locales_2.1.2-11.0.1 worked fine for me). The exact error message was: trying to overwrite `/usr/bin/locale', which is also in package locales cu, Adrian
