Bug#1068235: mkdocs: packaged themes require newer version of jquery than is included
Package: mkdocs Version: 1.5.3+dfsg-1 Severity: important X-Debbugs-Cc: j...@johnleach.co.uk building a mkdocs site using the default mkdocs theme results in html which tries to include js/jquery-3.6.0.min.js but only js/jquery-1.10.2.min.js exists. /usr/lib/python3/dist-packages/mkdocs/themes/mkdocs/base.html references it like this: but the package doesn't include it: $ dpkg -L mkdocs | grep jquery /usr/lib/python3/dist-packages/mkdocs/themes/mkdocs/js/jquery-1.10.2.min.js /usr/lib/python3/dist-packages/mkdocs/themes/readthedocs/js/jquery-2.1.1.min.js The readthedocs theme does the same thing (but uses it's version of jquery, 2.1.1). The resulting site search system is unusuable. I'm reporting this from an ubuntu system but I have confirmed this bug exists in debian/sid. It looks like this bug was introduced in 1.5.2+dfsg-1 when the themes were upgraded. Somehow the updated jquery files were not committed. I notice this package depends on libjs-jquery but I'm not sure why as jquery is vendored with the themes, and libjs-jquery is not quite the right version of jquery to solve this problem anyway. -- System Information: Debian Release: trixie/sid APT prefers noble-updates APT policy: (500, 'noble-updates'), (500, 'noble') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.0-11-generic (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mkdocs depends on: ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 ii ghp-import 2.1.0-3 ii libjs-bootstrap4 4.6.1+dfsg1-4 ii libjs-jquery 3.6.1+dfsg+~3.5.14-1 ii libjs-lunr 2.3.9~dfsg-2 ii libjs-modernizr 2.6.2+ds1-5 ii python3 [python3-supported-min] 3.12.1-0ubuntu2 ii python3-click8.1.6-2 ii python3-importlib-metadata 4.12.0-1 ii python3-jinja2 3.1.2-1ubuntu1 ii python3-livereload 2.6.3-2 ii python3-lunr 0.7.0-1 ii python3-markdown 3.5.2-1 ii python3-markupsafe 2.1.5-1build1 ii python3-mergedeep1.3.4-3 ii python3-packaging23.2-1 ii python3-pathspec 0.12.1-1 ii python3-pkg-resources68.1.2-2ubuntu1 ii python3-platformdirs 4.2.0-1 ii python3-pyyaml-env-tag 0.1-3 ii python3-typing-extensions4.10.0-1 ii python3-watchdog 3.0.0-1 ii python3-yaml 6.0.1-2 ii sphinx-rtd-theme-common 2.0.0+dfsg-1 mkdocs recommends no packages. Versions of packages mkdocs suggests: pn mkdocs-doc ii nodejs 18.19.1+dfsg-2ubuntu4 ii python3-babel 2.10.3-3build1 -- no debconf information
Bug#682360: broken patch
the patch Clint provided is broken - on the restart stanza, the --retry option is in between the --pidfile and its argument. and the --retry option requires an argument of it's own - either a timeout or a schedule. I'm not sure of the appropriate argument in this case (hence no patch from me :) John. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538877: glusterfs-server: initscript stop command kills client processes as well as the server process
Package: glusterfs-server
Version: 2.0.4-2
Severity: important
Tags: patch
When stopping the glusterd daemon, the initscript uses start-stop-daemon
with the --exec option which Checks for processes that are instances
of this executable. Glusterfs uses the same binary for both server and
client processes, so if a machine has both processes running,
start-stop-daemon thinks the server process is still running. The
initscript then goes on to kill the client process too. Adding the
--name option fixes this.
The status initscript command relies on the same --exec option so
could misidentify the gluster client process as the server process
(unlikely but possible). Adding a --name option fixes this too.
commit 07d4979536e5bd01b3a251c2d226d08942a91e49
Author: John Leach j...@johnleach.co.uk
Date: Mon Jul 27 15:57:52 2009 +0100
Fix initscript stop and status functions. stop would kill client processes
too and status could misidentify client processes as server processes.
diff --git a/debian/glusterfs-server.init b/debian/glusterfs-server.init
index 15df29d..58759f0 100755
--- a/debian/glusterfs-server.init
+++ b/debian/glusterfs-server.init
@@ -68,19 +68,7 @@ do_stop()
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
$PIDFILE --name $NAME
- RETVAL=$?
- [ $RETVAL = 2 ] return 2
- # Wait for children to finish too if this is a daemon that forks
- # and if the daemon is only ever run from this initscript.
- # If the above conditions are not satisfied then add some other code
- # 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/30/KILL/5 --exec
$DAEMON
- [ $? = 2 ] return 2
- # Many daemons don't delete their pidfiles when they exit.
- rm -f $PIDFILE
- return $RETVAL
+ return $?
}
#
@@ -88,7 +76,7 @@ do_stop()
#
do_status()
{
- start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
--test /dev/null
+ start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON
--name $NAME --test /dev/null
RETVAL=$?
if [ $RETVAL = 1 ]; then
log_success_msg $DESC is running.
Bug#532689: upstream patch, fails to apply
This upstream patch fixes this bug: http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=revrevision=23652 Unfortunately, hunk #14 fails to apply to Hardy's Ruby source. It looks like the BigDecimal_to_f function has been rewritten since Hardy's version of Ruby (1.8.6.111). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
