Bug#971713: sysstat: init or systemd file has overlapping runlevels
On Tue, 15 Dec 2020 12:45:40 -0400
Jesse Smith wrote:
> I gave the patch a test run and, while I like what it does in theory,
> in practise I'm running into trouble with it. When I use the attached
> patch and then run "make check" in the insserv source directory,
> inssrev segfaults after about eight tests. I haven't had a chance yet
> to hunt down what is causing the problem, but I'm guessing a variable
> is getting used before it is given a value/initialized.
well, moving the Start_Stop_Overlap call broke the assumption that
start_levels and stop_levels are never undefined, so this additional
patch should fix the regression
make check now passes all 240 tests
thanks for the review and happy hacking! :)
>From 4a3b1e90f23792b6f640e8d9bc28c334cafce843 Mon Sep 17 00:00:00 2001
From: Trek
Date: Tue, 15 Dec 2020 20:00:18 +0100
Subject: [PATCH 3/3] Skip overlapping check on empty runlevels
---
insserv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/insserv.c b/insserv.c
index dbd3202..b7e1d8f 100644
--- a/insserv.c
+++ b/insserv.c
@@ -2737,6 +2737,8 @@ boolean Start_Stop_Overlap(char *start_levels, char *stop_levels)
int string_index = 0;
char *found;
+ if (!start_levels || !stop_levels) return false;
+
while (start_levels[string_index]) /* go to end of string */
{
if (start_levels[string_index] != ' ') /* skip spaces */
--
2.20.1
Bug#971713: sysstat: init or systemd file has overlapping runlevels
On Tue, 15 Dec 2020 00:58:19 +0100
Robert Luberda wrote:
> >> insserv: Script ssh has overlapping Default-Start and Default-Stop
> >> runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
>
> What is surprising the ssh warning is shown even if I run insserv from
> the command line without giving any other arguments:
> [...]
> While the sysstat warning is shown only on upgrades.
it is because insserv scan all the init.d files on each invocation, but
it scans the rc.d links only for the ones specified by commandline
> Removing the links removes the warning as well:
> [...]
> But when I re-add the K01ssh links, 'apt install --reinstall sysstat'
> warns about ssh, and no longer about sysstat service...
this is the culprit: if the user tweaks the rc.d links, then the
overlapping warning appears, but it should not
> Oh, wait, I've just read my email from Sunday, and it looks like the
> warning on my system was always about ssh:
> [...]
> Sorry about not noticing it before, I must have been too strongly
> suggested by the Julian's original bug report :(
>
> So it looks like the warning says that run-level links were customized
> by a user. IMHO it would be nice if the warning message stated this
> simple fact in a more explicit way.
well, thanks to your report we found a bug in insserv :)
> I looked into insserv(8) man page before changing the script, and was
> under impression that Default-Start and Default-Stop must contain at
> least one run level, as the example given at the top of the man page
> says:
>
> # Default-Start: run_level_1 [ run_level_2 ...]
> # Default-Stop: run_level_1 [ run_level_2 ...]
the actual syntax may be misleading, because insserv works happily if
any of those fields are empty (or even missing)
> But if you're sure they can be empty, I will revert the change in
> sysstat's init.d script.
yes, you can safely revert it, as far i understand
@Jesse Smith: I attached a possible fix, but it slightly changes the
behavior, as now it prints the overlapping warning when loading all the
init.d scripts and not only for the ones in the commandline
this because if script_inf.default_start and stop are empty, they are
overwritten by the levels gathered from rc.d links and I do not fully
understand the implications of removing those overwrites, so I just
moved the code before this part
the second patch is for the manpage about empty fields, that are
allowed by insserv, but probably it could be explained better
please to tell me if you need some more info or work to be done :)
ciao!
>From d6704148edd51cbb972a9e61e9d165a9e266be45 Mon Sep 17 00:00:00 2001
From: Trek
Date: Tue, 15 Dec 2020 16:17:54 +0100
Subject: [PATCH 1/2] Check only LSB header for overlapping runlevels to fix
Debian bug #971713
---
insserv.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/insserv.c b/insserv.c
index 1e43bf0..dbd3202 100644
--- a/insserv.c
+++ b/insserv.c
@@ -3573,6 +3573,14 @@ int main (int argc, char *argv[])
if (script_inf.stop_after && script_inf.stop_after != empty) {
reversereq(service, REQ_SHLD|REQ_KILL, script_inf.stop_after);
}
+
+overlap = Start_Stop_Overlap(script_inf.default_start, script_inf.default_stop);
+if (overlap)
+{
+warn("Script `%s' has overlapping Default-Start and Default-Stop runlevels (%s) and (%s). This should be fixed.\n",
+ d->d_name, script_inf.default_start, script_inf.default_stop);
+}
+
/*
* Use information from symbolic link structure to
* check if all services are around for this script.
@@ -3739,13 +3747,6 @@ int main (int argc, char *argv[])
}
#endif /* not SUSE */
-overlap = Start_Stop_Overlap(script_inf.default_start, script_inf.default_stop);
-if (overlap)
-{
-warn("Script %s has overlapping Default-Start and Default-Stop runlevels (%s) and (%s). This should be fixed.\n",
- d->d_name, script_inf.default_start, script_inf.default_stop);
-}
-
if (isarg && !defaults && !del) {
if (argr[curr_argc]) {
char * ptr = argr[curr_argc];
--
2.20.1
>From fa303693753e774adc3ad1d34679d346b4beddaa Mon Sep 17 00:00:00 2001
From: Trek
Date: Tue, 15 Dec 2020 16:16:12 +0100
Subject: [PATCH 2/2] Added Default-Start and Stop definitions to insserv.8
---
insserv.8.in | 9 +
1 file changed, 9 insertions(+)
diff --git a/insserv.8.in b/insserv.8.in
index b79385a..5faa46e 100644
--- a/insserv.8.in
+++ b/insserv.8.in
@@ -97,6 +97,11 @@ execute insserv directly unless you know exactly what you're doing, doing so
may render your boot system inoperable.
.B update\-rc.d
i
Bug#971713: sysstat: init or systemd file has overlapping runlevels
On Mon, 14 Dec 2020 03:54:28 +0100 Lorenzo wrote: > if you are searching in the source under /debian directory, the code > that you are looking for will be written by dh-installinit in place of > the #DEBHEPLER# placeholder, during the build of the package. @Lorenzo oh yeah, many thanks :) so the fix would be like the one attached to this mail but reading the init.d script I see that it does not stop anything, so an empty Default-Stop should be correct what I really don't understand now it's from where those messages come from: > insserv: Script sysstat has overlapping Default-Start and > Default-Stop runlevels (2 3 4 5) and (2 3 4 5). This should be fixed. running insserv on a script with an empty Default-Stop field does not print this message, at least with buster and sid versions reading the source, it could set an empty Default-Stop to the value of Default-Start, but only when compiled with the -DSUSE flag enabled: https://sources.debian.org/src/insserv/1.21.0-1/insserv.c/#L3727 and this flag is not enabled on debian builds > insserv: Script ssh has overlapping Default-Start and Default-Stop > runlevels (2 3 4 5) and (2 3 4 5). This should be fixed. this instead comes from ssh, that have an empty Default-Stop too @Robert Luberda: I ran out of ideas, your script was correct with an empty Default-Stop field, like the ssh one! Actually I'm running a buster installation, but using the sid insserv binary it does not show this issue, so I can't debug further for now ciao! diff --git a/debian/sysstat.postinst b/debian/sysstat.postinst index f4730d0..3ea1596 100644 --- a/debian/sysstat.postinst +++ b/debian/sysstat.postinst @@ -114,6 +114,11 @@ if [ "$1" = "configure" ] ; then --slave /usr/share/man/man1/sar.1.gz sar.1.gz \ /usr/share/man/man1/sar.sysstat.1.gz fi + +# new Default-Stop (see #971713) +if dpkg --compare-versions "$2" le '12.4.1-2'; then +update-rc.d -f sysstat remove +fi fi #DEBHELPER#
Bug#971713: sysstat: init or systemd file has overlapping runlevels
On Sun, 13 Dec 2020 11:03:57 +0100 Robert Luberda wrote: > sysstat's init.d has the following lines in /etc/init.d/sysstat > # Default-Start: 2 3 4 5 > # Default-Stop: > I'm not sure how empty Default-Stop is interpreted, so I've just tried it seems to me that on empty Default-Stop the runlevels will be copied from Default-Start, but this is not an issue, just to better understand > to change it to: > # Default-Stop: 0 1 6 this seems correct > As a result insserv displays two warnings instead of one: before explaining the error messages, remember that init scripts and their links are configuration files, like (almost) everything else under /etc > insserv: warning: current stop runlevel(s) (empty) of script `sysstat' > overrides LSB defaults (0 1 6). it is saying that the current stop runlevels (the /etc/rc*.d/*sysstat links) are overriding the ones described by the LSB header (inside the /etc/init.d/sysstat script) > insserv: Script ssh has overlapping Default-Start and Default-Stop > runlevels (2 3 4 5) and (2 3 4 5). This should be fixed. the end result is that the rc*.d links are unchanged and the runlevels still inconsistent > As a maintainer of sysstat I have no idea what else I can do to fix > the warning. It seems to me there is some bug in insserv. As the bug > affects my package, and according to the bug report "any package > that has init.d file", I'm setting severity of this report to grave. on new installations, simply adding the correct levels (0 1 6) to the script should fix the bug, but to fix on upgrades you should remove those links before running insserv, that is adding something like that to postinst inside the configure step: # new Default-Stop (see #971713) if dpkg --compare-versions "$2" le '12.4.0-2'; then update-rc.d -f sysstat remove fi this will also remove any tweaking done by user, that should be annotated inside the NEWS.Debian file I would like to provide you a patch, but I can't find where the init.d file is enabled inside the sysstat postinst, that should be: update-rc.d sysstat defaults ciao!
Bug#971644: [elogind/elogind] System crashed on suspend/hibernate failure (#177)
searching for info, I found this assertion, that made me think the issue could be outside of elogind: This appears to be that Debian in user space tries to trigger the resume when the system is falling to hibernation. https://bugzilla.kernel.org/show_bug.cgi?id=201855#c10 I really don't know how the power-management stuff works, but if you have pm-utils installed you could try to run pm-hibernate to see if the issue is the same ciao!
Bug#962350: /etc/init.d/checkfs.sh is not very robust, and fails on missing filesystems.
On Sat, 06 Jun 2020 07:27:18 -0700 Brad Lanam wrote: > /etc/init.d/checkfs.sh fails when trying to check a non-existent > filesystem. Apparently it is trying to run a fsck on a filesystem > that was removed. it seems to be working as expected, but you could disable that behavior adding the nofail mount option to that partition inside the /etc/fstab file: see fstab(5) and fsck(8) manual pages for more info ciao!
Bug#931867: /lib/init/init-d-script is sourcing /etc/default/* too late
On Thu, 11 Jul 2019 12:05:10 -0500 Justin Pasher wrote: > Moving it above the following block would ensure it's sourced first: this is a chicken-egg problem: init-d-script sources /etc/default/$NAME but $NAME is defined inside /etc/init.d/snmpd (that is $SCRIPTNAME) init-d-script could be modified, for example to source at first /etc/default/$(basename $SCRIPTNAME), but to retain backward compatibility it should source also /etc/default/$NAME and it would begin a sourcing mess with possible conflicts i think the init-d-script sourcing feature is not really useful and the right way to include variables it is to source the environment file inside the /etc/init.d/snmpd script, like batmand does for example: https://sources.debian.org/src/batmand/0.3.2-21/debian/batmand.init another possible way it could be to define DAEMON_ARGS directly inside /etc/default/snmpd, but I don't know how well it will play with other init systems ciao!
Bug#968038: sysvinit-utils: do_restart fails when not ran from a terminal
you spotted a bug fixed in my patch 7 of 12 a month ago :) http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2020-July/003306.html may be someone will apply them, but who knows? ciao!
Bug#962649: init-d-script: fix PIDFILE argument to status_of_proc
Package: sysvinit-utils
Version: 2.88dsf-59.3
Control: tags -1 patch
the fix for #822674 had a caveat, because status_of_proc cannot parse
options after the first non-option argument, as it uses getopts
a simple test, where /run/crond.pid contains a running pid:
$ . /lib/lsb/init-functions
$ status_of_proc -p /run/crond.pid /non/existant/filename name
[ ok ] name is running.
$ status_of_proc /non/existant/filename name -p /run/crond.pid
[FAIL] name is not running ... failed!
usually it works because it checks the command name only, omitting the
pidfile check at all:
$ status_of_proc /usr/sbin/cron name -p /non/existant/filename
[ ok ] name is running.
please see the attached patch
ciao!
diff --git a/debian/init-d-script b/debian/init-d-script
index 212537fc..f5388af9 100755
--- a/debian/init-d-script
+++ b/debian/init-d-script
@@ -157,7 +157,7 @@ do_reload_sigusr1() {
do_status() {
# FIXME: Does it make sense to call `status_of_proc' if PIDFILE is
# empty?
- status_of_proc "$DAEMON" "$NAME" ${PIDFILE:="-p ${PIDFILE}"}
+ status_of_proc ${PIDFILE:+-p "$PIDFILE"} "$DAEMON" "$NAME"
}
if [ "$DEBUG" = "true" ] ; then
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Tue, 24 Sep 2019 07:28:29 +0800 Ian Campbell wrote: > Has anyone investigated late dynamic binding using a stub library > which merely determines which init is running and then dlopens the > appropriate libsystemd0 of libelogind0 library and forwards the calls > to it? it could be in the form of libglvnd, a generic dispatcher to have co-installed multiple vendor implementations of libgl, with runtime selection https://github.com/NVIDIA/libglvnd a stripped down version of that architecture could be used to simply detect what init system is actually running and then dispatch to the correct library (libsystemd or libelogind) ciao!
Bug#930019: default-jre wants to uninstall sysvinit-core to install systemd
On Wed, 17 Jul 2019 10:41:39 +0200 Emmanuel Bourg wrote: > I suspect openjdk-11 ends up pulling libpam-systemd in its dependency > graph, which triggers #926316. going up the reverse dependency tree it happens: libpam-systemd (is needed by) dbus-user-session dconf-service dconf-gsettings-backend libgtk-3-common libgtk-3-0 openjdk-11-jre default-jre so to resolve the issue, you have three options: 1. openjdk-11-jre depends on libgtk2.0-0 or libgtk-3-0, so to fix it you can install libgtk2.0-0 and not libgtk-3-0 2. libgtk-3-common depends on dconf-gsettings-backend or gsettings-backend (provided by gconf-gsettings-backend), so you can install libgtk-3-0 and gconf-gsettings-backend without dconf-gsettings-backend 3. dconf-service depends on default-dbus-session-bus or dbus-session-bus (provided by dbus-x11), again you can install dbus-x11 instead of dbus-user-session and it will not require systemd actually I prefer a fourth option, but it require a small patch to the libgtk-3-0 binary package, to remove gsettings-backend from dependencies and it runs fine, showing this message: GLib-GIO-Message: 11:19:12.298: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. to apply the patch (attached) you should do as user: fakeroot apt download libgtk-3-common dpkg-deb -R libgtk-3-common_3.24.5-1_all.deb libgtk-3-common patch -d libgtk-3-common -p1 diff -urN a/DEBIAN/control b/DEBIAN/control --- a/DEBIAN/control 2019-02-05 18:02:24.0 +0100 +++ b/DEBIAN/control 2019-07-18 12:05:28.739714053 +0200 @@ -1,11 +1,10 @@ Package: libgtk-3-common Source: gtk+3.0 -Version: 3.24.5-1 +Version: 3.24.5-1++fix Architecture: all Maintainer: Debian GNOME Maintainers Installed-Size: 24939 -Depends: dconf-gsettings-backend | gsettings-backend -Recommends: libgtk-3-0 +Recommends: libgtk-3-0, dconf-gsettings-backend | gsettings-backend Section: misc Priority: optional Multi-Arch: foreign
Bug#930428: debootstrap should ensure matching _apt uid
On Thu, 20 Jun 2019 22:31:15 +0200 Ansgar Burchardt wrote: > If _apt deserves a special solution, I would suggest assigning the > _apt user a static uid instead of patching debootstrap. it seems to me the simplest approach, from a technical point of view, and it's the one I'm using since _apt user was introduced (making sure uids match) ciao!
Bug#930428: debootstrap should ensure matching _apt uid
On Thu, 20 Jun 2019 09:32:17 +0200 Ansgar Burchardt wrote: > I don't think it is a good idea to require debootstrap to know about > such details. _apt user is standard to debian, but not its uid the _apt user is created by the apt postinst, that cannot know anything about the host system from where debootstrap was launched, so debootstrap seems to me the only place where this functionality can be added > For limiting network access, I would recommend instead using network > namespaces (to only provide limited network access for all processes) > and/or user namespaces (if filtering for single UIDs is really > needed). These do not require any uids to match between in- and > outside. filtering out the root user is a pretty common security practice and setting an iptables rule on uids is simple for system administrators using namespaces, how can you block any user but not the _apt user if it is not already created? just my 2 cents :) ciao! P.S.: the patch seems ok to me, I don't like hard-conding the _apt user line in /etc/passwd, as apt postinst uses adduser, but it's not clear to me when adduser is installed during debootstrap
Bug#930473: bsdgames: New wtf acronym makes no sense
On Thu, 13 Jun 2019 17:27:33 +0200 Trek wrote: > where is the food: what the heck? no fantasy here? what it means? how > changing the meaning of an utility can be considered acceptable? if we > really want to be boringly polite, then why not "what term for"? sorry, I misunderstood, only the meaning of the acronym for wtf was changed, not the wtf utility anyway it seems unfair to me, it would be better to remove the wtf acronym instead of to display a false meaning, that would be confusing and spread misinformation ciao ciao :)
Bug#930473: bsdgames: New wtf acronym makes no sense
On Thu, 13 Jun 2019 13:30:51 +0200 Fabian Greffrath wrote: > It's understandable that this was introduced to avoid using the > f-word. How about replacing it with "frick" or "fsck" instead? frick seems to me to be the most appropriate fsck can cause confusion, it is not a filesystem check where is the food: what the heck? no fantasy here? what it means? how changing the meaning of an utility can be considered acceptable? if we really want to be boringly polite, then why not "what term for"? ciao :)
Bug#924640: tt-rss: initscript tt-rss action "stop" failed
Control: tag -1 patch this (untested) patch should fix the issue ciao! diff -urN a/debian/tt-rss.init b/debian/tt-rss.init --- a/debian/tt-rss.init 2019-05-17 17:47:08.174896466 +0200 +++ b/debian/tt-rss.init 2019-05-17 17:52:21.938887893 +0200 @@ -79,7 +79,7 @@ # 1 if daemon was already stopped # 2 if daemon could not be stopped # other if a failure occurred - start-stop-daemon --stop --quiet --retry=TERM/1/KILL/5 --pidfile $PIDFILE + start-stop-daemon --stop --quiet --retry=TERM/1/KILL/5 --pidfile $PIDFILE --exec $DAEMON --user www-data RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 # Wait for children to finish too if this is a daemon that forks @@ -88,7 +88,7 @@ # that waits for the process to drop all resources that could be # needed by services started subsequently. A last resort is to # sleep for some time. - start-stop-daemon --stop --quiet --oknodo --retry=0/1/KILL/5 --exec $DAEMON + start-stop-daemon --stop --quiet --oknodo --retry=0/1/KILL/5 --exec $DAEMON --user www-data [ "$?" = 2 ] && return 2 # Many daemons don't delete their pidfiles when they exit. rm -f $PIDFILE
Bug#928040: lprng: fails to install
Control: tag -1 patch
this patch should fix the issue
ciao!
diff -urN a/debian/lprng.init.in b/debian/lprng.init.in
--- a/debian/lprng.init.in 2012-06-11 09:47:19.0 +0200
+++ b/debian/lprng.init.in 2019-05-17 16:54:10.750983282 +0200
@@ -106,7 +106,8 @@
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" lpd
- if start-stop-daemon --stop --oknodo --quiet --pidfile "${PIDFILE}" ; then
+ if start-stop-daemon --stop --oknodo --quiet --pidfile "${PIDFILE}" \
+ --exec $DAEMON --user daemon ; then
cleanup
[ "$VERBOSE" != no ] && log_end_msg 0
else
@@ -129,7 +130,8 @@
;;
restart|force-reload)
[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" lpd
- start-stop-daemon --stop --quiet --pidfile "${PIDFILE}"
+ start-stop-daemon --stop --quiet --pidfile "${PIDFILE}" \
+ --exec $DAEMON --user daemon
sleep 1
initialise
start-stop-daemon --start --quiet --pidfile "${PIDFILE}" \
Bug#878953: libpurple0: please stop linking to libfarstream
I think this bug should be merged with #823909 that was fixed this year while the submitter requested removing libfarstream dependency from libpurple, he was concerned about gstreamer-plugins-bad, that was removed form the dependencies of libfarstream ciao!
Bug#927904: claws-mail: filtering option does not work as excepted
On Wed, 24 Apr 2019 22:23:55 +0200 Pierre wrote: > The Debian computer is ignoring these rules, and the OpenIndiana > machine is running fine. > For example, if I send a mail from this address to another mail > address, the Debian machine will ignore the filtering action and the > mail will stay in the inbox folder. checking the filtering logs could help you to figure out what is going, but you should enable them in: configuration -> preferences -> other -> logging ciao!
Bug#831828: libgtk2.0-0: GTK+ 2 is not GNOME and should not depend on GNOME icons
On Thu, 13 Apr 2017 16:12:50 +0200 Laurent Bigonville wrote: > And in a lot of cases, not having these icons might IMVHO result in a > degraded user experience. I think this definition perfectly fits the one of the Recommends dependency: The Recommends field should list packages that would be found together with this one in all but unusual installations. https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends anyway the recommends packages are installed by default since at least 10 years, if I remember right ciao!
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Tue, 5 Mar 2019 23:39:00 +0100 Michael Biebl wrote: > Strictly speaking, we should only need either --notify-await when > starting the daemon via s-s-d, or --wait-daemon when calling udevadm > trigger. Using both probably doesn't hurt, but isn't really necessary. correct, actually only the s-s-d --notify-await solves the issue, as it was confirmed by Bill Brelsford in the messages #134 and #258 > Since I can't reproduce the original issue myself, I wonder if > udevadm trigger --wait-daemon actually works. There was conflicting > feedback regarding this matter. udevadm --wait-daemon doesn't fix this specific issue, as it doesn't retry if the connection was refused (udevadm-trigger.c:177) > Would be cool if someone affected by this problem could try the > following: it was tested a similar configuration: udevadm trigger --type=subsystems --action=add --wait-daemon ciao!
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Tue, 5 Mar 2019 09:46:53 +0100
Andreas Henriksson wrote:
> You likely also want to include in your patch a debian/control
> change that makes udev depend on a new enough dpkg which has the
> new flags you're making use of.
right, a new patch is attached
thank you!diff --git a/debian/control b/debian/control
index 8fbe346..f26a177 100644
--- a/debian/control
+++ b/debian/control
@@ -330,6 +330,7 @@ Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends},
${misc:Depends},
adduser,
+ dpkg (>= 1.19.3),
libudev1 (= ${binary:Version}),
lsb-base (>= 3.0-6),
util-linux (>= 2.27.1),
diff --git a/debian/udev.init b/debian/udev.init
index 6a3c9b3..cf93107 100644
--- a/debian/udev.init
+++ b/debian/udev.init
@@ -166,7 +166,8 @@ case "$1" in
log_daemon_msg "Starting $DESC" "$NAME"
if start-stop-daemon --start --name $NAME --user root --quiet \
---pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then
+--pidfile $PIDFILE --exec $DAEMON --background --make-pidfile \
+--notify-await; then
# prevents udevd to be killed by sendsigs (see #791944)
mkdir -p $OMITDIR
ln -sf $PIDFILE $OMITDIR/$NAME
@@ -178,7 +179,7 @@ case "$1" in
fi
log_action_begin_msg "Synthesizing the initial hotplug events (subsystems)"
-if udevadm trigger --type=subsystems --action=add; then
+if udevadm trigger --type=subsystems --action=add --wait-daemon; then
log_action_end_msg $?
else
log_action_end_msg $?
@@ -226,7 +227,8 @@ case "$1" in
log_daemon_msg "Starting $DESC" "$NAME"
if start-stop-daemon --start --name $NAME --user root --quiet \
---pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then
+--pidfile $PIDFILE --exec $DAEMON --background --make-pidfile \
+--notify-await; then
# prevents udevd to be killed by sendsigs (see #791944)
mkdir -p $OMITDIR
ln -sf $PIDFILE $OMITDIR/$NAME
Bug#908796: udev (with sysvinit) fails to find devices at boot
Control: tag -1 patch hello, the new dpkg version finally landed to testing, so I send you a little patch to enable both --notify-await and --wait-daemon options this patch was tested against dpkg 1.19.5 and udev 241-1 (unstable) all is running fine! (boot and shutdown) I would say a big thank you to everyone involved :) Trekdiff --git a/debian/udev.init b/debian/udev.init index 6a3c9b3926..cf9310734c 100644 --- a/debian/udev.init +++ b/debian/udev.init @@ -166,7 +166,8 @@ case "$1" in log_daemon_msg "Starting $DESC" "$NAME" if start-stop-daemon --start --name $NAME --user root --quiet \ ---pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then +--pidfile $PIDFILE --exec $DAEMON --background --make-pidfile \ +--notify-await; then # prevents udevd to be killed by sendsigs (see #791944) mkdir -p $OMITDIR ln -sf $PIDFILE $OMITDIR/$NAME @@ -178,7 +179,7 @@ case "$1" in fi log_action_begin_msg "Synthesizing the initial hotplug events (subsystems)" -if udevadm trigger --type=subsystems --action=add; then +if udevadm trigger --type=subsystems --action=add --wait-daemon; then log_action_end_msg $? else log_action_end_msg $? @@ -226,7 +227,8 @@ case "$1" in log_daemon_msg "Starting $DESC" "$NAME" if start-stop-daemon --start --name $NAME --user root --quiet \ ---pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then +--pidfile $PIDFILE --exec $DAEMON --background --make-pidfile \ +--notify-await; then # prevents udevd to be killed by sendsigs (see #791944) mkdir -p $OMITDIR ln -sf $PIDFILE $OMITDIR/$NAME
Bug#916696: initramfs-tools: search for nonexistent resume device
On Sun, 10 Feb 2019 17:32:08 +
Ben Hutchings wrote:
> > I include a patch, tested with and without an ephemeral swap:
> > - the second block (-79,9 +83,10) is the actual fix
> If you would actually send me the log messages I might understand this
> fix, but as it is I don't. I do need to understand it before I will
> apply it.
yes, sorry, you're right
here the log:
Calling hook resume
I: Configuration sets RESUME=
I: Checking swap device /dev/dm-1
I: /dev/dm-1 has device-mapper name sdb5_crypt; checking crypttab
I: Found cryptdev=sda5_crypt keyfile=/dev/urandom
I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
I: Rejecting /dev/dm-1 since it has no permanent key
I: Checking swap device /dev/dm-0
I: /dev/dm-0 has device-mapper name sda5_crypt; checking crypttab
I: Found cryptdev=sda5_crypt keyfile=/dev/urandom
I: Rejecting /dev/dm-0 since it has no permanent key
I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
Calling hook thermal
it ends up with the initrd file /main/conf/conf.d/zz-resume-auto
containing:
RESUME=/dev/dm-0
running resume with set -x explain what's going on:
+ report_verbose Rejecting /dev/dm-0 since it has no permanent key
+ test y != y
+ echo I: Rejecting /dev/dm-0 since it has no permanent key
I: Rejecting /dev/dm-0 since it has no permanent key
+ ephemeral=true
+ read -r cryptdev srcdev keyfile junk
+ report_verbose Found cryptdev=sdb5_crypt keyfile=/dev/urandom
+ test y != y
+ echo I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
+ [ sdb5_crypt = sda5_crypt ]
+ read -r cryptdev srcdev keyfile junk
+ true
+ [ -n /dev/dm-0 ]
+ true
+ [ = auto ]
+ [ -n /dev/dm-0 ]
+ [ -z /dev/dm-0 ]
+ echo RESUME=/dev/dm-0
basically, it finishes the while-loop
while read -r cryptdev srcdev keyfile junk; do
+ read -r cryptdev srcdev keyfile junk
then it checks the ephemeral variable inside the for-loop
$ephemeral || break
+ true
now the for-loop is finished and it evaluates the first if-construct
if [ -n "$resume_auto" ] && ! $ephemeral; then
+ [ -n /dev/dm-0 ]
+ true
it evaluates the second if-construct (the bug is here, as it doesn't
account for ephemeral)
if [ "$RESUME" = auto ] || [ -n "$resume_auto" ]; then
+ [ = auto ]
+ [ -n /dev/dm-0 ]
then the inner if-construct
if [ -z "$resume_auto" ]; then
+ [ -z /dev/dm-0 ]
and finally it writes the resume file
echo "RESUME=${resume_auto}" > "${DESTDIR}/conf/conf.d/zz-resume-auto"
+ echo RESUME=/dev/dm-0
my fix is to reset the resume_auto variable if the device is ephemeral,
thus removing the need to check the ephemeral variable in the two
if-construct after the for-loop
$ephemeral || break # exit the for-loop if ephemeral=true
resume_auto= # otherwise empty resume_auto
that's it :)
thanks again for your time
ciao!
Bug#916696: initramfs-tools: search for nonexistent resume device
On Wed, 06 Feb 2019 21:21:57 + Ben Hutchings wrote: > The RESUME variable doesn't have to be set in any particular file. > Please check with: > > grep -rw RESUME /etc/initramfs-tools/initramfs.conf \ > /etc/initramfs-tools/conf.d \ > /usr/share/initramfs-tools/conf.d/ it's empty > If it's definitely not set, then please: > > 1. Upgrade to initramfs-tools version 0.133 (I just uploaded this so >you will have to wait a few hours for it to be available) > 2. Run "update-initramfs -u -v >initramfs.log 2>&1" > 3. Look in initramfs.log for "Calling hook resume" and send the >messages after that thanks for your help, now I've managed to debug and fix the resume hook: when all the swaps are ephemeral, it finishes the for-loop, but the last if-construct doesn't check the ephemeral variable I include a patch, tested with and without an ephemeral swap: - the second block (-79,9 +83,10) is the actual fix - the first one (-63,9 +63,13) is only to be safer, as it checks /dev/random too and it stops searching /etc/crypttab when the device is found ciao!--- a/usr/share/initramfs-tools/hooks/resume 2019-02-06 05:40:30.0 +0100 +++ b/usr/share/initramfs-tools/hooks/resume 2019-02-10 05:50:51.270496152 +0100 @@ -63,9 +63,13 @@ # shellcheck disable=SC2034 while read -r cryptdev srcdev keyfile junk; do report_verbose "Found cryptdev=$cryptdev keyfile=$keyfile" -if [ "$cryptdev" = "$dm_name" ] && [ "$keyfile" = /dev/urandom ]; then - report_verbose "Rejecting $resume_auto since it has no permanent key" - ephemeral=true +if [ "$cryptdev" = "$dm_name" ]; then + if [ "$keyfile" = /dev/urandom ] || [ "$keyfile" = /dev/random ]; then + report_verbose "Rejecting $resume_auto since it has no permanent key" + ephemeral=true + fi + + break fi done < /etc/crypttab fi @@ -79,9 +83,10 @@ esac $ephemeral || break + resume_auto= done - if [ -n "$resume_auto" ] && ! $ephemeral; then + if [ -n "$resume_auto" ]; then if [ -n "$dm_name" ]; then resume_auto_canon="/dev/mapper/$dm_name" elif UUID=$(blkid -s UUID -o value "$resume_auto"); then
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Fri, 25 Jan 2019 19:14:54 -0800 Bill Brelsford wrote: > It works with a 2-second sleep inserted before the udevadm call. > Sounds familiar.. too much familiar.. :) well, at least we found this patch is absolutely useless regarding this issue hopefully it seems dpkg version 1.19.3 will include the notify-await parameter, just in time for buster release thank you for all your time and efforts in testing all the possible solutions! ciao
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Thu, 24 Jan 2019 19:02:54 -0800
Bill Brelsford wrote:
> Thanks for the build instructions, Trek. However, dpkg-buildpackage
> fails (at test-condition, line 4259 in attached trace file).
to workaround these @#!%^&* tests, you should go in the systemd-240
directory and type as user:
sed -i 's/\(main(.*) {\)/\1 return 0;/' src/test/test-*.c
then try again to rebuild:
dpkg-buildpackage -b -uc -us
I hope it will work fine this time!
ciao
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Tue, 22 Jan 2019 18:21:43 -0800
Bill Brelsford wrote:
> I'm still using version 1.19.2+test2 of dpkg, but without udev's
> --wait-daemon argument. The next dpkg (1.19.3) will handle
> --wait-daemon; I assume including it in udev will fix the problem..?
these are two independent ways to fix the same issue:
1. modified dpkg to use start-stop-daemon with --notify-await parameter
2. modified udev to use udevadm trigger with --wait-daemon parameter
actually I don't know if the dpkg will be released with these
modifications in time for buster release
thanks to the work done by Michael Biebl, udev developers added the
--wait-daemon parameter
> Unfortunately, I'm not set up to re-compile so can't test your
> patches.
I can provide you a binary package with these patches applied, but it's
not a good security practice to install a package, that runs as root, if
it does not come from the package maintainers
if you want try to patch and compile yourself, you should type as root:
apt install build-essential fakeroot
echo 'deb-src http://httpredir.debian.org/debian buster main' \
>>/etc/apt/sources.list
apt-get update
LANG=C apt-get -s build-dep systemd | \
sed '/^ /!bA;H;$bA;d;:A;x;/The following NEW/!d;s/^The .*:\n//' \
>>/root/build-packages.txt
apt-get build-dep systemd
then as a normal user, download the attached patch into your home
directory and type:
mkdir ~/debian
cd ~/debian
apt-get source systemd
cd systemd-240
patch -p1 <~/udev-wait-daemon-full.patch
dpkg-buildpackage -b -uc -us
finally you can install the binary package and remove the development
packages, as root:
dpkg -i /home/user/debian/udev_240-4_i386.deb
apt-get purge $(cat /root/build-packages.txt)
apt-get purge build-essential fakeroot
for more info see https://wiki.debian.org/BuildingTutorial
thanks for your time!
ciaodiff -urN systemd-240/debian/udev.init systemd-240-new/debian/udev.init
--- systemd-240/debian/udev.init 2019-01-12 21:49:44.0 +0100
+++ systemd-240-new/debian/udev.init 2019-01-24 19:17:47.727632051 +0100
@@ -178,7 +178,7 @@
fi
log_action_begin_msg "Synthesizing the initial hotplug events (subsystems)"
-if udevadm trigger --type=subsystems --action=add; then
+if udevadm trigger --type=subsystems --action=add --wait-daemon; then
log_action_end_msg $?
else
log_action_end_msg $?
diff -urN systemd-240/man/udevadm.xml systemd-240-new/man/udevadm.xml
--- systemd-240/man/udevadm.xml 2018-12-21 19:53:33.0 +0100
+++ systemd-240-new/man/udevadm.xml 2019-01-24 19:17:47.687632051 +0100
@@ -319,6 +319,14 @@
the same command to finish.
+
+ --wait-daemon[=SECONDS]
+
+Before triggering uevents, wait for systemd-udevd daemon to be initialized.
+Optionally takes timeout value. Default timeout is 5 seconds. This is equivalent to invoke
+invoking udevadm control --ping before udevadm trigger.
+
+
diff -urN systemd-240/src/udev/udev-ctrl.c systemd-240-new/src/udev/udev-ctrl.c
--- systemd-240/src/udev/udev-ctrl.c 2018-12-21 19:53:33.0 +0100
+++ systemd-240-new/src/udev/udev-ctrl.c 2019-01-24 19:20:06.647633460 +0100
@@ -213,7 +213,7 @@
DEFINE_TRIVIAL_REF_UNREF_FUNC(struct udev_ctrl_connection, udev_ctrl_connection, udev_ctrl_connection_free);
-static int ctrl_send(struct udev_ctrl *uctrl, enum udev_ctrl_msg_type type, int intval, const char *buf, int timeout) {
+static int ctrl_send(struct udev_ctrl *uctrl, enum udev_ctrl_msg_type type, int intval, const char *buf, usec_t timeout) {
struct udev_ctrl_msg_wire ctrl_msg_wire;
int err = 0;
@@ -246,7 +246,7 @@
pfd[0].fd = uctrl->sock;
pfd[0].events = POLLIN;
-r = poll(pfd, 1, timeout * MSEC_PER_SEC);
+r = poll(pfd, 1, DIV_ROUND_UP(timeout, USEC_PER_MSEC));
if (r < 0) {
if (errno == EINTR)
continue;
@@ -267,35 +267,35 @@
return err;
}
-int udev_ctrl_send_set_log_level(struct udev_ctrl *uctrl, int priority, int timeout) {
+int udev_ctrl_send_set_log_level(struct udev_ctrl *uctrl, int priority, usec_t timeout) {
return ctrl_send(uctrl, UDEV_CTRL_SET_LOG_LEVEL, priority, NULL, timeout);
}
-int udev_ctrl_send_stop_exec_queue(struct udev_ctrl *uctrl, int timeout) {
+int udev_ctrl_send_stop_exec_queue(struct udev_ctrl *uctrl, usec_t timeout) {
return ctrl_send(uctrl, UDEV_CTRL_STOP_EXEC_QUEUE, 0, NULL, timeout);
}
-int udev_ctrl_send_start_exec_queue(struct udev_ctrl *uctrl, int timeout) {
+int udev_ctrl_send_start_exec_queue(struct udev_ctrl *uctrl, usec_t timeout) {
return ctrl_send(uctrl, UDEV_CTRL_START_EXEC_QUEUE, 0, NULL, timeout);
}
-int udev_ctrl_send_reload(struct udev_ctrl *uctrl, int timeout) {
+int udev_ctrl_send_reload(
Bug#908796: udev 240-2: failed to connect to udev daemon (on boot)
On Mon, 21 Jan 2019 16:34:56 + js jb wrote: > I'm surprised at the change between udev_240-2 and udev_240-4, since > I thought the -4 refers only to the debian revision but it resultedin > a significant change in the package's usability. some patches were gracefully backported from the next release by Michael Biebl: it appears to me (please correct me if I'm wrong) that systemd uses a rolling release model, so there are not (yet) any point releases and it's up to the package maintainers to backport the bug fixes as this bug is a race condition, something that comes up in relation to the timings when things are executed, there is a chance these patches changed the timings and the bug don't come up anymore moreover, one of these patches may be fixed the roots of this race condition: "sd-device-monitor: fix ordering of setting buffer size" https://github.com/systemd/systemd/commit/ee0b9e721a368742ac6fa9c3d9a33e45dc3203a2 the buffer was too small to receive all the uevents, if they were not processed in time by udev anyway I hope this explained why a debian revision resulted in code change and thus restored the usability ciao!
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Mon, 21 Jan 2019 08:36:51 +0100 Trek wrote: > and the one in the attach missed, sorry attached to this message--- udev.init.orig 2019-01-12 21:49:44.0 +0100 +++ udev.init 2019-01-21 01:54:51.047997585 +0100 @@ -178,7 +178,7 @@ fi log_action_begin_msg "Synthesizing the initial hotplug events (subsystems)" -if udevadm trigger --type=subsystems --action=add; then +if udevadm trigger --type=subsystems --action=add --wait-daemon; then log_action_end_msg $? else log_action_end_msg $?
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Sun, 13 Jan 2019 20:11:04 +0100 Michael Biebl wrote: > Can you test https://github.com/systemd/systemd/pull/11349 I have built and tested udev 240-4 with these patches: https://github.com/systemd/systemd/commit/3797776e11d2a242517c3a20a953b5d0e80384f8.patch https://github.com/systemd/systemd/commit/2001622c58c1989f386086d11bd2a00d5fe00a30.patch and the one in the attach it works, however I can't reproduce the bug if I remove the --wait-daemon argument, so I am not sure in practice, but at least in theory it seems to be the correct approach to fix this issue @Michael Biebl: thank you for your work with the upstream maintainers @Bill Brelsford: is the problem gone with the 240-4 version? if not, can you test udev with these patches applied? thanks! ciao
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Sun, 13 Jan 2019 20:11:04 +0100 Michael Biebl wrote: > Can you test https://github.com/systemd/systemd/pull/11349 I've just figured out how to download the patch from github I assume that you would apply this patch https://github.com/systemd/systemd/pull/11349/commits/4c234f0e6c03dd6f8cae2bc47e49a5f2e9a23d4b on top of the 240 version? this weekend I'll try to compile and test the package is it possible to compile only udev without rebuilding all the systemd packages? ciao!
Bug#908796: udev (with sysvinit) fails to find devices at boot
Version: 240-2 after upgrading from 239-13 to 240-2, the VGA card is no more recognized on my system, but adding a small sleep fixes the problem if dpkg will not be updated with the new sd-notify interface, I think it would be better to rollback the #791944 patch: the system will not shutdown correctly with cryptsetup, but at least it can boot (with and without cryptsetup) I can prepare a patch if needed ciao!
Bug#918009: firmware-amd-graphics: please add amdgpu firmware for kaveri
Version: 20180825+dfsg-1 I confirm the problem, it leads to a crash of the amdgpu module if the 4.19 kernel is booted with amdgpu.cik_support=1 radeon.cik_support=0 for further informations see https://bugs.freedesktop.org/show_bug.cgi?id=107855 comment 2 for the kernel messages and comment 4 for a simple workaround however the correct solution is to include the amdgpu firmware, as the radeon firmware seems to be no more updated ciao!
Bug#610719: dpkg: [S-S-B] make start-stop-daemon find out the pid of forked processes
this patch would be really useful for daemons like udev that does not create the pidfile (bugs #791944 and #908796) ciao!
Bug#888106: initramfs-tools: mkinitramfs should fail when ldd fails in copy_exec
On 23 Jan 2018 13:49:30 +0100
Andrew Shadura wrote:
> The return code of ldd is not handled at all. Should ldd fail for any
> reason, this failure will be ignored.
with this code, failures of ldd should be handled
ldd_output=$(ldd "${src}" 2>/dev/null) || return $?
for x in $(echo "$ldd_output" | sed -e …)
do
done
the problem is when copy_exec is used to copy script files, for
example as cryptsetup does to copy the keyscripts
it can be solved in two ways:
1) check if ldd is running fine at the start of mkinitramfs
ldd /bin/sh >/dev/null || exit $?
2) handle ldd errors and change packages to use copy_file instead of
copy_exec when copying files other than binaries
ciao!
Bug#908796: udev (with sysvinit) fails to find devices at boot
Hi, is there any blocking to fix this bug? can I help in some way? this is nearly a release critical bug, as it "makes unrelated software on the system break" (cryptsetup) and "the whole system" (some system don't boot) if dpkg can't be upgraded before the freeze, can we add a workaround to the cryptsetup package? the workaround would be to remove the udev control socket before sendsigs thank you!
Bug#916696: initramfs-tools: search for nonexistent resume device
Package: initramfs-tools Version: 0.132 at boot, initramfs blocks searching for a resume device Begin: Waiting for suspend/resume device ... Begin: Running /scripts/local-block ... done. I'm using sysvinit and two encrypted swap partitions the file /etc/initramfs-tools/conf.d/resume does not exist the contents of /etc/crypttab are: sda5_crypt /dev/disk/by-id/ata-XX-XX_-part5 /dev/urandom cipher=aes-xts-plain64,size=256,swap sdb5_crypt /dev/disk/by-id/ata-XX-XX_-part5 /dev/urandom cipher=aes-xts-plain64,size=256,swap if I disable swap (swapoff -a) and rebuild the initrd, the problem disappears can I do something to further investigate the issue? thank you!
Bug#911916: x11-apps: xcacl won't divide correctly on buster
> I was trying to calculate how much carfentanil I needed, and when I > tried 0.2/5000 I got the result 4e-05 it correct, the result is in the e-notation format, where MeN means M*10^N check with bc: $ echo "4*10^-5" | bc -l results in 0.4 exactly like: $ echo ".2/5000" | bc -l can this bug be closed? ciao!
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Tue, 16 Oct 2018 22:26:40 +0200
Michael Biebl wrote:
> > to Guilhem Moulin: I made a little patch because the socket
> > permissions seems to be wrong when --chuid is specified
> I think you meant Guillem (our dear dpkg maintainer) here?
yes, I'm sorry, please Guillem Jover can you check this patch?
ciao!>From 67d080cc7c195f1a34cb6a0dc7ac7a5d9dbad28d Mon Sep 17 00:00:00 2001
From: Trek
Date: Tue, 16 Oct 2018 21:45:42 +0200
Subject: [PATCH] Set the proper permissions to s-s-d notify socket and
directory
If the --chuid parameter is specified, the notify socket is not
accessible by the client, because mkdtemp() creates a directory owned
by root with 0700 permission. Moreover fchown() on a socket does not
have effects, because a socket doesn't have an associated inode.
Change the directory owner to runas_uid and use chown() instead of
fchown() to change the socket owner. Drop unneeded fchmod().
---
utils/start-stop-daemon.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/utils/start-stop-daemon.c b/utils/start-stop-daemon.c
index 476b31b..5f14931 100644
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
@@ -548,6 +548,9 @@ setup_socket_name(const char *suffix)
atexit(cleanup_socket_dir);
+ if (chown(notify_sockdir, runas_uid, runas_gid))
+ fatal("cannot change socket directory ownership");
+
if (asprintf(¬ify_socket, "%s/notify", notify_sockdir) < 0)
fatal("cannot allocate socket name");
@@ -578,7 +581,7 @@ create_notify_socket(void)
if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) < 0)
fatal("cannot set close-on-exec flag for notification socket");
- sockname = setup_socket_name(".s-s-d-notify");
+ sockname = setup_socket_name("start-stop-daemon");
/* Bind to a socket in a temporary directory, selected based on
* the platform. */
@@ -590,12 +593,7 @@ create_notify_socket(void)
if (rc < 0)
fatal("cannot bind to notification socket");
- rc = fchmod(fd, 0660);
- if (rc < 0)
- fatal("cannot change notification socket permissions");
-
- rc = fchown(fd, runas_uid, runas_gid);
- if (rc < 0)
+ if (chown(su.sun_path, runas_uid, runas_gid))
fatal("cannot change notification socket ownership");
// XXX: verify we are talking to an expected child?? not sure whether
@@ -1446,7 +1444,7 @@ parse_options(int argc, char * const *argv)
badusage("--remove-pidfile requires --pidfile");
if (pid_str && pidfile)
- badusage("need either --pid of --pidfile, not both");
+ badusage("need either --pid or --pidfile, not both");
if (background && action != ACTION_START)
badusage("--background is only relevant with --start");
--
2.1.4
Bug#908796: udev (with sysvinit) fails to find devices at boot
good job!
with cryptsetup the new patches are running fine
thank you to every one!
to Guilhem Moulin: I made a little patch because the socket permissions
seems to be wrong when --chuid is specified
ciao :)>From 67d080cc7c195f1a34cb6a0dc7ac7a5d9dbad28d Mon Sep 17 00:00:00 2001
From: Trek
Date: Tue, 16 Oct 2018 21:45:42 +0200
Subject: [PATCH] Set the proper permissions to s-s-d notify socket and
directory
If the --chuid parameter is specified, the notify socket is not
accessible by the client, because mkdtemp() creates a directory owned
by root with 0700 permission. Moreover fchown() on a socket does not
have effects, because a socket doesn't have an associated inode.
Change the directory owner to runas_uid and use chown() instead of
fchown() to change the socket owner. Drop unneeded fchmod().
---
utils/start-stop-daemon.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/utils/start-stop-daemon.c b/utils/start-stop-daemon.c
index 476b31b..5f14931 100644
--- a/utils/start-stop-daemon.c
+++ b/utils/start-stop-daemon.c
@@ -548,6 +548,9 @@ setup_socket_name(const char *suffix)
atexit(cleanup_socket_dir);
+ if (chown(notify_sockdir, runas_uid, runas_gid))
+ fatal("cannot change socket directory ownership");
+
if (asprintf(¬ify_socket, "%s/notify", notify_sockdir) < 0)
fatal("cannot allocate socket name");
@@ -578,7 +581,7 @@ create_notify_socket(void)
if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) < 0)
fatal("cannot set close-on-exec flag for notification socket");
- sockname = setup_socket_name(".s-s-d-notify");
+ sockname = setup_socket_name("start-stop-daemon");
/* Bind to a socket in a temporary directory, selected based on
* the platform. */
@@ -590,12 +593,7 @@ create_notify_socket(void)
if (rc < 0)
fatal("cannot bind to notification socket");
- rc = fchmod(fd, 0660);
- if (rc < 0)
- fatal("cannot change notification socket permissions");
-
- rc = fchown(fd, runas_uid, runas_gid);
- if (rc < 0)
+ if (chown(su.sun_path, runas_uid, runas_gid))
fatal("cannot change notification socket ownership");
// XXX: verify we are talking to an expected child?? not sure whether
@@ -1446,7 +1444,7 @@ parse_options(int argc, char * const *argv)
badusage("--remove-pidfile requires --pidfile");
if (pid_str && pidfile)
- badusage("need either --pid of --pidfile, not both");
+ badusage("need either --pid or --pidfile, not both");
if (background && action != ACTION_START)
badusage("--background is only relevant with --start");
--
2.1.4
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Sun, 7 Oct 2018 01:57:31 +0200
Michael Biebl wrote:
> > - We tweak the LSB headers to make sure the udev init script is
> > called before sendsigs on shutdown. This is important!
>
> I have to add, that this change has the potential to significantly
> change the shutdown order or cause a conflicting ordering, in case
> there are other init scripts which declare an explicit shutdown
> dependency.
yes, this would create a circular dependency
before the 791944 patch, the shutdown sequence was:
K03sendsigs (before umountnfs)
K05umountnfs(before umountfs)
K07umountfs (before umountroot)
K08cryptdisks (after umountfs, before umountroot udev)
K10umountroot
if udev is stopped before sendsigs:
- cryptdisks should be stopped before udev
- umountfs should be stopped before cryptdisks
- umountnfs should be stopped before umountfs
- but sendsigs cannot be stopped after umountnfs
it can be easily resolved removing the udev entry in the Should-Stop
header of cryptdisks (and cryptdisks-early)
> Looking at https://codesearch.debian.net/ and searching for packages
> which declare a Should-Stop or Required-Stop on udev and checking if
> any late shutdown services are involved.
wow! I didn't know this site
with this simple search "Stop(|-After):.*udev", it returned these
packages that could be affected: multipath-tools, pcsc-lite,
network-manager, mouseemu, pulseaudio, cryptsetup, nut
it seems to me none of these packages would break (except cryptsetup)
this change should be mentioned in the NEWS.Debian file, as it could
break any script that depends on udev on shutdown and that is not
distributed by debian (open/closed source packages and system
administrator scripts)
the patches attached are tested on a system with swaps and filesystems
encrypted in plain mode (no luks, no cryptroot)
ciao!>From b8f8bcfa1c447bc0839a84c4f64a551278a33dec Mon Sep 17 00:00:00 2001
From: Trek
Date: Sun, 7 Oct 2018 17:59:25 +0200
Subject: [PATCH] Stop udev before sendsigs to fix a regression of #791944
The start-stop-daemon command with the --background argument returns
immediately, too soon to trigger events on some systems. The #791944
patch is partly reverted and a dependency to sendsigs is added in the
SysV init script at shutdown.
Closes: #908796
---
debian/udev.init | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/debian/udev.init b/debian/udev.init
index 9c394bb..794373d 100644
--- a/debian/udev.init
+++ b/debian/udev.init
@@ -3,6 +3,7 @@
# Provides: udev
# Required-Start:mountkernfs
# Required-Stop: umountroot
+# Should-Stop: sendsigs
# Default-Start: S
# Default-Stop: 0 6
# Short-Description: Start systemd-udevd, populate /dev and load drivers.
@@ -12,9 +13,7 @@ PATH="/sbin:/bin"
NAME="systemd-udevd"
DAEMON="/lib/systemd/systemd-udevd"
DESC="hotplug events dispatcher"
-PIDFILE="/run/udev.pid"
CTRLFILE="/run/udev/control"
-OMITDIR="/run/sendsigs.omit.d"
# we need to unmount /dev/pts/ and remount it later over the devtmpfs
unmount_devpts() {
@@ -165,11 +164,7 @@ case "$1" in
[ -x /sbin/restorecon ] && /sbin/restorecon -R /dev
log_daemon_msg "Starting $DESC" "$NAME"
-if start-stop-daemon --start --name $NAME --user root --quiet \
---pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then
-# prevents udevd to be killed by sendsigs (see #791944)
-mkdir -p $OMITDIR
-ln -sf $PIDFILE $OMITDIR/$NAME
+if $DAEMON --daemon; then
log_end_msg $?
else
log_warning_msg $?
@@ -198,7 +193,7 @@ case "$1" in
stop)
log_daemon_msg "Stopping $DESC" "$NAME"
if start-stop-daemon --stop --name $NAME --user root --quiet \
---pidfile $PIDFILE --remove-pidfile --oknodo --retry 5; then
+--oknodo --retry 5; then
# prevents cryptsetup/dmsetup hangs (see #791944)
rm -f $CTRLFILE
log_end_msg $?
@@ -210,7 +205,7 @@ case "$1" in
restart)
log_daemon_msg "Stopping $DESC" "$NAME"
if start-stop-daemon --stop --name $NAME --user root --quiet \
---pidfile $PIDFILE --remove-pidfile --oknodo --retry 5; then
+--oknodo --retry 5; then
# prevents cryptsetup/dmsetup hangs (see #791944)
rm -f $CTRLFILE
log_end_msg $?
@@ -219,11 +214,7 @@ case "$1" in
fi
log_daemon_msg "Starting $DESC" "$NAME"
-if start-stop-daemon --start --name $NAME --user root --quiet \
---pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then
-# prevents udevd to be killed by sendsigs (see #791944)
-mkdir -p $OMITDIR
-ln -sf $PIDFILE $OMITDIR/$NAME
+if $DAEMON --daemon; then
log_
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Thu, 4 Oct 2018 21:58:38 +0200 Michael Biebl wrote: > > 1) revert the 791944 patch, create a new init.d/udev-clear script to > > remove the control file and run it just after sendsigs (this will > > restore the old well tested behavior) > > The removal of the control file should be bound to the live time of > the udev service, so splitting it off into a separate init script is > not a good idea. yes, to be sure, we should call udev-clear before sendsigs this will mimic the old behavior, where the control file doesn't exists after sendsigs I think this is the first step we should do to restore the functionality, then we have more time to find the proper solution, but at least we will not miss another stable release without a functioning udev + sysvinit + dmsetup/cryptdisks > Afaics this problem is unfortunately not really fixable with the > limited facilities sysvinit/sysv-rc provides. this is why I think we should consider to live with a workaround, that at least allows the users to boot and shutdown the system > A proper solution might (emphasis on might, as I haven't checked this) > be to teach start-stop-daemon about daemons using the sd-notify > interface. This is a more elaborate fix, for sure, but everything else > feels like an incomplete hack. yes, probably this is a good solution as start-stop-daemon is called in parallel, it could be required to create a different notify socket per instance, but luckily the client library manage the NOTIFY_SOCKET environment variable another possible solution is to add an option to udev to remove the control file on exit, as it was in the past thank you and ciao!
Bug#908796: udev (with sysvinit) fails to find devices at boot
thanks to Bill Brelsford, the last test confirmed we are in the worst situation: udev is running, the control file is created, but udev is not ready to listen new events so we must to rethink about the 791944 bug: it was caused because udev no longer removes the control file on stop we have at least three options to workaround it: 1) revert the 791944 patch, create a new init.d/udev-clear script to remove the control file and run it just after sendsigs (this will restore the old well tested behavior) 2) revert the 791944 patch, remove the control file on stop in init.d/udev, stop it after sendsigs and remove udev from the Should-Stop header in any script, probably cryptdisks, mdadm and lvm2 (this could break any script that depends on udev and not distributed by debian) 3) do not revert, but start with udevd --background and create the pidfile using pidof udevd (this could break if there are more than one process of udevd) what do you think about? thanks for your time Trek
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Mon, 1 Oct 2018 01:11:30 +0200 Michael Biebl wrote: > The only supported way in udev to signal readiness is the sd-notify > API. My gut feeling is, that having an sd-notify wrapper for > non-systemd systems (e.g. directly built into start-stop-daemon via > say an --wait-for-sd-notify switch) would be the cleanest and most > robust way. This might even benefit other daemons besides udevd. nice catch, but probably it cannot be done in time for buster freeze after another code inspection, I wrote a simpler version of the patch, as it only checks for the existence of the control file it should be sufficient as udev --daemon forks and exits just after calling listen_fds(), that creates the control file via bind() to Bill Brelsford: please, can you try again if this new patch fixes the problem? thank you! ciao>From e1322be4d6416259a0e3e1e4370e8ff722cda146 Mon Sep 17 00:00:00 2001 From: Trek Date: Mon, 1 Oct 2018 06:38:35 +0200 Subject: [PATCH] Wait for udev to be ready before trigger under sysvinit The start-stop-daemon command with the --background argument returns immediately, too soon to trigger events on some systems. Update the SysV init script to wait until udev is ready, checking the control file. Closes: #908796 --- debian/udev.init | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/debian/udev.init b/debian/udev.init index 9c394bb..374df4e 100644 --- a/debian/udev.init +++ b/debian/udev.init @@ -170,11 +170,16 @@ case "$1" in # prevents udevd to be killed by sendsigs (see #791944) mkdir -p $OMITDIR ln -sf $PIDFILE $OMITDIR/$NAME -log_end_msg $? + +# wait for udev to be ready (see #908796) +timeout=150 +until [ -S $CTRLFILE -o $timeout -le 0 ]; do +timeout=$((timeout - 1)) +sleep 0.1 +done +[ -S $CTRLFILE ] && log_success_msg || log_failure_msg else -log_warning_msg $? -log_warning_msg "Waiting 15 seconds and trying to continue anyway" -sleep 15 +log_failure_msg fi log_action_begin_msg "Synthesizing the initial hotplug events" -- 2.1.4
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Sat, 29 Sep 2018 18:41:45 +0200 Michael Biebl wrote: > > +# wait for udev to be ready (see #908796) > > +timeout=15 > > +until udevadm control -S || [ $timeout -le 0 ]; do > > +timeout=$((timeout-1)) > > +sleep 1 > > +done > > +udevadm control -S && log_success_msg || log_failure_msg > > This repeatedly tries to start the execution queue. > Besides having this side-effect, why is this a proper test to check if > udev is ready? this probably shows my ignorance about udev (and lack of documentation), but it seems to me there isn't a proper way to test if udev is ready as the bug doesn't affect my system, I cannot know the state of udev when the udevadm trigger is launched: it could be the control file is missing or it's created but the daemon is not already accepting events reading the source, there is a ping message that is recognized by the control socket, sent internally by udevadm settle, but there isn't a command line for that message in particular it seems to me the least dangerous command is to start the execution queue: in fact when udev is just started, the stop_exec_queue variable is set to false, then the start of exec queue command will set again stop_exec_queue to false and it should results in a no-op we could simply rerun udevadm trigger until it's ok, but it seems not a good idea https://github.com/kubernetes/kubernetes/issues/55007 may be their fix (calling settle with timeout before trigger) will work for us? I don't know, as there are many possible side effects depending on the hardware it could be a good idea to ask the developers, but reading https://github.com/systemd/systemd/issues/2477 it seems they are not really interested about this type of issue and in forward compatibility (it was running fine until they stopped to remove the control socked on exit) I hope I have answered your question, anyway tell me if I can do something more ciao!
Bug#908796: udev (with sysvinit) fails to find devices at boot
On Thu, 13 Sep 2018 19:02:26 -0700 Bill Brelsford wrote: > With the --background argument, a race condition exists and > "udevadm trigger" starts too soon. > A workaround is to add a short sleep: can you try if this patch fixes the problem? my system is not affected so I can't check thank you! the sleep timeout could be different depending on the hardware, so it checks every second if udev is ready, up to 15 seconds it seems to be there is no reliable method to know if udev is running fine, so it calls udevadm control -S, that it's essentially a no-op when udev is just started, but at least it checks if the control socket is listening ciao >From 1c9dd060a25d904aa200c9fdc33e34dc003dd1d8 Mon Sep 17 00:00:00 2001 From: Trek Date: Sat, 15 Sep 2018 05:50:03 +0200 Subject: [PATCH] Wait for udev to be ready before trigger under sysvinit The start-stop-daemon command with the --background argument returns immediately, too soon to trigger events on some systems. Update the SysV init script to wait until udev is ready. Closes: #908796 --- debian/udev.init | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/debian/udev.init b/debian/udev.init index 9c394bb..4b30297 100644 --- a/debian/udev.init +++ b/debian/udev.init @@ -170,11 +170,16 @@ case "$1" in # prevents udevd to be killed by sendsigs (see #791944) mkdir -p $OMITDIR ln -sf $PIDFILE $OMITDIR/$NAME -log_end_msg $? + +# wait for udev to be ready (see #908796) +timeout=15 +until udevadm control -S || [ $timeout -le 0 ]; do +timeout=$((timeout-1)) +sleep 1 +done +udevadm control -S && log_success_msg || log_failure_msg else -log_warning_msg $? -log_warning_msg "Waiting 15 seconds and trying to continue anyway" -sleep 15 +log_failure_msg fi log_action_begin_msg "Synthesizing the initial hotplug events" -- 2.1.4
Bug#791944: /etc/init.d/sendsigs kills systemd-udevd upon shutdown, causing dmsetup to hang
On Fri, 7 Sep 2018 19:41:52 +0200 Michael Biebl wrote: > I made an upload today which incorporates that patch (with a small fix > as udev needs a aproper ordering on shutdown against umountroot). I see, thank you, you was faster than me :)
Bug#791944: /etc/init.d/sendsigs kills systemd-udevd upon shutdown, causing dmsetup to hang
On Mon, 3 Sep 2018 16:41:58 +0200 Michael Biebl wrote: > The patch looks fine to me from a cursory glance. I haven't tested it > though. Trek, I assume you built a test package and did a test-upgrade > checking it works as expected? I haven't built a test package, but instead I have patched the compiled deb package with dpkg-deb -R and dpkg-deb -b and tested the upgrade process I'll build udev from the source package in the next days, then I'll test again the upgrade process (manually removing rc*.d/K* symlinks before install the new package) and the shutdown fix > If you don't mind, would you send a git formatted patch so the changes > are properly attributed to you? I think it should not be attributed to me, as it's the result of a very collaborative work, especially (in order of appearance) Guilhem Moulin, Theppitak Karoonboonyanan, Felipe Sateler, Michael Biebl, Pali Rohár and at last me > The git commit message should follow gbp-dch style, with a Closes: > #791944. A MR via https://salsa.debian.org/systemd-team/systemd would > be even nicer. It's not a pre-requisite it just makes things more > convenient for us and speeds up processing. I'll try to do it many thanks to you! Trek
Bug#791944: /etc/init.d/sendsigs kills systemd-udevd upon shutdown, causing dmsetup to hang
Hi, I write directly to you, as in the past you pointed out some additional fixes to do is there any remaining work that I can do to get this patch merged? it a really annoying bug, that prevents a clean shutdown/unmount of the system many thanks in advance ciao!
Bug#791944: /etc/init.d/sendsigs kills systemd-udevd upon shutdown, causing dmsetup to hang
Hi,
I can confirm the version 239-7 is affected by this bug and it's fixed
by the patch written by Pali Rohár
I've added a fix in the maintainer scripts to actually create rc.d
symlinks on upgrade and some little lifting to the init.d script
thanks to all the people involved!
also I would like to port the init.d script to the new init-d-script
format, it would be accepted? or at least to move the start and stop
code in functions, to remove code duplication in the restart action
c-ya!
diff -urN systemd-239/debian/udev.init systemd-239-cryptsetup-fix/debian/udev.init
--- systemd-239/debian/udev.init 2018-07-22 13:40:15.0 +0200
+++ systemd-239-cryptsetup-fix/debian/udev.init 2018-08-11 11:51:48.0 +0200
@@ -4,10 +4,18 @@
# Required-Start:mountkernfs
# Required-Stop:
# Default-Start: S
-# Default-Stop:
+# Default-Stop: 0 6
# Short-Description: Start systemd-udevd, populate /dev and load drivers.
### END INIT INFO
+PATH="/sbin:/bin"
+NAME="systemd-udevd"
+DAEMON="/lib/systemd/systemd-udevd"
+DESC="the hotplug events dispatcher"
+PIDFILE="/run/udev.pid"
+CTRLFILE="/run/udev/control"
+OMITDIR="/run/sendsigs.omit.d"
+
# we need to unmount /dev/pts/ and remount it later over the devtmpfs
unmount_devpts() {
if mountpoint -q /dev/pts/; then
@@ -98,10 +106,6 @@
##
-PATH="/sbin:/bin"
-NAME="systemd-udevd"
-DAEMON="/lib/systemd/systemd-udevd"
-DESC="the hotplug events dispatcher"
[ -x $DAEMON ] || exit 0
@@ -175,7 +179,11 @@
[ -x /sbin/restorecon ] && /sbin/restorecon -R /dev
log_daemon_msg "Starting $DESC" "$NAME"
-if $DAEMON --daemon; then
+if start-stop-daemon --start --name $NAME --user root --quiet \
+ --pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then
+ # prevents to be killed by sendsigs (see #791944)
+ mkdir -p $OMITDIR
+ ln -sf $PIDFILE $OMITDIR/$NAME
log_end_msg $?
else
log_warning_msg $?
@@ -203,7 +211,9 @@
stop)
log_daemon_msg "Stopping $DESC" "$NAME"
-if start-stop-daemon --stop --name $NAME --user root --quiet --oknodo --retry 5; then
+if start-stop-daemon --stop --name $NAME --user root --quiet \
+ --pidfile $PIDFILE --remove-pidfile --oknodo --retry 5; then
+ rm -f $CTRLFILE# prevents cryptsetup/dmsetup hangs (see #791944)
log_end_msg $?
else
log_end_msg $?
@@ -212,14 +222,20 @@
restart)
log_daemon_msg "Stopping $DESC" "$NAME"
-if start-stop-daemon --stop --name $NAME --user root --quiet --oknodo --retry 5; then
+if start-stop-daemon --stop --name $NAME --user root --quiet \
+ --pidfile $PIDFILE --remove-pidfile --oknodo --retry 5; then
+ rm -f $CTRLFILE# prevents cryptsetup/dmsetup hangs (see #791944)
log_end_msg $?
else
log_end_msg $? || true
fi
log_daemon_msg "Starting $DESC" "$NAME"
-if $DAEMON --daemon; then
+if start-stop-daemon --start --name $NAME --user root --quiet \
+ --pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then
+ # prevents to be killed by sendsigs (see #791944)
+ mkdir -p $OMITDIR
+ ln -sf $PIDFILE $OMITDIR/$NAME
log_end_msg $?
else
log_end_msg $?
diff -urN systemd-239/debian/udev.postinst systemd-239-cryptsetup-fix/debian/udev.postinst
--- systemd-239/debian/udev.postinst 2018-07-22 13:40:15.0 +0200
+++ systemd-239-cryptsetup-fix/debian/udev.postinst 2018-08-11 11:51:57.0 +0200
@@ -85,6 +85,11 @@
NamePolicy=onboard kernel
EOF
fi
+
+ # new Default-Stop (see #791944)
+ if dpkg --compare-versions "$2" le '239-7'; then
+update-rc.d -f udev remove
+ fi
}
update_hwdb() {
Bug#868453: xorg flooded by dbus messages
Package: xserver-xorg-core Version: 2:1.16.4-1+deb8u1 Dear maintainer, after the security upgrade from 2:1.16.4-1 to 2:1.16.4-1+deb8u1, I got flooded by dbus messages (which is not installed) every 10 seconds (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory) can you revert to the previous configuration where libdbus is not linked in? thanks!
Bug#528058: patch
Control: tags -1 patch
xfonts-75dpi or 100dpi are required by the X client, but not for the
server alone
c-ya!--- control.orig 2017-05-15 17:21:30.0 +0200
+++ control 2017-05-15 17:23:22.716441323 +0200
@@ -9,6 +9,7 @@
Package: xfrisk
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Recommends: xfonts-75dpi | xfonts-100dpi
Description: Server and X11 client for playing risk with humans or AIs
Risk is a board game played on a map of the world. You control a group
of armies and attempt to capture large sections of the world and try to
Bug#827395: firefox hidden connections
the connections you found can be blocked by changing these configuration directives: browser.newtabpage.enabled security.OCSP.enabled browser.safebrowsing.enabled browser.safebrowsing.malware.enabled privacy.trackingprotection.pbmode.enabled browser.search.suggest.enabled browser.search.update extensions.blocklist.enabled extensions.update.enabled extensions.getAddons.cache.enabled datareporting.healthreport.service.enabled toolkit.telemetry.enabled network.http.speculative-parallel-limit and may be: beacon.enabled browser.send_pings from time to time I have collected a list of configuration directives to stop automatic connections to remote hosts you can find at http://www.trek.eu.org/text/firefox-tuning.html I hope this can help
Bug#823908: bad dependencies
On Tue, 10 May 2016 10:34:37 + (UTC)
Gianfranco Costamagna wrote:
> Hi, can you please double-check this commit?
>
> http://anonscm.debian.org/cgit/pkg-gambas/gambas3.git/commit/?id=adacb811579d0bf80fe805829ed707f96d2f6789
>
> otherwise feel free to propose a patch
I made a new patch based on your commit, to fix all the gui related
dependencies
the simpler way to fix dependencies is to check this page at first:
http://gambaswiki.org/wiki/howto/package
then I check the Require line in /usr/lib/gambas3/*.component files, to
make sure that all dependencies are satisfied even if the packaging is
different
some component (like gb.gui, gb.gui.opengl, gb.db) search runtime for
packages, so you can find the needed components searching for strings in
the /usr/lib/gambas3/*.so files (but reading the source code is better)
in the next days, I will send you a bigger patch, with other
dependencies fixed
> thanks
thanks to you!
--- control.orig 2016-05-11 23:38:11.777590135 +0200
+++ control 2016-05-12 00:15:36.121548098 +0200
@@ -484,7 +484,7 @@
Package: gambas3-gb-gtk
Architecture: any
Section: libdevel
-Depends: gambas3-runtime (>= ${binary:Version}),
+Depends: gambas3-runtime (>= ${binary:Version}), gambas3-gb-image (>= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
Description: Gambas GTK+ component
@@ -496,7 +496,7 @@
Package: gambas3-gb-gtk3
Architecture: any
Section: libdevel
-Depends: gambas3-runtime (>= ${binary:Version}),
+Depends: gambas3-runtime (>= ${binary:Version}), gambas3-gb-image (>= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
Description: Gambas GTK+3 component
@@ -536,7 +536,7 @@
Package: gambas3-gb-gui-opengl
Architecture: any
Section: libdevel
-Depends: gambas3-gb-gtk-opengl (>= ${binary:Version}) | gambas3-gb-gui (>= ${binary:Version}) | gambas3-gb-qt5-opengl (>= ${binary:Version}) | gambas3-gb-qt4-opengl (>= ${binary:Version}),
+Depends: gambas3-gb-gui (>= ${binary:Version}), gambas3-gb-opengl (>= ${binary:Version}), gambas3-gb-gtk-opengl (>= ${binary:Version}) | gambas3-gb-qt5-opengl (>= ${binary:Version}) | gambas3-gb-qt4-opengl (>= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
Description: Gambas OpenGL selector
@@ -741,7 +741,7 @@
Package: gambas3-gb-opengl
Architecture: any
Section: libdevel
-Depends: gambas3-runtime (>= ${binary:Version}),
+Depends: gambas3-runtime (>= ${binary:Version}), gambas3-gb-image (>= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
Description: Gambas OpenGL component
@@ -812,7 +812,7 @@
Package: gambas3-gb-qt4
Architecture: any
Section: libdevel
-Depends: gambas3-runtime (>= ${binary:Version}),
+Depends: gambas3-runtime (>= ${binary:Version}), gambas3-gb-image (>= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
Description: Gambas Qt GUI component
@@ -824,7 +824,7 @@
Package: gambas3-gb-qt5
Architecture: any
Section: libdevel
-Depends: gambas3-runtime (>= ${binary:Version}),
+Depends: gambas3-runtime (>= ${binary:Version}), gambas3-gb-image (>= ${binary:Version}),
${misc:Depends},
${shlibs:Depends}
Description: Gambas Qt5 GUI component
Bug#823913: remove gconf
Package: pidgin Version: 2.10.12-1 the gconf2 dependency must be removed, as it pollutes desktop environments other than gnome gconf is useful only with gnome, where it is already installed ciao!
Bug#823909: bad dependencies
Package: libfarstream-0.2-5 Version: 0.2.7-1 libfarstream must not depends on gstreamer1.0-plugins-* instead, the application packages should depend on these plugins like any other GIO interface, they are dynamically loaded only if found, so it's up to the user to decide what features want to install you can check the same behavior on other packages using gstreamer like: parole, snappy, clementine, gnac, libwine, etc the extra dependencies are that should be removed or suggested only are: libgupnp-1.0-4, libgupnp-igd-1.0-4, libnice10, gstreamer0.10-plugins-base, gstreamer0.10-plugins-good, gstreamer0.10-plugins-bad, gstreamer0.10-nice
Bug#823908: bad dependencies
Package: gambas3 Version: 3.5.4-2 I'm reviving this thread as it was confirmed by upstream developer and has a patch to fix. Basically: - gb.gui technically depends on no components, as it searches for GUI components (gb.gtk, gb.gtk3 and gb.qt4) at runtime. Concretely, it should depends on gb.gtk OR gb.gtk3 OR gb.qt4. Same logic with gb.gui.opengl. - gb.db depends on nothing. It may depends on gb.db.mysql OR gb.db.postgresql... But there is no need for that normally. It's up to the developer to make its project depends on the database driver it needs. http://lists.alioth.debian.org/pipermail/pkg-gambas-devel/Week-of-Mon-20141124/000369.html
Bug#779824: claws-mail depends on plugins libraries
Package: claws-mail Version: 3.10.1-2~bpo70+1 installing claws-mail 3.10+ on Debian (jessie and wheezy-backports) results to the installation of libgpgme and thus all the gnupg2 stuff, nearly doubling the required disk space (20.2MB vs 11.9MB on a minimal setup with openbox and iceweasel) the claws-mail binary of the 3.10+ versions is linked to libgpgme, but it was not the case for the 3.8 version (Debian wheezy), anyway the binary does not use any of the exported symbols of gpgme I see no related changes in the sources, as gpgpme is only used by the pgp plugins, in both 3.8 and 3.10+, so why the resulting binary links to libgpgme? it may be related to the configure scripts, libtool or something else, but a simple way to fix it should be to remove the GPGME_LIBS from the claws_mail_LDADD variable in src/Makefile.am further research with the aid of 'ldd -r -u' and 'objdump -dpr' led me to figure out that libarchive is used only by a plugin, but it is linked with the claws-mail binary and with all the other plugins! (removing libarchive saves 0.9MB of additional space) the correct way should be to link only the pgp plugins with the GPGME_LIBS and only the archiver plugin with the ARCHIVE_LIBS, but I'm not really sure how to do it thanks to patchelf I tested claws-mail with libarchive, libassuan, libgpgme and libgpg-error removed and it runs fine (plugins not tested) ciao -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697905: persistent naming in crypttab
as I have installed jessie with debootstrap, I cannot verify if the swap config lines in /etc/crypttab are safe now, but reading the source they are not the patch I proposed 2 years ago sadly run only on linux but not on kfreebsd nor hurd may be that in the meanwhile we can add a warning in the README.Debian file of the cryptsetup package? The user should be informed to use /dev/disk/by-id devices on linux or a precheck script with the other kernels ciao -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778500: iputils-ping: reconfiguring with setcap leaves the binary suid
Package: iputils-ping Version: 3:20121221-5 Tags: patch I have installed iputils-ping without having setcap, so the /bin/ping* binaries where suid root thanks to the warning message, I have installed libcap2-bin and then ran dpkg-reconfigure on iputils-ping, but even if the setcap was done correctly, the binaries remain setuid I have to remove and then reinstall iputils-ping to have /bin/ping* nosuid and with capabilities the attached patch should be sufficient for ping, but also the arping, clockdiff and tracepath postinst files should be modified accordingly ciao--- iputils-ping.postinst 2014-02-01 22:16:48.0 +0100 +++ iputils-ping.postinst.nosuid 2015-02-15 23:10:10.459548411 +0100 @@ -8,6 +8,7 @@ # bit. if command -v setcap > /dev/null; then if setcap cap_net_raw+ep /bin/ping cap_net_raw+ep /bin/ping6; then +chmod u-s /bin/ping /bin/ping6 echo "Setcap worked! Ping(6) is not suid!" else echo "Setcap failed on /bin/ping, falling back to setuid" >&2
Bug#778499: purging does not remove all configuration files
Package: systemd Version: 215-11 purging the systemd package leaves the system dirty, as it does not remove /etc/sytemd/system/*remote-fs* (or something similar) and possibly other files and directories created on postinst one cannot simply remove the /etc/systemd directory as it may contains files from other packages like syslog.service from rsyslog created on postinst by init-system-helpers adding to prerm the systemctl disble remote-fs.target commad may be sufficient to remove the symlinks on /etc, but I do not know how systemd works ciao -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668001: please help test proposed patch for bug#668001
the patch works perfectly, I hope it will be included in jessie+1 you can roughly apply the patch on debootstrap 1.0.66 with: patch -r- /usr/sbin/debootstrap 668001.patch patch -r- /usr/share/debootstrap/functions 668001.patch and press enter to any question after patching I can install a new system using sysvinit-core with: debootstrap --exclude=systemd,systemd-sysv /mnt http://ftp.debian.org/debian/ I must exclude not only systemd-sysv but also systemd, because it does not remove some configuration file on purge and will leave dirty the just installed system, but I will submit another bug report for that ciao P.S.: the preseed/late_command does not apply to debootstrap and will leave the system dirty until the systemd bug is not resolved -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#21941: dpkg usage of /var
here the example hooks for readonly /usr and noexec /var that should be
added to /etc/apt/apt.conf to works with apt-get/aptitude:
DPkg {
// Auto re-mounting of a readonly /usr and noexec /var
Pre-Invoke { "mount -o remount,rw /usr && mount -o remount,exec /var"; };
Post-Invoke { "test ${NO_APT_REMOUNT:-no} = yes || mount -o remount,ro /usr
&& mount -o remount,noexec /var || true"; };
};
this is slightly modified from the debian wiki:
https://wiki.debian.org/ReadonlyRoot#Make_apt-get_remount_.2F_if_needed
ciao
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763399: Hardening dpkg/apt
I never submitted a bugreport for that, as I thought it was too
paranoid for debian, but while the new version of apt uses a similar
method, I want to share the one I used since wheezy to drop privileges:
adduser --system --home /var/lib/apt --no-create-home --group apt
dpkg-statoverride --update --add apt apt 755 \
/var/cache/apt/archives/partial
dpkg-statoverride --update --add apt apt 755 /var/lib/apt/lists/partial
install -m 700 -d /root/.aptitude
cp -a /usr/lib/apt/methods ~/.aptitude
chown apt:apt /root/.aptitude/methods/{ftp,http,mirror,rsh}
chmod 6755 /root/.aptitude/methods/{ftp,http,mirror,rsh}
now you can launch apt-get or aptitude setting the Dir::Bin::Methods
configuration option to /root/.aptitude/methods, for example:
apt-get -o Dir::Bin::Methods=/root/.aptitude/methods install aptitude
or creating the file /root/.aptitude/config with this content:
Dir "/";
Dir::Bin "";
Dir::Bin::Methods "/root/.aptitude/methods";
thanks to the modular design of apt-get, this solution is applicable
for the wheezy/jessie users, as you don't even need to modify the
source, but you must take care to upgrade the files
on /root/.aptitude/methods/* every time the apt package is updated
ciao!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550891: It is a libfarstream packaging bug
On Sat, 07 Dec 2013 10:28:55 -0500 Ari Pollak wrote: >Thanks for the patch. For the patch to the libpurple source, can you >try to get it merged with pidgin upstream? I don't really trust myself >to maintain a far-reaching patch that I didn't write, since I am not an >expert on the upstream source. The patch on the libpurple source code is not useful, because it does not add any real functionality that is not already present, as the gstreamer/farstream libraries do the dynamic loading work of their plugins. So there is no need to patch the code. I have included it only as a reference and an alternative way to circumvent the problem in the future. >As far as the patch to Debian control files, unfortunately I can't use >that as-is because it will only apply to the auto-generated version, >which will change with any new build. Can you create a patch that I can >apply against the full extracted debian source (e.g. apt-get source >pidgin), and create a separate bug for farstream? Ideally it will >obtain the correct dependency versions automatically (probably via >debian/rules) instead of hardcoding them in the control file. Please to correct me, but I think I should not create a separate bug for farstream, as this bug report describes the problem found in the farstream package, that affects the pidgin package (and others), but it is not a bug of pidgin itself. It should be reassigned and the previous mail was CC'ed to the farstream maintainers for that reason. The patch to the pidgin/finch debian packages only adds descriptions for the optional packages and refine some other dependency like gconf, pidgin-data and the gstreamer-plugins missed. I would make the patches against the full debian source, but actually I do not exactly understand how, as for example gconf is not mentioned in the depends field of the control file. It will take to me some day to learn the debian helper architecture, meanwhile I wanted to write here my findings. I need to do further testing to know exactly which gstreamer-plugins are required to make voice/video calls or simply to play sounds. In fact, according to the specifications, gstreamer-plugins-bad is needed to make a video call on Gtalk, but I have no hardware or counterpart to test it at the moment. Also gstreamer-nice may be needed but missed in my patch and gstreamer-plugins-good should be required not only to make voice calls, but also to decode the .wav files of pidgin-data. Finally, the position of /etc/purple/prefs.xml in the pidgin-data package is correct, I was in error. The patch provided in my previous mail can anyway be applied to do some testing and to fix the bug for the users that read this bug log and cannot wait. It can be applied with these commands for every debian package modified (libfarstream, pidgin, finch): $ dpkg-deb -R libfarstream-0.1-0_0.1.2-1_i386.deb libfarstream $ cd libfarstream $ patch -p1 < ../nogst.patch $ rm DEBIAN/control.* $ cd .. $ dpkg-deb -b libfarstream libfarstream-0.1-0_0.1.2-1+nogst_i386.deb $ sudo dpkg -i libfarstream-0.1-0_0.1.2-1+nogst_i386.deb Sorry for my bad english if I was unclear, I should write more code and less english :) ciao! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550891: It is a libfarstream packaging bug
In the effort to reduce the pidgin dependencies, I wrote a patch to dynamically load libfarstream only if it is installed. I never coded with GObjects and so only during the testing to finish the patch I realized that there is no need to modify the code. Only the package dependencies should be reworked. In fact libpurple depends on libfarstream (855kB), that depends on the gstreamer plugins (65,5MB), but they are dynamically loaded only if installed[1] and they are needed only to make voice and video calls with Gtalk (only voice with finch). I patched the libfarsteram package and tested it with pidgin on a Gtalk account. No crash or errors reported and the voice/video calls menu entries are disabled but visible. The farstream transmitters plugins are loaded dynamically too, so there is no need to install gssdp, gupnp, nice and soup libraries if they are not used. I also patched the pidgin package to remove the gconf dependency, as it is needed only with Gnome (that installs it) to get the automatic configuration[2] for audio, video and url-handlers. Also the finch package uses gconf for audio configuration, while the libpurple package uses gconf for the proxy one. Finally finch does not require pidgin-data (25,7MB), but it is used only if installed for sounds, translations and the /etc/purple/prefs.xml file (that should go instead in the libpurple package). The patch attached should fix the bug, reducing by 2/3 the disk space requirements for pidgin (36,9MB / 10 packages instead of 102,4MB / 78 packages) and by 9/10 for finch (9,1MB / 8 packages instead of 100,3MB / 77 packages). The depends fields are replaced with recommends or suggests for the optional packages, conforming to the policy manual rule 7.2. No breakage is excepted because since the 0.7.17 version of Apt, the recommended packages are installed by default. There are other packages that depend on libfarstream and that may need to add the gstreamer plugins in the dependency fields (like empathy and gajim) according to the changes, but I will provide patches later. All the patches applies on the wheezy version, but the jessie packages are affected too. ciao References: 1. http://lists.freedesktop.org/archives/farstream-devel/2012-April/15.html 2. https://developer.pidgin.im/ticket/11191 Patches: 1. nogst: to be applied to the wheezy debian packages i386 2. backend_module: not useful, but included as reference (ver. 2.10.7) diff -urN libfarstream/DEBIAN/control libfarstream-nogst/DEBIAN/control --- libfarstream/DEBIAN/control 2012-04-08 01:48:13.0 +0200 +++ libfarstream-nogst/DEBIAN/control 2013-12-03 17:25:03.484908105 +0100 @@ -1,11 +1,13 @@ Package: libfarstream-0.1-0 Source: farstream -Version: 0.1.2-1 +Version: 0.1.2-1+nogst Architecture: i386 Maintainer: Debian Telepathy maintainers Installed-Size: 855 Pre-Depends: multiarch-support -Depends: libc6 (>= 2.7), libglib2.0-0 (>= 2.31.8), libgssdp-1.0-3 (>= 0.12.0), libgstreamer-plugins-base0.10-0 (>= 0.10.33), libgstreamer0.10-0 (>= 0.10.33), libgupnp-1.0-4 (>= 0.18.0), libgupnp-igd-1.0-4 (>= 0.1.8), libnice10 (>= 0.1.0), libsoup2.4-1 (>= 2.4.0), libxml2 (>= 2.6.27), gstreamer0.10-plugins-base (>= 0.10.33), gstreamer0.10-plugins-good (>= 0.10.29), gstreamer0.10-plugins-bad (>= 0.10.17), gstreamer0.10-nice (>= 0.1.0) +Depends: libc6 (>= 2.7), libglib2.0-0 (>= 2.31.8), libgstreamer-plugins-base0.10-0 (>= 0.10.33), libgstreamer0.10-0 (>= 0.10.33), libxml2 (>= 2.6.27) +Recommends: libgssdp-1.0-3 (>= 0.12.0), libgupnp-1.0-4 (>= 0.18.0), libgupnp-igd-1.0-4 (>= 0.1.8), libnice10 (>= 0.1.0), libsoup2.4-1 (>= 2.4.0) +Suggests: gstreamer0.10-plugins-base (>= 0.10.33), gstreamer0.10-plugins-good (>= 0.10.29), gstreamer0.10-plugins-bad (>= 0.10.17), gstreamer0.10-nice (>= 0.1.0) Conflicts: libgstfarsight0.10-0 Replaces: libgstfarsight0.10-0 Section: libs @@ -20,3 +22,10 @@ plugins. . This package provides the core Farstream library. + . + libnice10 is needed to use the nice and the raw udp transmitters and the + MSN Webcam plugin. + libgssdp-1.0-3, libgupnp-1.0-4, libgupnp-igd-1.0-4 and libsoup2.4-1 are needed + to use the raw udp transmitter. + GStreamer plugins are optional components that may be needed by the software + built with Farsteram. diff -urN pidgin/DEBIAN/control pidgin-nogst/DEBIAN/control --- pidgin/DEBIAN/control 2013-02-13 21:57:39.0 +0100 +++ pidgin-nogst/DEBIAN/control 2013-12-06 09:19:20.582410040 +0100 @@ -1,11 +1,11 @@ Package: pidgin -Version: 2.10.6-3 +Version: 2.10.6-3+nogst Architecture: i386 Maintainer: Ari Pollak Installed-Size: 2206 -Depends: pidgin-data (>= 2.10.6), pidgin-data (<< 2.10.6-z), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.7), libcairo2 (>= 1.2.4), libdbus-1-3 (>= 1.0.2), libdbus-glib-1-2 (>= 0.78), libfontconfig1 (>= 2.9.0), libfreetype6 (>= 2.2.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.24.0), libgstreamer0.10-0 (>= 0.10.10), libgtk2.0-0 (>= 2.24.0), libgtkspell0 (>= 2.0.10), libice6 (>= 1:1.0.0), libpango1.0
Bug#711097: radeon rv100 XVideo diagonal tearing
Package: xserver-xorg-video-radeon Version: 1:6.14.4-8 Tags: upstream playing videos with mplayer causes diagonal tearing on fullscreen with the xv driver, that uses Radeon Textured Video, even if it is played step by step the definition is not an issue as it appears always, as this example: http://commons.wikimedia.org/wiki/File:Goa_1955_invasion.ogg it appears perfect with the gl and x11 drivers the problem appears with the default configuration, with KMS and without composition, on an AGP ATI RV100 and AMD Athlon XP 2000+ the diagonal tearing is from up-right to down-left it may be related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=59606 if I run a composition manager (xcompmgr), casual horizontal tearing appears, with xv, gl and x11 drivers, but this is another story Instelled packages: xserver-xorg-video-radeon 1:6.14.4-8 i386 libdrm-radeon1:i386 2.4.40-1~deb7u2 i386 linux-image-3.2.0-4-686-pae 3.2.41-2+deb7u2 i386 libxv1:i386 2:1.0.7-1+deb7u1 i386 mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 i386 Video card: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] RADEON(0): Chipset: "ATI Radeon VE/7000 QY (AGP/PCI)" (ChipID = 0x5159) xvinfo output: X-Video Extension version 2.2 screen #0 Adaptor #0: "Radeon Textured Video" number of ports: 16 port base: 63 operations supported: PutImage supported visuals: depth 24, visualID 0x21 number of attributes: 2 "XV_VSYNC" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_CRTC" (range -1 to 1) client settable attribute client gettable attribute (current value is -1) maximum XvImage size: 2048 x 2048 Number of image formats: 4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711082: black boxes around widgets without composition
Package: libwebkitgtk-1.0-0 Version: 1.8.1-3.4 Tags: upstream I have two rendering bugs with Midori and GtkLauncher on wheezy. The first, black rectangles around gtk widgets are rendered in pages. I have found similar bug reports and screenshots as reference: http://i.imgur.com/b1gOZ.png https://bugs.launchpad.net/midori/+bug/1092532 http://kalev.fedorapeople.org/midori_about_widgets.png https://bugs.webkit.org/show_bug.cgi?id=79680#c3 The second, dragging text makes the box all black and dragging images with alpha blending makes black the transparent parts of the image. The bug may be related to this upstream bug (patched): https://bugs.webkit.org/show_bug.cgi?id=108376 X runs without composition on an AGP ATI RV100 and AMD Athlon XP 2000+ After some test I found that the first bug disappear if I enable the Composite extension in xorg.conf (that I had previously disabled) and the second bug disappear if I also run a composition manager (xcompmgr) Instelled packages: libwebkitgtk-1.0-0 1.8.1-3.4 i386 libgtk2.0-0:i386 2.24.10-2 i386 libcairo2:i386 1.12.2-3 i386 xserver-xorg-video-radeon 1:6.14.4-8 i386 libdrm-radeon1:i386 2.4.40-1~deb7u2 i386 linux-image-3.2.0-4-686-pae 3.2.41-2+deb7u2 i386 midori 0.4.3+dfsg-0.1 i386 Video card: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] RADEON(0): Chipset: "ATI Radeon VE/7000 QY (AGP/PCI)" (ChipID = 0x5159) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699034: Is this fixed in upstream LIBGCRYPT-1-5-BRANCH?
On Sun, 24 Feb 2013 16:34:32 +0100 Andreas Metzler wrote: >relevant patches. Could you please test whether >http://people.debian.org/~ametzler/libgcrypt11_1.5.0-3+test+2_i386.deb >also does the trick? It just adds three patches >(35_Avoid-dereferencing-pointer-right-after-the-end.patch >39_Fix-segv-with-AES-NI-on-some-platforms.patch >40_libgcrypt-1.5-rinjdael-Fix-use-of-SSE2-outside-USE_A.patch) instead >of 11. It runs fine and the bug no longer shows up. I can exclude also the patches 39 and 40 as the CPU is an old AMD Athlon without AES-NI and SSE2. Ciao! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699034: Is this fixed in upstream upstream LIBGCRYPT-1-5-BRANCH?
On Sun, 24 Feb 2013 11:44:05 +0100 Andreas Metzler wrote: >upstream has a couple of patches in in their LIBGCRYPT-1-5-BRANCH, >would you mind checking whether the issue is fixed there? > >I have built binary packages for i386, and have temporarily uploaded >them to people.debian.org. >http://people.debian.org/~ametzler/libgcrypt11_1.5.0-3+test+1_i386.deb Thank you! The bug is fixed with claws-mail as it can establish SSL connections. If it is fixed also with midori/webkit, this new version should be uploaded. Ciao! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699034: libwebkitgtk-1.0-0: midori and GtkLauncher crash after typing a url (cairo-surface.c assertion)
Control: reassign -1 libgcrypt11 Control: affects -1 + libwebkitgtk-1.0-0 Control: severity -1 grave Control: merge -1 640501 On Fri, 22 Feb 2013 22:57:09 +0100 Alberto wrote: >Since claws-mail doesn't use webkit (except with the Fancy plugin), it >think this bug should not be related directly to webkit. It may be a bug in libgcrypt11 or how it is used by libgnutls, but the behavior is the same of #640501 so I merge the bugs. >> Newer versions of gnutls (like libgnutls28) deprecated libgcrypt in >> favor of libnettle and when the affected applications will be ported, >> the bug will go away with libgcrypt. >Is it just a matter of selecting the right library/backend at compile >time? >If yes, maybe it could be simpler to close this issue. As I understand it is a licensing problem as libnettle uses gmp, that is licensed as LGPL3, but some applications linked with libgnutls are GPL2 that is incompatible: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658739#42 >> >If libgcrypt11 is responsible of this, maybe this issue should be >> >addressed before next stable. >> I think so too. Also the severity should be raised. >I agree. The problem may be how libgcrypt 1.5 is used by libgnutls and/or the target application, but anyway it seems hard to switch to libnettle in wheezy: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368297#122 Downgrading libgcrypt seems to be the less problematic fix of the bug. Ciao! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699034: libwebkitgtk-1.0-0: midori and GtkLauncher crash after typing a url (cairo-surface.c assertion)
On Thu, 21 Feb 2013 18:33:03 +0100 Alberto wrote: >I've checked again today after updating the distribution with the >latest packages (including also libc6 and nouveau). > >With libgcrypt11 1.5 the bug is present (with https sites). >With libgcrypt11 1.4.6 the bug doesn't show up. > >I think the bugs could be merged... but I think also it's pretty >strange having an _assert_ inside a library (that's the case of cairo). This behavior seems to be a memory management problem (overflow). It is discussed further in this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=49719#c12 >I'm not therefore completely sure that only libgcrypt11 is responsible >for this issue. Maybe there's something wrong also in cairo, but that's >just an hypothesis without evidence. I found this bug very similar to #640501, that it is merged with #640123 related to claws-mail. They both share the use of libgcrypt through libgnutls26 and the bug appears only when doing an encrypted connection. All others operations are running fine, like drawing widgets and rendering fonts with gtk/cairo or making unencrypted connections. Also the bug appeared after upgrading libgcrypt. >Still, I don't think it could be _secure_ having an outdated crypt >library into a stable system. Newer versions of gnutls (like libgnutls28) deprecated libgcrypt in favor of libnettle and when the affected applications will be ported, the bug will go away with libgcrypt. >If libgcrypt11 is responsible of this, maybe this issue should be >addressed before next stable. I think so too. Also the severity should be raised. Ciao -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699034: libwebkitgtk-1.0-0: midori and GtkLauncher crash after typing a url (cairo-surface.c assertion)
On Tue, 5 Feb 2013 16:39:37 -0500 (EST) alber...@aol.it wrote: >> Did you trydowngrading libcrypt11 as mentioned in: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699034#35 > >Apparently with the downgraded version of libgcrypt11 the bug doesn't >show up anymore. If the bug is no more affecting midori using libgcrypt11 1.4.6, then this bug should be merged with #699034 and assigned to libgcrypt. >Still, I've noticed in the last days (with the latest 1.5.0 version of >libgcrypt11) that the few times does not appear. The bug should not appears if you do a plain http connection (for example to a debian bug page). It should fail only if you do an https connection or a mixed http/https connection (many buttons, analytic software and advertising are doing this in plain http web pages). Please to confirm that to be sure before merging bugs. Ciao! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699034: similar bug report
you may find interesting this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640501 that was fixed downgrading libgcrypt11 to the 1.4.6-9 version from: http://snapshot.debian.org/archive/debian/20110807T212024Z/pool/main/libg/libgcrypt11/ may be it is the same bug? Ciao -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658739: please try to downgrade libgcrypt11 to 1.4.6
Hi, can you try to downgrade libgcrypt11 to the version 1.4.6-9? You can download it from: http://snapshot.debian.org/archive/debian/20110807T212024Z/pool/main/libg/libgcrypt11/ this resolved a bug using claws-mail and midori with libgcrypt 1.5, that seems to have problems with its memory management: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640123 If this is the case, may be that libgcrypt11 should be downgraded before wheezy is released. Ciao! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658896: please try to downgrade libgcrypt11 to 1.4.6
Hi, can you try to downgrade libgcrypt11 to the version 1.4.6-9? You can download it from: http://snapshot.debian.org/archive/debian/20110807T212024Z/pool/main/libg/libgcrypt11/ this resolved a bug using claws-mail and midori with libgcrypt 1.5, that seems to have problems with its memory management: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640123 If this is the case, may be that libgcrypt11 should be downgraded before wheezy is released. Ciao! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681860: xscreensaver-data should recommends vs. depends on libwww-perl
On Sat, 12 Jan 2013 20:54:41 -0800 Jamie Zawinski wrote: >Actually "xscreensaver-text" already does something very similar with >LWP. Do you mean without? That was my first guess, but xscreensaver-text (in the version included by Debian) uses the Socket module instead of LWP. So I searched where LWP is actually used and found it only in xscreensaver-getimage-file Ciao -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681860: xscreensaver-data should recommends vs. depends on libwww-perl
xscreensaver-data actually depends on libwww-perl to download images
from the web, disabled by default. The installed size of
xscreensaver-data is 1209KB, where libwww-perl depends on 18 others
packages totaling 5167KB.
I wrote a patch to dynamically load the LWP module at runtime and print
an error suggesting the user to install libwww-perl if not present.
I tested this patch only without libwww-perl installed: anyone wants to
test it on a system with libwww-perl?
Ciao--- xscreensaver/bin/xscreensaver-getimage-file 2012-06-30 00:00:00.0 +0200
+++ xscreensaver-nolwp/bin/xscreensaver-getimage-file 2013-01-13 05:35:32.266695036 +0100
@@ -50,7 +50,6 @@
# errors about UTF-8 all over the place without this.
use Digest::MD5 qw(md5_base64);
-use LWP::Simple qw($ua);
my $progname = $0; $progname =~ s@.*/@@g;
@@ -111,6 +110,10 @@
my @all_files = (); # list of "good" files we've collected
my %seen_inodes;# for breaking recursive symlink loops
+# LWP::Simple module is loaded runtime and the user agent is defined
+# here to avoid compilation errors.
+my $ua = undef;
+
# For diagnostic messages:
#
my $dir_count = 1; # number of directories seen
@@ -851,6 +854,7 @@
sub main() {
my $dir = undef;
+ my $lwp_support = 0;
while ($_ = $ARGV[0]) {
shift @ARGV;
@@ -882,6 +886,18 @@
}
}
+ # LWP::Simple module is loaded runtime, disabling URLs if not.
+ eval {
+require LWP::Simple;
+LWP::Simple->import(qw($ua));
+$lwp_support = 1;
+ };
+
+ if (($dir =~ m/^https?:/si) && ($lwp_support == 0)) {
+print STDERR "$progname: URLs not supported; install libwww-perl\n";
+exit 1;
+ }
+
my $file = find_random_file ($dir);
print STDOUT "$file\n";
}
Bug#698026: libsoup should recommends vs. depends on glib-networking
Package: libsoup2.4-1 Version: 2.38.1-2 Severity: wishlist libsoup actually depends on glib-networking for the SSL/TLS support and, probably, the automatic proxy configuration. The installed size of libsoup is 522KB, where glib-networking depends on 8 other packages with a total installed size of 2183KB. glib-networking contains three GIOModules, that are shared modules explicitly linked by libglib with a dlopen, only if they are available. So they not treated like shared libraries where programs fail to start if not available. Also, for the SSL support, libsoup fails nicely if the relative GIOModule is absent, suggesting the user to install glib-networking: https://mail.gnome.org/archives/commits-list/2011-February/msg00703.html Reducing dependencies is particularly useful for embedded systems, like the GPE Palmtop Environment, where gpe-calendar depends on libsoup. I patched the control file of libsoup to actually not depends on glib-networking and all run fine. I tested it with gpe-calendar and it runs with http urls. If https urls are used it returns the error suggesting to install glib-networking. In this way I saved 2.2MB and installed 4.1MB. This patch should also resolve another bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665468 Ciao--- libsoup2.4-1/DEBIAN/control 2012-04-17 22:01:54.0 +0200 +++ libsoup2.4-1-noglibnet/DEBIAN/control 2013-01-09 05:48:03.546230713 +0100 @@ -5,7 +5,8 @@ Maintainer: Debian GNOME Maintainers Installed-Size: 510 Pre-Depends: multiarch-support -Depends: libc6 (>= 2.4), libglib2.0-0 (>= 2.31.8), libxml2 (>= 2.7.4), zlib1g (>= 1:1.1.4), glib-networking (>= 2.32.0) +Depends: libc6 (>= 2.4), libglib2.0-0 (>= 2.31.8), libxml2 (>= 2.7.4), zlib1g (>= 1:1.1.4) +Recommends: glib-networking (>= 2.32.0) Section: libs Priority: optional Multi-Arch: same @@ -30,3 +31,6 @@ * Basic client-side SOAP and XML-RPC support . This package contains the shared library. + . + glib-networking is required for the SSL support and the automatic proxy + detection.
Bug#697913: wine crash with nouveau vieux driver
On Sat, 12 Jan 2013 16:12:28 +0100 Hilko Bengen wrote: >> A binary package of patched libwine-gl would be really appreciated >Please use the packages at http://people.debian.org/~bengen/wine/ Many thanks for the package built with the patch, but unlucky the issue is not resolved. I have done more testing and I found that I misunderstood code and error messages. SimpleGLUT demo runs fine with and without the patch! http://web.media.mit.edu/~gordonw/OpenGL/simpleGLUT.zip It actually use hardware acceleration (90fps vs 3fps on software render) Critter fails with and without the patch, but not with software renderer http://prdownloads.sourceforge.net/criticalmass/CriticalMass-Windows-1.0.0.zip I have attached the full dump of patched and unpatched version. The function wined3d_guess_card_vendor returns anyway HW_VENDOR_NVIDIA even if not correctly recognized. The function select_card_nvidia_mesa has a fallback to discover the card by gl_info. So the patch I proposed may be useful but not required. The error messages "Received unrecognized GL_VENDOR" and "Unknown renderer" appear only when launching Critter and not with Simpleglut. Running critter the common error with and without the patch is: nv10_state_fb.c:50: get_rt_format: Assertion `0' failed. that should not be an error of wine, but of nouveaux driver. So, I'm really sorry to have misreported the bug to wine and to have you work on this. I think the bug should be reassigned to the libgl1-mesa-dri package. I found similar bug reports with other old GForce < NV30: https://bugs.freedesktop.org/show_bug.cgi?id=47796 http://bugs.winehq.org/show_bug.cgi?id=30203 https://bugs.launchpad.net/ubuntu/+source/stellarium/+bug/1079011 https://bugzilla.redhat.com/show_bug.cgi?id=834329 Ciao!err:d3d:wined3d_adapter_init_gl_caps > GL_INVALID_ENUM (0x500) from extension detection @ ../../../dlls/wined3d/directx.c / 2720 fixme:d3d_caps:wined3d_guess_card_vendor Received unrecognized GL_VENDOR "Nouveau". Returning HW_VENDOR_NVIDIA. fixme:d3d_caps:select_card_nvidia_mesa Unknown renderer "Mesa DRI nv11 x86/MMX+/3DNow!+". nv10_state_fb.c:50: get_rt_format: Assertion `0' failed. wine: Assertion failed at address 0xb77cd424 (thread 0009), starting debugger... Unhandled exception: assertion failed in 32-bit code (0xb77cd424). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:b77cd424 ESP:006bea88 EBP:006beaa0 EFLAGS:00200206( - -- I - -P- ) EAX: EBX:13be ECX:13be EDX:0006 ESI:b761f29f EDI:b7643ff4 Stack dump: 0x006bea88: 006beaa0 0006 13be b750f941 0x006bea98: b7643ff4 006bebc0 006bebc8 b7512d72 0x006beaa8: 0006 006beb40 006beae8 0x006beab8: b755b8ed 0068 0040 b7a2 0x006beac8: 006beaf0 0068 0040 003a 0x006bead8: 7c6bb150 b7643ff4 003a 0039 Backtrace: =>0 0xb77cd424 __kernel_vsyscall+0x10() in [vdso].so (0x006beaa0) 1 0xb750f941 gsignal+0x50() in libc.so.6 (0x006beaa0) 2 0xb7512d72 abort+0x181() in libc.so.6 (0x006bebc8) 3 0xb7508b58 __assert_fail+0xf7() in libc.so.6 (0x006bec10) 4 0x7dfd02e0 in nouveau_vieux_dri.so (+0x252df) (0x7c6a7d78) 5 0x7dfc35fc in nouveau_vieux_dri.so (+0x185fb) (0x7c65de60) 6 0x7e04227b in nouveau_vieux_dri.so (+0x9727a) (0x) 7 0x7e04351a in nouveau_vieux_dri.so (+0x98519) (0x006bf220) 8 0x7e180c68 in nouveau_vieux_dri.so (+0x1d5c67) (0x006bf220) 9 0x7dbbb6a4 in wined3d (+0xdb6a3) (0x006bf220) 10 0x7dbbce08 in wined3d (+0xdce07) (0x006bf2f0) 11 0x7db35a23 in wined3d (+0x55a22) (0x006bf880) 12 0x7db411d3 in wined3d (+0x611d2) (0x006bf8a0) 13 0x7dbc485a wined3d_create+0x59() in wined3d (0x006bf8d0) 14 0x7dc36315 in ddraw (+0x16314) (0x006bf920) 15 0x7dc46aad in ddraw (+0x26aac) (0x006bf980) 16 0x7dc47487 DirectDrawCreate+0x46() in ddraw (0x006bf9d0) 0xb77cd424 __kernel_vsyscall+0x10 in [vdso].so: popl%ebp Modules: Module Address Debug info Name (99 modules) PE24- 28a000 Deferredsdl_image PE29- 2dc000 Deferredsdl_mixer PE40- 4bf000 Deferredcritter PE 1000-1004 Export sdl PE 6658-66596000 Deferredz PE 6aa8-6aaa6000 Deferredpng ELF 7b80-7ba3a000 Deferredkernel32 \-PE 7b81-7ba3a000 \ kernel32 ELF 7bc0-7bcd4000 Deferredntdll \-PE 7bc1-7bcd4000 \ ntdll ELF 7bf0-7bf04000 Deferred ELF 7dacd000-7dc14000 Dwarf wined3d \-PE 7dae-7dc14000 \ wined3d ELF 7dc14000-7dc87000 Dwarf ddraw \-PE 7dc2-7dc87000 \ ddraw ELF 7dc87000-7dc9d000 Deferredmidimap \-PE 7dc9-7dc9d000 \ midimap ELF 7dc9d000-7dd95000 Deferredlibasound.so.2 ELF 7dd95000-
Bug#697913: wine crash with nouveau vieux driver
Package: libwine-gl Version: 1.4.1-4 Hi, there is a bug that prevents to run 3D applications under wine with the nouveau vieux driver. It fails with this error message: err:d3d:wined3d_adapter_init_gl_caps > GL_INVALID_ENUM (0x500) from extension detection @ ../../../dlls/wined3d/directx.c / 2720 fixme:d3d_caps:wined3d_guess_card_vendor Received unrecognized GL_VENDOR "Nouveau". Returning HW_VENDOR_NVIDIA. fixme:d3d_caps:select_card_nvidia_mesa Unknown renderer "Mesa DRI nv11 x86/MMX+/3DNow!+". nv10_state_fb.c:50: get_rt_format: Assertion `0' failed. wine: Assertion failed at address 0xb77d8424 (thread 0009), starting debugger... The installed drivers are: libdrm-nouveau1a 2.4.33-3 i386 libgl1-mesa-dri 8.0.5-3 i386 libgl1-mesa-glx 8.0.5-3 i386 linux-image-3.2.0-4-686-pae 3.2.35-2 i386 xserver-xorg-video-nouveau 1:1.0.1-4 i386 The video card is: NVIDIA Corporation NV11 [GeForce2 MX/MX 400] (rev a1) It runs fine without the hardware acceleration, removing the user from the group video that owns /dev/dri/card0 This bug seems to be fixed in wine 1.5.0 with this commit: http://source.winehq.org/git/wine.git/blobdiff/ab4474c19b308311b6408a2802225a44849bb70c..112e2e219f88cf81280359ae74ae809a3d288574:/dlls/wined3d/directx.c At a first look this patch should apply nicely to the 1.4.1 version. I think this patch should be added to wheezy because the actual code is broken, as it checks NV04-NV20 with the Gallium renderer, that never supported these cards, that instead are handled by the vieux driver present in wheezy. Also these are minor changes to the device detection between wine and opengl. Ciao -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697905: persistent naming in crypttab
Package: partman-crypto Version: 56 Hi, I think that using udev persistent device naming in /etc/crypttab would be useful to prevent some dangerous situation, like the following one. I have a 3 disks setup with the first two in raid mode and the third as archive. The swap partitions are encrypted with dm-crypt and out of the raid. After the install /etc/crypttab contains: sda1_crypt /dev/sda1 /dev/urandom cipher=aes-xts-plain64,size=256,swap sdb1_crypt /dev/sdb1 /dev/urandom cipher=aes-xts-plain64,size=256,swap When the first or the second disk fails or begin removed, sdc is renamed sdb and the first partition (that unlucky was not a swap partition) is overwritten. The recover of the filesystem was not automatic and required to rewrite with zeros all the sectors overwritten by encrypted data, as explained by that mail message: https://www.redhat.com/archives/ext3-users/2011-January/msg00010.html As dm-crypt without luks do not supports UUIDs, udev persistent naming should prevent this situation in a safe manner, mapping the device and doing mkswap or mkfs only if the partition is exactly on the disk selected by the installer. In other cases it fails, that is safer than doing mkswap on random partitions. I have attached an untested patch to partman-crypto that should address this issue. As this is my first look of debian installer sources, this patch is not intended to be applied as is, but as a detailed explanation of the fix. The /etc/crypttab would be: sda1_crypt /dev/disk/by-id/scsi-NAME-SERIAL-part1 /dev/urandom ... This bug affects both squeeze and wheezy. Ciao--- partman-crypto-56/finish.d/crypto_config 2011-01-19 05:58:49.0 +0100 +++ partman-crypto-56-udevid/finish.d/crypto_config 2013-01-11 08:35:13.408173693 +0100 @@ -124,6 +124,9 @@ if cryptsetup isLuks "$source"; then local uuid=$(cryptsetup luksUUID "$source") source="UUID=$uuid" + else + # Use udev persistent device naming + source=$(find /dev/disk/by-id -lname "*/$(basename $source)" | tail -1) fi # Add entry to crypttab
Bug#640123: wheezy fresh install
Hi, I have recently installed a new wheezy i386 system and claws-mail fails when checking mail on a POP3 SSL connection with this error message: claws-mail: /build/buildd-cairo_1.12.2-2-i386-1cmzkR/cairo-1.12.2/src/cairo-surface.c:1591: cairo_surface_set_device_offset: Assertion "status == CAIRO_STATUS_SUCCESS" failed. Aborted after installing the squeeze version of libgcrypt11 1.4.5-2 all run fine. The downgrade of libgrypt11 breaks libcryptsetup4 and at the boot the encrypted swap partitions are not started, with a dmesg error: device-mapper: ioctl: Unable to rename non-existent device, sda1_crypt_unformatted to sda1_crypt but after the boot they starts manually doing: service cryptdisks start To resolve this issue I have installed libgcrypt11 1.4.6-9 from: http://snapshot.debian.org/archive/debian/20110807T212024Z/pool/main/libg/libgcrypt11/ So, I can confirm the bug in a fresh install of wheezy and the bugfix downgrading libgcrypt11 to the 1.4.6-9 version. I would please to help resolving this bug providing more info if useful or at least to warn the maintainer that the 1.4.6 version would be preferable in wheezy. The downgrade seems to only affect the package aria2, but it seems that can be rebuilt with this version. All the other packages in main are built with the 1.4.5 or the 1.4.6 version, 203 and 8 packages respectively. Ciao -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#440551: patch
Ciao, with this patch start-stop-daemon will wait for mldonkey to shutdown correctly. The timeout was simply got from the apache init script. I hope that this time the Debian bug tracking system don't stop this patch. Trek --- debian/mldonkey-server.init 2007-09-14 04:50:03.0 +0200 +++ debian/mldonkey-server.init 2007-10-26 13:32:02.0 +0200 @@ -105,7 +105,7 @@ stop) echo -n "Stopping $DESC: $NAME" -start-stop-daemon --stop --oknodo --pidfile $PIDFILE +start-stop-daemon --stop --oknodo --pidfile $PIDFILE --retry 30 echo "." ;; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307019: odd counters in log files after reboot
Package: mrtg
Version: 2.9.17-4
Tags: patch
Every time the box is rebooted all the traffic counters are set with the
values of the last run of mrtg. This is erraneous and, if the box was
switched off for some time, it produces really wrong graphs! (all flat).
The traffic counters are in the first line of the mrtg-2 logfile. After a
period of poweroff you can see in the logs:
951759461 158622809 184439887
951759461 1079 626 1079 626
951759204 1079 626 1079 626
951759000 1079 626 1079 626
951758700 1079 626 1079 626
951758400 1079 626 1079 626
951758100 1079 626 1079 626
951757800 1079 626 1079 626
this repeats all the way til..
951743400 1079 626 1079 626
The proposed patch is to add this /etc/init.d/mrtg boot script that resets
all the counters to 0 (the first line only). This problem affects Debian
3.0-i386 that i use, but i think it is a problem since the year 2000 at
least (search the numbers on google groups) and persist in the unstable
release.
c-ya!
3 http://www.trek.eu.org/
k PGPKey: 7016731A57D4A69B 1A8EE5E90EF2608E (since 1995)
#!/bin/sh
#
# MRTG Debian boot file by Trek <[EMAIL PROTECTED]>
#
case "$1" in
start)
if [ -e /etc/mrtg.cfg ]
then
logdir=`grep -i ^LogDir: /etc/mrtg.cfg | (read a b; echo $b)`
if [ "$logdir" = "" ]
then
logdir=`grep -i ^WorkDir: /etc/mrtg.cfg | (read a b; echo $b)`
fi
echo "Reset MRTG logs counters in $logdir"
for log in $logdir/*.log
do
mv $log ${log/%\.log/.old}
sed '1,1s/^\([0-9]\+\) [0-9]\+ [0-9]\+$/\1 0 0/' \
< ${log/%\.log/.old} > $log
done
fi
;;
stop|restart|reload|force-reload)
;;
*)
echo "Usage: /etc/init.d/mrtg {start|stop|reload|force-reload|restart}"
;;
esac
exit 0
