Bug#776776: Bug#776778: Please play nicely with resolvconf
On 4 February 2015 at 12:00, Ondřej Surý ond...@sury.org wrote: On Wed, Feb 4, 2015, at 11:14, Axel Beckert wrote: Ondřej Surý wrote: do you think that we can push the resolvconf compatibility to jessie? I see two possible paths here: a) add Breaks: resolvconf That's ok-ish. It would be the short-hack temporary solution and likely suitable for Jessie. okay, this is fairly easy Please do this quickly, closing #776776, and push to Jessie. For post Jessie we can work on making dnssec-trigger compatible with resolvconf, which is bug report #776778. On that topic Dnssec-trigger should certainly not Pre-Depend on resolvconf and should also not Depend on resolvconf. When resolvconf is installed, dnssec should refrain entirely from touching /etc/resolv.conf. This goes for install time and for run time. [...] unless there's a way how dnssec-trigger can hook into resolvconf postinst, it won't play well. Also we will need to have lo.dnssec in first place in the list of priorities and a way how to tell resolvconf to stop after localhost (e.g. trigger TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS when dnssec-trigger is installed). As I mentioned earlier, unbound itself already registers the nameserver address 127.0.0.1 with record name lo.unbound. This matches the pattern lo.!(pdns|pdns-recursor) in /etc/resolvconf/interface-order and thus gets a high priority. So the address 127.0.0.1 will be listed before external addresses. If it turns out that unbound's record needs a different priority than it now has then we (resolvconf maintainers, in a new release of resolvconf) can add a line lo.unbound at the right place in that file. TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS=yes is the default, so we don't need to do anything new in order to cause there to be no further addresses listed after unbound's 127.0.0.1. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776776: Breaks resolvconf
Let this report (#776776) track the issue that dnssec-trigger breaks resolvconf and therefore must declare a Breaks: resolvconf. This can and should be fixed immediately, for jessie. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775356: Please test
Axel, can you please install resolvconf 1.76.1 and check that it works properly? -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775356: New patch
OK, I've pushed code to git as described by the attached patch with
the resulting attached /etc/dhcp/dhclient-enter-hooks.d/resolvconf.
Will be released as 1.77.
--
Thomas
diff --git a/debian/changelog b/debian/changelog
index eb219dd..7f925b8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+resolvconf (1.77) unstable; urgency=medium
+
+ * [eb81ca0] Eliminate bashisms.
+Thanks to Michael Gilbert (Closes: #775356)
+
+ -- Thomas Hood jdth...@gmail.com Fri, 23 Jan 2015 21:46:34 +0100
+
resolvconf (1.76) unstable; urgency=low
* resolvconf.service: Install into sysinit.target, not into
diff --git a/etc/dhcp/dhclient-enter-hooks.d/resolvconf b/etc/dhcp/dhclient-enter-hooks.d/resolvconf
index 529504b..72b2be7 100644
--- a/etc/dhcp/dhclient-enter-hooks.d/resolvconf
+++ b/etc/dhcp/dhclient-enter-hooks.d/resolvconf
@@ -23,7 +23,7 @@ if [ -x /sbin/resolvconf ] ; then
# It gets run later (or, in the TIMEOUT case, MAY get run later)
make_resolv_conf() {
local R
- local nameserver
+ local N
R=
if [ $new_domain_name_servers ] [ $new_domain_name ] ; then
R=${R}domain $new_domain_name
@@ -33,8 +33,8 @@ if [ -x /sbin/resolvconf ] ; then
R=${R}search $new_domain_search
fi
- for nameserver in $new_domain_name_servers ; do
-R=${R}nameserver $nameserver
+ for N in $new_domain_name_servers ; do
+R=${R}nameserver $N
done
[ ! $interface ] || echo -n $R | /sbin/resolvconf -a ${interface}.dhclient
@@ -45,27 +45,27 @@ if [ -x /sbin/resolvconf ] ; then
# It gets run later (or, in the TIMEOUT case, MAY get run later)
make_resolv_conf() {
local R
- local nameserver
- local zone_id
+ local N
+ local N_LOW
+ local ZONE_ID
R=
if [ $new_dhcp6_name_servers ] [ $new_dhcp6_domain_search ] ; then
R=${R}search $new_dhcp6_domain_search
fi
- shopt -s nocasematch
- for nameserver in $new_dhcp6_name_servers ; do
+ for N in $new_dhcp6_name_servers ; do
# If the nameserver has a link-local address
# then add a zone ID (interface name) to it.
-if [[ $nameserver =~ ^fe80:: ]] ; then
- zone_id=%$interface
+N_LOW=$(echo $N | tr '[:upper:]' '[:lower:]')
+if expr $N_LOW : ^fe80:: /dev/null ; then
+ ZONE_ID=%$interface
else
- zone_id=
+ ZONE_ID=
fi
-R=${R}nameserver $nameserver$zone_id
+R=${R}nameserver $N$ZONE_ID
done
- shopt -u nocasematch
[ ! $interface ] || echo -n $R | /sbin/resolvconf -a ${interface}.ip6.dhclient
}
;;
resolvconf
Description: Binary data
Bug#775356: Evolved patch
Here's a cosmetically evolved patch which I'll commit and release
shortly. Thanks!
--
Thomas
diff --git a/etc/dhcp/dhclient-enter-hooks.d/resolvconf b/etc/dhcp/dhclient-enter-hooks.d/resolvconf
index 529504b..cf61615 100644
--- a/etc/dhcp/dhclient-enter-hooks.d/resolvconf
+++ b/etc/dhcp/dhclient-enter-hooks.d/resolvconf
@@ -45,27 +45,26 @@ if [ -x /sbin/resolvconf ] ; then
# It gets run later (or, in the TIMEOUT case, MAY get run later)
make_resolv_conf() {
local R
- local nameserver
- local zone_id
+ local N
+ local N_LOW
+ local ZONE_ID
R=
if [ $new_dhcp6_name_servers ] [ $new_dhcp6_domain_search ] ; then
R=${R}search $new_dhcp6_domain_search
fi
- shopt -s nocasematch
- for nameserver in $new_dhcp6_name_servers ; do
-
+ for N in $new_dhcp6_name_servers ; do
# If the nameserver has a link-local address
# then add a zone ID (interface name) to it.
-if [[ $nameserver =~ ^fe80:: ]] ; then
- zone_id=%$interface
+N_LOW=$(echo $N | tr '[:upper:]' '[:lower:]')
+if expr $N_LOW : ^fe80:: /dev/null ; then
+ ZONE_ID=%$interface
else
- zone_id=
+ ZONE_ID=
fi
-R=${R}nameserver $nameserver$zone_id
+R=${R}nameserver $N$ZONE_ID
done
- shopt -u nocasematch
[ ! $interface ] || echo -n $R | /sbin/resolvconf -a ${interface}.ip6.dhclient
}
;;
Bug#775356: Yep
package resolvconf tags 775356 confirmed stop Hmm, yes, as you say this arises from the fact that isc-dhcp-client's /sbin/dhclient-script switched from #!/bin/bash to #!/bin/sh last September. If you have a patch to send, please send it quickly as this is an RC bug. A fixed release of resolvconf will have to be pushed into testing. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773749: Resolvconf vs wicd
On 14 January 2015 at 16:18, Axel Beckert a...@debian.org wrote: It's up to the admin to change things in /etc/. Programs that play around with things in /etc/ at runtime are not well behaved by Debian standards. Depends. I agree for anything in the maintainer scripts, but I disagree for anything which can be seen as (configuration) editor. Configuration is what the administrator does before starting a service, not what a program does to maintain state at runtime. As the FHS puts it: «The /etc hierarchy contains configuration files. A configuration file is a local file used to control the operation of a program; it must be static [...].» Configuration is thus by definition not dynamic. The list of nameserver addresses obtained via the most recent DHCP negotiation *is* dynamic. Admittedly it is difficult to draw a completely sharp distinction between configuration and state. But the idea behind it, which is clear enough, is that it should be possible to run a Debian machine with the root filesystem (including /etc) mounted read-only. These issues were discussed at some length in 2003, e.g., in the following thread. https://lists.debian.org/debian-devel/2003/03/msg00493.html So as dictated by the FHS, well-behaved programs do not change files in /etc at run time. Resolvconf was introduced in order to deal with the exceptional case of the file /etc/resolv.conf which is under /etc but has to be updated dynamically. In the resolvconf scheme, the dynamic file is on another filesystem and /etc/resolv.conf itself is a static but configurable symbolic link. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773749: Resolvconf vs wicd
On 14 January 2015 at 15:08, Vincent Lefevre vinc...@vinc17.net wrote: On 2015-01-14 14:14:22 +0100, Thomas Hood wrote: This is an allowed configuration (which is sometimes even useful). [...] OK, but this is a very atypical usage for users of wicd, whose goal is to make things work without needing to be root. So what about an option for /etc/default/resolvconf to force the link creation when using dhclient? It's up to the admin to change things in /etc/. Programs that play around with things in /etc/ at runtime are not well behaved by Debian standards. Otherwise the user needs to modify /etc/dhcp/dhclient-enter-hooks.d/resolvconf to get this behavior. Now I have the feeling I'm missing something. Is there some reason that the symlink at /etc/resolv.conf has to be created at run time? Why can't the administrator just do ln -s /run/resolvconf/resolv.conf /etc/resolv.conf to restore the symlink? When the resolvconf package is initially installed it optionally and by default creates the symlink at /etc/resolv.conf, But the symlink got removed for some reason I ignore. I'm wondering whether wicd was the cause (with the code related to the backup file). If so then there might be room for improvement in wicd or in its maintainer scripts. Wicd should not touch a symlink at /etc/resolv.conf. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773749: Resolvconf vs wicd
Hi there and thanks for the report. First I need some info. 1. When (if ever) does wicd modify dhclient.conf? 2. When the malfunction occurs are the contents /run/resolvconf/resolv.conf correct (i.e., what one would expect to find in resolv.conf)? So that the problem is that /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf? -- Thomas Hood resolvconf maintainers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773749: Resolvconf vs wicd
I just read bug report #514597 entitled wicd does not work properly with resolvconf which was closed in version 1.5.9-2 with the message that 07-add_resolvconf_support.patch added. Although I don't see this patch in the current source tree, I do see references to the resolvconf program which indicate that resolvconf is supported by wicd to some extent. $ grep -r resolvconf . [...] wicd-1.7.2.4/wicd/wnettools.py: Checks for the existence of resolvconf. wicd-1.7.2.4/wicd/wnettools.py:self.resolvconf_cmd = self._find_program_path(resolvconf) wicd-1.7.2.4/wicd/wnettools.py:if self.resolvconf_cmd: wicd-1.7.2.4/wicd/wnettools.py:cmd = [self.resolvconf_cmd, '-a', self.iface] We can at least conclude that the problem isn't that wicd has never been adapted to cooperate with resolvconf. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749405: [Resolvconf-devel] Bug#749405: Bug#749405: Current Status + Moving Forward?
Here is a patch which survives some basic testing. The tricky part turns out to be cleaning up after a change to the .service file. The available helpers don't handle this properly. In order to remove the obsolete symbolic link /etc/systemd/system/network.target.wants/resolvconf.service on a system without systemctl installed I resorted to using rm, but I don't know how evil that is. Comments, please. $ git diff debian/1.75..HEAD | cat - diff --git a/debian/changelog b/debian/changelog index 56d3e91..e2a1971 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +resolvconf (1.76) unstable; urgency=medium + + * resolvconf.service: Install into sysinit.target, not into +network.target (Closes: #749405) + + -- Thomas Hood jdth...@gmail.com Tue, 24 Jun 2014 11:50:33 +0200 + resolvconf (1.75) unstable; urgency=low * [49dedb8] Update man page re: dns-nameserver (Closes: 718021) diff --git a/debian/postinst b/debian/postinst index cb50a26..750e350 100755 --- a/debian/postinst +++ b/debian/postinst @@ -29,6 +29,18 @@ rm -f /etc/dhcp3/dhclient-enter-hooks.d/resolvconf # We use dh_installinit with --no-start #DEBHELPER# +### Clean up old symlinks from release 1.75: see #749405 ### +case $1 in + configure) + if [ $2 = 1.75 ] ; then + if which systemctl /dev/null 21 ; then + systemctl reenable resolvconf + else + rm -f /etc/systemd/system/network.target.wants/resolvconf.service || : + fi + fi + ;; +esac ### Create run-time directories and linkify ### # diff --git a/debian/resolvconf.service b/debian/resolvconf.service index 2a7285d..94fde69 100644 --- a/debian/resolvconf.service +++ b/debian/resolvconf.service @@ -11,4 +11,4 @@ ExecStart=/sbin/resolvconf --enable-updates ExecStop=/sbin/resolvconf --disable-updates [Install] -WantedBy=network.target +WantedBy=sysinit.target
Bug#749405: [Resolvconf-devel] Bug#749405: Current Status + Moving Forward?
On 23 June 2014 05:45, Nick Daly nick.m.d...@gmail.com wrote: What still needs to be done on this bug to resolve it? I think it just needs to be tested. Have you tested the proposed fix at all? -- Thomas
Bug#749405: [Resolvconf-devel] Bug#749405: resolvconf: /etc/resolvconf/run/interface either does not exist or is not a directory
Hi all, First of all I must apologize for the inconvenience caused by this bug. Martin, can you please comment? -- Thomas
Bug#746941: Proposed solution
I would suggest that the initscript disable itself in the absence of some non-conffile file in the dnsmasq package. E.g., add a file /usr/lib/dnsmasq/package-is-installed to the package and add a line of code to the beginning initscript like the following. [ -e /usr/lib/dnsmasq/package-is-installed ] || exit 0 The file /usr/lib/dnsmasq/package-is-installed could include a comment explaining the purpose of the file. -- Thomas Hood
Bug#746941: Initscript fails to disable itself when the dnsmasq package is removed
Package: dnsmasq Version: 2.70-1 Severity: serious By means of test -x $DAEMON || exit 0 the initscript disables itself if /usr/sbin/dnsmasq is not installed. But this binary belongs to another package, dnsmasq-base. So the initscript disables itself if and only if that other package, dnsmasq-base, is not installed. Whereas Debian policy says (§9.3.2) that the initscript should disable itself if the package that owns the initscript is not installed. As a result of this error, someone who installs dnsmasq and later removes dnsmasq and not dnsmasq-base still has a fully functional dnsmasq package. A case of this was reported at https://bugs.launchpad.net/debian/+source/dnsmasq/+bug/1315741
Bug#717438: Confirmation
I just tested pdnsd on Debian 7.1 and can confirm that at least the comination pdnsd + resolvconf does not work out of the box (even after setting START_DAEMON=yes in /etc/default/pdnsd). I found two apparent bugs. First, resolvconf -a is not called in the initscript on start. With set -x the initscript output is: + start_resolvconf + test -x /sbin/resolvconf + seq 1 60 + sleep 0.1 + pdnsd-ctl status + break + grep+ -q resolvconf pdnsd-ctl status + sed -ne /^Global:$/,/^Server.*:$/s/.*Server ip.*: \(.*\)$/\1/p + pdnsd-ctl status + server= + exit 0 Something seems to be wrong with the processing of the output from pdnsd-ctl status. The variable server has as value the null string and consequently resolvconf -a doesn't get run. If I subsequently run echo 'nameserver 127.0.0.1' | resolvconf -a lo.pdnsd on the command line then pdnsd starts working. The second bug is in pdnsd's resolvconf update hook script. After running echo 'nameserver 127.0.0.1' | resolvconf -a lo.pdnsd the output of pdnsd-ctl status is: [...] Server 0: -- label: resolvconf ip: 127.0.0.1 server assumed available: yes ip: 192.168.1.254 server assumed available: yes [...] It appears that 127.0.0.1 is now included as a forwarding address. Turning on set -x I can see that /etc/resolvconf/update.d/pdnsd passes both the real forwarding address and 127.0.0.1 as arguments to pdnsd-ctl server resolvconf up. The address 127.0.0.1 should of course be filtered out if it's an address that pdnsd itself is listening on. -- Thomas Hood
Bug#717438: Recall latest pdnsd version
Also tell me if there are any hot alternatives to pdnsd, Most people use dnsmasq for DNS caching. It is very well maintained. -- Thomas
Bug#691973: wicd-daemon.py clobbers /etc/resolv.conf
Op 31 okt. 2012 23:36 schreef David Paleino da...@debian.org het volgende: I've fixed it by taking care of the case where resolv.conf is a symlink. Please note the quotes around fixed. :-) Well let me think. Certainly making the backup does no harm. And restoring a symlink with the same symlink also does no harm. So from resolvconf's perspective you have fixed the present (clobber) bug. Unfortunately, where the daemon does the backup/restore operations, it doesn't know anything about the interfaces -- or whether resolvconf is being used. Anything can always assume that resolvconf is being used if it is installed, i.e., /sbin/resolvconf exists and is executable. P.s. Thanks for responding so quickly. In the future I'll just file reports in the Debian BTS unless the Ubuntu package is relevantly different. P.p.s. Looking forward to trying out wicd. -- Thomas
Bug#691973: wicd-daemon.py clobbers /etc/resolv.conf
Package: wicd
Version: 1.7.2.4-2
Severity: serious
In wicd-daemon.py the main() function backs up and restores
/etc/resolv.conf. To back up it does
shutil.copy2('/etc/resolv.conf', wpath.varlib + 'resolv.conf.orig')
which is like the following shell command.
cp -p /etc/resolv.conf path/resolv.conf.orig
Note that if /etc/resolv.conf is a symbolic link to another file, the
shutil.copy2() copies the contents to the target; it does not create an
equivalent symbolic link at the target.
To restore, it does
shutil.move(wpath.varlib + 'resolv.conf.orig', '/etc/resolv.conf')
which is like the following.
mv path/resolv.conf.orig /etc/resolv.conf
If /etc/resolv.conf was a symbolic link before the backup-and-restore
sequence then afterwards it is a plain file with the contents of the target
of that symlink. Put more bluntly, it clobbers the symlink.
Resolvconf makes use of a symbolic link /etc/resolv.conf -
../run/resolvconf/resolv.conf. Therefore it appears that wicd-daemon.py
will break any system using resolvconf.
I was just reading the wicd code and this bug report arises from that
reading, not from testing. But even if the code in question isn't currently
executed it should be fixed.
Bug#662724:
Thanks a lot for the report. At the point the error occurs, please do the following and post the output: ls -l /etc/resolvconf ls -l /run ls -l /run/resolvconf -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662724:
On Tue, Mar 6, 2012 at 12:02, Hector Oron hector.o...@gmail.com wrote: root@polynomio:/# ls -l /etc/resolvconf total 12 -rw-r--r-- 1 root root 116 Mar 4 16:45 interface-order drwxr-xr-x 2 root root 4096 Mar 6 10:58 resolv.conf.d drwxr-xr-x 2 root root 4096 Mar 4 16:45 update.d Wow, there is no /etc/resolvconf/run! I've never seen that before. Please do: dpkg --purge resolvconf apt-get install resolvconf reboot and again do ls -l /etc/resolvconf and post the results. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662724:
package resolvconf severity 662724 important tags 662724 confirmed pending stop This is a chroot environment created with multistrap From reading about multistrap I gather that multistrap doesn't always run package preinsts. That would explain why /etc/resolvconf/run doesn't get created by the preinst. We'll try to solve this by creating /etc/resolvconf/run and its target in the postinst as well, if needed: http://anonscm.debian.org/gitweb/?p=resolvconf/resolvconf.git;a=commitdiff;h=3f0a1a1663aea9026eae0b623502475491723480 -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657259: [Resolvconf-devel] Bug#657259: resolvconf wipes out /run
/etc/resolvconf/run should point to /run/resolvconf, not to /run. The package's maintainer scripts see to that. Why is your symlink different? I suggest you purge the resolvconf package, install the package again, check that /etc/resolvconf/run points to /run/resolvconf, then reboot. -- Thomas Hood Op 25 jan. 2012 01:39 schreef Antonio Ospite osp...@studenti.unina.it het volgende: Package: resolvconf Version: 1.63 Severity: critical Justification: breaks unrelated software Dear Maintainer, maybe it is just me, but resolvconf breaks udev on my system, so I am setting the severity to critical here, feel free to downgrade the severity if you think this is my fault. That is what is happening: 1. /sbin/resolvconf defines RUN_DIR=/etc/resolvconf/run 2. /etc/resolvconf/run links to /run in my system 3. resolvconf --wipe-runtime-directories does rm -rf $RUN_DIR/* which removes non-resolvconf files from /run After 3., when udev starts I get the message: udevd: Failed to create queue file. No such file or directory. If I set RUN_DIR=/etc/resolvconf/run/resolvconf then udev works again but resolvconf does not work 100%. I also see that ubuntu got rid of the link in /etc/resolvconf/run and just used /run/resolvconf: http://package-import.ubuntu.com/diffs/resolvconf Maybe we could do that too? Thanks a lot for your time. Regards, Antonio Ospite http://ao2.it -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (900, 'unstable'), (600, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages resolvconf depends on: ii debconf [debconf-2.0] 1.5.41 ii initscripts2.88dsf-18 ii lsb-base 3.2-28.1 resolvconf recommends no packages. resolvconf suggests no packages. -- debconf information: * resolvconf/linkify-resolvconf: true resolvconf/reboot-recommended-after-removal: * resolvconf/downup-interfaces: resolvconf/link-tail-to-original: false ___ Resolvconf-devel mailing list resolvconf-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/resolvconf-devel
Bug#651801: [Resolvconf-devel] Bug#651801: resolvconf: /etc/resolv.conf is a broken link after reboot
Hi there, thanks for the bug report and apologies for whatever I've screwed up in version 1.62. Can you please let me know a little more about your configuration? Every time I reboot the system I have to fix /etc/resolv.conf to have DNS working again. Since /etc/resolv.conf - /etc/resolvconf/run/resolv.conf, the later is not automatically created at reboot. I see now that this is actually a symlink to /run which is a tmpfs. What is in your /etc/resolv.conf file after reboot? What exactly do you do to fix it? What do you expect to find in resolv.conf? After reboot, when the anomalous situation pertains, please send directory listings of everything under /etc/resolvconf and /run/resolvconf and the contents of each of the files in those directories. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651801: [Resolvconf-devel] Bug#651801: resolvconf: /etc/resolv.conf is a broken link after reboot
It is possible that this is the same issue as #651827. The issue there is that no update is run at boot, so if your system only uses the base file (and no interface configurers, e.g., ifupdown, dhclient, are run) then your dynamically generated /etc/resolv.conf will be absent. If you think that this may be the same issue, please test the patch I supplied in #651827, or do the following: In the start part of the case statement in the resolvconf init script, insert a resolvconf -u line between the resolvconf --create-runtime-directories line and the resolvconf --enable-updates line. Please let me know whether or not this solves your problem. -- Thomas
Bug#651801: [Resolvconf-devel] Bug#651801: resolvconf: /etc/resolv.conf is a broken link after reboot
Hi there and thanks very much for the additional information. The mere absence of a file /etc/resolv.conf is not a bug. This is an allowed situation if there is no nameserver information; the resolver does not require the file to be present. But from the fact that you are reporting here I infer that something worked before and no longer works in 1.62. * Is there some piece of software which relies upon the target of /etc/resolv.conf existing? What software? * Or is there information missing from (the absent) /etc/resolv.conf? If so, what information is missing and when is it missing? -- Thomas
Bug#651801: [Resolvconf-devel] Bug#651801: resolvconf: /etc/resolv.conf is a broken link after reboot
Hi again Elke, Also, please make the change I described earlier in this bug thread and let me know whether or not this fixes your problem. (The change is to add a resolvconf -u to the initscript just after resolvconf --create-runtime-directories.) -- Thomas
Bug#629186: [Resolvconf-devel] Bug#629186: fails on installation: mkdir: cannot create directory `/etc/resolvconf/run/interface'
On 05/06/11 22:57, Michael Prokop wrote: 3. Please send the content of /proc/mounts I don't have /proc mounted Ah, that explains it. I guess I should test resolvconf installation into a chroot as well as onto a Squeeze virtual machine. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629186: [Resolvconf-devel] Bug#629186: fails on installation: mkdir: cannot create directory `/etc/resolvconf/run/interface'
package resolvconf tags 629186 pending stop Thanks for the report! Yep, it's a bug. Fixed in svn. I'll ask for an upload ASAP. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629186: [Resolvconf-devel] Bug#629186: fails on installation: mkdir: cannot create directory `/etc/resolvconf/run/interface'
Workaround 'til 1.56 is released: Do mkdir /etc/resolvconf/run before installing resolvconf. By the way, it seems that /run/ and /lib/init/rw/ are not available on your system. Why are they unavailable? -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629186: [Resolvconf-devel] Bug#629186: fails on installation: mkdir: cannot create directory `/etc/resolvconf/run/interface'
Hmm. Then I have a couple of questions, since I don't understand why resolvconf's preinst didn't use either /run or /lib/init/rw for run-time data. 1. After doing mkdir /etc/resolvconf/run and then installing resolvconf, is /etc/resolvconf/run a symlink to /run/resolvconf? 2. Please send the output of ls -ld /run. 3. Please send the content of /proc/mounts -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628524: Re #628524: What to do?
So one solution is for all suppliers of nameserver information to include resolvconf packaging-event hook scripts. But that is what we can call an, ahem, long-term solution. In the meantime, how can we address the problem? The crux of the problem is 1. resolvconf (normally) omits the external nameserver address from resolv.conf when dnsmasq or another caching nameserver is installed; 2. resolvconf postrm leaves the contents of resolv.conf unchanged on removal. Though neither behavior is cast in stone, both (1) and (2) are done for good reasons. I am reluctant to change either behavior and I am also reluctant to do something ugly such as appending /var/run/dnsmasq/resolv.conf to /etc/resolv.conf on remove. If anyone has any other ideas, let's hear them. One quick win (done for 1.55) is to print a Reboot recommended message in the postrm. We should turn this into a debconf note so that it can be translated. In the absence of new ideas I will just do this. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628524: pending
package resolvconf tags 628524 pending stop I have added the debconf note for release 1.55. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628524: Bug on purge and reinstall
there seems to be a nasty bug when resolvconf is installed, purged and installed again. Here is what happens, assuming no nameserver information suppliers yet include resolvconf dpkg-event hook scripts. Debian system boots up. Some interface configurer configures a network interface and obtains an external nameserver address. Dnsmasq starts. * /etc/resolv.conf lists both external nameserver address and loopback address (for dnsmasq) Install resolvconf * /run/resolvconf/interface/original.resolvconf lists both addresses * /etc/resolv.conf lists both addresses * /var/run/dnsmasq/resolv.conf lists both addresses[*] Resolvconf update * /run/resolvconf/interface/original.resolvconf lists both addresses * /etc/resolv.conf lists only loopback address * /var/run/dnsmasq/resolv.conf lists both addresses[*] Purge resolvconf * /etc/resolv.conf lists only loopback address * /var/run/dnsmasq/resolv.conf lists both addresses, but dnsmasq will no longer look at this file if it is restarted. Install resolvconf * /run/resolvconf/interface/original.resolvconf lists only loopback address * /etc/resolv.conf lists only loopback address * /var/run/dnsmasq/resolv.conf lists only loopback address End. The external nameserver address has been lost. The only solution is to reboot. [*] This is already wrong. The loopback address should not be included in /var/run/dnsmasq/resolv.conf. However, dnsmasq ignores loopback addresses so no great harm done. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628524: Bug on purge and reinstall
(cont'd) Here is what happens if nameserver information suppliers *DO* include resolvconf dpkg-event hook scripts. Debian system boots up. Some interface configurer configures a network interface and obtains an external nameserver address. Dnsmasq starts. * /etc/resolv.conf lists both external nameserver address and loopback address (for dnsmasq) Install resolvconf * /run/resolvconf/interface/original.resolvconf lists both addresses * /etc/resolv.conf lists both addresses * /var/run/dnsmasq/resolv.conf lists both addresses Resolvconf update * /run/resolvconf/interface/original.resolvconf lists both addresses * /etc/resolv.conf lists only loopback address * /var/run/dnsmasq/resolv.conf lists both addresses Purge resolvconf * /etc/resolv.conf lists both addresses because the interface configurer inserts its nameserver address into resolv.conf again. End. The original situation has been recreated. There is no problem! Now here's what happens if nameserver information suppliers include resolvconf dpkg-event hook scripts *and* the include- original-nameserver-information workaround is removed. Debian system boots up. Some interface configurer configures a network interface and obtains an external nameserver address. Dnsmasq starts. * /etc/resolv.conf lists both external nameserver address and loopback address (for dnsmasq) Install resolvconf * /etc/resolv.conf lists loopback address * /var/run/dnsmasq/resolv.conf lists external address Purge resolvconf * /etc/resolv.conf lists both addresses End. The original situation has been recreated. There is no problem at all! These scenarios are fiction, however, because suppliers of nameserver information don't cooperate when they write to /etc/resolv.conf as is assumed in the purge resolvconf results above. The idea that all suppliers of nameserver information will actually include resolvconf dpkg-event hook scripts within our lifetimes is, furthermore, highly fantastic. -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628524: Keep 1.54 out of testing
Package: resolvconf Version: 1.54 Severity: serious Keep version 1.54 out of testing. One reason is that the definitive directory for packaging-hook-scripts will be another than the one employed in 1.54 and we don't want people to start using the wrong directory. Another is that there seems to be a nasty bug when resolvconf is installed, purged and installed again. Under investigation. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627691: Prevent 1.52 from entering testing
Package: resolvconf Version: 1.52 Severity: serious Version 1.52 should not enter testing. Version 1.53 will soon be uploaded with a different solution to #567059. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570896: NMU to delayed/5 of resolvconf
Marco wrote: I agree with all changes. If you all agree, I could tag and upload version 1.46 now. Thanks for taking care of this, Marco. I made the necessary changes in svn some days ago but due to lack of time didn't get around to requesting an upload. Also, good for you for noticing that the debhelper dependency needed to be made more strict (... strictened?...). Cheers! -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570896: Please test resolvconf 1.46
Help, I am getting these messages [...] Hi. I have prepared a release candidate for resolvconf 1.46 which addresses this issue. The version number is currently (in svn revision 145) set to 1.46~4. Can you please check out, build and install this version and report your results back here? $ svn info [...] Repository Root: svn+ssh://jdthood-gu...@svn.debian.org/svn/resolvconf -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582755: Incompatible with resolvconf
dnscache-run modifies /etc/resolv.conf. So do several other packages. All these packages overwrite one another's changes. That is bad. The resolvconf package was created in order to resolve this and related problems. Resolvconf allows packages to add information to the resolver configuration file without conflicting with one another. See the resolvconf package's README for a full explanation. Most caching nameservers are compatible with resolvconf but dnscache-run is not (yet). If everyone agrees then I will retitle this report Please make dnscache-run compatible with resolvconf and, if needed, provide more information about how to make dnscache-run compatible with resolvconf. That's a *wish*. The only real *bug* at present is the fact that dnscache-run conflicts with every other package that writes to /etc/resolv.conf, including resolvconf. In order to deal with this from the resolvconf end of things I will add a Conflicts: dnscache-run to the next release of resolvconf. The issue of whether any package has the right to alter /etc/resolv.conf is an issue affecting several packages and should be discussed on debian-devel before any bug reports are filed. Note that resolvconf does not write to /etc/resolv.conf but to a file under /lib/init/rw/ to which /etc/resolv.conf is symlinked. -- Thomas Hood Member of the resolvconf maintainers team -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514411: [Resolvconf-devel] Bug#514411: resolvconf breaks all network operations
We need to figure out why resolvconf is not functioning correctly on your system. Resolvconf writes the resolver configuration file on the basis of information provided to it. If nothing provides it with nameserver addresses then it writes an empty resolv.conf file. What nameservers are available to your system which resolvconf doesn't know about? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514411: Fwd: Bug#514411: [Resolvconf-devel] Bug#514411: resolvconf breaks all network operations
Through which network interface can those nameservers be reached? How is that network interface configured? -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514411: Fwd: Bug#514411: [Resolvconf-devel] Bug#514411: resolvconf breaks all network operations
iface eth0 inet static address 172.17.207.12 gateway 172.17.207.1 netmask 255.255.255.0 I'll assume that interface eth0 is configured using the ifup command. Add this line to the iface eth0 stanza in /etc/network/interfaces dns-nameservers 172.17.207.1 172.17.207.18 Then do, as root: ifdown eth0 ifup eth0 Then your resolv.conf file should be correct. Please read resolvconf(8) and the README file in/usr/share/doc/resolvconf for background information. -- Thomas Hood -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514049: [Pkg-mwavem-devel] Bug#514049: mwavem package does not install under Lenny
Do you have a need for this package? -- Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477752: [Resolvconf-devel] Bug#477752: resolvconf: Don't reinstall init script on upgrades
tags 477752 confirmed pending stop On Fri, 2008-04-25 at 00:17 +0200, Jörg Sommer wrote: Policy 10.7.3 says you must preserve user changes during upgrades, but on upgrade (or reinstall) the init script level gets changed. I've a different ordering of the services due to insserv and if you reset the level on every upgrade, you destroy my settings. Thanks for the report. This will be fixed in the next release. To my fellow resolvconf developers: When I run lintian I get the following warning: W: resolvconf: manpage-has-errors-from-man usr/share/man/man8/resolvconf.8.gz 67: warning: `EX' not defined What is the best way to fix this? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400141: thinkpad-source: No rule to make target
gulfstream wrote: How to do if I want use some thinkpad device such as SMAPI? Check out the tp_smapi driver: http://thinkwiki.org/wiki/Tp_smapi -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364235: [Pkg-tpctl-devel] Bug#364235: thinkpad-base: bad interaction with udev 0.090-2: *all* devices end up group 'thinkpad' (?!)
Chip Salzenberg wrote: On reboot with udev 0.090-2, I found /dev/null was group 'thinkpad' and mode 664, a bad thing. Further inspection revealed that *all* nodes were group 'thinkpad' and *no* nodes had the world-write bit enabled, a very bad thing. Reverting to udev 0.090-1 fixed the problem. Md: Do you think this is a udev bug or a thinkpad-base bug? [EMAIL PROTECTED]:/etc/udev$ cat thinkpad.rules # Set permissions on thinkpad device KERNEL=thinkpad, MODE=0664, GROUP=thinkpad -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364235: [Pkg-tpctl-devel] Bug#364235: thinkpad-base: bad interaction with udev 0.090-2: *all* devices end up group 'thinkpad' (?!)
Marco d'Itri wrote: If replacing the line with its correct form fixed it, then it would be a thinkpad-base bug: KERNEL==thinkpad, MODE=0664, GROUP=thinkpad 0.090-2 introduced some code which exposes incorrect usage of =/== (see the Debian changelog for details). OK, we will make a new thinkpad release with s/KERNEL=/KERNEL==/ soon. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357456: [Pkg-alsa-devel] Bug#357456: error in postinst script
tags 357456 confirmed pending stop Julien Danjou wrote: The postinst script of alsa-utils is not writtent correctly: You're right---thanks for the report. Fixed in svn. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357106: [Pkg-alsa-devel] Bug#357106: alsaconf modifies modules.conf unrelatedly
Jeroen van Wolffelaar wrote: Running alsaconf, my modules.conf was modified: -alias net-pf-10 off# IPv6 +# alias net-pf-10 off # IPv6 alsaconf runs update-modules after modifying /etc/modutils/sound. If you made changes to files in /etc/modutils/ without running update-modules then those changes will show up after you run alsaconf. That isn't a bug; that's how update-modules is supposed to be used. I assume that the alias net-pf-10 off line is commented out in your /etc/modutils/aliases file, which is the source of that line in /etc/modules.conf. alsaconf doesn't touch that file. [...] Also, there is no dry-run option what would list the proposed modifications, and alsaconf is very chatty. While nice, in most cases I guess it can be much less so, and actually with only slight modifications cause sound to work out-of-the-box: autodetected at bootup, without writing anything to a configuration file? Actually I would like to modify alsaconf so that it doesn't write out configuration files any more but only prints information on the console. What you should understand is that alsaconf isn't needed in most cases. We provide it because it's apparently still useful for configuring ISA sound cards and for debugging. -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355436: More info, please
In report #355436 we will deal with the claim that upgrading the initscripts package caused files in /tmp to be deleted. I have set the severity level to critical on the assumption that this actually occurred and that it occurred during upgrade. Please let us know whether or not this assumption is correct. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342887:
retitle 342887 util-linux: hwclock runs at the wrong point in the rcS.d sequence stop I have two newly installed (this week) Sarge systems that exhibit this problem. I used the debian-31ra1a-i386-netinst image and /usr is in the root filesystem. I told the diaglog that the hardware was localtime, my timezone is EST, and to observe daylight savings. I do not understand why I am having this problem as that it seems the trigger is having a separate /usr and HW clock set to local. Did I miss something in the explination above? I have made no customizations to my timezone settings anywhere other than the install dialogs. There is a bug in util-linux: hwclockfirst.sh is not run early enough. hwclockfirst.sh should be run earlier than checkroot.sh so that the system clock gets correctly set before fsck is run. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346148: [Pkg-sysvinit-devel] Bug#346148: checkroot.sh: does not properly handle fsck exit states
tags 346148 fixed-in-experimental patch pending severity 342160 critical merge 346148 342160 found 346148 2.86.ds1-4 stop Wouter Verhelst wrote: I just noticed that my laptop, at bootup, started an fsck for the root filesystem, claiming that it was a filesystem with errors. When it was about 20% done, it exited, and told me to rerun it manually. I expected a prompt for my root password and to be put in single-user mode, but this did not happen; instead, my system did a normal boot. This should _never_ happen! If the fsck fails, all sorts of bad things might have happened with the file system; continueing the boot at that point is a very good way to lose all your data. Thanks for reporting the bug. checkroot.sh in at 2.86.ds1-[46] contains a bug such that the return status of fsck is ignored. This bug has been fixed in more recent releases (to experimental). Additional info: Reading checkroot.sh I see that it only continues with booting if the fsck return status is 0 or 1. If the status is 2 or 3 then the system is rebooted after five seconds. If the status is greater than 3 then a shell is started. The comment in checkroot.sh says A return code of 1 indicates that file system errors were corrected but that the boot may proceed. The fsck(8) and fsck.ext3(8) man pages say that 1 means File system errors corrected. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#237056: udev breaks bootlogd
Marco d'Itri wrote: This is what I do on my system and it works fine, but I'd rather split mountvirtfs which is the correct solution. OK, what if I split mountdevsubfs out of mountvirtfs and run it at S04 and S37. Then udev can move its script to S03 so that it mounts /dev between S02mountvirtfs and S04mountdevsubfs. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343555: [Pkg-alsa-devel] Bug#343555: alsa-source: fails to configure with bash 3.1 as /bin/sh
tags 343555 pending stop Aaron M. Ucko wrote: Package: alsa-source Version: 1.0.10-2 Severity: grave Justification: renders package unusable alsa-source's config script fails on my system (which has bash 3.1-1 installed as /bin/sh); AFAICT, the problem is constructs such as ALSA_NOPNP=$(. /etc/alsa/alsa-source.conf /dev/null 21 ; echo $ALSA_NOPNP) Right. Will fix this right away. -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343555: [Pkg-alsa-devel] Bug#343555: alsa-source: fails to configure with bash 3.1 as /bin/sh
Please test 1.0.10-3 which is now in incoming http://incoming.debian.org or unstable. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339136: Which packages rely on the old stat behavior?
If the solution is going to be: to fix the programs that use the stat program so that they work either with the old or with the new behavior, and/or to add versioned Conflicts to coreutils for each package version containing a program that depends on the old behavior, then I would suggest that someone perform a systematic search through current Debian packages looking for the stat command so that all the required Conflicts can be added at once. (I don't know how to do such a search. I'd be interested to know.) -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341075: Keep 2.86.ds1-6 out of testing
Package: initscripts Version: 2.86.ds1-6 Severity: serious We should probably keep 2.86.ds1-6 out of testing since we know it contains bugs and we have another release almost ready for unstable. pere: Please just close this if you disagree. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340935: Netcfg - hotplugging config no longer works with 2.6.14 + udev
After some testing I've determined that the following configuration (in /etc/network/interfaces) does work: snip mapping eth0 script grep map eth0 allow-hotplug eth0 iface eth0 inet dhcp /snip NOTE: I'm not sure if this is the correct/optimal solution. This new config will probably not work if package hotplug _is_ installed. Question is if netcfg should also still support that situation. Can a configuration be found that will work for both situations? Hotplug itself was modified to use the allow mechanism. hotplug (0.0.20040329-25) unstable; urgency=low ... * NET_AGENT_POLICY is deprecated. use ifupdown allow mechanism instead. closes: Bug#303383 So, it should suffice if netcfg is modified to write /etc/network/interfaces that employ the new allow mechanism, in the manner you suggested. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340688: /etc/init.d/initrd-tools.sh exits
Package: initrd-tools Version: 0.1.84 Severity: serious Debian Policy states (§9.3.1): Also, if the script name ends `.sh', the script will be sourced in runlevel `S' rather that being run in a forked subprocess, but will be explicitly run by `sh' in all other runlevels. Accordingly, .sh scripts run from /etc/rcS.d/ should not do exit. /etc/init.d/initrd-tools.sh is run from /etc/rcS.d/ and it does do exit. $ grep exit /etc/init.d/initrd-tools.sh [ $KEEPINITRD = yes ] exit command -v blockdev /dev/null 21 || exit 0 mount -n /proc || exit grep -q '^[^ ]* /initrd ' /proc/mounts || exit 0 umount /initrd/dev || exit umount /initrd || exit exit 1 This prevents sysv-rc from obeying policy §9.3.1. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (700, 'unstable'), (400, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-3-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.93-5 The GNU core utilities ii cpio 2.6-9 GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.2-8The Debian Almquist Shell ii fileutils 5.93-5 The GNU file management utilities ii util-linux2.12p-8Miscellaneous system utilities initrd-tools recommends no packages. -- no debconf information
Bug#340689: /etc/rcS.d/S05keymap.sh exits
Package: console-common Version: 0.7.54 Severity: serious Debian Policy states (§9.3.1): Also, if the script name ends `.sh', the script will be sourced in runlevel `S' rather that being run in a forked subprocess, but will be explicitly run by `sh' in all other runlevels. Accordingly, .sh scripts run from /etc/rcS.d/ must not do exit. /etc/init.d/keymap.sh is run from /etc/rcS.d/ and it does do exit. S05keymap.sh:command -v loadkeys /dev/null 21 || exit 0 S05keymap.sh: [ $CONSOLE_TYPE = serial ] exit 0 S05keymap.sh: exit 1 This prevents sysv-rc from obeying policy §9.3.1. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (700, 'unstable'), (400, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-3-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages console-common depends on: ii console-data2002.12.04dbs-50 Keymaps, fonts, charset maps, fall ii console-tools 1:0.2.3dbs-58Linux console and font utilities ii debconf [debconf-2.0] 1.4.59 Debian configuration management sy ii debianutils 2.15.1 Miscellaneous utilities specific t ii kbd-compat [kbd]1:0.2.3dbs-58Wrappers around console-tools for ii lsb-base3.0-11 Linux Standard Base 3.0 init scrip console-common recommends no packages. -- debconf information: console-data/keymap/powerpcadb: console-data/keymap/ignored: console-data/keymap/full: console-data/keymap/template/keymap: * console-data/keymap/policy: Don't touch keymap console-data/bootmap-md5sum: none console-data/keymap/template/layout: console-data/keymap/family: qwerty console-data/keymap/template/variant:
Bug#339955: TODO
Before /etc/init.d/rc can source .sh scripts, all we have to do is get
various maintainers to eliminate all these exit commands.
/etc/rcS.d$ grep exit *.sh
S01glibc.sh:exit_check () {
S01glibc.sh:exit 1
S01glibc.sh:exit_check
S01glibc.sh:exit_check
S01glibc.sh:exit_check
S01glibc.sh:exit_check
S01glibc.sh:exit_check
S01glibc.sh:exit_check
S01glibc.sh:exit_check
S01glibc.sh:exit_check
S01glibc.sh:exit_check
S01glibc.sh:exit 0
S05initrd-tools.sh:[ $KEEPINITRD = yes ] exit
S05initrd-tools.sh:command -v blockdev /dev/null 21 || exit 0
S05initrd-tools.sh: mount -n /proc || exit
S05initrd-tools.sh:grep -q '^[^ ]* /initrd ' /proc/mounts || exit 0
S05initrd-tools.sh: umount /initrd/dev || exit
S05initrd-tools.sh:umount /initrd || exit
S05initrd-tools.sh: exit 1
S05keymap.sh:command -v loadkeys /dev/null 21 || exit 0
S05keymap.sh: [ $CONSOLE_TYPE = serial ] exit 0
S05keymap.sh: exit 1
S10checkroot.sh:# NOTE: failure is defined as exiting with a return
code of
S10checkroot.sh:exit 3
S10checkroot.sh:exit 3
S10checkroot.sh:: exit 0
S22hwclockfirst.sh:[ ! -x /sbin/hwclock ] exit 0
S22hwclockfirst.sh: exit 1
S22hwclockfirst.sh: *)log_failure_msg Unknown UTC setting:
\$UTC\; exit 1 ;;
S22hwclockfirst.sh: *)log_failure_msg unknown BADYEAR setting:
\$BADYEAR\; exit 1 ;;
S22hwclockfirst.sh: exit 1
S30checkfs.sh: exit 3
S30checkfs.sh: exit 3
S30checkfs.sh:: exit 0
S30procps.sh:# Check for existance of the default file and exit if not there,
S30procps.sh:[ -r /etc/default/rcS ] || exit 0
S30procps.sh:which sysctl /dev/null || exit 0
S30procps.sh: exit 0
S30procps.sh: exit 1
S35mountall.sh: exit 3
S35mountall.sh: exit 3
S35mountall.sh:: exit 0
S40hostname.sh: exit 3
S40hostname.sh: exit 3
S45mountnfs.sh: exit 3
S45mountnfs.sh: exit 3
S45mountnfs.sh:: exit 0
S48console-screen.sh:[ -x ${SETFONT} ] || exit 0
S48console-screen.sh:CONSOLE_TYPE=`fgconsole 2/dev/null` || exit 0
S48console-screen.sh:[ $VT = no ] exit 0
S50hwclock.sh:[ ! -x /sbin/hwclock ] exit 0
S50hwclock.sh: exit 1
S50hwclock.sh: *) log_failure_msg Unknown UTC setting: \$UTC\; exit 1
;;
S50hwclock.sh: *) log_failure_msg unknown BADYEAR setting:
\$BADYEAR\; exit 1 ;;
S50hwclock.sh: exit 1
S55bootmisc.sh: exit 3
S55bootmisc.sh: exit 3
S55bootmisc.sh:: exit 0
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339955: not really serious
severity 339955 normal stop This bug is ranked serious because sysvinit is supposedly violating policy. I think that §9.3.1 should be seen as a description of how the system works, not as a prescription. The quoted paragraph can be interpreted as a warning to initscript authors that if they assign to their scripts names with '.sh' suffixes then these scripts may be sourced instead of executed; so they should code accordingly. Certainly initscript authors should not _assume_ that their .sh scripts are sourced (and then, e.g., try to alter the behavior of scripts sourced later by playing with the environment). -- Thomas Hood
Bug#339955: breaks unrelated packages?
What packages are broken by the fact that sysv-rc does not source .sh scripts? We know of one package that is broken if sysv-rc _does_ source.sh scripts. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339955: sysv-rc: /etc/init.d/*.sh should be sourced in runlevel S
Brendan O'Dea wrote: there are quite a few instances in /etc/init.d/*.sh scripts where exit is called. All the exit commands are either (1) at the end of usage exception sections, or (2) preceded by colons ':'. Testing suggests that a : exit 0 does the same as :, namely, nothing. Miquel: What is the purpose of those : exit 0 commands? Do they have an effect under some conditions? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339955: sysv-rc: /etc/init.d/*.sh should be sourced in runlevel S
Brendan O'Dea wrote: Note: I believe that return should work to exit from a script both when sourced and when executed but perhaps someone with a copy of POSIX could confirm. Disconfirmation: $ cat /tmp/s #!/bin/bash echo foo return echo bar [EMAIL PROTECTED]:~/src/sysvinit/pkg-sysvinit/sysvinit/trunk/debian/initscripts/etc/init.d$ /tmp/s foo /tmp/s: line 3: return: can only `return' from a function or sourced script bar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325142: [Pkg-alsa-devel] Bug#325142: Don't understand, seems like circular issue
Steve Strong wrote: If nothing, could this be rebuilt for testing with the testing version of udev (.056-3)? At least until udev resolves their many issues and get's a newer version into testing... I am not going to do this, but I have no objection if someone else rolls alsa-utils in testing back to 1.0.9a-3. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323331: [Pkg-alsa-devel] Bug#323331: [patch] ld10k1 not 64bit clean.
tags 323331 pending thanks Zephaniah E. Hull wrote: The attached patch fixes the bitops to be independent of the size of longs, and is confirmed to fix the bug on my box. Applied in svn. Thanks! -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319156: Needs repackaging for latest aspell
Thijs Kinkhorst wrote: Since aspell-nl now has an RC bug (#319156) it might be the right time to adopt the package? I don't want to be the chief maintainer, but I am prepared to help with the packaging as general packaging mankracht. For this to work, the package must be in svn on alioth (or equivalent). -- Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309581: Deinstalling udev
On Sun, 2005-05-22 at 12:00 +0200, Marco d'Itri wrote: If alsa-base does not use MAKEDEV, then alsa-base is buggy. OK, this will be fixed in 1.0.9-1. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309883: Why grave?
What is the justification for assigning this bug report a severity level of grave? Clearly the program isn't unusable. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215773: postfix still does addgroup without --system
[EMAIL PROTECTED]:/var/lib/dpkg/info$ grep addgroup postfix.preinst [ -x /usr/sbin/addgroup ]; then addgroup postdrop || true -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302519: t-p-u upload?
If bug #304188 in ifupdown 0.6.6 won't be fixed in time for sarge then I have a 0.6.4-4.13 version ready which fixes #302519 in ifupdown 0.6.4-4.12. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304188: Does 0.6.4-4.12 work properly?
Does 0.6.4-4.12 work properly? -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303656: More info needed
Setting up ifupdown (0.6.6) ... Moving /etc/network/ifstate to /etc/network/run/ifstate mv: writing `/etc/network/run/ifstate': No space left on device Please send the output of: df ls -l /etc/network ls -l /etc/network/run ls -l /dev/shm ls -l /dev/shm/network Severity: critical Justification: breaks the whole system How was your whole system broken? -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302519: ifupdown: postinst fails if /dev/shm/network/ does not exist
On 1 Apr 2005 12:07:05, Stefan Kluth wrote: On Fri, 1 Apr 2005, Thomas Hood wrote: What version of the initscripts package do you have? [EMAIL PROTECTED]:~$ apt-cache show initscripts [...] Version: 2.86.ds1-1 Please do dpkg -s initscripts|grep Version. On Mon, 2005-04-04 at 17:38 +0200, Stefan Kluth wrote: [EMAIL PROTECTED]:~$ ls -l /lib/init/readlink ls: /lib/init/readlink: No such file or directory [EMAIL PROTECTED]:~$ which readlink /bin/readlink Thanks for the additional information. This confirms that the problem was an outdated initscripts package. Current initscripts contains a /lib/init/readlink program which works around the problem in the current coreutils readlink program. This will be fixed when I can find someone to sponsor an upload. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302519: unreproducible
I am unable to reproduce the failure, so I speculate that the failure only occurs when certain combinations of packages are installed. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302680: Inadequate copyright information
Package: zeroconf Version: 0.2-1 Severity: serious The copyright file says: It was downloaded from http://www.progsoc.org/~wildfire/zeroconf/ That URL reports Your browser requested a page that could not be found: Copyright: This line must be of the form: Copyright (C) date copyright-holder (The (C) is optional, I think, but it is safer to put it in.) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages zeroconf depends on: ii ifupdown0.6.4-4.12 high level tools to configure netw ii iproute 20041019-3 Professional tools to control the ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302585: Please shorten hook script name
Package: zeroconf Version: 0.2-1 Severity: serious The ifup hook script is currently called '/etc/network/if-up.d/zeroconf-up'. There is no need for an '-up' suffix because the file is in the if-up.d directory. Other packages follow the convention of naming their hook scripts after themselves, without an -up or down suffix. Please follow this convention. I have filed this at an RC severity in order to prevent the package from migrating to testing while you consider this issue. I only do this for convenience. Once the package is in testing there is more of an obligation to implement these changes in a foolproof manner, which in this case requires renaming code in the preinst. So long as the package is only in unstable I think you should feel free simply to rename the file. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages zeroconf depends on: ii ifupdown0.6.4-4.12 high level tools to configure netw ii iproute 20041019-3 Professional tools to control the ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302519: ifupdown: postinst fails if /dev/shm/network/ does not exist
On Fri, 2005-04-01 at 10:45 +0200, Stefan Kluth wrote: Setting up ifupdown (0.6.4-4.12) ... From which version did you upgrade? ifupdown.postinst: Error: The canonical path of /etc/network/run could not be determined. Aborting. Do you have the /lib/init/readlink program? Please send the output of ls -l /lib/init/readlink. Please do grep PATH /var/lib/dpkg/info/ifupdown.postinst. It will be helpful if you can reproduce the failure. Please remove the package with dpkg --remove --force-depends and reinstall it. (Make sure you have the package available locally so you don't need to access the network in order to reinstall.) You may have to install the version of ifupdown you had before, and upgrade to 0.6.4-4.12, in order to reproduce the problem. If the postinst fails again then please send the output of ls -l /etc/network ls -l /etc/network/run ls -l /dev/shm ls -l /dev/shm/network /lib/init/readlink -f /etc/network/run /bin/readlink -f /etc/network/run cat /proc/mounts dpkg: error processing ifupdown (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: ifupdown After googling for a few minutes I found that Can you give me the URL where you saw information about this problem? -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302519: severity serious
severity 302519 serious thanks This bug should be fixed for sarge. In looking for the cause of the bug I have realized that ifupdown is missing a versioned Dependency on initscripts which supplies a necessary version of the readlink program; this alone justifies another sarge-targeted release. However, because the submitter had a satisfactory version of initscripts installed, I don't yet know where the bug lies. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302519: Bug #302519: ifupdown: postinst fails
Thanks a lot for the input.
On Fri, 2005-04-01 at 23:13 +0100, Henning Makholm wrote:
To the submitter: A better short-term workaround if you prefer not to
edit conffiles that are hopefully going to be fixed soon, is to do
# mkdir /var/run/network
# ln -sf /var/run/network/ /etc/network/run
Otherwise the underlying bug might show up next time you boot, anyway.
That can be done as a workaround. It can't be the default because on
some systems /var/ is network mounted.
The problem is that readlink -f /etc/network/run returns nothing and
exits with failure when /etc/network/run is a dangling symlink, so the
mkdir that is the point of this code never gets a chance to run.
The code depends on the presence of a correctly working readlink
program. Woody debianutils readlink did the right thing and so does
upstream-unreleased coreutils 5.3.0. To work around the fact that
sarge/sid coreutils 5.2.1 does the wrong thing when the ultimate target
of the symlink chain does not exist, we use the
substitute /lib/init/readlink program included in current initscripts
packages.
[EMAIL PROTECTED]:~$ cd /tmp
[EMAIL PROTECTED]:/tmp$ ln -s foo bar
[EMAIL PROTECTED]:/tmp$ /bin/readlink -f bar
[EMAIL PROTECTED]:/tmp$ echo $?
1
[EMAIL PROTECTED]:/tmp$ /lib/init/readlink -f bar
/tmp/foo
[EMAIL PROTECTED]:/tmp$ echo $?
0
The postinst sets
PATH=/lib/init:/sbin:/bin:/usr/sbin:/usr/bin
so that the substitute version of the program gets run.
The submitter has an appropriate version of initscripts installed, so he
should be getting the right version of the readlink program.
ifupdown is missing a versioned Dependency on initscripts so we will
need to make a new version for sarge which adds it, but this doesn't
seem to have been the cause of the failure on the submitter's system.
Code that depends on readlink -f being able to stop at a dangling
symlink also appears in /etc/init.d/{ifupdown,ifupdown-clean}
and will abort the boot initialization on systems where
/etc/network/run refers to a ramdisk. (Which I suppose is the default,
as I do not remember having done anything to redirect /etc/network/run
myself).
/etc/init.d/ifupdown also set the PATH in order to get the fixed
readlink program.
/etc/init.d/ifupdown-clean does not set the PATH because it does not
need the fixed readlink program; the current coreutils readlink program
only deviates in its behavior if the ultimate target does not exist,
whereas ifupdown-clean only calls the readlink program if the ultimate
target does exist.
Refusing to work with dangling links is the documented behavior in GNU
readlink, so coreutils probably cannot be faulted for this.
Well, upstream changed the behavior back to the old way for 5.3.0.
A
quick-and-dirty workaround that should work in the most common cases
would be to say
$(readlink -f /etc/network/run || readlink /etc/network/run)
instead of just
$(readlink -f /etc/network/run)
in all three affected files.
Interesting idea, but it isn't that simple. For one thing, readlink
without -f prints a relative path rather than a canonical one. Second,
we have to make sure that we don't end up deleting the second symlink in
a chain, etc.
--
Thomas Hood [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299947: Improving ifplugd
If the patches I submitted upstream (cc:ed to #219000) get applied to ifplugd.c then it will be possible to restart ifplugd cleanly: i.e., stop ifplugd using SIGQUIT and restart it using the --no-startup option. Then -q can be dropped from the default list of options. In order to minimize the amount of time that ifplugd is not running, both stopping and starting should be done in the postinst. (Currently, ifplugd is stopped in the prerm and started again in the postinst.) This means that custom postinst code will have to be used instead of the snippets generated by dh_installinit. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294404: Status?
This RC bug was assigned to mdadm over a month ago and there has been no comment from the maintainer. What is the status of this bug? -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291757: Evolution is not unusable
This bug certainly does not render the package unusable! -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299947: Reproducible?
Can you reproduce this problem when installing ifplugd 0.26-1, or is this a reproducible problem introduced in 0.26-2, ... or is the problem not reproducible at all? -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#285135: Remove from sarge
These are all fixed in 0.3.3-1, which is blocked from even making it into sid because liboil0.3 is in NEW. So should swf-player be removed from sarge? -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#285135: Remove from sarge
On Tue, 2005-03-22 at 13:41 -0800, David Schleef wrote: On Tue, Mar 22, 2005 at 10:03:29PM +0100, Thomas Hood wrote: These are all fixed in 0.3.3-1, which is blocked from even making it into sid because liboil0.3 is in NEW. So should swf-player be removed from sarge? No, why? It's fixed in sid. (Did I put the wrong tag on it?) No, I was just going by the information in the BTS as quoted above. I should have checked to see if 0.3.3-1 had made it into sid. Sorry for the bother. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299947: ifplugd bringing down interface on upgrade
You wrote: When updating ifplugd package, the host's networking is brought down for a long time, particularly if they are many other packages being updated/installed/removed simultaneously. Some background info ... In #219000 I wrote: The default set of arguments for ifplugd includes -q. However, in normal use with hotplug and ifupdown this will make ifplugd fail to bring down the interface on removal of the device. Oliver Kurth explained there: The reason I've put -q into the default args was that the network connection should not be broken on re- or de-install. I replied: That's true. Hmm. I would suggest that a new restart-no-downup be added to the initscript which would be used by the postinst instead of restart. It would stop the daemon using SIGQUIT instead of the usual SIGTERM, thus preventing the shutdown script from running. The daemon should then be run with an option telling it not to run the start script. We are still waiting for the required option to be added to ifplugd. In the meantime, though, ifplugd should be doing the right thing on package upgrade. What is the value of ARGS set in your /etc/default/ifplugd? -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297898: ifupdown: postinst fails: /etc/network/ifstate: no such file or directory
severity 297898 important thanks Thanks for the report. The postinst fails because in your case /etc/network/run points to /dev/shm/network prior to installation but /dev/shm/network does not exist at that time. The failure does _not_ occur if /etc/network/run is absent when the package is installed (because in that case the postinst creates the directory) or if /etc/network/run points to /dev/shm/network and /dev/shm/network/ does exist. Thus the postinst fails in a relatively rare case. Because of this and because the same bug was also present in the previous version, I am downgrading the report below RC level. Nevertheless, the bug is important and must be fixed. Please test ifupdown version 0.6.4-4.12~rc1 which I have made available at http://www.aglu.demon.nl/ifupdown. I attach the postinst if you prefer just to test that. -- Thomas Hood [EMAIL PROTECTED] ifupdown-postinst_4.12~rc1 Description: application/shellscript
Bug#295804: libjack0.80.0-dev has no Dependencies
Package: libjack0.80.0-dev Version: 0.99.0-5 Severity: grave For 0.99.0-4: $ dpkg -s libjack0.80.0-dev | grep Depends Depends: libjack0.80.0-0 (= 0.99.0-4), libasound2-dev, libglib1.2-dev, pkg-config For 0.99.0-5: $ dpkg -f libjack0.80.0-dev_0.99.0-5_i386.deb |grep Depends $ This caused the alsa-lib 1.0.8-2 release to fail to build on all architectures except mipsel which still has libjack0.80.0-dev version 0.99.0-4. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libjack0.80.0-dev depends on: ii libasound2-dev1.0.8-2ALSA library development files ii libglib1.2-dev1.2.10-9 Development files for GLib library ii libjack0.80.0-0 0.99.0-4 JACK Audio Connection Kit (librari ii pkg-config0.15.0-4 Manage compile and link flags for -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294121: Dependencies on libdiscover2 and discover-date missing
On Wed, 2005-02-09 at 11:17 -0500, Jeff Licquia wrote: It would make our lives a lot easier, yes, but I doubt it will ever happen. People are (understandably) nervous about bloating up /lib and /bin. Rightly so. (However, statically linking binaries on the root filesystem is another way to bloat it up. If several early-running programs need libfoo and end up statically linking it then, depending on how much of libfoo each program uses, and how popular each program is, etc., it could be profitable to move the shared library.) -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#281568: g-s-t, high quality program
gnome-system-tools is a configuration utility. In Debian, configuration utilities can do anything, no matter how stupid, without it being considered an RC bug. The reasoning is that the administrator chooses to run the program; hence if chaos results then it is the admin's own fault. He should have known better. If a higher standard than this were applied to gnome-system-tools -- e.g., if the standard were applied that g-s-t should not mangle system configuration files or dupe the admin into doing so, then g-s-t would not be releasable. (See the many bugs open against g-s-t in the Debian BTS.) If it couldn't be released with sarge then neither could the gnome package, which depends on it. You don't want sarge releasing without GNOME, do you? (P.S. Please note that this is my sarcastic way of saying that this bug report is an additional reason for deeming g-s-t not to be of release quality.) -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293458: sysv-rc: Trys to overwrite /etc/init.d/rc
On Thu, 2005-02-03 at 10:35 -0500, Edward C. Jones wrote: trying to overwrite /etc/init.d/rc', which is also in package sysvinit What version of sysvinit did you have installed when this happened? -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290876: alsa-utils 1.0.8-1 package for powerpc now available
Thanks to Jordi Mallach, alsa-utils_1.0.8-1_powerpc.deb is now available at incoming.debian.org, pending installation in sid. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290876: [Pkg-alsa-devel] Bug#290876: alsa-base still uninstallable on powerpc
On Sat, 2005-01-29 at 15:42 +0100, Georg C. Kaindl wrote: unfortunately, alsa-base is still uninstallable on powerpc because the new alsa-utils ppc package is not in sid even tough the x86 one is (and alsa-base as well as alsa-utils in fact is installable on x86). I also find it ridiculous that it takes two weeks to build a package on the powerpc arch. It is in the queue. There is nothing more that I can do about it. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292897: More info
Do this: Edit the first line of /var/lib/dpkg/info/alsa-base.postinst so that it reads #!/bin/bash -x then execute the command (as root) /var/lib/dpkg/info/alsa-base.postinst configure and send the output. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278495: Update, please
Hi. What is happening with this bug? It's still rated RC and there hasn't been any visible (in the log) activity for a couple of months now. -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#265285: Really RC?
Hi. I was looking at the bug logs and it isn't obvious to me why this bug is rated RC. What's the status of this bug? Can it be downgraded? -- Thomas Hood [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291339: [Pkg-alsa-devel] Bug#291339: alsa-modules-2.4.27-1-686: undefined symbols
On Thu, 2005-01-20 at 17:12 +1100, Brian May wrote:
depmod: *** Unresolved symbols in
/lib/modules/2.4.27-1-686/updates/alsa/snd-pdaudiocf.o
[...]
I rebuilt the modules from the source code, and the modules I require
work (I still get undefined symbols from
snd-{pdaudiocf,vx-cs,vxp440,vxpocket}.o, but I don't need these anyway).
I strongly suspect that you haven't built your alsa-modules package
against the sources for the kernel you are running. Please double check
that the kernel you are running is the one built from the tree in which
you built the alsa-modules package.
--
Thomas Hood [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
