Bug#521737: [alpha] Segfault in memchr when called via strstr

2010-04-06 Thread Santiago Vila
Hmm, but last message in this report was from October 2009. Should I just modify m4 so that the test is ignored on alpha? Or maybe don't worry at all as alpha is not a release architecture for squeeze? -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of

Bug#521737: [alpha] Segfault in memchr when called via strstr

2010-04-06 Thread Santiago Vila
Hi. This seems to be the same bug that makes m4 1.4.14 test suite to fail on alpha. The failed test is test-strstr. Here is a backtrace: #0 memchr () at ../ports/sysdeps/alpha/memchr.S:73 #1 0x020db9f8 in two_way_short_needle (haystack_start=0x2027ffc aax, needle_start=value

Re: Bug#459664: this bug/#459664 - host.conf: multi on appears to be default

2008-06-18 Thread Santiago Vila
On Tue, 8 Jan 2008, Justin Pryzby wrote: #459664 - host.conf: multi on appears to be default http://bugs.debian.org./459664 I just checked the source. The default (when no host.conf exists or includes no multi line and none of the overriding environment variables are sert) seems to be

Re: Bug#496915: [base-files] Modifications related to GSoC project PamNssInstaller

2008-08-29 Thread Santiago Vila
reassign 496915 libc6 thanks The submitter suggests adding a perl script called update-nsswitch to base-files, but I consider that to be a bad idea, as base-files is not supposed to contain any binaries. The file nsswitch.conf is really a configuration file for libc6, so I reassign this bug to

base-files: provided /etc/host.conf file shouldn't contain an order bind, hosts line (fwd)

2006-06-14 Thread Santiago Vila
Hi. In this report I'm asked to drop the order line from host.conf. I assume no versioned dependency on glibc is needed for this, as it seems such line has been ignored for a looong time (probably since glibc 2.0), but I better make sure that's the case by asking here. Thanks. --

Bug#673271: libc-bin: Please include /etc/nsswitch.conf

2012-05-17 Thread Santiago Vila
Package: libc-bin Version: 2.13-32 We should probably move /etc/nsswitch.conf from base-files to libc-bin, as it is really a configuration file for libc6. The file was in base-files for historical reasons, but now that there is a libc-bin package and it's essential, that would be its real place.

Bugs #619605 and #649265

2012-06-30 Thread Santiago Vila
reassign 619605 libc-bin reassign 649265 libc-bin thanks These two bugs are related to /etc/nsswitch.conf, so they should be considered bugs in libc-bin now as we are moving the file from base-files. Bug#619605 complains that the default /etc/nsswitch.conf has an implicit dependency on

Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures

2002-10-15 Thread Santiago Vila
Package: locales The dependency of locales on glibc-$DEBVERSION is harmful for non-released architectures like the Hurd, since the only locales package which exists (since there is not a testing disrtibution) becomes uninstallable until the glibc package is recompiled. Such dependency should be

Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures

2002-10-21 Thread Santiago Vila
GOTO Masanori wrote: Santiago Vila wrote: GOTO Masanori wrote: How many uninstallable period do you have? Undefined. May be a short time, but it may be a lot of time as well. I wonder why such delay was occured. locales package is built with libc6. I'm surprised that you ask

Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures

2002-10-15 Thread Santiago Vila
Package: locales The dependency of locales on glibc-$DEBVERSION is harmful for non-released architectures like the Hurd, since the only locales package which exists (since there is not a testing disrtibution) becomes uninstallable until the glibc package is recompiled. Such dependency should be

Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures

2002-10-21 Thread Santiago Vila
reopen 164868 thanks On Mon, 21 Oct 2002, GOTO Masanori wrote: At Tue, 15 Oct 2002 19:00:24 +0200 (CEST), Santiago Vila wrote: The dependency of locales on glibc-$DEBVERSION is harmful for non-released architectures like the Hurd, since the only locales package which exists (since

Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures

2002-10-21 Thread Santiago Vila
GOTO Masanori wrote: Santiago Vila wrote: That's not the problem, the problem is that *while* it's not recompiled yet, the locales package becomes *completely* uninstallable, because the old version is not available anymore. How many uninstallable period do you have? Undefined. May

Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures

2002-10-21 Thread Santiago Vila
GOTO Masanori wrote: Santiago Vila wrote: GOTO Masanori wrote: How many uninstallable period do you have? Undefined. May be a short time, but it may be a lot of time as well. I wonder why such delay was occured. locales package is built with libc6. I'm surprised that you ask

Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures

2002-10-21 Thread Santiago Vila
On Mon, 21 Oct 2002, Ben Collins wrote: If you do not consider this a problem in libc, please reassign this to the ftp.debian.org package so that they create a testing distribution for all unreleased architectures, one that does not remove old packages until the new ones become

Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures

2002-10-21 Thread Santiago Vila
On Mon, 21 Oct 2002, Ben Collins wrote: It's not just that things are not in sync, it's that you are artificially forcing them to be in sync without need, and every time they aren't, an important package like locales becomes *completely* uninstallable. Do you still think most people

Re: Bug#119526: gettext support for ro_RO

2003-05-10 Thread Santiago Vila
reassign 119526 libc6 thanks I received this bug from Ionel Mugurel Ciobica: Package: gettext Version: 0.10.40-1 In the file /usr/share/gettext/intl/locale.alias it is a line: romanianro_RO.ISO-8859-2 which I have to change all the time to romanianro_RO.ISO-8859-16

Re: Bug#259302: Patch update against base-files 3.1

2004-12-02 Thread Santiago Vila
reassign 259302 libc6 thanks On Wed, 1 Dec 2004, Goswin von Brederlow wrote: Conclusion: - I would like to see those links in sarge (for amd64 only, no change for other archs) since they are currently essential for amd64 (glibc relies on it). What package provides them is no that

Bug#259302: Patch update against base-files 3.1

2004-12-05 Thread Santiago Vila
On Sun, 5 Dec 2004, Kurt Roeckx wrote: On Sun, Dec 05, 2004 at 04:39:06PM +0100, Santiago Vila wrote: Could you please provide details about the problem of having the symlinks in glibc? Is it that glibc has a versioned Replaces: base-files and dpkg removes the symlink in base-files

Bug#259302: Patch update against base-files 3.1

2004-12-05 Thread Santiago Vila
On Sun, 5 Dec 2004, Goswin von Brederlow wrote: The problem is we already have it in base-files on every installed amd64 system. Yes, I'm fully aware of that. See the message I wrote after that. In such case I think it would be completely acceptable that the preinst simply manipulates

Bug#259302: Patch update against base-files 3.1

2004-12-06 Thread Santiago Vila
On Mon, 6 Dec 2004, Goswin von Brederlow wrote: Kurt Roeckx [EMAIL PROTECTED] writes: Preparing to replace libc6-dev 2.3.2.ds1-18 (using .../libc6-dev_2.3.2.ds1-19_amd64.deb) ... Unpacking replacement libc6-dev ... Preparing to replace libc6 2.3.2.ds1-18 (using

Bug#206210

2005-01-05 Thread Santiago Vila
reassign 206210 libc6 thanks This was the diff does not pass LSB test suite bug, but at the very end in the thread there is a solution from Paul Eggert in the form of a patch against glibc. Therefore, I'm reassigning this report to libc6. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]

Bug#344358: using db for groups in nsswitch.conf creates double groups (fwd)

2005-12-22 Thread Santiago Vila
reassign 344358 glibc thanks I believe the submitter is complaning about libc behaviour here, not about defaults in base-files. Reassigning accordingly. -- Forwarded message -- From: Ron Peterson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 21 Dec 2005 22:03:11 -0500

Bug#827095: base-files and libc-bin install different /etc/nsswitch.conf files

2016-06-12 Thread Santiago Vila
On Sun, 12 Jun 2016, Sven Joachim wrote: > Package: base-files,libc-bin > > Both base-files and libc-bin install the /etc/nsswitch.conf file. > Although it has been agreed in #673271 that libc-bin should take over > responsibility for it, base-files still installs and updates it. > Moreover, in

Bug#827105: libc-bin: Updating /etc/nsswitch.conf to current default

2016-06-12 Thread Santiago Vila
, but if the patches are still not ok, I trust they will be easy to fix. Thanks.From 2aee8524a0ea508d77b72cbbc2928c3f5622d70b Mon Sep 17 00:00:00 2001 From: Santiago Vila <sanv...@debian.org> Date: Sun, 12 Jun 2016 11:43:05 +0200 Subject: [PATCH 1/3] Add gshadow line to default /etc/nsswi

Bug#827095: base-files and libc-bin install different /etc/nsswitch.conf files

2016-06-12 Thread Santiago Vila
reassign 827095 base-files thanks I said: > I see that the file has moved to libc-bin, but there was some simple > code in postinst to update to the current default. I'm going to see > if I can create a simple patch for libc-bin to do the same. Done in Bug #827105. So, I'm going to consider

Bug#865144: libc-bin: /etc/nsswitch.conf is always updated on upgrades (even when no changes)

2017-06-19 Thread Santiago Vila
Package: libc-bin Version: 2.24-11+deb9u1 Tags: patch Hello Aurelien et al. As the subject says, the file /etc/nsswitch.conf is always updated to the current default on upgrades when it is already the default. This makes the file to have a different mtime without need, which is bad for people

Bug#928405: reassign 928405 to src:glibc, notfixed 926215 in 2.6~20180302-1, tagging 926215

2019-05-10 Thread Santiago Vila
On Tue, 7 May 2019, Andreas Beckmann wrote: > reassign 928405 src:glibc 2.28-10 > notfixed 926215 2.6~20180302-1 > tags 926215 + unreproducible > thanks Hello Andreas. Sorry, I have just marked this bug as fixed, because I didn't realize that you had the intention to reassign it. The bug I