El 3/6/24 a las 23:10, Helmut Grohne escribió:
On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote:
Since noble includes these changes and I'd get this done sooner rather
than later, how about moving forward with June 5th after 22:30 UTC (such
that all buildds have regenerated
Sorry, I forgot to Cc the bug address. I wrote the rationale for the reassign
here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=459664;msg=34#34
Also, please note that the following two addresses do not work anymore:
Joey Hess
Justin Pryzby
(In case you want to avoid bounces)
reassign 459664 src:glibc
thanks
Hello.
Summary of this bug: The file /etc/host.conf from base-files sets "multi on",
while glibc's default is "multi off".
Apparently, there are good reasons for "multi on" to be the default,
for example, the fact that "localhost" in modern systems has
both an
Package: src:tzdata
Version: 2022g-4
Severity: important
Tags: ftbfs
Dear maintainer:
During a rebuild of all packages in bookworm, your package failed to build:
[...]
debian/rules binary-indep
dh binary-indep
Package: libc-bin
Version: 2.31-13+deb11u2
Severity: serious
Tags: patch
Dear libc-bin maintainers:
In Debian 11, the default /etc/nsswitch.conf file has now "files"
instead of the traditional "compat".
So far, so good. This is documented in Release Notes, and those who
need NIS may change
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
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
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
, 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
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
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
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.
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
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
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
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
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.
--
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
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
32 matches
Mail list logo