Re: Bug#459664: this bug/#459664 - host.conf: "multi on" appears to be default
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 "multi off"; however debian > distributes a conffile with default content "multi on", so the > behavior default is different from the behavior default in glibc. > It's not clear to me if this justifies an explanation in the manpage, > as this same situation occurs with some regularity; perhaps the > conffile should instead include comments; in particular, a commented > line for each value that is left at the default (and of course an > uncommented line for each value that's changed therefrom). It is in fact a little bit inconsistent that glibc has a default and we override it in /etc/host.conf by default. I don't quite understand the rationale given by the manpage, namely: multi Valid values are on and off. If set to on, the resolv+ library will return all valid addresses for a host that appears in the /etc/hosts file, instead of only the first. This is off by default, as it may cause a substantial performance loss at sites with large hosts files. Are there really many systems using large hosts files these days? Do they really suffer from bad performance by using "multi on" (which, by way of /etc/host.conf, is the default in Debian). Could we make "multi on" the default in glibc and remove host.conf entirely? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#496915: [base-files] Modifications related to GSoC project PamNssInstaller
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 libc6. Maybe nsswitch.conf should be in libc6 as well, but for now I don't mind if it's still part of base-files. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#521737: [alpha] Segfault in memchr when called via strstr
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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.1.10.1004061059460.23...@cantor.unex.es
Bug#521737: [alpha] Segfault in memchr when called via strstr
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 str-two-way.h:269 #2 *__GI_strstr (haystack_start=0x2027ffc "aax", needle_start=) at strstr.c:79 #3 0x00012e48 in main (argc=1, argv=0x11ff245e8) at test-strstr.c:70 (gdb) Thanks. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.1.10.1004061049310.23...@cantor.unex.es
Bug#673271: libc-bin: Please include /etc/nsswitch.conf
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.
[ You can take the master copy from /usr/share/base-files/nsswitch.conf
from any Debian system ].
This file is currently installed by base-files postinst in this way:
#!/bin/sh
set -e
install_from_default() {
if [ ! -f $2 ]; then
cp -p $1 $2
fi
}
[...]
if [ "$1" = "configure" ] && [ "$2" = "" ]; then
install_from_default /usr/share/base-files/nsswitch.conf /etc/nsswitch.conf
[...]
i.e. the file is put there when base-files is installed by
debootstrap, and it's not touched again.
For now, I think you can simply do a similar thing in libc-bin at any
given time (i.e. copy the file from a directory owned by libc-bin),
as this move does not require any coordination between libc-bin and
base-files (nothing bad will happen if two different packages put the
same file there when the file is not there).
We could then wait for a stable release to happen (ideally, wheezy),
and then I could remove this stuff from base-files.
Please note that people is now asking for a procedure to add and
remove entries to this file (see Bug#649265), and for that reason the
file should not be a conffile.
Thanks.
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/alpine.deb.2.02.1205171350520.21...@cantor.unex.es
Bugs #619605 and #649265
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. Bug#649265 complains that there is not a mechanism to update /etc/nsswitch.conf. I guess a fix for #649265 would make #619605 quite easy to fix. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1206301514001.31...@cantor.unex.es
Bug#827095: base-files and libc-bin install different /etc/nsswitch.conf files
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 response for #699090 base-files has updated its copy, and > now it differs from libc-bin's version: > > , > | diff -u /usr/share/base-files/nsswitch.conf > /usr/share/libc-bin/nsswitch.conf > | --- /usr/share/base-files/nsswitch.conf 2014-05-04 14:38:37.0 +0200 > | +++ /usr/share/libc-bin/nsswitch.conf 2016-03-21 00:45:12.0 +0100 > | @@ -7,7 +7,6 @@ > | passwd: compat > | group: compat > | shadow: compat > | -gshadow:files > | > | hosts: files dns > | networks: file > ` > > The net effect is apparently that the content of /etc/nsswitch.conf in > fresh installations depends on whether libc-bin or base-files is > configured first, which is bad. Could you please work out who should be > responsible for that file? Thanks a lot for the report. You are absolutely right. Yes, the file should not be in both places, but on the other hand, we might better have them in sync before I remove it from base-files. 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. Thanks.
Bug#827105: libc-bin: Updating /etc/nsswitch.conf to current default
Package: libc-bin
Version: 2.22-11
Dear glibc maintainers:
As Sven Joachim has pointed out in Bug#827095, the file
/etc/nsswitch.conf is currently both in base-files and libc-bin.
I've created the following patches for the transition to be complete.
The first patch just updates /usr/share/libc-bin/nsswitch.conf
to be in sync with base-files default after adding gshadow line.
The second and third patches add code borrowed from base-files
postinst so that the file is updated to current default if the user
never modified it.
You will see that this code is some kind of "poor's man UCF system"
but it has worked flawlessly for me in base-files and it has the added
benefit that the user is never bothered with stupid questions: Either
the user changed the file and we do nothing at all, or the file was
not changed from the old default and we update it to the new default.
Note 1: The file nsswitch.conf.md5sums could be trimmed down a little
bit on the basis that we "do not support upgrades skipping releases",
but IMHO, I would not remove the last three lines (that is, the lines
from "base-files 3.1.16 to 7.2 and libc-bin 2.19-18 to 2.22-11" to the
end).
Note 2: To test this I have copied the files to /usr/share/libc-bin
and libc-bin.postinst to /var/lib/dpkg/info.
Then I removed the gshadow line from /etc and checked that
"dpkg-reconfigure libc-bin" works as expected.
What I have not tested is a complete build of glibc source 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
#699090)
---
debian/local/etc/nsswitch.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/local/etc/nsswitch.conf b/debian/local/etc/nsswitch.conf
index d2f03b0..1142be1 100644
--- a/debian/local/etc/nsswitch.conf
+++ b/debian/local/etc/nsswitch.conf
@@ -7,6 +7,7 @@
passwd: compat
group: compat
shadow: compat
+gshadow:files
hosts: files dns
networks: files
--
2.8.1
From 96f9245571823ea8ab8499d29a0df5b9e110ac4e Mon Sep 17 00:00:00 2001
From: Santiago Vila
Date: Sun, 12 Jun 2016 11:56:14 +0200
Subject: [PATCH 2/3] Create nsswitch.conf.md5sums for updates to the current
default if unchanged
---
debian/debhelper.in/libc-bin.install | 1 +
debian/local/etc/nsswitch.conf.md5sums | 5 +
2 files changed, 6 insertions(+)
create mode 100644 debian/local/etc/nsswitch.conf.md5sums
diff --git a/debian/debhelper.in/libc-bin.install b/debian/debhelper.in/libc-bin.install
index dfab166..77ad21d 100644
--- a/debian/debhelper.in/libc-bin.install
+++ b/debian/debhelper.in/libc-bin.install
@@ -2,6 +2,7 @@ debian/local/etc/bindresvport.blacklist etc
debian/local/etc/ld.so.conf etc
debian/local/etc/ld.so.conf.d etc
debian/local/etc/nsswitch.conf usr/share/libc-bin
+debian/local/etc/nsswitch.conf.md5sums usr/share/libc-bin
nis/nss etc/default
posix/gai.conf etc
debian/tmp-libc/sbin/ldconfig sbin
diff --git a/debian/local/etc/nsswitch.conf.md5sums b/debian/local/etc/nsswitch.conf.md5sums
new file mode 100644
index 000..657fe79
--- /dev/null
+++ b/debian/local/etc/nsswitch.conf.md5sums
@@ -0,0 +1,5 @@
+109e33e2c91d1853b5bc56078a96aa18 base-files 3.0.0 to 3.1.15
+3114ea9cf2f3bd8d120b4da96e3832d5 base-files 3.1.8 and 3.1.9
+295c15c4bdac80e50b37689ef08f359c base-files 3.1.16 to 7.2 and libc-bin 2.19-18 to 2.22-11
+30b82cb1ce20d480703da2208a4607b4 base-files 6.6
+f8e97bf611374634c7cb3a6085503ab5 base-files 7.3 and libc-bin 2.22-12
--
2.8.1
From c51efa83cdf0250db2186d3092e590c73a160be6 Mon Sep 17 00:00:00 2001
From: Santiago Vila
Date: Sun, 12 Jun 2016 12:03:34 +0200
Subject: [PATCH 3/3] libc-bin.postinst: Add code to update /etc/nsswitch.conf
---
debian/debhelper.in/libc-bin.postinst | 16
1 file changed, 16 insertions(+)
diff --git a/debian/debhelper.in/libc-bin.postinst b/debian/debhelper.in/libc-bin.postinst
index 50f3e79..29effc8 100644
--- a/debian/debhelper.in/libc-bin.postinst
+++ b/debian/debhelper.in/libc-bin.postinst
@@ -8,10 +8,26 @@ install_from_default() {
fi
}
+update_to_current_default() {
+ if [ -f $2 ]; then
+md5=`md5sum $2 | cut -f 1 -d " "`
+if grep -q "$md5" $1.md5sums; then
+ if ! cmp -s $1 $2; then
+cp -p $1 $2
+echo Updating $2 to current default.
+ fi
+fi
+ fi
+}
+
if [ "$1" = "configure" ] && [ "$2" = "" ] ; then
install_from_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf
fi
+if [ "$1" = "configure" ] && [ "$2" != "" ]; then
+ update_to_current_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf
+fi
+
if [ "$1" = "triggered" ] || [ "$1" = "configure" ]; then
ldconfig || ldconfig --verbose
exit 0
--
2.8.1
Bug#827095: base-files and libc-bin install different /etc/nsswitch.conf files
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 this one as a bug in base-files (will wait for #827105 to be fixed in libc-bin, or, at the very minimum, the gshadow line to be added). Thanks.
Bug#865144: libc-bin: /etc/nsswitch.conf is always updated on upgrades (even when no changes)
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 using tripwire/samhain/etc.
We introduced this bug one year ago, when we moved the file from
base-files:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827105
I can think of at least three ways to fix it, which I append
to this report:
In the first patch, we only modify the file if it's really different.
This is what base-files did for ages and what I initially proposed in
the patch for libc-bin (the bug was introduced by removing the cmp part).
In the second patch, we do consider the md5sum of the current default,
but we just return in such case, so the file is not updated.
This is probably the cleanest patch.
In the third patch, similar to the first one, we just don't check
the md5sum for the current default, and we fall back to the case
where the file has been modified.
I understand that this is not a big problem, but it is otherwise
trivial to fix (and it is formally a regression), so please consider
fixing this in the next upload for stretch, if there is one.
Thanks a lot.--- a/debian/debhelper.in/libc-bin.postinst
+++ b/debian/debhelper.in/libc-bin.postinst
@@ -32,8 +32,10 @@ update_to_current_default() {
return
;;
esac
-echo "Updating $2 to current default."
-cp -p $1 $2
+if ! cmp -s $1 $2; then
+ echo "Updating $2 to current default."
+ cp -p $1 $2
+fi
fi
}
--- a/debian/debhelper.in/libc-bin.postinst
+++ b/debian/debhelper.in/libc-bin.postinst
@@ -26,6 +26,7 @@ update_to_current_default() {
;;
# base-files 7.3 and libc-bin 2.22-12
f8e97bf611374634c7cb3a6085503ab5)
+return
;;
# modified file
*)
--- a/debian/debhelper.in/libc-bin.postinst
+++ b/debian/debhelper.in/libc-bin.postinst
@@ -25,8 +25,9 @@ update_to_current_default() {
30b82cb1ce20d480703da2208a4607b4)
;;
# base-files 7.3 and libc-bin 2.22-12
- f8e97bf611374634c7cb3a6085503ab5)
-;;
+ # This is the current default, to be uncommented if it changes again
+ # f8e97bf611374634c7cb3a6085503ab5)
+ # ;;
# modified file
*)
return
Bug#998008: libc-bin: postinst makes a working NIS system not to work anymore at every point release
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/nsswitch.conf if they need it. But there is a problem: The postinst updates the file every time it is detected that it matches *any* old default (via md5sum). This is a functionality which was part of base-files in the past and it was useful when there was a default /etc/nsswitch.conf which would work for almost everybody. But this is not the case anymore, because the default file is not good for those using NIS. As a result, not only upgrading a Debian 10 system to Debian 11 makes NIS to require an adjustment (i.e. putting compat again after postinst modifies the file), but also each and every upgrade from Debian 11 point x to Debian 11 point x+1. Patch attached. I hope this may be fixed for Debian 11.2. Thanks.--- a/debian/debhelper.in/libc-bin.postinst +++ b/debian/debhelper.in/libc-bin.postinst @@ -43,9 +43,10 @@ if [ "$1" = "configure" ] && [ "$2" = "" ] ; then install_from_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf fi -if [ "$1" = "configure" ] && [ "$2" != "" ]; then - update_to_current_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf -fi +# Not ok to do this on a Debian 11 system anymore. +# if [ "$1" = "configure" ] && [ "$2" != "" ]; then +# update_to_current_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf +# fi if [ "$1" = "triggered" ] || [ "$1" = "configure" ]; then ldconfig || ldconfig --verbose
Bug#1031028: tzdata: FTBFS (undeclared build-dependency on tzdata)
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
dh_update_autotools_config -i
dh_autoreconf -i
dh_auto_configure -i
debian/rules override_dh_auto_build-indep
make[1]: Entering directory '/<>'
# Generate a tzdata.zi file
/usr/bin/make AWK=gawk BACKWARD="backward" PACKRATDATA=backzone VERSION_DEPS=
tzdata.zi
make[2]: Entering directory '/<>'
gawk \
-v DATAFORM=`expr main.zi : '\(.*\).zi'` \
-v PACKRATDATA='backzone' \
-v PACKRATLIST='' \
-f ziguard.awk \
africa antarctica asia australasia europe northamerica southamerica
etcetera factory backward backzone >main.zi.out
mv main.zi.out main.zi
version=`sed 1q version` && \
LC_ALL=C gawk \
-v dataform='main' \
-v deps='ziguard.awk africa antarctica asia australasia europe
northamerica southamerica etcetera factory backward backzone zishrink.awk' \
-v redo='posix_right' \
-v version="$version" \
-f zishrink.awk \
main.zi >tzdata.zi.out
mv tzdata.zi.out tzdata.zi
make[2]: Leaving directory '/<>'
# Generate the leapseconds file
/usr/bin/make AWK=gawk PACKRATDATA=backzone leapseconds
make[2]: Entering directory '/<>'
make[2]: 'leapseconds' is up to date.
make[2]: Leaving directory '/<>'
# Build the timezone data
/usr/sbin/zic -d /<>/tzgen -L /dev/null tzdata.zi ; \
mkdir "/<>/tzgen/posix"; \
find "/<>/tzgen" -mindepth 1 -maxdepth 1 ! -name posix -printf
"%P\n" | while read -r tz; do \
ln -sr "/<>/tzgen/$tz" "/<>/tzgen/posix/$tz";
\
done; \
/usr/sbin/zic -d /<>/tzgen/right -L leapseconds tzdata.zi ; \
warning: "leapseconds", line 83: "#expires" is obsolescent; use "Expires"
# Replace hardlinks by symlinks
grep '^L ' /<>/tzdata.zi | while read L target name ; do \
ln -srf /<>/tzgen/$target /<>/tzgen/$name ; \
ln -srf /<>/tzgen/posix/$target
/<>/tzgen/posix/$name ; \
ln -srf /<>/tzgen/right/$target
/<>/tzgen/right/$name ; \
done
# Generate a posixrules file
ln -s America/New_York /<>/tzgen/posixrules
debian/generate_debconf_templates -d "/<>/tzgen" >
debian/tzdata.templates
debconf-updatepo
make[1]: Leaving directory '/<>'
debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
debian/test_timezone_conversions -z "/<>/tzgen"
INFO: Selectable timezones in debian/tzdata.templates: 503
INFO: Available timezones in /<>/tzgen: 1241
INFO: Available conversion targets in debian/tzdata.config: 89
TZPATH="/<>/tzgen" debian/tests/python
test_2022g (__main__.TestZoneinfo.test_2022g)
Test new zone America/Ciudad_Juarez from 2022g release. ... ERROR
test_available_timezones_count
(__main__.TestZoneinfo.test_available_timezones_count)
Test available_timezones() count to be reasonable. ... FAIL
test_daylight_saving_transition
(__main__.TestZoneinfo.test_daylight_saving_transition)
Test daylight saving time transition from Python documentation. ... ERROR
test_localtime (__main__.TestZoneinfo.test_localtime)
Test 'localtime' timezone. ... ERROR
test_timezones (__main__.TestZoneinfo.test_timezones)
Test all zones to load, have a name, and have a reasonable offset. ... ok
==
ERROR: test_2022g (__main__.TestZoneinfo.test_2022g)
Test new zone America/Ciudad_Juarez from 2022g release.
--
Traceback (most recent call last):
File "/usr/lib/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
return resources.files(package_name).joinpath(resource_name).open("rb")
^
File "/usr/lib/python3.11/importlib/resources/_common.py", line 22, in files
return from_package(get_package(package))
File "/usr/lib/python3.11/importlib/resources/_common.py", line 53, in
get_package
resolved = resolve(package)
File "/usr/lib/python3.11/importlib/resources/_common.py", line 44, in resolve
return cand if isinstance(cand, types.ModuleType) else
importlib.import_module(cand)
^
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1128, in _find_and_load_unlocked
File "", line 241, in _call_with_frames_removed
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1128, in _find_and_load_unlocked
File "", line 241, in _call_with_
host.conf: "multi on" appears to be default
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 IPv4 and an IPv6 address, as explained here: https://bugzilla.redhat.com/show_bug.cgi?id=486461 So maybe it would make sense to change the default in glibc. (Hence the reassign). Cc: to all relevant parties. Thanks.
Bug#459664: host.conf: "multi on" appears to be default
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.
Re: Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
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 chroots before the upload)? I got vaguely positive feedback from Paul Gevers on this date. Hence, I plan to upload after the June 5th mirror push and allocate time for handling unexpected fallout. dash, base-files and bash are fully migrated at the time of this writing. glibc migrated -11 and -12 still has 5 autopkgtest regressions. util-linux migrated -6, -7 has a piuparts regression and -8 hopefully gets tested soon. I hope that both migrate before the planned upload and will consult with the release team on whether to bump back or go ahead. I have rebased and retested the patches in https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo. Andrew, Aurelien, Chris, Matthias, Santiago: Any objections? For base-files, please use branch "wip-202406" here: git clone https://salsa.debian.org/sanvila/base-files-not-yet/ (I've just made such branch the default) and upload as is. This will avoid sending signed files. Thanks.
Bug#928405: reassign 928405 to src:glibc, notfixed 926215 in 2.6~20180302-1, tagging 926215
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 submitted originally was definitely reproducible, and that's why I wanted to close it. If you still want to reassign the bug, please do so (apparently the reassign above didn't work), but I'd like to know the rationale for doing so. Thanks.
Bug#344358: using db for groups in nsswitch.conf creates double groups (fwd)
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 Subject: Bug#344358: using db for groups in nsswitch.conf creates double groups Package: base-files Version: 3.1.2 Debian Sarge If I'm not mistaken, if you use db lookups for groups in nsswitch.conf, followed by files, this leads to double group membership. For example, when my nsswitch.conf contains: group: db files ...and after I've updated the database files in /var/lib/misc, I find that any group membership specified in /etc/group is reported twice by the 'groups' command. The effect isn't noticable unless you log in again, of course. If logging in via ssh, the ssh daemon has to be restarted. We discovered this quite by accident trying to track down an issue with Tru64 file locking in directories having no permissions for 'other' on nfs mounts from linux, but that's another story... Best. -- Ron Peterson Network & Systems Manager Mount Holyoke College http://pks.mtholyoke.edu:11371/pks/lookup?search=0xB6D365A1&op=vindex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
base-files: provided /etc/host.conf file shouldn't contain an "order bind, hosts" line (fwd)
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. -- Forwarded message -- From: Samuel Thibault <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Date: Thu, 23 Feb 2006 15:07:02 +0100 Subject: base-files: provided /etc/host.conf file shouldn't contain an "order bind, hosts" line Package: base-files Version: 3.1.10 Severity: minor Tags: patch Hi, The "order" line of /etc/host.conf doesn't work any more (see http://sourceware.org/bugzilla/show_bug.cgi?id=2389) and is replaced by the "hosts:" line of /etc/nsswitch.conf. I requested documentation removal from the manpage in bug #270368. For even less confusion, please also apply the following patch to base-files, since the "order" line doesn't make sense any more. --- host.conf.orig 2006-02-23 15:05:56.0 +0100 +++ host.conf 2006-02-23 15:06:00.0 +0100 @@ -1,2 +1 @@ -order hosts,bind multi on Regards, Samuel [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 on glibc-$VERSION at most. The reason glibc-$DEBVERSION was required in the past was that, at some point, there were incompatible locales and libc packages having the same VERSION but different DEBVERSION numbers. This was because the maintainer was introducing new code from CVS without changing the VERSION, which may be considered as a bad practice. So, I request that the dependency is changed again to a non-debversioned one (like glibc-$VERSION) and the maintainer refrains from making incompatible changes without changing $VERSION as well. Thanks.
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 there is not a testing disrtibution) > > becomes uninstallable until the glibc package is recompiled. > > I don't know why hurd is the special case. > Why do you just recompile them? 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. 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 installable. > > Such dependency should be on glibc-$VERSION at most. > > > > The reason glibc-$DEBVERSION was required in the past was that, at > > some point, there were incompatible locales and libc packages having > > the same VERSION but different DEBVERSION numbers. This was because > > the maintainer was introducing new code from CVS without changing > > the VERSION, which may be considered as a bad practice. > > > > So, I request that the dependency is changed again to a non-debversioned > > one (like glibc-$VERSION) and the maintainer refrains from making > > incompatible changes without changing $VERSION as well. > > Locales should depends on glibc-$DEBVERSION, because somethimes > we apply the latest glibc cvs code in the same glibc-$VERSION > (and count up glibc-$DEBVERSION) as you said. > > Locale handling is still active development area, so we can't > ignore the difference of both localedata and locale handling code. > Thus, I can't accept your request. If you are going to keep a "="-type dependency, you should perhaps merge both packages into a single one.
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 be a short time, but it may be a lot of time as well. > > 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 installable. > > (1) At least we use pool system for released architecture, and > some versions stay for a while. > (2) Unreleased architecture does not stay and only single version > is placed. You hit this case. > (3) However, we can't remove '='-type dependency for locales. > > Thus, our discussion goes side by side. We can't agree. I think you can make '='-type dependency in locales to be something slightly different which achieves the same desired result without harming unreleased architectures so much. The DEBVERSION thing is arbitrary, in some sense. You just need a character string which has the property that it changes every time there is an incompatible change in the locales code. Certainly, DEBVERSION has such property, since it *always* changes. The problem is that most of the time it changes without real need. You could also use a character string of the form locales-DATE, and update DATE when (and only when) an incompatibility in the locale code is detected.
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 this. libc is Architecture: any. locales is Architecture: all. When you upload a new libc+locales for i386, libc and locales stop being in sync for unreleased architectures like hurd-i386, because the locales available is the new one uploaded by you, while the libc is the last compiled version. > > I think you can make '='-type dependency in locales to be something > > slightly different which achieves the same desired result without > > harming unreleased architectures so much. > > > > The DEBVERSION thing is arbitrary, in some sense. You just need a > > character string which has the property that it changes every time > > there is an incompatible change in the locales code. > > > > Certainly, DEBVERSION has such property, since it *always* changes. > > The problem is that most of the time it changes without real need. > > You could also use a character string of the form locales-DATE, and > > update DATE when (and only when) an incompatibility in the locale > > code is detected. > > Hmm, it increases our maintenance cost. I don't want to make us be > such difficult rule. It's a quite simple rule, not a difficult one. In fact, I think it should be *much* less work for you than the work it imposes on hundreds of people who have to workaround the too-much-harcoded dependency by editing /var/lib/dpkg/status manually just to be able to cheat dpkg into thinking that the available packages are ok to be installed simultaneously, which is what actually happens most of the time. > Moreover, it loses libc6-locales package version > consistency. I dislike such locales-DATE name. This is merely an aesthetically issue that should not be taken in account. A name is just a name (remember what Shakespeare said about the rose?). You could use glibc-2.2.5-last-one-that-had-to-be-changed and update it to the current version when there is a need. Or you could just drop the name entirely and reintroduce it if the problem reappears. You can use whatever name it looks nicer for you, as far as it changes whenever the interface changes, but changing the name at every release without a *real* need is gratuitous and wrong, IMHO. As a matter of principle, a package should depend on what it *really* needs. > In addition, from my point of view, your idea stands only 'delaying > locales package inconvenient for me, it's suck, the version difference > mitigation is the best way for my architecture, and I have no relation > to such maintenance cost or technically point/right, or package version > consistency'. > > Your idea only focuses glibc, not general. > Is it only glibc related issue? All debian users get nicely with your > idea? If other package hits this problem, then you also do BTS? > Consider what is the problem, please. > [...] > I think it's not only glibc but also more generic (other package > related) issue. IMHO, it's more appropriate that we discuss > at debian-devel, or modify the management of packaging system. > Why do you want to fix only glibc locales package? I reported this against glibc because I think it is a bug in glibc. A testing distribution for unreleased architectures would make this problem invisible. Nobody would notice that glibc packages have a hardcoded "=" dependency, but that would not mean "=" dependencies are a good thing in general. Most of the time, "=" dependencies are wrong in the sense that they ask the user more than it is really needed. (Consider the case of a person who wants to upgrade to testing while minimizing the telephone bill at the same time, we could be forcing this user to upload more MB of data than it is really required). If you can use a string like glibc-2.2.5-last-one-that-had-to-be-changed, that would be a *huge* improvement over the current status, and I don't think it would be so much work for you (feel free to disagree, since you are the maintainer). On the other side, if you think (gratuitous, IMHO) "=" dependencies are ok and the only way to fix this problem is by having a testing distribution for unreleased architectures, then please reassign this bug to the ftp.debian.org virtual package. Thanks.
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 installable. > > Unstable is a freaking moving target. Don't file bugs just because > things don't stay in sync. That's ignorant. Exactly what part of "please reassign to ftp.debian.org" didn't you understand? 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 don't use locales", Ben?
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 don't use locales", Ben? > > > Oh no, I understand that most ppl use locales. The issue is not that. > Most ppl use i386, so most of the ppl who use locales are unaffected. > > The point is we have a real reason that the locales dep is the way it > is. it's not artificial. Old bug reports forced this issue. We will also > continue to pull CVS to keep glibc in sync. Hand picking patches from > CVS for individual problems makes upkeep that much harder, especially > when the next stable comes out. Ok, I understand that you want to keep in sync with CVS, but it is really true that the locales code still changes so often in an incompatible way? The glibc-$DEBVERSION virtual package which libc6 provides seems very similar to the shlibs info, which, if I'm not mistaken, it is updated "when there is a need to". Is there a reason (other than "it's easier") why the string used for this dependency could not be updated as well "when there is a need to"? > The fact is, you are also quite incorrect in your assesment. The problem > only affects two instances: > > 1) New installs from sid (rare seeing as we don't have a sid installer) You are speaking as a i386 user. This is not so rare for unreleased architectures, since sid is the *only* existing distribution. In fact, "I'm using sid" is a meaningful sentence for a i386 user, since he/she could be using woody or sarge instead. For unreleased architectures it's somewhat meaningless, since there is no other distribution to choose from. Currently it's a real pain in the ass to try to install the Hurd from scratch, or upgrade it, when the locales and libc packages are not in sync. You have to edit /var/lib/dpkg/status by hand and edit some of the Provides field. I guess that the same is true for all other unreleased architectures. If we do not make unreleased architectures usable enough, they will never become stable enough to be released. My point is that unreleased architectures should not be second-class citizens, as far as useability is concerned. > 2) Ppl who did not originally have locales installed, but upgraded to > sid, and later decided to install locales. Since this only affects the > random non-serious user of locales, I don't think it affects you or the > "hardcore locales users" you seem to be defending. It's more "users of unreleased architectures", really. > If you are following sid with locales installed, apt will not allow you > to upgrade locales. Of course your currently installed version will > remain working. What's broken about that? Nothing at all that I can see. Again, you seem to speak as a i386 user. There is no such concept of "upgrading to sid" for a hurd-i386 user. They are always running sid, because there is no other distribution to choose from. If they are not even able to install sid from scratch, they hardly will be able to upgrade from the sid-of-yesterday to the sid-of-today. There is a breakage that you don't see: Say that a hurd-i386 user has glibc-2.2 and locales-2.2 installed (I'm dropping debversion numbers for clarity). Say that you upload glibc-2.3 and locales-2.3 for i386, which are recompiled for hurd-i386, and the day after, you upload glibc-2.3.1 and locales-2.3.1, which are not recompiled for hurd-i386 yet. Well, if the hurd-i386 user didn't upgrade to glibc-2.3 and locales-2.3 the day they were both available, he/she will not even be able to upgrade from glibc-2.2 to glibc-2.3 the day after, because that would break locales dependency and apt will not let you to do that. So, if we want unreleased architectures to be useable, we should either eliminate "=" dependencies of very popular arch:all packages on essential-de-facto arch:any packages, or we should create a testing distribution for them. If you are not willing to do anything about the dependencies, please let us agree that a testing distribution is *really* needed. Thanks.
Re: Bug#119526: gettext support for ro_RO
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 > > when I make an upgrade. > > > ISO-8859-16 is the only 8-bit charset which support Romanian language, > ISO-8859-2 is just giving support for one extra letter (a breve) > compared with ISO-8859-1, so I don't see why a Romanian should use it. > > Want to know more about Romanian language? Just let me know... > > > Ionel And this was the reply from Bruno Haible: > I'd like to encourage you to report this to the glibc maintainers. > gettext's locale.alias file is aligned on the one from glibc, and > glibc's Romanian locale still comes in ISO-8859-2 (see > glibc-2.2.5/localedata/SUPPORTED). > > Bruno so I'm reassigning the bug to libc6. Thanks.
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 on glibc-$VERSION at most. The reason glibc-$DEBVERSION was required in the past was that, at some point, there were incompatible locales and libc packages having the same VERSION but different DEBVERSION numbers. This was because the maintainer was introducing new code from CVS without changing the VERSION, which may be considered as a bad practice. So, I request that the dependency is changed again to a non-debversioned one (like glibc-$VERSION) and the maintainer refrains from making incompatible changes without changing $VERSION as well. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 this. libc is Architecture: any. locales is Architecture: all. When you upload a new libc+locales for i386, libc and locales stop being in sync for unreleased architectures like hurd-i386, because the locales available is the new one uploaded by you, while the libc is the last compiled version. > > I think you can make '='-type dependency in locales to be something > > slightly different which achieves the same desired result without > > harming unreleased architectures so much. > > > > The DEBVERSION thing is arbitrary, in some sense. You just need a > > character string which has the property that it changes every time > > there is an incompatible change in the locales code. > > > > Certainly, DEBVERSION has such property, since it *always* changes. > > The problem is that most of the time it changes without real need. > > You could also use a character string of the form locales-DATE, and > > update DATE when (and only when) an incompatibility in the locale > > code is detected. > > Hmm, it increases our maintenance cost. I don't want to make us be > such difficult rule. It's a quite simple rule, not a difficult one. In fact, I think it should be *much* less work for you than the work it imposes on hundreds of people who have to workaround the too-much-harcoded dependency by editing /var/lib/dpkg/status manually just to be able to cheat dpkg into thinking that the available packages are ok to be installed simultaneously, which is what actually happens most of the time. > Moreover, it loses libc6-locales package version > consistency. I dislike such locales-DATE name. This is merely an aesthetically issue that should not be taken in account. A name is just a name (remember what Shakespeare said about the rose?). You could use glibc-2.2.5-last-one-that-had-to-be-changed and update it to the current version when there is a need. Or you could just drop the name entirely and reintroduce it if the problem reappears. You can use whatever name it looks nicer for you, as far as it changes whenever the interface changes, but changing the name at every release without a *real* need is gratuitous and wrong, IMHO. As a matter of principle, a package should depend on what it *really* needs. > In addition, from my point of view, your idea stands only 'delaying > locales package inconvenient for me, it's suck, the version difference > mitigation is the best way for my architecture, and I have no relation > to such maintenance cost or technically point/right, or package version > consistency'. > > Your idea only focuses glibc, not general. > Is it only glibc related issue? All debian users get nicely with your > idea? If other package hits this problem, then you also do BTS? > Consider what is the problem, please. > [...] > I think it's not only glibc but also more generic (other package > related) issue. IMHO, it's more appropriate that we discuss > at debian-devel, or modify the management of packaging system. > Why do you want to fix only glibc locales package? I reported this against glibc because I think it is a bug in glibc. A testing distribution for unreleased architectures would make this problem invisible. Nobody would notice that glibc packages have a hardcoded "=" dependency, but that would not mean "=" dependencies are a good thing in general. Most of the time, "=" dependencies are wrong in the sense that they ask the user more than it is really needed. (Consider the case of a person who wants to upgrade to testing while minimizing the telephone bill at the same time, we could be forcing this user to upload more MB of data than it is really required). If you can use a string like glibc-2.2.5-last-one-that-had-to-be-changed, that would be a *huge* improvement over the current status, and I don't think it would be so much work for you (feel free to disagree, since you are the maintainer). On the other side, if you think (gratuitous, IMHO) "=" dependencies are ok and the only way to fix this problem is by having a testing distribution for unreleased architectures, then please reassign this bug to the ftp.debian.org virtual package. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 installable. > > Unstable is a freaking moving target. Don't file bugs just because > things don't stay in sync. That's ignorant. Exactly what part of "please reassign to ftp.debian.org" didn't you understand? 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 don't use locales", Ben? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#164868: glibc-$DEBVERSION dependency is harmful for unreleased architectures
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 don't use locales", Ben? > > > Oh no, I understand that most ppl use locales. The issue is not that. > Most ppl use i386, so most of the ppl who use locales are unaffected. > > The point is we have a real reason that the locales dep is the way it > is. it's not artificial. Old bug reports forced this issue. We will also > continue to pull CVS to keep glibc in sync. Hand picking patches from > CVS for individual problems makes upkeep that much harder, especially > when the next stable comes out. Ok, I understand that you want to keep in sync with CVS, but it is really true that the locales code still changes so often in an incompatible way? The glibc-$DEBVERSION virtual package which libc6 provides seems very similar to the shlibs info, which, if I'm not mistaken, it is updated "when there is a need to". Is there a reason (other than "it's easier") why the string used for this dependency could not be updated as well "when there is a need to"? > The fact is, you are also quite incorrect in your assesment. The problem > only affects two instances: > > 1) New installs from sid (rare seeing as we don't have a sid installer) You are speaking as a i386 user. This is not so rare for unreleased architectures, since sid is the *only* existing distribution. In fact, "I'm using sid" is a meaningful sentence for a i386 user, since he/she could be using woody or sarge instead. For unreleased architectures it's somewhat meaningless, since there is no other distribution to choose from. Currently it's a real pain in the ass to try to install the Hurd from scratch, or upgrade it, when the locales and libc packages are not in sync. You have to edit /var/lib/dpkg/status by hand and edit some of the Provides field. I guess that the same is true for all other unreleased architectures. If we do not make unreleased architectures usable enough, they will never become stable enough to be released. My point is that unreleased architectures should not be second-class citizens, as far as useability is concerned. > 2) Ppl who did not originally have locales installed, but upgraded to > sid, and later decided to install locales. Since this only affects the > random non-serious user of locales, I don't think it affects you or the > "hardcore locales users" you seem to be defending. It's more "users of unreleased architectures", really. > If you are following sid with locales installed, apt will not allow you > to upgrade locales. Of course your currently installed version will > remain working. What's broken about that? Nothing at all that I can see. Again, you seem to speak as a i386 user. There is no such concept of "upgrading to sid" for a hurd-i386 user. They are always running sid, because there is no other distribution to choose from. If they are not even able to install sid from scratch, they hardly will be able to upgrade from the sid-of-yesterday to the sid-of-today. There is a breakage that you don't see: Say that a hurd-i386 user has glibc-2.2 and locales-2.2 installed (I'm dropping debversion numbers for clarity). Say that you upload glibc-2.3 and locales-2.3 for i386, which are recompiled for hurd-i386, and the day after, you upload glibc-2.3.1 and locales-2.3.1, which are not recompiled for hurd-i386 yet. Well, if the hurd-i386 user didn't upgrade to glibc-2.3 and locales-2.3 the day they were both available, he/she will not even be able to upgrade from glibc-2.2 to glibc-2.3 the day after, because that would break locales dependency and apt will not let you to do that. So, if we want unreleased architectures to be useable, we should either eliminate "=" dependencies of very popular arch:all packages on essential-de-facto arch:any packages, or we should create a testing distribution for them. If you are not willing to do anything about the dependencies, please let us agree that a testing distribution is *really* needed. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#259302: Patch update against base-files 3.1
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 important. In > base-files it is realy simple to do so. > > - If the links are split out of base-files into other debs and those > don't make it to sarge I would still rather patch base-files for > sarge amd64 before I touch anything else. It is the simplest place > to put them. My conclusion: As the symlinks will not be there forever, it's glibc who relies on them, and there might be potential problems at the time of removing them if they are not in the same package as the dynamic linker or libc6, I consider the glibc package should be the one to manage the symlinks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
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 binaries could not > find the dynamic linker anymore. If glibc, which contains all the essential libraries and it's in the best position to do it, have problems creating the symlinks, imagine the *huge* mess that might happen if we finally put the symlinks in base-files and we want to remove it later for multiarch support, considering that base-files and glibc do not have any sort of "sync" between them. That is my main objection for putting the symlinks in base-files. 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 before installing the one from glibc, creating a big window during which /lib64 does not exist at all? In such case I think it would be completely acceptable that the preinst simply manipulates /var/lib/dpkg/info/base-files.list to remove the /lib64 entry from it, so that the Replaces becomes innecessary. I believe dpkg should not have problems installing a symlink when the symlink already exists in the filesystem and does not belong to any package. Sure, it would be a hack, but if the symlink is in base-files, it could be that we need a much bigger hack to remove it later, or worse, it could be that we are in a dead-end and there is no possible hack for the multiarch transition. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
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 before installing the one from glibc, > > creating a big window during which /lib64 does not exist at all? > > glibc (libc6) does not replace base-files. Why should it? Because otherwise the upgrade from an already running amd64 system (which has a modified base-files containing the symlink) would result in dpkg complaining about a file conflict. A Replaces field would allow dpkg to move the ownership of the symlink from base-files to libc in a clean way. However, it there is a time window during which /lib64 does not exist at all it will not work that way. I think that dpkg replaces files from a package with files from the same package (when upgrading it) in an atomic way, it's a pity that it does not seem to do the same for files affected by a Replaces which are moved from one package to another one. I agree that the preinst hack would not be very nice. You could also hack base-files itself (only the amd64 version in the amd64 archives) so that it removes /lib64 from /var/lib/dpkg/info/base-files.list in its preinst at the same time it does no longer ship /lib64 inside the .deb. Then /lib64 would still exist but it would not be "owned" by base-files. After this, libc6 will not need the hack. Then, after libc6 takes care of the symlink, the special version of base-files that contains the symlink could be removed from the amd64 archives so that the usual base-files version is used instead for new installs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
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 /var/lib/dpkg/info/base-files.list to remove > > the /lib64 entry from it, so that the Replaces becomes innecessary. > > Urgs, that is a dirty hack. Also what preinst do you mean? base-files? I was referring to the preinst of libc6 here, read my next message however. It could be better to accumulate all the hacks in the amd64 version of base-files. > IMHO at a minimum the base-files without the /lib64 link has to > predepend on a libc6 with the link and libc6 might have to replace > older base-files to avoid dpkg complaining about overwriting /lib64 > (or is that unneccessary for links of dirs?). > > > I believe dpkg should not have problems installing a symlink when the > > symlink already exists in the filesystem and does not belong to any package. > > > > Sure, it would be a hack, but if the symlink is in base-files, it > > could be that we need a much bigger hack to remove it later, or worse, > > it could be that we are in a dead-end and there is no possible hack > > for the multiarch transition. > > Iirc dpkg does never change a dir to symlink or symlink to dir in > order to preserve the local admins choices (like moving /usr/lib to a > different drive for space reasons). > > Maybe it is enough if base-files predepends on a libc6 with the link > and nothing else. I don't think that will be enough. libc6 and base-files will conflict if they both contain the symlink, but if libc6 has a Replaces: base-files for the symlink, the system might break due to dpkg's not atomic handling of replaces. > Goswin > > PS: Since we are talking unreleased inofficial debs here without any > long time not upgraded systems the base-file predepends could be amd64 > only just until everyone has updated and could then be phased out. We > probably don't need to burden sarge with that. Yes, such unreleased status and the simplicity of the base-files package is exactly why I propose to hack your base-files version a little bit more so that /lib64 is provided without being part of the .deb first, then libc6 can take care of /lib64 without a Replaces: field, and finally you can remove the special amd64 base-files version and use the normal base-files again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
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 > > ..././libc6_2.3.2.ds1-19_amd64.deb) ... > > Unpacking replacement libc6 ... > > dpkg - warning, overriding problem because --force enabled: > > trying to overwrite `/lib64', which is also in package base-files > > Does libc6 replace base-files? Most probably, not. A Replaces: field would produce different messages. It seems --force-overwrite is enabled by default on amd64. You are lucky :-) > > Now I just need to be sure how to package this properly so > > nobody has problems updating libc6 and base-files at the > > same time. Any hint welcome. > > > > > > Kurt > > I was thinking about that and noticed some problem. I haven't checked > the docs or source yet so this is from memory: > > When dpkg updates base-files and libc6 at the same time (and > even when base-files predepends on libc6) the following happens: > > - base-files and libc6 control.tar.gz is unpacked and preinst is run. > > - base-files and libc6 data.tar.gz each are unpacked and obsolete > files are removed. The order can be either way and if base-files is > first we are screwed. > > - libc6 is configured. > > - base-files is configured. > > So the problem is the second step. Is my memory right there or does > dpkg first unpack all debs and only then remove obsolete files? PreDepends are stronger than Depends. If you upload a base-files version which Pre-Depends on the libc6 that contains /lib64, then such libc6 should be unpacked *and* configured first. Unfortunately, removing /lib64 in the preinst does not seem to work (I've just checked). Instead, you probably need a base-files version which *contains* /lib64 in the .deb but removes it from base-files.list in the postinst (not the preinst). > I fear removing the /lib64 from base-files.list in preinst could be > neccessary. Just till every amd64 user has updated. Yes, some hacks will have to be there for some time. It could be like this: a) A new base-files removes /lib64 from base-files.list in postinst. b) Wait until everybody has upgraded. c) Upload libc6 containing /lib64. d) Remove /lib64 from base-files, or just remove the special amd64 base-files version and use the ordinary one, which does not contain /lib64. Upgrading from the version which removed /lib64 from its .list should be safe. So, I think it would be better if base-files stops claiming ownership over /lib64 ASAP, before the symlink is added to libc6. Then there is the problem of new installs (debootstrap). I think the above plan would work for new installs as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#206210
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] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
