Hello.
One of the reasons tzdata will not migrate to testing is that it has an
artificial bug preventing it from doing so:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084190
In my opinion (after reporting several tzdata-related bugs
and also fixing some of them), the breakage introduced
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 their
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)
Thanks.
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 I
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 /etc/
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 submi
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 us
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 thi
ce package, 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
Date: Sun, 12 Jun 2016 11:43:05 +0200
Subject: [PATCH 1/3] Add gshadow line to default /etc/nsswitch.conf (Bug
#699
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 r
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 libnss-db.
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.
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=)
at
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 "unsubs
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 lib
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
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.
-- Forw
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
Subje
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
> > ..././libc
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 manipulate
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 an
On Sat, 4 Dec 2004, Andreas Jochens wrote:
> However, I had severe problems with 'glibc' upgrades when the '/lib64'
> symlink was created by 'glibc' instead of 'base-files'.
> Basically, everything stopped working during the upgrade because
> the '/lib64' temporarily disappeared and the binarie
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 i
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-8
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
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
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 ins
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 ins
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
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
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 uninsta
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: 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 o
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
36 matches
Mail list logo
