Bug#137317: sqwebmail: missing passphrase input field
Package: sqwebmail Followup-For: Bug #137317 The error message "gpg: Sorry, no terminal at all requested - can't get input" appears, if no passphrase was supplied. Sqwebmail does not show the passphrase input field, if it was connected with http instead of https. This can be overriden for the apache webserver by the following directive: SetEnv HTTPS on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383260: dfsbuild: Custom script OR mount --bind /proc
Package: dfsbuild Version: 0.99.2 Followup-For: Bug #383260 Hi, I have the same problem as described above: I cannot install samba via dfsbuild. If install scripts of packages (like samba) may not depend on /proc (according to the debian package policy), then a bug report should be filed against samba. But if this is allowed, then dfsbuild should provide /proc (and maybe /sys) within the chroot environment. Otherwise a hook for pre- and post-installation would be nice to solve this (very annoying) problem. thanks and regards, Lars -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dfsbuild depends on: ii cdebootstrap 0.3.15 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii grub 0.97-20GRand Unified Bootloader ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii mkisofs 9:1.1.0-1 Dummy transition package for genis ii reprepro 1.3.1-1debian package repository producer ii ucf 2.0017 Update Configuration File: preserv dfsbuild recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404555: dfsbuild: Patch for guessing a valid Release filename
Package: dfsbuild Version: 0.99.2 Followup-For: Bug #404555 Hi, the attached patch uses the file "Release" first and (if it fails) falls back to "_dists_._Release". It works for me. I hope, this fix is appropriate. regards, Lars -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dfsbuild depends on: ii cdebootstrap 0.3.15 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii grub 0.97-20GRand Unified Bootloader ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii mkisofs 9:1.1.0-1 Dummy transition package for genis ii reprepro 1.3.1-1debian package repository producer ii ucf 2.0017 Update Configuration File: preserv dfsbuild recommends no packages. -- no debconf information diff -ru dfsbuild.orig/dfsbuild-0.99.2/Actions/Mirror.hs dfsbuild/dfsbuild-0.99.2/Actions/Mirror.hs --- dfsbuild.orig/dfsbuild-0.99.2/Actions/Mirror.hs 2006-04-20 00:10:11.0 +0200 +++ dfsbuild/dfsbuild-0.99.2/Actions/Mirror.hs 2007-01-01 22:09:26.0 +0100 @@ -33,7 +33,7 @@ archargs ++ debugargs ++ ["-d", suite, targetdir env, mirror] -- Next, copy them into the mirror. codename <- getCodeName - (targetdir env ++ "/var/cache/bootstrap/Release") + (targetdir env ++ "/var/cache/bootstrap/") dm $ "Codename for this is " ++ codename mapM_ (\x -> handle (\_ -> return ()) (createDirectory x 0o755)) [mirrordir, mirrordir ++ "/conf"] diff -ru dfsbuild.orig/dfsbuild-0.99.2/Utils.hs dfsbuild/dfsbuild-0.99.2/Utils.hs --- dfsbuild.orig/dfsbuild-0.99.2/Utils.hs 2006-04-20 00:10:11.0 +0200 +++ dfsbuild/dfsbuild-0.99.2/Utils.hs 2007-01-01 22:40:34.0 +0100 @@ -16,6 +16,7 @@ import MissingH.ConfigParser import MissingH.Cmd import System.IO.Unsafe +import System.IO.Error import Text.Regex import MissingH.Path.FilePath import System.Directory(doesFileExist) @@ -72,7 +73,11 @@ getCodeName :: FilePath -> IO String getCodeName fp = -do c <- readFile fp +do c_old <- System.IO.Error.catch (readFile (fp ++ "Release")) + (\e -> if System.IO.Error.isDoesNotExistError e then return "" else ioError e) + c_new <- System.IO.Error.catch (readFile (fp ++ "_dists_._Release")) + (\e -> if System.IO.Error.isDoesNotExistError e then return "" else ioError e) + c <- if length(c_old) > 0 then return c_old else return c_new let cr = mkRegex "Codename: ([a-z]+)" case matchRegex cr c of Just [cn] -> return cn
Bug#404563: dfsbuild: Patch for scanning /usr/lib/grub and /lib/grub for bootloader files
Package: dfsbuild Version: 0.99.2 Followup-For: Bug #404563 Hi, the attached patch scans both /usr/lib/grub and /lib/grub for the grub bootloader files. This resolves the copy-grubfile bug for me. regards, Lars -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dfsbuild depends on: ii cdebootstrap 0.3.15 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii grub 0.97-20GRand Unified Bootloader ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii mkisofs 9:1.1.0-1 Dummy transition package for genis ii reprepro 1.3.1-1debian package repository producer ii ucf 2.0017 Update Configuration File: preserv dfsbuild recommends no packages. -- no debconf information diff -ruN dfsbuild.orig/dfsbuild-0.99.2/Bootloader/Grub.hs dfsbuild/dfsbuild-0.99.2/Bootloader/Grub.hs --- dfsbuild.orig/dfsbuild-0.99.2/Bootloader/Grub.hs2006-04-20 00:10:11.0 +0200 +++ dfsbuild/dfsbuild-0.99.2/Bootloader/Grub.hs 2007-01-02 00:56:45.0 +0100 @@ -40,8 +40,11 @@ grub_generic env = do createDirectory (targetdir env ++ "/boot/grub") 0o755 - grubfiles <- glob "/lib/grub/*/*" - safeSystem "cp" $ ["-rv"] ++ grubfiles ++ [targetdir env ++ "/boot/grub/"] + -- since etch (Debian 4.0) grub files are located in /usr/lib instead of /lib + grubfiles_pre_etch <- glob "/lib/grub/*/*" + grubfiles_since_etch <- glob "/usr/lib/grub/*/*" + safeSystem "cp" $ ["-rv"] ++ grubfiles_pre_etch ++ grubfiles_since_etch ++ + [targetdir env ++ "/boot/grub/"] menuText <- grubMenu env writeFile (targetdir env ++ "/boot/grub/menu.lst") menuText
Bug#390801: dfsbuild: Duplicate of #404563
Package: dfsbuild Version: 0.99.2 Followup-For: Bug #390801 Hi, this bug report seems to be a duplicate of #404563. regards, Lars -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dfsbuild depends on: ii cdebootstrap 0.3.15 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii grub 0.97-20GRand Unified Bootloader ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii mkisofs 9:1.1.0-1 Dummy transition package for genis ii reprepro 1.3.1-1debian package repository producer ii ucf 2.0017 Update Configuration File: preserv dfsbuild recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#399861: dfsbuild: Duplicate of #404555
Package: dfsbuild Version: 0.99.2 Followup-For: Bug #399861 Hi, this bug seems to be a duplicate of #404555. regards, Lars -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dfsbuild depends on: ii cdebootstrap 0.3.15 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii grub 0.97-20GRand Unified Bootloader ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii mkisofs 9:1.1.0-1 Dummy transition package for genis ii reprepro 1.3.1-1debian package repository producer ii ucf 2.0017 Update Configuration File: preserv dfsbuild recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405246: dfsbuild: Filenames in config file are relative to work directory
Package: dfsbuild Version: 0.99.2 Severity: minor Hi, dfsbuild changes its current directory to the "work" directory. Thus it is necessary to specify locations of files for 'installdebs', 'unpackdebs' and similar configuration settings either as absolute paths (this is ok) or as relative paths based on the "work" directory. The latter is not obvious and should (IMO) be mentioned in the comments of the configuration file. regards, Lars -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dfsbuild depends on: ii cdebootstrap 0.3.15 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii grub 0.97-20GRand Unified Bootloader ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii mkisofs 9:1.1.0-1 Dummy transition package for genis ii reprepro 1.3.1-1debian package repository producer ii ucf 2.0017 Update Configuration File: preserv dfsbuild recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383260: dfsbuild: Patch for custom hook scripts
Package: dfsbuild Version: 0.99.2 Followup-For: Bug #383260 Hi, the attached patch introduces the configuration settings 'preparescripts' and 'cleanupscripts'. Both may be a list of scripts that will get executed after bootstrapping/before iso generation with the target directory as the first and only parameter. I hope that it helps. regards, Lars -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dfsbuild depends on: ii cdebootstrap 0.3.15 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii grub 0.97-20GRand Unified Bootloader ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii mkisofs 9:1.1.0-1 Dummy transition package for genis ii reprepro 1.3.1-1debian package repository producer ii ucf 2.0017 Update Configuration File: preserv dfsbuild recommends no packages. -- no debconf information --- dfsbuild.orig/dfsbuild-0.99.2/Actions.hs2006-04-20 00:10:11.0 +0200 +++ dfsbuild/dfsbuild-0.99.2/Actions.hs 2007-01-03 15:36:59.0 +0100 @@ -43,6 +43,11 @@ finished Bootstrapped Bootstrapped -> -- Time to install shared files do installlib env +finished EnvironmentPrepared + EnvironmentPrepared ->-- execute configurable hook scripts + do im $ "Executing preparation scripts" +mapM_ (safeSystem `flip` [ targetdir env ]) +(splitWs $ eget env "preparescripts") finished LibsInstalled LibsInstalled ->-- Install additional packages do installpkgs env @@ -68,6 +73,11 @@ do safeSystem "mkcramfs" [(targetdir env) ++ "/opt/initrd", (targetdir env) ++ "/boot/initrd.dfs"] recursiveRemove SystemFS $ (targetdir env) ++ "/opt/initrd" +finished EnvironmentCleaned + EnvironmentCleaned ->-- execute configurable hook scripts + do im $ "Executing preparation scripts" +mapM_ (safeSystem `flip` [ targetdir env ]) +(splitWs $ eget env "cleanupscripts") finished RamdiskBuilt RamdiskBuilt ->-- Install the bootloader do (isoargs, blfunc) <- Bootloader.install env --- dfsbuild.orig/dfsbuild-0.99.2/Utils.hs 2007-01-01 23:06:17.0 +0100 +++ dfsbuild/dfsbuild-0.99.2/Utils.hs 2007-01-03 15:33:00.0 +0100 @@ -30,10 +31,10 @@ marker :: String, datestr :: String} -data DFSState = Fresh | Initialized | Mirrored | Bootstrapped | Installed - | LibsInstalled | DebsInstalled | CfgHandled | InitPrepped +data DFSState = Fresh | Initialized | Mirrored | Bootstrapped | EnvironmentPrepared + | Installed | LibsInstalled | DebsInstalled | CfgHandled | InitPrepped | RDPrepped - | KernelsInstalled | RamdiskBuilt | BootloaderInstalled + | KernelsInstalled | EnvironmentCleaned | RamdiskBuilt | BootloaderInstalled deriving (Eq, Show, Read, Ord) im = infoM "dfs" --- dfsbuild.orig/dfsbuild-0.99.2/dfs.cfg 2006-07-02 01:46:22.0 +0200 +++ dfsbuild/dfsbuild-0.99.2/dfs.cfg2007-01-03 15:40:22.0 +0100 @@ -115,6 +115,12 @@ /var/log/dpkg.log /var/log/bootstrap.log +# Scripts that should be executed after bootstrapping and before package installation +#preparescripts = + +# Scripts that should be executed after package installation and before iso generation +#cleanupscripts = + ## # Arch settings: i386 ##
Bug#408471: dfsbuild: "includedeb" used for var/cache/bootstrap/_dists_._Release.gpg
Package: dfsbuild Version: 0.99.4 Severity: important Hi, dfsbuild exits on my system with the following error output: [dfs/INFO] Welcome to dfsbuild. Image architecture: "i386" [dfs/INFO] Using working directory /home/lars/subversion/cryptobox/live-cd/_builddir [dfs/INFO] Using library directory /usr/lib/dfsbuild [dfs/INFO] Running. [dfs/INFO] Mirroring process starting. [dfs/INFO] Running cdebootstrap for amd64 [dfs/INFO] Running reprepro for sarge includedeb called with a file not ending with '.deb' To ignore use --ignore=extension. There have been errors! [System.Cmd.Utils.safeSystem/WARNING] Command reprepro ["-b",".","includedeb","sarge","/home/lars/subversion/cryptobox/live-cd/_builddir/target/var/cache/bootstrap/_dists_._Release.gpg"] failed; exit code 255 [dfs/CRITICAL] Exception: user error (Command reprepro ["-b",".","includedeb","sarge","/home/lars/subversion/cryptobox/live-cd/_builddir/target/var/cache/bootstrap/_dists_._Release.gpg"] failed; exit code 255) dfsbuild: user error (Command reprepro ["-b",".","includedeb","sarge","/home/lars/subversion/cryptobox/live-cd/_builddir/target/var/cache/bootstrap/_dists_._Release.gpg"] failed; exit code 255) it seems, as if line 53 in Actions/Mirror.hs [debs <- glob (targetdir env ++ "/var/cache/bootstrap/*.deb"] also includes files not ending in "*.deb" (e.g. "_dists_._Release.gpg" as seen above). What could cause this potential misbehaviour of "glob"? regards, Lars -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages dfsbuild depends on: ii cdebootstrap 0.3.15 Bootstrap a Debian system ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii grub 0.97-21GRand Unified Bootloader ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii mkisofs 9:1.1.1-1 Dummy transition package for genis ii reprepro 1.3.1-1debian package repository producer ii ucf 2.0018 Update Configuration File: preserv dfsbuild recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#740438: [shinken-common] Upgrade fails: mkdir: cannot create directory `/var/run/shinken': File exists
Package: shinken-common Version: 1.4-3 Severity: normal --- Please enter the report below this line. --- Hi, the postinst script of shinken-common contains the following line: mkdir /var/run/shinken (around line 45) This should probably be changed to: mkdir -p /var/run/shinken The upgrade worked well after applying this change. btw: thank you so much for upgrading the shinken package from 0.6 to 1.4! Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683229: [yate-core] module regfile is missing but its config file exists
Package: yate-core Version: 4.1.0-1~dfsg-2 Severity: normal --- Please enter the report below this line. --- Hi, as a novice user of yate it took me some time to understand why the settings in my /etc/yate/regfile.conf file were ignored completely. Finally I realized that the regfile module is not part of the debian package. Please either add the regfile module (which is great for a quick start) or remove the corresponding config file in order to avoid confusion. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722960: [php-horde] hook uses /usr/bin/grep instead of /bin/grep
Package: php-horde Version: 5.0.3+debian0-1 Severity: minor --- Please enter the report below this line. --- The file /etc/horde/horde/hooks.php contains a reference to /usr/bin/grep instead of the correct path /bin/grep. An error message is visible when running "horde-alarms": sh: 1: /usr/bin/grep: not found Additionally the same error message appears periodically in the error log of the webserver. cheers, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668626: [isc-dhcp-client] rfc3442 classless routes: breaks routing if gateway is a local IP
Package: isc-dhcp-client
Version: 4.1.1-P1-9
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
Hi,
the current implementation of the "rfc3442-classless-routes" exit hook breaks
the routing in my local setup. The attached patch fixes this issue for me.
Here is my setup ...
Consider four hosts:
A/B/C:
three routers in front of different sub-nets (netA, netB, netC); their WAN
interfaces are configured via DHCP (provided by G)
G:
central router - delivering DHCP to A, B and C
I want to announce A, B and C as routers for their respective sub-nets via DHCP
to the other routers. This reduces problems with ICMP redirect and simplifies
routing in general (for me).
Here is the problem:
A adds the following routes via the rfc3442 exit hook:
netA via A
netB via B
netC via C
the route to itself ("netA via A") competes with A's interface based route
(something along "netA dev eth0"). The result: the hosts in netA can't talk to A
anymore, since A uses the new "netA via A" route (looping -> packets are lost)
The attached patch skips the routes that point to the current router itself.
Just in case you need some real-life numbers: the following example is taken
from a host with the local IPs 172.16.19.1 ("lan") and 172.16.23.13 ("wan").
root@router-lardia:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 172.16.23.1 0.0.0.0 UG0 00 wan
172.16.16.0 172.16.23.1 255.255.240.0 UG0 00 wan
172.16.17.0 172.16.23.11255.255.255.0 UG0 00 wan
172.16.18.0 172.16.23.12255.255.255.0 UG0 00 wan
172.16.19.0 172.16.23.13255.255.255.0 UG0 00 wan
172.16.19.0 0.0.0.0 255.255.255.0 U 0 00 lan
The second to last line (gateway 172.16.23.13) is the crucial one: it prevents
packets to the local "lan" network (172.16.19.0/24) from being delivered via
"lan".
Essentially the router does not communicate via the "lan" interface at all.
The respective rfc3442 dhcp option (distributed by the central gateway) is the
following:
dhcp-option=121,172.16.16.0/20,172.16.23.1, \
172.16.17.0/24,172.16.23.11, \
172.16.18.0/24,172.16.23.12, \
172.16.19.0/24,172.16.23.13
The attached patch compares the rfc3442 "gateway" with all local IP addresses
(retrieved via "ip addr show").
Basically it says: "never add a route that points to yourself".
What do you think about this change? Is this a relevant use-case?
cheers,
Lars
--- /root/rfc3442-classless-routes.orig 1960-09-30 13:33:19.0 +
+++ rfc3442-classless-routes 1960-09-30 13:49:04.0 +
@@ -23,6 +23,10 @@
gateway[$j]=${rfc_routes[$i]}
done
+# skip gateways identified by IP addresses that are attached to local interfaces
+# (prevent competing routes for local networks)
+ip addr show | grep -q " inet ${gateway[0]}\.${gateway[1]}\.${gateway[2]}\.${gateway[3]}/" && continue
+
old_IFS="$IFS"
IFS='.'
Bug#646236: [libmp4v2-dev] FTBFS for armhf: offset out of range
Package: libmp4v2-dev Version: 1.9.1+svn479~dfsg0-2 Severity: normal --- Please enter the report below this line. --- the libmp4v2 package fails to build from source on armhf (armel with hard-float). Here is a build log: http://buildd.debian-ports.org/status/fetch.php?pkg=mp4v2&arch=armhf&ver=1.9.1%2Bsvn479~dfsg0-2&stamp=1319080649 The crucial lines are: libtool: compile: g++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -g -O2 -fvisibility=hidden -c src/bmff/typebmff.cpp -fPIC -DPIC -o src/bmff/.libs/typebmff.o /tmp/ccshNagF.s: Assembler messages: /tmp/ccshNagF.s:6419: Error: offset out of range /tmp/ccshNagF.s:8635: Error: offset out of range Building is successful with optimization disabled. Thus adding the "--disable-optimize" parameter to the "configure" line in debian/rules fixes the problem on that platform. But this is surely not the perfect solution. btw: CXXFLAGS given in debian/rules (specifically "-Ox") is ignored due to configure, I guess. thanks for the package! cheers, Lars --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#858940: [node-browserify-light] browserify ignores modules in /usr/lib/nodejs
Package: node-browserify-light Severity: normal --- Please enter the report below this line. --- Dear maintainers, currently the node-browserify-lite program is searching for node modules only in the directory $PWD/node_modules. Thus it is not possible to use node modules that are installed via other debian packages. These are found below /usr/lib/nodejs. I would like to bundle a local application (partially) based on the system-wide installed node modules. This requires the above additional search path. The NODE_PATH environment variable could be used to override the default node_modules location, but it doesn’t seem to be used when resolving modules recursively and therefor fails if a required module requires another module. Thus this environment variable currently would not solve my problem. Thank you for your time! Cheers, Lars
Bug#855809: [clamav-milter] LocalNet configuration via debconf fails for multiple networks or hosts
Package: clamav-milter
Version: 0.99.2+dfsg-0+deb8u2
Severity: minor
--- Please enter the report below this line. ---
Dear Maintainer,
the helpful debconf-based configuration of clamav-milter contains the following
description for the "LocalNet" setting:
Please specify, in CIDR notation (host(name)/mask), the hosts for which no
scanning should be performed on incoming mail. Multiple entries should be
separated by spaces.
After entering multiple networks in this field (e.g. "10.0.1.0/24 10.0.2.0/24")
the following line is written into the clamav-milter config file:
LocalNet 10.0.1.0/24 10.0.2.0/24
clamav-milter refuses to work with this setting ("failed to resolve ...").
The proper configuration settings (according to the manpage) would be the
following:
LocalNet 10.0.1.0/24
LocalNet 10.0.2.0/24
Thank you for your time!
Cheers,
Lars
Bug#828188: [slt] Missing init script
Package: slt Version: 0.0.git20140301-1 Severity: normal Tags: patch --- Please enter the report below this line. --- Dear slt maintainer, currently the slt package lacks integration for init systems. Attached you find an init script and its related /etc/defaults/slt file. Additionally you find a snippet for the (currently non-existing) READNE.Debian file referring to this setup. Thank you for your time! Cheers, Lars --- System information. --- Architecture: i386 Kernel: Linux 4.5.0-2-686-pae slt_default Description: Binary data slt_init Description: Binary data slt_readme Description: Binary data
Bug#828188: [slt] Correction: disable by default
Package: slt --- Please enter the report below this line. --- Hi, I need to correct my previous submission. In the defaults file "START_DAEMON" is set to "yes". It should be "no" instead, since we cannot hope that a working configuration file exists. Cheers, Lars
Bug#768376: [libvirt-daemon-system]
Package: libvirt-daemon-system Version: 1.2.15-2 --- Please enter the report below this line. --- Is there anything missing in the documentation patch offered by Reco on the 7th of November 2014? From my point of view it clearly documents access control with and without policykit as well as the special treatment possibly necessary when using systemd without policykit. Just the first word of Reco's patch needs to be changed from "Remove" to "Remote". Or is anything else missing? Cheers, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703282: [linphone] Workaround for numeric username
Package: linphone Version: 3.6.1-2.4+b1 --- Please enter the report below this line. --- The same problem still persists with v3.6. Numeric IDs are common for other providers, as well (e.g. easybell). I worked around this problem with these steps: * enter a username starting with a letter in the wizard * use "Options -> Preferences -> Manage SIP Accounts" and change the username (there is no validation in this dialog) cheers, Lars --- System information. --- Architecture: i386 Kernel: Linux 3.16.0-4-686-pae -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724344: [wnpp]
Package: wnpp --- Please enter the report below this line. --- Hi maxigas, just two days ago v0.9 of bdsync was released: https://github.com/TargetHolding/bdsync/releases/tag/v0.9 It includes fln's patch (or a variation) for GnuTLS support: https://github.com/fln/bdsync/commit/768d7ecbb95c46af88c3bdad94193d71ea281815 I would appreciate a debian package for bdsync a lot! thanks, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#816061: [needrestart] Login manager "slim" should be disabled by default
Package: needrestart
Version: 2.6-1
Severity: normal
--- Please enter the report below this line. ---
Hello,
I noticed that "slim" (a graphical login manager) is not disabled by default in
/etc/needrestart/needrestart.conf.
"q(^gdm) => 0," should probably be added to $nrconf{override_rc}.
Thank you!
Cheers,
Lars
--- System information. ---
Architecture: i386
Kernel: Linux 4.3.0-1-686-pae
Debian Release: stretch/sid
500 testing 192.168.2.12
--- Package information. ---
Package's Depends field is empty.
Package's Recommends field is empty.
Package's Suggests field is empty.
Bug#872985: [lirc] postinst of lirc fails if systemd is not installed
Package: lirc Version: 0.10.0-2 --- Please enter the report below this line. --- Hello, I experienced the same problem after upgrading lirc from v0.9.4c-9 to v0.10.0-2. On 23/08/17 12:34, Alec Leamas wrote: > hm... don't you have systemd installed? systemd-tmpfiles is an > integral part of systemd, seems strange that the script cannot find it. The following set of related packages is installed on my system: # dpkg -l | grep -E "(systemd|sysv)" | cut -c 1-60 ii libsystemd0 234-2.3 ii systemd-shim 10-3 ii sysv-rc 2.88dsf-59.9 ii sysvinit-core2.88dsf-59.9 ii sysvinit-utils 2.88dsf-59.9 "systemd-tmpfiles" is part of the "systemd" package (not installed). It looks like it would be sufficient to guard the content of the (systemd-related) postinst script with a check for the existence of "/bin/systemd-tmpfiles". Thank you! Cheers, Lars
Bug#769158: [Packaging] Bug#769158: munin, munin-node: fails to upgrade from 'sid' - trying to overwrite /usr/share/man/man5/munin.conf.5.gz
Hello, Am Fri, 7 Oct 2016 16:03:00 + schrieb Holger Levsen : > On Thu, Oct 06, 2016 at 10:38:45AM +0200, Andreas Beckmann wrote: > > Followup-For: Bug #769158 > > Control: found -1 2.999.3-1 > > and now we have even more overwrite conflicts (without > > guarantee on completeness): > > hmpf. where do you see those? > https://piuparts.debian.org/sid2experimental/source/m/munin.html looks > sunny and well… I am not used to reading piuparts logs, thus just wild guessing ... Could it be, that munin-doc was not installed during the above test? Taking the history of the file /usr/share/man/man5/munin.conf.5.gz as an example: * stretch/buster/sid: part of "munin-doc" * experimental: part of "munin" Andreas' log indicated the same conflict / transition from "munin-plugins-extra" to "munin". Cheers, Lars [1] https://packages.debian.org/sid/all/munin-doc/filelist [2] https://packages.debian.org/experimental/all/munin/filelist
Bug#866180: [mod-wsgi] "Bad Request" with moinmoin while saving a page
Package: mod-wsgi Version: 4.5.11-1 Severity: normal --- Please enter the report below this line. --- Recently I upgrade my wiki server (based on moinmoin) from jessie to buster. Thank you for that release! Sadly I received notifications from multiple users in multiple moin wikis afterwards. They received the following message when trying to save a page: Bad Request The browser (or proxy) sent a request that this server could not understand. Not all wiki pages were affected - but all affected wiki pages showed this behaviour reliably with every save request. I chased down the problem to the package libapache2-mod-wsgi. With the version from buster (4.5.11-1) the problem occurred. With the version from jessie (4.4.13-0.1) the problem disappeared. I also tried another version (4.5.7-1) from snapshot.debian.org - this worked, as well. Switching back and forth between these versions showed predictable behaviour. I bisected the (few) commits of mod-wsgi's upstream repository. The problem started here: https://github.com/GrahamDumpleton/mod_wsgi/commit/4e757103334765691fab24362a41c870c990be8f I went away with this commit: https://github.com/GrahamDumpleton/mod_wsgi/commit/9192fd36620ca7515954e4ef2d21458c8563ebe2 The host is running amd64. Thank you for your time. Cheers, Lars
Bug#867790: vdirsyncer: missing upstream changelog
Package: vdirsyncer Version: 0.16.0-1 Severity: minor Dear Maintainer, the changelog file shipped with the Debian package of vdirsyncer contains no information, but just a reference to another file (in upstream's source, probably): root@erker:~# zcat /usr/share/doc/vdirsyncer/changelog.gz .. include:: ../CHANGELOG.rst Thank you for your time! Cheers, Lars -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.9.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages vdirsyncer depends on: ii python33.5.3-3 ii python3-atomicwrites 1.1.5-1 ii python3-click 6.6-1 ii python3-click-log 0.1.8-1 ii python3-click-threading0.4.3-1 ii python3-requests 2.12.4-1 ii python3-requests-toolbelt 0.7.0-1 vdirsyncer recommends no packages. Versions of packages vdirsyncer suggests: pn python3-requests-oauthlib -- no debconf information
Bug#849426: [openvdb] Add python3 support
Package: openvdb Version: 3.2.0-2.1 Severity: normal --- Please enter the report below this line. --- Hello, with v3.2 openvdb gained python3 support. See the changelog: https://github.com/dreamworksanimation/openvdb/blob/v3.2.0/openvdb/CHANGES#L149 or the merged feature branch: https://github.com/dreamworksanimation/openvdb/commit/4f5d7cb073bf1d798d5ed2044992d7d29ef09fc8 I would highly appreciate a python3 module for openvdb. Currently there is only a python2 module. Thank you for your time! Cheers, Lars --- System information. --- Architecture: Kernel: Linux 4.8.0-1-686-pae Debian Release: stretch/sid 500 testing 192.168.2.12 --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
Bug#831464: [munin-plugins-extra] spamstats: add debian-specific default configuration
Package: munin-plugins-extra Version: 2.0.25-1 Severity: normal --- Please enter the report below this line. --- Dear maintainers, I just tried to enable the spamstat plugin on my host with a local running spamassassing daemon. In order to get the munin plugin running, I needed to add a configuration for spamassassins default setup (at least for the Debian one): [spamstats] group adm env.logfile mail.log Maybe the package munin-plugins-extra should deliver an additional plugin configuration file (e.g. /etc/munin/plugin-conf.d/munin-plugins-extra) next to the one delivered by munin-node? Or maybe the section above should be included in the configuration file that is part of munin-node? Thank you for your time! Cheers, Lars
Bug#831738: [gajim] Please downgrade "Depends" to "Recommends" on dbus, python-dbus
Package: gajim Version: 0.16.5-1 Severity: normal --- Please enter the report below this line. --- Dear maintainers, Gajim lists "dbus" as an optional runtime requirement. It carefully checks during startup if the "dbus" python module is available. In contrast "dbus" and "python-dbus" are currently listed in "Depends" instead of "Recommends". I just verified that gajim works on a Debian testing system by removing the dbus module files. Gajim started and worked without any issues. I would be pleased if you could downgrade the package dependency. Thank you! Cheers, Lars --- System information. --- Architecture: i386 Kernel: Linux 4.6.0-1-686-pae Debian Release: stretch/sid --- Package information. --- Depends (Version) | Installed ===-+-== python:any(>= 2.6.6-7~) | python-gtk2 (>= 2.22.0) | 2.24.0-4 dnsutils| 1:9.10.3.dfsg.P4-10 dbus| 1.10.8-1 python-dbus (>= 0.81) | 1.2.4-1 python-nbxmpp(>= 0.5.3) | 0.5.3-1 Recommends (Version) | Installed ==-+-=== python-openssl (>= 0.12) | 16.0.0-1 python-pyasn1 | 0.1.9-1 python-crypto | 2.6.1-6+b1 notification-daemon| 3.20.0-1 ca-certificates| 20160104 Suggests(Version) | Installed =-+-=== libxss1 | 1:1.2.2-1 avahi-daemon | 0.6.32-1 python-avahi | libgtkspell0 | 2.0.16-1.1 aspell-en | OR aspell-dictionary | python-gnome2 | 2.28.1+dfsg-1.1 python-gnomekeyring | gnome-keyring | 3.20.0-1 kwalletcli| python-kerberos (>= 1.1) | texlive-latex-base| 2016.20160623-1 dvipng| 1.14-2+b2 python-farstream | gstreamer0.10-plugins-ugly| python-gconf | 2.28.1+dfsg-1.1 nautilus-sendto | network-manager | python-pycurl | 7.43.0-1 python-gupnp-igd |
Bug#1077759: gosa: failed to change user entry: Uncaught ReflectionException: Property LDAP::$count does not exist
Package: gosa
Version: 2.8~git20230203.10abe45+dfsg-1+deb12u2
Severity: normal
Dear Maintainer,
I recently noticed, that I cannot edit properties of a user account
in the GOsa web interface anymore.
This applies to my own account as well as other people's accounts in an
admin context.
I am running Debian Bookworm and I am not aware of any special
ingredients in the affected system.
Example procedure:
1. log into GOsa as a user
1. select "Edit user settings" (the wording is not exact; I am using the
German localization)
1. click "Edit"
1. change one of the user properties (e.g. first name, academic title,
birthday, ...)
1. click "OK"
The following error message is emitted now:
Fatal error: Uncaught ReflectionException:
Property LDAP::$count does not exist in
/usr/share/gosa/include/class_ldapMultiplexer.inc:55
Stack trace:
#0 /usr/share/gosa/include/class_ldapMultiplexer.inc(55):
ReflectionProperty->__construct()
#1 /usr/share/gosa/plugins/personal/generic/class_user.inc(1357):
ldapMultiplexer->__get()
#2 /usr/share/gosa/include/class_tabs.inc(412): user->check()
#3 /usr/share/gosa/plugins/personal/myaccount/main.inc(87): tabs->check()
#4 /usr/share/gosa/html/main.php(427): require('...')
#5 {main} thrown in /usr/share/gosa/include/class_ldapMultiplexer.inc on line
55
A reboot of the host providing GOSa did not change this behavior.
I *think*, the above procedure was working before, but I am not aware
of any local changes.
Do you have an idea, what could cause this error message?
Thank you for your time!
Lars
Bug#1058561: auto-apt-proxy: for hostname `apt-proxy` resolving to both an IPv4 and IPv6 address, only the IPv6 address is attempted
Package: auto-apt-proxy
Version: 14.1
Severity: normal
Dear Maintainer,
Hello,
in my environment the name `apt-proxy` resolves to both an IPv4 and an
IPv6 address.
In `/usr/bin/auto-apt-proxy` the hostname `apt-proxy` is resolved via
the following command:
getent hosts apt-proxy
But the above command omits all IPv4 addresses, if at least one IPv6
address is found.
This seems to be the quirky - but intended - behavior of the `getent hosts`
command: https://sourceware.org/bugzilla/show_bug.cgi?id=10859
This prevents `auto-apt-proxy` from working in environments, where IPv6
is disabled for some reason (e.g. a docker instance started by
gitlab-runner configured for IPv4-only).
There, IPv6 addresses are returnd by `getent hosts`, but the IPv4-only
network setup renders these addresses unreachable.
Maybe something like the following command could be useful instead?
getent ahosts ix.de | awk '{print $1}' | sort --reverse | uniq
This should return all IPv4 and IPv6 addresses for a given hostname.
`--reverse` seems to result in IPv6 addresses being on top.
Cheers,
Lars
-- System Information:
Debian Release: trixie/sid
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages auto-apt-proxy depends on:
ii apt 2.7.6
Versions of packages auto-apt-proxy recommends:
ii busybox 1:1.36.1-3.1
ii iproute2 6.5.0-4
auto-apt-proxy suggests no packages.
-- no debconf information
Bug#1058566: auto-apt-proxy: "approx" should not be given https URLs
Package: auto-apt-proxy Version: 14.1 Severity: normal Dear Maintainer, according to d#756656 [1] https-URLs cannot be given to `approx`. Thus, the `approx` check should be skipped when an https URL is requested. Cheers, Lars [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756656
Bug#1068865: gosa: Setup failure: "PHP Fatal error: Uncaught TypeError: ldap_get_entries()"
Package: gosa
Version: 2.8~git20230203.10abe45+dfsg-1+deb12u2
Severity: normal
Dear Maintainer,
thank you for maintaining gosa!
I just run the web-based setup procedure of gosa in Debian Bookworm.
Quite early I received the following error:
PHP Fatal error: Uncaught TypeError: ldap_get_entries(): Argument #2 ($result)
must be of type LDAP\\Result, bool given in
/usr/share/gosa/include/class_ldap.inc:1525\nStack trace:\n#0
/usr/share/gosa/include/class_ldap.inc(1525): ldap_get_entries()\n#1
/usr/share/gosa/setup/class_setupStep_Ldap.inc(73):
LDAP::get_naming_contexts()\n#2 /usr/share/gosa/setup/class_setup.inc(79):
Step_Ldap->execute()\n#3 /usr/share/gosa/setup/main.inc(29):
setup->execute()\n#4 /usr/share/gosa/html/setup.php(123):
require_once('...')\n#5 {main}\n thrown in
/usr/share/gosa/include/class_ldap.inc on line 1525, referer:
https://accounts.silicann.systems/setup.php
According to the environment settings visible in the apache2 log, the
culprit seems to be the assumption, that a local LDAP server is
available:
ldap_connect_to_host: TCP localhost:389
Maybe the setup procedure does not deal with a remote LDAP server gracefully?
My workaround was a temporary `ssh -R ...` port forwarding between the
remote LDAP server and the local host running gosa.
The following setup screen allowed me to configure the real LDAP URI.
Thanks for your time,
Lars
Bug#1032484: django-macaddress: Please package new upstream releases for compatibility with recent Django versions
Source: django-macaddress Version: 1.5.0-3 Severity: wishlist Dear Maintainer, a few minor releases were published for django-macaddress during the last years. Mostly they deal with issues regarding compatibility with more recent Django versions. See [1] for details. I would really appreciate, if you could package the latest upstream version of django-macaddress. Maybe even in time for Bookworm? That would be fabulous! Thank you for maintaining this package! Cheers, Lars [1] https://github.com/django-macaddress/django-macaddress/releases
Bug#1010406: kexec-tools: add trivial support for restart/reload via stop/start
Package: kexec-tools Version: 1:2.0.24-1+b1 Followup-For: Bug #1010406 Control: tags -1 patch Dear Maintainer, here on my system I replaced the content of the "restart" branch with a simple stop/start sequence: restart|reload|force-reload) "$0" stop "$0" start ;; This works fine here (the "start" operation is a no-op, anyway). Attached you find a patch with the above change applied to both init scripts. Thanks for providing an init script for this package! Cheers, Lars --- /etc/init.d/kexec.orig 2022-11-06 21:26:18.670086639 +0100 +++ /etc/init.d/kexec 2022-11-06 21:27:52.981249908 +0100 @@ -37,8 +37,8 @@ # No-op ;; restart|reload|force-reload) - echo "Error: argument '$1' not supported" >&2 - exit 3 + "$0" stop + "$0" start ;; stop) # Systemd has its own kexec service (which will call the kexec --- /etc/init.d/kexec-load.orig 2022-11-06 21:26:10.545814141 +0100 +++ /etc/init.d/kexec-load 2022-11-06 21:27:58.109421912 +0100 @@ -102,8 +102,8 @@ # No-op ;; restart|reload|force-reload) - echo "Error: argument '$1' not supported" >&2 - exit 3 + "$0" stop + "$0" start ;; stop) # If running systemd, we want kexec reboot only if current
Bug#1024143: gitlab: postinst fails silently within rake-tasks, if /var/lib/gitlab/.cache/yarn/v6 does not exist
Package: gitlab
Version: 15.2.3+ds1-2~fto11+1
Severity: normal
Tags: patch
Dear Maintainer,
during gitlab's package installation, the following line in
`rake-tasks.sh` causes a failure of the postinst processing:
> -runuser -u ${gitlab_user} -- sh -c 'test -d "/var/lib/gitlab/.cache/yarn/v6"
> && find /var/lib/gitlab/.cache/yarn/v6/ -name .yarn-metadata.json -perm -a=w
> -exec chmod 644 {} \;'
The above fails, if the directory does not exists.
Due to the shell's exit-on-error (`set -e`), this failure is fatal.
Attached you find a patch, which ensures the proper exitcode for the
line above.
Cheers,
Lars
--- /usr/lib/gitlab/scripts/rake-tasks.sh.orig 2022-11-15 05:16:06.185030967
+0100
+++ /usr/lib/gitlab/scripts/rake-tasks.sh 2022-11-15 05:16:32.504552974
+0100
@@ -45,7 +45,7 @@
runuser -u ${gitlab_user} -- sh -c 'if ! grep nodeLinker .yarnrc.yml
>/dev/null; then echo "nodeLinker: \"node-modules\"" >>.yarnrc.yml; fi'
runuser -u ${gitlab_user} -- sh -c 'yarnpkg install'
# Remove write permissions of .yarn-metadata.json files
-runuser -u ${gitlab_user} -- sh -c 'test -d "/var/lib/gitlab/.cache/yarn/v6"
&& find /var/lib/gitlab/.cache/yarn/v6/ -name .yarn-metadata.json -perm -a=w
-exec chmod 644 {} \;'
+runuser -u ${gitlab_user} -- sh -c 'if test -d
"/var/lib/gitlab/.cache/yarn/v6"; then find /var/lib/gitlab/.cache/yarn/v6/
-name .yarn-metadata.json -perm -a=w -exec chmod 644 {} \;; fi'
cd /usr/share/gitlab
Bug#1029623: gitlab: Services are not restarted in case of a missing database server during startup
Package: gitlab Version: 15.2.3+ds1-2~fto11+1 Severity: normal Dear Maintainer, recently I noticed, that the following gitlab-related services remained in the "failed" state after booting the VM: * gitlab-puma * gitlab-sidekiq * gitlab-workhorse The problem was caused by the absence of the database server (it was just booting up in a separate VM). The same applies probably to `gitlab-mailroom`, but that service was probably just lucky or arrived late. Currently the `Restart` directive in the service files of the above services is set to `Restart=on-abnormal`. Thus, non-zero exit codes do not trigger a restart. But the missing database connection caused exactly such a non-zero exitcode. Thus I would suggest to use `Restart=on-failure` for these (all?) services, instead. Thank you for maintaining the gitlab package! Cheers, Lars
Bug#1058566: auto-apt-proxy: "approx" should not be given https URLs
Hello, Am Wed, 4 Sep 2024 19:48:27 -0300 schrieb Antonio Terceiro : > Can you please clarify how exactly are you hitting this issue? Can you > provide an example of how I can reproduce this? yes, sorry for omitting these details in my initial bug report. I just created a fresh image for testing and ran the following procedure: 1. `apt install auto-apt-proxy ca-certificates` (certificates are necessary for https connections) 1. change the URL in `/etc/apt/sources.list` to http://deb.debian.org/debian 1. run `apt update` -> success 1. change the URL in `/etc/apt/sources.list` to https://deb.debian.org/debian 1. run `apt update` -> failure (see below) 1. `apt purge auto-apt-proxy` 1. run `apt update` -> success Here `auto-apt-proxy` detected the presence of approx via the DNS SRV entry (_apt_proxy._tcp). The above example illustrates, that auto-apt-proxy will send the request for an https ressource to approx, even though approx cannot handle such requests. Of course, the use case behind the above switch to "https" can be questioned, since the default settings for apt servers usually use http URLs. In my use case we stumbled upon the problem, since our internal apt repository server is usually accessed via https (for no specific reasons). This turned out to be problematic as soon as approx was indirectly used via auto-apt-proxy. I hope, this clarifies my use case. Cheers, Lars Error message during "apt update" for HTTPS URL via approx: Err:2 https://deb.debian.org/debian bookworm InRelease Invalid response from proxy: HTTP/1.1 403 Forbidden Content-type: text/html Content-Length: 76 Date: Fri, 06 Sep 2024 02:12:16 GMT Server: approx/5.12 Ocamlnet/ [IP: fdb5:576b:c643:100:216:3eff:fe27:86ee ] Err:3 https://deb.debian.org/debian bookworm-updates InRelease Invalid response from proxy: HTTP/1.1 403 Forbidden Content-type: text/html Content-Length: 76 Date: Fri, 06 Sep 2024 02:12:17 GMT Server: approx/5.12 Ocamlnet/ [IP: fdb5:576b:c643:100:216:3eff:fe27:86ee ] Reading package lists... Done Building dependency tree... Done Reading state information... Done All packages are up to date. W: Failed to fetch https://deb.debian.org/debian/dists/bookworm/InRelease Invalid response from proxy: HTTP/1.1 403 Forbidden Content-type: text/html Content-Length: 76 Date: Fri, 06 Sep 2024 02:12:16 GMT Server: approx/5.12 Ocamlnet/ [IP: fdb5:576b:c643:100:216:3eff:fe27:86ee ] W: Failed to fetch https://deb.debian.org/debian/dists/bookworm-updates/InRelease Invalid response from proxy: HTTP/1.1 403 Forbidden Content-type: text/html Content-Length: 76 Date: Fri, 06 Sep 2024 02:12:17 GMT Server: approx/5.12 Ocamlnet/ [IP: fdb5:576b:c643:100:216:3eff:fe27:86ee ]
Bug#482379: [stunnel4] connection to terminal caused by libwrap in stunnel
Package: stunnel4 Version: 3:4.22-2 --- Please enter the report below this line. --- Hi, this problem does not ocour with stunnel 4.18 (etch). I went through intermediate releases (taken from ubuntu) and noticed, that the problem starts in 4.21. Version 4.20 still works as expected. The problem disappeared, when I added the "--disable-libwrap" switch to the "configure" line in debian/rules. A symptom of this problem is the existence of multiple processes after startup: erker:~/ttt/stunnel/testing/stunnel4-4.22# ps -ef| grep stun root 29364 1 0 13:37 pts/100:00:00 src/stunnel -fd 0 root 29365 1 0 13:37 pts/100:00:00 src/stunnel -fd 0 root 29366 1 0 13:37 pts/100:00:00 src/stunnel -fd 0 root 29367 1 0 13:37 pts/100:00:00 src/stunnel -fd 0 root 29368 1 0 13:37 pts/100:00:00 src/stunnel -fd 0 lars 29369 1 0 13:37 ?00:00:00 src/stunnel -fd 0 The stdout/stderr FDs of the first five root-owned processes are connected to /dev/pts/1. The user-owned process is connected to /dev/null (as it should be). I posted this problem to the stunnel-user mailinglist - see http://stunnel.mirt.net/pipermail/stunnel-users/2009-January/002218.html Hopefully, upstream will take care for the problem ... Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: 5.0 990 testing localhost 990 testing debian-multimedia.gnali.org --- Package information. --- Depends (Version) | Installed ==-+-== libc6 (>= 2.7-1) | 2.7-16 libssl0.9.8 (>= 0.9.8f-5) | 0.9.8g-14 libwrap0 (>= 7.6-4~) | 7.6.q-16 openssl| 0.9.8g-14 netbase| 4.34 perl-modules | 5.10.0-18 -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc signature.asc Description: PGP signature
Bug#510210: [libkolab-perl] bootstrap fails due to missing directory /var/lib/kolab/backups/
Package: libkolab-perl
Version: 2.2.1-20081212-1
Severity: important
Tags: patch
--- Please enter the report below this line. ---
when running "kolab_bootstrap -b" for the first time in a fresh lenny system,
it breaks with the following error:
cannot mkdir : Datei oder Verzeichnis nicht gefunden
at /usr/sbin/kolab_bootstrap line 214, line 1.
It looks like the parent directory (/var/lib/kolab/backups/) should be created
first.
This problem can be fixed with the attached patch.
Thanks for your work,
Lars
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.26-1-686
--- /usr/sbin/kolab_bootstrap 2008-12-30 14:48:39.0 +0100
+++ kolab_bootstrap 2008-12-30 14:51:26.0 +0100
@@ -211,6 +211,8 @@
}
my $epochseconds = timelocal(gmtime);
my $backupdir="$Kolab::config{'backupdir'}/backup".$epochseconds;
+ # create the backup base directory, if necessary
+ mkdir("$Kolab::config{'backupdir'}",0700) unless (-e "$Kolab::config{'backupdir'}");
mkdir($backupdir,0700) || die "cannot mkdir : $!";
print "creating backup of LDAP repository\n";
Bug#375568: busybox-static should include "Provides: busybox"
Package: busybox-static Severity: normal Hi, when I try to install busybox-static, then the already installed package busybox gets removed. This is ok. But: all packages depending on "busybox" also get removed (e.g. initramfs-tools) - even if this should not be necessary - right? One solution would - of course - to change the dependencies of initramfs-tools (and other packages). But as busybox-static really has the same features as busybox, a "Provides" entry should be more appropriate. What do you think? regards, Lars -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#370669: clearsilver: this patch does not work for cdbs
Package: clearsilver Followup-For: Bug #370669 Hi, thanks for the patch, but there is a problem as cdbs is used for package building. clearsilver needs to be reconfigured with a different configure setting for python2.4. Sadly, cdbs executes configure only once for all packages. There are two solutions for this problem: 1) use plain debhelpers instead of cdbs for package building 2) wait until cdbs developers implement multiple configure runs sorry - for now, this won't get fixed ... Lars -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#528043: [debian-installer] mkfs hangs when formatting a major block device
Package: debian-installer Severity: normal --- Please enter the report below this line. --- Hi, I tried to install lenny with the official net-install cd on i386 in a qemu environment. I did not partition /dev/hda, but choose to use the whole device for the root filesystem. This caused the "mkfs.ext3 /dev/hda" command to hang indefinitely. The reason seems to be the confirmation prompt of mkfs when trying to format a non-partition. Sending "y" via echo to stdin of the mkfs.ext3 process fixed the problem and allowed mkfs to progress as expected. I guess, the installer should add the "-F" switch for mkfs.ext3 in case of a non-partition target device. Obviously it is not recommended to use a whole block device for a filesystem. But since the installer seems to allow this, it should not hang later. thanks for your time, Lars -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc signature.asc Description: PGP signature
Bug#528711: [kolab-webadmin] postinst file contains old config file location /etc/kolab-webadmin/session_vars.php
Package: kolab-webadmin Version: 2.2.1-20090331-2 Severity: normal --- Please enter the report below this line. --- Hi, while trying to install kolab-webadmin in a testing system, I stumbled upon a post-install configuration error: Setting up kolab-webadmin (2.2.1-20090331-2) ... chmod: cannot access `/etc/kolab-webadmin/session_vars.php': No such file or directory dpkg: error processing kolab-webadmin (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: kolab-webadmin The kolab-webadmin.postinst file contains the old path /etc/kolab-webadmin/session_vars.php in the "fixperms" function. This path should depend on the previous version of the kolab-webadmin package - similar to the last four lines of the postinst script. After fixing this path in /var/lib/dpkg/info/kolab-webadmin.postinst, the package was configured without further problems. thanks for your time, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#528716: [kolab-webadmin] missing dependency for php-net-ldap
Package: kolab-webadmin Version: 2.2.1-20090331-2 Severity: normal --- Please enter the report below this line. --- Hi, after installing kolab-webadmin, I received en empty page for https://example.net/admin It looks like php-net-ldap was missing. After installing the package and restarting apache2, I was greeted by the expected login screen. I guess, that kolab-webadmin can't work without the ldap module, or? regards, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#528723: [slapd] segfault possibly caused by libdb-4.6.so
Package: slapd Version: 2.4.11-1 Severity: normal --- Please enter the report below this line. --- Hi, I installed a lenny system via an official netinstall cd. Then I upgraded the system to testing and installed kolabd and kolab-webadmin. Without further manual configuration changes, slapd segfaults during the first request (e.g. triggered by ldapsearch). I installed slapd-dbg and started slapd via gdb. Attached you find the gdb log and the slapd.conf file, as well as the used kolab2.schema file. My versions of db4.6 (it was mentioned in the gdb output): ii db4.6-util 4.6.21-13 ii libdb4.64.6.21-13 I hope, this helps you to reproduce the segfault. thanks for your time, Lars -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc Starting program: /usr/sbin/slapd -d 2 -g openldap -u openldap -f /etc/ldap/slapd.conf [Thread debugging using libthread_db enabled] [New Thread 0xb7a586c0 (LWP 31809)] [New Thread 0xb5113b90 (LWP 31812)] [Thread 0xb5113b90 (LWP 31812) exited] [New Thread 0xb5113b90 (LWP 31813)] [New Thread 0xb4511b90 (LWP 31814)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb4511b90 (LWP 31814)] 0xb7b9afd3 in strchrnul () from /lib/i686/cmov/libc.so.6 Thread 4 (Thread 0xb4511b90 (LWP 31814)): #0 0xb7b9afd3 in strchrnul () from /lib/i686/cmov/libc.so.6 #1 0xb7b5e81b in vfprintf () from /lib/i686/cmov/libc.so.6 #2 0xb7b63590 in ?? () from /lib/i686/cmov/libc.so.6 #3 0xb7b5ea4e in vfprintf () from /lib/i686/cmov/libc.so.6 #4 0xb79bba34 in __db_errfile () from /usr/lib/libdb-4.6.so #5 0xb79c599f in ?? () from /usr/lib/libdb-4.6.so #6 0x084cc808 in ?? () #7 0x in ?? () Thread 3 (Thread 0xb5113b90 (LWP 31813)): #0 0xb7f4b424 in __kernel_vsyscall () #1 0xb7c028d6 in epoll_wait () from /lib/i686/cmov/libc.so.6 #2 0x08073227 in slapd_daemon_task (ptr=0x0) at /build/buildd/openldap-2.4.11/servers/slapd/daemon.c:2281 #3 0xb7c864e5 in start_thread () from /lib/i686/cmov/libpthread.so.0 #4 0xb7c0210e in clone () from /lib/i686/cmov/libc.so.6 Thread 1 (Thread 0xb7a586c0 (LWP 31809)): #0 0xb7f4b424 in __kernel_vsyscall () #1 0xb7c86b67 in pthread_join () from /lib/i686/cmov/libpthread.so.0 #2 0xb7f0ed94 in ldap_pvt_thread_join () from /usr/lib/libldap_r-2.4.so.2 #3 0x08070043 in slapd_daemon () at /build/buildd/openldap-2.4.11/servers/slapd/daemon.c:2643 #4 0x0805deee in main (argc=9, argv=0xbfe68eb4) at /build/buildd/openldap-2.4.11/servers/slapd/main.c:948 #0 0xb7b9afd3 in strchrnul () from /lib/i686/cmov/libc.so.6 The program is running. Exit anyway? (y or n) kolab2.schema.bz2 Description: application/bzip slapd.conf Description: Binary data signature.asc Description: PGP signature
Bug#534132: [qgo] desktop file contains invalid MimeType
Package: qgo Version: 1.5.4-r3-1 Severity: normal --- Please enter the report below this line. --- Hi, after running "update-desktop-database" from a user account, I receive the following error message: File '/usr/share/applications/kde/qgo.desktop' contains invalid MIME type 'Application' that is missing a slash Indeed the file /usr/share/applications/kde/qgo.desktop contains the following MimeType: MimeType=text/plain;text/sfg;Application Removing ";Application" resolves the problem for me. thanks for your time, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.29-2-686 Debian Release: squeeze/sid 990 testing localhost 500 unstablewww.claws-mail.org 500 unstabledebian.zaubberer.net 500 lenny www.lamaresh.net --- Package information. --- Depends(Version) | Installed -+-== libaudio2| 1.9.2-1 libc6 (>= 2.7-1) | 2.9-12 libfontconfig1(>= 2.4.0) | 2.6.0-3 libfreetype6 (>= 2.3.5) | 2.3.9-4.1 libgcc1 (>= 1:4.1.1) | 1:4.4.0-5 libice6 (>= 1:1.0.0) | 2:1.0.5-1 libjpeg62| 6b-14 libpng12-0 (>= 1.2.13-4) | 1.2.37-1 libqt3-mt (>= 3:3.3.8b) | 3:3.3.8b-5+b1 libsm6 | 2:1.1.0-2 libstdc++6(>= 4.1.1) | 4.4.0-5 libx11-6 | 2:1.2.1-1 libxcursor1 (>> 1.1.2) | 1:1.1.9-1 libxext6 | 2:1.0.4-1 libxft2 (>> 2.1.1) | 2.1.13-3 libxi6 | 2:1.2.1-2 libxinerama1 | 2:1.0.3-2 libxrandr2 | 2:1.3.0-2 libxrender1 | 1:0.9.4-2 libxt6 | 1:1.0.5-3 zlib1g (>= 1:1.1.4) | 1:1.2.3.3.dfsg-13 Package's Recommends field is empty. Suggests (Version) | Installed ===-+-=== gnugo | 3.8-1 -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc signature.asc Description: PGP signature
Bug#445525: pioneers-client: missing optional scrollbar in trade window
Package: pioneers-client Version: 0.10.2-3 Severity: normal Hi, in case the map window is quite small (e.g. with a big chat window on a small screen (1024x768), the trade window is not fully usable. The trade items at the bottom are not really visible. Maybe the trade item part of the window or the whole trade window should optionally have a scrollbar (if it is too small). thanks for the game! Lars -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages pioneers-client depends on: ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libglib2.0-0 2.14.0-2 The GLib library of C routines ii libgnome2-0 2.20.0-1 The GNOME 2 library - runtime file ii libgtk2.0-0 2.10.13-1 The GTK+ graphical user interface ii libpango1.0-0 1.18.2-1 Layout and rendering of internatio Versions of packages pioneers-client recommends: ii pioneers-help 0.10.2-3 online help for the Pioneers clien ii pioneers-server-gtk 0.10.2-3 computer version of the Settlers o -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445526: pioneers-server-gtk: map preview during selection
Package: pioneers-server-gtk Version: 0.10.2-3 Severity: wishlist Hi, it would be great to see a preview of the maps in one of the following locations: * in the map selection scroll list * or somewehere in the server setup window after selecting a map * or in a new window after pushing a "preview" button in the server setup window this would help to have an idea of a map without starting a real game, I guess. Thanks anyway, Lars -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages pioneers-server-gtk depends on: ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries ii libglib2.0-0 2.14.0-2 The GLib library of C routines ii libgnome2-0 2.20.0-1 The GNOME 2 library - runtime file ii libgtk2.0-0 2.10.13-1 The GTK+ graphical user interface ii pioneers-server-data 0.10.2-3 data required by the Pioneers serv Versions of packages pioneers-server-gtk recommends: ii pioneers-ai 0.10.2-3 computer version of the Settlers o ii pioneers-client 0.10.2-3 computer version of the Settlers o -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445538: restart fails if pound is not running
Package: pound
Version: 2.0-1.2
Severity: normal
Hi,
I am not sure, if this is required by some policy, but I expect a
"invoke-rc.d pound restart" to start a daemon even if it was not running
before.
Since /etc/init.d/pound contains the bash exit-on-error setting
("set -e"), execution stops after the "stop" line in the "restart" part
of "case".
What about adding " || true" to this line in order to ignore a potential
failure of "stop"?
thanks,
Lars
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#547322: [libapache2-mod-python] Purge after removal fails
Package: libapache2-mod-python Severity: normal Tags: patch --- Please enter the report below this line. --- Purging the package after removal fails due to the missing "python" module for a2dismod. how to reproduce: - install the package - remove it - purge the configuration The last step fails due to an exitcode 1 from the post removal script. The attached patch tolerates a failure of "a2dismod python" and thus allows to purge the package successfully. thanks for your work, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.30-1-686 Debian Release: squeeze/sid 990 testing localhost --- Package information. --- Depends (Version) | Installed =-+-= libapache2-mod-python2.3 (>= 3.1.3-3) | python (>= 2.3) | 2.5.4-2 python (<< 2.4) | 2.5.4-2 Package's Recommends field is empty. Package's Suggests field is empty. -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc --- libapache2-mod-python.postrm.orig 2009-09-18 14:45:08.0 +0200 +++ libapache2-mod-python.postrm 2009-09-18 14:40:59.0 +0200 @@ -3,7 +3,8 @@ set -e if [ "$1" = "remove" -o "$1" = "purge" ]; then -a2dismod python +# module deactivation may fail, if the package was "removed" before and then later "purged" +a2dismod python || true fi # mod_python.load renamed to python.load in 3.3.1-3
Bug#547349: [bash-completion] "quote_readline" doubles backslashs
Package: bash-completion Version: 1:1.0-3 --- Please enter the report below this line. --- Hi, the function "quote_readline" seems to cause this behavior. How to reproduce: mkdir "foo bar" mv foo\ this produces no resulting matches. bash-completion uses the function "_longopt" in /etc/bash-completion for this operation. The problem seems to be caused by the output of "quote_readline" which is called within "_filedir", which is called by "_longopt". Running dequote/quote_readline does not recover the original input: l...@erker:~$ quote_readline "foo\ " 'foo\\ ' l...@erker:~$ dequote "$(quote_readline "foo\ ")" foo\\ (two backslashs instead of one) In contrast the combination dequote/quote works as expected: l...@erker:~$ quote "foo\ " 'foo\ ' l...@erker:~$ dequote "$(quote "foo\ ")" foo\ (one backslash as expected) I could not understand the difference between "quote" and "quote_readline". But in the case shown above, "quote" would not cause a problem, while "quote_readline" does. Maybe "_filedir" (and "_filedir_xpsec") should use "quote" instead of "quote_readline"? thanks for your work, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.30-1-686 Debian Release: squeeze/sid 990 testing localhost --- Package information. --- Depends (Version) | Installed ==-+-=== bash(>= 3.1dfsg-9) | 4.0-4 Package's Recommends field is empty. Package's Suggests field is empty. -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc signature.asc Description: PGP signature
Bug#495300: [claws-mail] newmail plugin causes segmentation fault
Package: claws-mail Version: 3.5.0-2 Severity: normal --- Please enter the report below this line. --- when the newmail plugin (same version as claws-mail (3.5.0-2)) is enabled, then claws-mail crashes when accessing IMAP folders for write access. After disabling the newmail plugin, everything works fine again. See an upstream bug report regarding this problem: http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=1654 It looks like the problem was solved upstream in CVS. --- System information. --- Architecture: i386 Kernel: Linux 2.6.24-1-686 Debian Release: lenny/sid 990 testing localhost 500 unstablelocalhost --- Package information. --- Depends (Version) | Installed ==-+-== libaspell15 (>= 0.60) | 0.60.6-1 libc6 (>= 2.7-1) | 2.7-13 libcairo2 (>= 1.2.4) | 1.6.4-6 libcompfaceg1 | 1:1.5.2-4 libdbus-glib-1-2 (>= 0.71) | 0.76-1 libetpan13 (>= 0.54) | 0.54-3 libglib2.0-0 (>= 2.16.0) | 2.16.4-2 libgtk2.0-0(>= 2.12.0) | 2.12.11-3 libice6 (>= 1:1.0.0) | 2:1.0.4-1 libldap-2.4-2 (>= 2.4.7) | 2.4.10-3 libpango1.0-0 (>= 1.20.3) | 1.20.5-1 libpisock9 | 0.12.3-5 libsm6 | 2:1.0.3-2 libssl0.9.8 (>= 0.9.8f-5) | 0.9.8g-13 -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc signature.asc Description: PGP signature
Bug#357908: perl-clearsilver: wrong installation directory in original makefile and broken debian/rules
Package: perl-clearsilver Version: 0.10.2-1 Severity: important Tags: patch Content-Type: multipart/mixed; boundary="===1680032553==" MIME-Version: 1.0 From: Lars Kruse <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: perl-clearsilver: wrong installation directory Message-ID: <[EMAIL PROTECTED]> X-Mailer: reportbug 3.18 Date: Mon, 20 Mar 2006 08:49:26 +0100 This is a multi-part MIME message sent by reportbug. --===1680032553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Package: perl-clearsilver Version: 0.10.2-1 Severity: important Tags: patch I) The makefile of the upstream source code uses a wrong installation directory (/usr/local/lib/perl instead of /usr/lib/perl5) II) the debian/rules file contains an invalid line (resulting in a missing Clearsilver.pm file) the attached patches should solve both problems I did already sent a patch to the upstream author regarding the first (non debian-specific) problem. Thanks for packaging clearsilver for perl! Lars -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.5cork Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages perl-clearsilver depends on: ii perl 5.8.8-2Larry Wall's Practical Extraction perl-clearsilver recommends no packages. -- no debconf information --===1680032553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clearsilver-perl_installdir.diff" --- Makefile.orig 2006-03-13 00:42:06.0 +0100 +++ Makefile2006-03-20 06:17:50.0 +0100 @@ -29,7 +29,7 @@ @for mdir in $(SUBDIRS); do \ if test -d $$mdir; then \ if test -f $$mdir/Makefile.PL -a ! -f $$mdir/Makefile; then \ - cd $$mdir; $(PERL) Makefile.PL; cd ..; \ + cd $$mdir; $(PERL) Makefile.PL PREFIX=$(prefix) INSTALLDIRS=vendor; cd ..; \ fi; \ $(MAKE) -C $$mdir PREFIX=$(prefix); \ fi; \ @@ -46,7 +46,7 @@ @for mdir in $(SUBDIRS); do \ if test -d $$mdir; then \ if test -f $$mdir/Makefile.PL -a ! -f $$mdir/Makefile; then \ - cd $$mdir; $(PERL) Makefile.PL; cd ..; \ + cd $$mdir; $(PERL) Makefile.PL PREFIX=$(prefix) INSTALLDIRS=vendor; cd ..; \ fi; \ $(MAKE) -C $$mdir PREFIX=$(prefix) install; \ fi; \ --===1680032553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clearsilver-debian_packaging.diff" --- rules.orig 2006-03-20 07:36:21.0 +0100 +++ rules 2006-03-20 07:36:58.0 +0100 @@ -31,7 +31,8 @@ build/perl-clearsilver:: install -d debian/tmp/usr/lib/perl5 - install -d debian/tmp/usr/lib/perl5/auto/ClearSilver \ + install -d debian/tmp/usr/lib/perl5/auto/ClearSilver + install -m644 $(DEB_BUILDDIR)/perl/ClearSilver.pm \ debian/tmp/usr/lib/perl5/ClearSilver.pm install -m755 $(DEB_BUILDDIR)/perl/blib/arch/auto/ClearSilver/ClearSilver.so \ debian/tmp/usr/lib/perl5/auto/ClearSilver/ClearSilver.so --===1680032553==-- -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.5cork Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages perl-clearsilver depends on: ii perl 5.8.8-2Larry Wall's Practical Extraction perl-clearsilver recommends no packages. -- no debconf information --- Makefile.orig 2006-03-13 00:42:06.0 +0100 +++ Makefile2006-03-20 06:17:50.0 +0100 @@ -29,7 +29,7 @@ @for mdir in $(SUBDIRS); do \ if test -d $$mdir; then \ if test -f $$mdir/Makefile.PL -a ! -f $$mdir/Makefile; then \ - cd $$mdir; $(PERL) Makefile.PL; cd ..; \ + cd $$mdir; $(PERL) Makefile.PL PREFIX=$(prefix) INSTALLDIRS=vendor; cd ..; \ fi; \ $(MAKE) -C $$mdir PREFIX=$(prefix); \ fi; \ @@ -46,7 +46,7 @@ @for mdir in $(SUBDIRS); do \ if test -d $$mdir; then \ if test -f $$mdir/Makefile.PL -a ! -f $$mdir/Makefile; then \ - cd $$mdir; $(PERL) Makefile.PL; cd ..; \ + cd $$mdir; $(PERL) Makefile.PL PREFIX=$(prefix) INSTALLDIRS=vendor; cd ..; \ fi; \ $(MAKE) -C $$mdir PREFIX=$(prefix) install; \ fi; \
Bug#512370: [libgl1-mesa-dri] Still segfaulting with mesa 7.10
Package: libgl1-mesa-dri Version: 7.10-3 --- Please enter the report below this line. --- Hi people, sadly I still experience the same behaviour :( dpkg -l|grep mesa| cut -c 1-60 ii libgl1-mesa-dev 7.10-3 ii libgl1-mesa-dri 7.10-3 ii libgl1-mesa-glx 7.10-3 ii libglu1-mesa7.10-3 ii mesa-common-dev 7.10-3 ii mesa-utils 8.0.1-2 The attached valgrind log shows a similar error: ==28841== Process terminating with default action of signal 11 (SIGSEGV) ==28841== Access not within mapped region at address 0x18 ==28841==at 0x5D0DFAF: ??? (in /usr/lib/dri/savage_dri.so) ==28841==by 0x5D377D7: ??? (in /usr/lib/dri/savage_dri.so) ==28841==by 0x5D0CFB3: ??? (in /usr/lib/dri/savage_dri.so) ==28841==by 0x5D06C46: ??? (in /usr/lib/dri/savage_dri.so) ==28841==by 0x4829E47: ??? (in /usr/lib/libGL.so.1.2) ==28841==by 0x48054EB: ??? (in /usr/lib/libGL.so.1.2) ==28841==by 0x4559219: QGLContext::reset() (in /usr/lib/libqt-mt.so.3.3.8) ==28841==by 0x45544FC: QGLContext::~QGLContext() (in /usr/lib/libqt-mt.so.3.3.8) ==28841==by 0x4558554: QGLWidget::setContext(QGLContext*, QGLContext const*, bool) (in /usr/lib/libqt-mt.so.3.3.8) ==28841==by 0x809A7B6: ??? (in /usr/bin/earth3d) ==28841==by 0x809C86E: ??? (in /usr/bin/earth3d) ==28841==by 0x80583BD: ??? (in /usr/bin/earth3d) I hope, this helps ... Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.37-trunk-686 --- Package information. --- Depends (Version) | Installed =-+-=== libc6 (>= 2.3.6-6~) | 2.11.2-10 libdrm-intel1 (>= 2.4.21) | 2.4.23-0.0 libdrm-radeon1(>= 2.4.17) | 2.4.23-0.0 libdrm2(>= 2.4.3) | 2.4.23-0.0 libexpat1 (>= 1.95.8) | 2.0.1-7 libgcc1 (>= 1:4.1.1) | 1:4.4.5-10 libstdc++6 (>= 4.1.1) | 4.4.5-10 libtalloc2 (>= 2.0.4~git20101213) | 2.0.5-1 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== libglide3| earth3d_segfault_mesa_7.10.valgrind.bz2 Description: application/bzip
Bug#620590: [pm-utils] hibernate fails silently if ~/.config/monitors.xml is broken
Package: pm-utils Version: 1.3.0-3 Severity: normal --- Please enter the report below this line. --- Hi, I noticed that my current user fails to use hibernate, while a fresh new user can hibernate/thaw without problems. I was able to track down the problem to the existence of the file ~/.config/monitors.xml. The file was created by 'gnome-display-properties'. Since I just moved my home directory from another PC to a new one (with a fresh squeeze installation), I assume, that the "monitors.xml" file soemhow does not suit my current hardware profile (probably I did not run 'gnome-display-properties' recently). Anyway: hibernate worked after removing monitors.xml. Hibernate even works with a new monitors.xml file (created by gnome-display-properties). Symptoms of hibernate failure: - screen went black after 5 seconds - no further activity - no response - a hard reboot was necessary (with no valid hibernate image found) I attached both versions of monitors.xml (working and broken) and the output of "xrandr". Hopefully, "pm-utils" is the right place for this bug report ... The package "hibernate" is installed - I don't know, if/how it is involved. cheers, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.32-5-686 Debian Release: 6.0.1 500 stable-updates ftp.de.debian.org 500 stable security.debian.org 500 stable ftp.de.debian.org --- Package information. --- Depends (Version) | Installed =-+-=== powermgmt-base| 1.31 kbd | 1.15.2-2 OR console-tools | Recommends (Version) | Installed =-+-=== vbetool | 1.1-2 radeontool| 1.6.1-1 procps| 1:3.2.8-9 Suggests (Version) | Installed ===-+-=== cpufrequtils| 007-1 monitors_broken.xml Description: XML document monitors_working.xml Description: XML document xrandr.out Description: Binary data
Bug#577320: [patch]: clearsilver: FTBFS: /bin/sh: Syntax error: "(" unexpected
Hi Hideki, > I made a simple patch for this issue. > Please check and apply it, thanks. thanks for your work! I already committed this change to the debian packaging repository of clearsilver (svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/clearsilver). Currently Otavio Salvador is about to upload the new package. I am just the co-maintainer of the package without upload permissions. Hopefully the new package will be out soon ... Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519503: [apache2-mpm-itk] EncodingEngine (mod_encoding) does not work with ITK
Package: apache2-mpm-itk
Version: 2.2.6-02-1+b4
Severity: minor
--- Please enter the report below this line. ---
The setting "EncodingEngine on" of the apache2 module "encoding"
(libapache2-mod-encoding - package version 20040616-5) behaves differently in a
apache2-mpm-itk and a default apache2-mpm-worker server.
The following lines work in apache2-mpm-worker:
EncodingEngine on
NormalizeUsername on
The same lines result in the following error message in apache2-mpm-itk:
EncodingEngine not allowed here
Sadly there is no online documentation for the pretty simple (~500 lines of
code) encoding module.
Maybe the following lines of the mod_encoding.c file can help analyzing the
problem? (I have no experience with apache code - sorry!)
258 /**
259 * Handler for "SetServerEncoding" directive.
260 */
261 static const char *
262 set_server_encoding(cmd_parms *cmd, encoding_config *conf, char *arg) {
263
264 if (! cmd->path) {
265 conf = ap_get_module_config(cmd->server->module_config,
&encoding_module);
266 }
267 conf->server_encoding = apr_pstrdup(cmd->pool, arg);
268
269 return NULL;
270 }
I would be glad, if the encoding module could work with ITK as well - it is
very useful
for a WebDAV server.
Thanks for your time,
Lars
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.26-1-xen-amd64
signature.asc
Description: PGP signature
Bug#521368: [claws-mail-vcalendar-plugin] the problem exists for v3.7.1-1 as well
Package: claws-mail-vcalendar-plugin Version: 3.7.1-1 --- Please enter the report below this line. --- claws-mail v3.7.1-1 shows the same problem ... regards, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: squeeze/sid 500 unstablelocalhost --- Package information. --- Depends (Version) | Installed =-+-== libatk1.0-0 (>= 1.20.0) | 1.24.0-2 libc6(>= 2.3) | 2.9-6 libcairo2 (>= 1.2.4) | 1.8.6-2+b1 libcurl3-gnutls (>= 7.16.2-1) | 7.18.2-8.1 libfontconfig1 (>= 2.4.0) | 2.6.0-3 libfreetype6 (>= 2.3.5) | 2.3.9-4 libglib2.0-0 (>= 2.16.0) | 2.20.0-2 libgtk2.0-0 (>= 2.14.0) | 2.14.7-5 libpango1.0-0 (>= 1.22.0) | 1.22.4-3 zlib1g (>= 1:1.1.4) | 1:1.2.3.3.dfsg-13 claws-mail (>= 3.7.1) | 3.7.1-1 -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc signature.asc Description: PGP signature
Bug#521368: [claws-mail-vcalendar-plugin] backtrace with symbols
Package: claws-mail-vcalendar-plugin Version: 3.7.1-1 --- Please enter the report below this line. --- Hi, thanks for your hint regarding the plugin debug package! attached you find the backtrace ... thanks, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.26-1-686 Debian Release: squeeze/sid 500 unstablelocalhost --- Package information. --- Depends (Version) | Installed =-+-== libatk1.0-0 (>= 1.20.0) | 1.24.0-2 libc6(>= 2.3) | 2.9-6 libcairo2 (>= 1.2.4) | 1.8.6-2+b1 libcurl3-gnutls (>= 7.16.2-1) | 7.18.2-8.1 libfontconfig1 (>= 2.4.0) | 2.6.0-3 libfreetype6 (>= 2.3.5) | 2.3.9-4 libglib2.0-0 (>= 2.16.0) | 2.20.0-2 libgtk2.0-0 (>= 2.14.0) | 2.14.7-5 libpango1.0-0 (>= 1.22.0) | 1.22.4-3 zlib1g (>= 1:1.1.4) | 1:1.2.3.3.dfsg-13 claws-mail (>= 3.7.1) | 3.7.1-1 vcal_segfault_symbols.gdb Description: Binary data signature.asc Description: PGP signature
Bug#603640: [iceowl] Failed http-authentication causes a flood of requests
Package: iceowl Version: 1.0~b1+dfsg1-1 Severity: normal --- Please enter the report below this line. --- I noticed that the Iceowl calendar client has a problem with a 401 status code returned by a webserver when trying to read calendar data from a http(s) source. When using http-authentication and supplying a wrong password, the webserver returns 401. Iceowl continues to send (by default) four requests per seconds in order to get a valid result. Obviously it would be nicer to inform the user about the wrong password and stop sending more requests. Currently no warning is provided to the user. The number of requests per second can be changed with the "network.http.pipelining.maxrequests" setting (available in "Edit -> Preferences -> Advanced -> Config Editor"). But the resulting traffic is still considerably large and should be avoided. When using HTTPS the problem grows due to the SSL handshake and creates a significant load on the server. The connected server uses pound as an SSL proxy and apache2 as the backend webserver. I hope this information is sufficient. Thanks for your work, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.32-5-686 Debian Release: squeeze/sid 990 testing localhost --- Package information. --- Depends (Version) | Installed =-+-=== libasound2(>> 1.0.18) | 1.0.23-2.1 libatk1.0-0 (>= 1.29.3) | 1.30.0-1 libbonobo2-0 (>= 2.15.0) | 2.24.3-1 libc6(>= 2.7) | 2.11.2-7 libcairo2 (>= 1.2.4) | 1.8.10-6 libdbus-1-3(>= 1.0.2) | 1.2.24-3 libdbus-glib-1-2(>= 0.78) | 0.88-2 libfontconfig1 (>= 2.8.0) | 2.8.0-2.1 libfreetype6 (>= 2.2.1) | 2.4.2-1 libgcc1 (>= 1:4.1.1) | 1:4.4.5-6 libgconf2-4 (>= 2.27.0) | 2.28.1-5 libglib2.0-0 (>= 2.24.0) | 2.24.2-1 libgnome2-0 (>= 2.17.3) | 2.30.0-1 libgnomevfs2-0 (>= 1:2.17.90) | 1:2.24.3-1 libgtk2.0-0 (>= 2.18.0) | 2.20.1-2 libjpeg62(>= 6b1) | 6b1-1 libnspr4-0d (>= 1.8.0.10) | 4.8.6-1 libnss3-1d(>= 3.12.3) | 3.12.8-1 liborbit2 (>= 1:2.14.10) | 1:2.14.18-0.1 libpango1.0-0 (>= 1.14.0) | 1.28.3-1 libpopt0(>= 1.16) | 1.16-1 libsqlite3-0 (>= 3.7.0) | 3.7.3-1 libstdc++6 (>= 4.1.1) | 4.4.5-6 libx11-6 | 2:1.3.3-3 libxrender1 | 1:0.9.6-1 libxt6| 1:1.0.7-1 zlib1g (>= 1:1.1.4) | 1:1.2.3.4.dfsg-3 calendar-timezones (= 1.0~b1+dfsg1-1) | 1.0~b1+dfsg1-1 Recommends(Version) | Installed ===-+-=== calendar-google-provider| 1.0~b1+dfsg1-1 Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600779: ITP: wnpp -- PyCAM is a toolpath generator for 3-axis CNC machining
Package: wnpp Severity: wishlist Package name: wnpp Version: 0.4 Upstream Author: Lars Kruse URL: http://pycam.sf.net License: GPL v3 Description: toolpath generation for 3-axis CNC machining PyCAM generates toolpaths for 3-axis CNC machining. 3D STL files or 2D SVG/DXF files are processed into the common GCode that is used by machine controller software (e.g. EMC2). PyCAM is based on GTK and OpenGL. I am the main developer of PyCAM and intend to maintain the debian package. I will start to search for someone to sponsor the upload soon via the mentors list. regards, Lars -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609724: [trickle] Please supply a trickled init script
Package: trickle Version: 1.07-9 Severity: wishlist Tags: patch --- Please enter the report below this line. --- Hi, some users may consider it beneficial to have a prepared init script for running the trickle daemon on startup. Personally I would even like a ready-to-use init script to be installed by default, but currently there seem to exist two issues with the current trickle package blocking this approach: 1) trickled should not run as user root - thus a (currently non-existing) "trickled" user would be necessary. 2) trickle(d)'s default socket location is /tmp/.trickled.sock. This is (as far as I understand it) not in line with the debian policy. It should probably be placed below /var/run. Thus maybe it would be just as helpful to provide a sample init script for everyone who needs to run trickled permanently. Attached you find an init script and the accompanying /etc/default/trickle file that could be used together as a clean startup solution for trickled. I would really appreciate it, if the trickle package would supply these two files as examples in its doc directory. What do you think about it? thanks for your time, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.32-5-686 Debian Release: 6.0 990 testing localhost --- Package information. --- Depends (Version) | Installed =-+-=== libbsd0 (>= 0.0) | 0.2.0-1 libc6(>= 2.3) | 2.11.2-7 libevent-1.4-2 (>= 1.4.11-stable) | 1.4.13-stable-1 Package's Recommends field is empty. Package's Suggests field is empty. triggle-default Description: Binary data triggle-init Description: Binary data
Bug#589225: [sqwebmail] Nested multipart attachments are not displayed
Package: sqwebmail Version: 0.53.3-5 Severity: normal Tags: patch --- Please enter the report below this line. --- Hi, sqwebmail does not seem to display nested multipart attachments (RFC2046?). Only the outer multipart attachment is shown. Please take a look at the example file attached. It is taken directly from a Maildir directory (with all personal information stripped). The attachments show up fine in claws-mail. The attachments are not displayed with Squirrelmail v1.4.5. Applying a patch [1] to squirrelmail fixes this problem. The patch was included in Squirrelmail v1.4.20 (see svn r13873). Maybe this gives you a clue how to fix this in Sqwebmail as well? anyway: thanks for your work, Lars [1] http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/class/mime/Message.class.php?r1=13850&r2=13873&pathrev=13873 --- System information. --- Architecture: amd64 Kernel: Linux 2.6.26-2-xen-amd64 --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. 1279044756.29923.systemausfall.org,S=1024006:2,S Description: Binary data
Bug#562005: [alacarte] GUI behaviour of right item pane does not meet expectations
Package: alacarte Version: 0.12.4-1 Severity: normal Tags: patch --- Please enter the report below this line. --- Hi, naming conventions for the following description: - "item pane": right half of the window - "menu pane": left part of the window various GUI actions of alacarte don't work as expected: 1) drag and drop of an item from the item pane "into" a menu item of the item pane I expect the dragged item to be moved into the selected target menu, but the item just gets moved to the position after the target. The same operation works as expected, if the destination is on the "menu pane". 2) moving a separator item from the item pane "into" a menu item of the "menu pane" I expect, that this removes the dragged separator from the original menu and creates a new separator in the destination. The GUI feedback also indicates this: the separator disappears. But the separator is not moved at all: clicking on the original menu (for refresh) causes the separator to appear again. The destination menu does not contain a new separator. 3) dragging an item from the item pane to another position in the item pane (between two other items) This works as expected, if the destination is _above_ the current position of the dragged item. But if it is below, then the item gets moved one position further down, than expected. The attached patch fixes these three issues. I am not sure, if I handled the "undo" log properly, but the rest of the code should be fine. thanks for your work, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.30-2-686 Debian Release: squeeze/sid 990 testing localhost --- Package information. --- Depends (Version) | Installed ===-+-= python (>= 2.4) | 2.5.4-2 python-support (>= 0.90.0) | 1.0.6 python-gtk2 (>= 2.13.0) | 2.16.0-1 python-gmenu (>= 2.27.92) | 2.28.0.1-1 gnome-menus(>= 2.27.92) | 2.28.0.1-1 python-gobject (>= 2.15.1) | 2.20.0-1 Recommends (Version) | Installed ==-+-=== gnome-panel| 2.28.0-3 Package's Suggests field is empty. -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc diff -ruN Alacarte.orig/MainWindow.py Alacarte/MainWindow.py --- Alacarte.orig/MainWindow.py 2009-09-26 02:30:48.0 +0200 +++ Alacarte/MainWindow.py 2009-12-21 22:27:14.0 +0100 @@ -419,6 +419,8 @@ elif item.get_type() == gmenu.TYPE_DIRECTORY: if self.editor.moveMenu(item, new_parent) == False: self.loadUpdates() +elif item.get_type() == gmenu.TYPE_SEPARATOR: + self.editor.moveSeparator(item, new_parent) else: context.finish(False, False, etime) context.finish(True, True, etime) @@ -495,7 +497,9 @@ def on_item_tree_drag_data_received(self, treeview, context, x, y, selection, info, etime): items = treeview.get_model() - types = (gtk.TREE_VIEW_DROP_BEFORE, gtk.TREE_VIEW_DROP_INTO_OR_BEFORE) + types_before = (gtk.TREE_VIEW_DROP_BEFORE, gtk.TREE_VIEW_DROP_INTO_OR_BEFORE) + types_into = (gtk.TREE_VIEW_DROP_INTO_OR_BEFORE, gtk.TREE_VIEW_DROP_INTO_OR_AFTER) + types_after = (gtk.TREE_VIEW_DROP_AFTER, gtk.TREE_VIEW_DROP_INTO_OR_AFTER) if selection.target == 'ALACARTE_ITEM_ROW': drop_info = treeview.get_dest_row_at_pos(x, y) before = None @@ -503,22 +507,32 @@ if self.drag_data == None: return False item = self.drag_data + # by default we assume, that the items stays in the same menu + destination = item.get_parent() if drop_info: path, position = drop_info -if position in types: - before = items[path][3] +target = items[path][3] +# move the item to the directory, if the item was dropped into it +if (target.get_type() == gmenu.TYPE_DIRECTORY) and (position in types_into): + # append the selected item to the choosen menu + destination = target +elif position in types_before: + before = target +elif position in types_after: + after = target else: - after = items[path][3] + # this does not happen + pass else: path = (len(items) - 1,) after = items[path][3] if item.get_type() == gmenu.TYPE_ENTRY: -self.editor.moveItem(item, item.get_parent(), before, after) +self.editor.moveItem(item, destination, before, after) elif item.get_type() == gmenu.TYPE_DIRECTORY: -if self.editor.moveMenu(item, item.get_parent(), before, after) == False: +if self.editor.moveMenu(item, destination, before, after) == False: self.loadUpdates() elif item.get_type() == gmenu.TYPE_SEPARATOR: -self.editor.moveSeparator(item, item.get_parent(), before, after) +self.editor.moveSeparator(item, destination, before, after) context.finish(True, True, etime) elif selection.target == 'text/plain': if selection.data == None: diff -ruN Alacarte.orig/MenuEditor.py Alacarte/MenuEditor.py --- Alacarte.orig/MenuEditor.py
Bug#562013: [alacarte] erroneous selection handling below separator items
Package: alacarte Version: 0.12.4-1 Severity: normal Tags: patch --- Please enter the report below this line. --- Hi, the selection marker on the right pane of alacarte acts weirdly, if there is a separator item above. How to reproduce: 1) add a separator 2) select the next item below 3) click on the "move down" button on the right side The selected item moves as expected. But afterwards the previous item is selected (instead of the moved one). This does not happen in lists without a separator item. The attached patch fixes this issue. thanks for your work, Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.30-2-686 Debian Release: squeeze/sid 990 testing localhost --- Package information. --- Depends (Version) | Installed ===-+-= python (>= 2.4) | 2.5.4-2 python-support (>= 0.90.0) | 1.0.6 python-gtk2 (>= 2.13.0) | 2.16.0-1 python-gmenu (>= 2.27.92) | 2.28.0.1-1 gnome-menus(>= 2.27.92) | 2.28.0.1-1 python-gobject (>= 2.15.1) | 2.20.0-1 Recommends (Version) | Installed ==-+-=== gnome-panel| 2.28.0-3 Package's Suggests field is empty. -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc diff -ruN Alacarte.orig/MainWindow.py Alacarte/MainWindow.py --- Alacarte.orig/MainWindow.py 2009-12-21 22:59:55.0 +0100 +++ Alacarte/MainWindow.py 2009-12-22 00:02:32.0 +0100 @@ -128,6 +128,8 @@ found = True if item[3].get_type() == gmenu.TYPE_SEPARATOR: if not isinstance(item_id, tuple): + #we may not skip the increment via "continue" + i += 1 continue #separators have no id, have to find them manually #probably won't work with two separators together signature.asc Description: PGP signature
Bug#490338: [alacarte] alacarte uses a menu_id, which is not unique
Package: alacarte
Version: 0.12.4-1
--- Please enter the report below this line. ---
Hi,
alacarte currently uses a non-unique menu_id, when adding new items (or menus).
This causes any new item will be placed under the first menu with a matching id
(usually under the debian menu tree).
E.g. the menu id "graphics" is available as a top-level menu (visible in
the application menu) and as a lower-level menu (below the debian tree).
The attached patch fixes this by using the specific destination menu object
instead of its id.
The following bugs seem to be duplicates of this one and should be merged (I
don't know how to do it):
- #444317
- #461318
thanks for your work,
Lars
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.30-2-686
Debian Release: squeeze/sid
990 testing localhost
--- Package information. ---
Depends (Version) | Installed
===-+-=
python (>= 2.4) | 2.5.4-2
python-support (>= 0.90.0) | 1.0.6
python-gtk2 (>= 2.13.0) | 2.16.0-1
python-gmenu (>= 2.27.92) | 2.28.0.1-1
gnome-menus(>= 2.27.92) | 2.28.0.1-1
python-gobject (>= 2.15.1) | 2.20.0-1
Recommends (Version) | Installed
==-+-===
gnome-panel| 2.28.0-3
Package's Suggests field is empty.
--
gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc
diff -ruN Alacarte.orig/MainWindow.py Alacarte/MainWindow.py
--- Alacarte.orig/MainWindow.py 2009-12-21 22:59:55.0 +0100
+++ Alacarte/MainWindow.py 2009-12-22 14:44:01.0 +0100
@@ -260,21 +260,21 @@
#this is a little timeout callback to insert new items after
#gnome-desktop-item-edit has finished running
- def waitForNewItemProcess(self, process, parent_id, file_path):
+ def waitForNewItemProcess(self, process, parent, file_path):
if process.poll() != None:
if os.path.isfile(file_path):
-self.editor.insertExternalItem(os.path.split(file_path)[1], parent_id)
+self.editor.insertExternalItem(os.path.split(file_path)[1], parent)
return False
return True
- def waitForNewMenuProcess(self, process, parent_id, file_path):
+ def waitForNewMenuProcess(self, process, parent, file_path):
if process.poll() != None:
#hack for broken gnome-desktop-item-edit
broken_path = os.path.join(os.path.split(file_path)[0], '.directory')
if os.path.isfile(broken_path):
os.rename(broken_path, file_path)
if os.path.isfile(file_path):
-self.editor.insertExternalMenu(os.path.split(file_path)[1], parent_id)
+self.editor.insertExternalMenu(os.path.split(file_path)[1], parent)
return False
return True
@@ -296,7 +296,7 @@
parent = menus[iter][2]
file_path = os.path.join(util.getUserDirectoryPath(), util.getUniqueFileId('alacarte-made', '.directory'))
process = subprocess.Popen(['gnome-desktop-item-edit', file_path], env=os.environ)
- gobject.timeout_add(100, self.waitForNewMenuProcess, process, parent.menu_id, file_path)
+ gobject.timeout_add(100, self.waitForNewMenuProcess, process, parent, file_path)
def on_new_item_button_clicked(self, button):
menu_tree = self.tree.get_object('menu_tree')
@@ -309,7 +309,7 @@
parent = menus[iter][2]
file_path = os.path.join(util.getUserItemPath(), util.getUniqueFileId('alacarte-made', '.desktop'))
process = subprocess.Popen(['gnome-desktop-item-edit', file_path], env=os.environ)
- gobject.timeout_add(100, self.waitForNewItemProcess, process, parent.menu_id, file_path)
+ gobject.timeout_add(100, self.waitForNewItemProcess, process, parent, file_path)
def on_new_separator_button_clicked(self, button):
item_tree = self.tree.get_object('item_tree')
diff -ruN Alacarte.orig/MenuEditor.py Alacarte/MenuEditor.py
--- Alacarte.orig/MenuEditor.py 2009-12-21 22:59:55.0 +0100
+++ Alacarte/MenuEditor.py 2009-12-22 14:43:27.0 +0100
@@ -222,10 +222,9 @@
def createItem(self, parent, icon, name, comment, command, use_term, before=None, after=None):
file_id = self.__writeItem(None, icon, name, comment, command, use_term)
- self.insertExternalItem(file_id, parent.menu_id, before, after)
+ self.insertExternalItem(file_id, parent, before, after)
- def insertExternalItem(self, file_id, parent_id, before=None, after=None):
- parent = self.__findMenu(parent_id)
+ def insertExternalItem(self, file_id, parent, before=None, after=None):
dom = self.__getMenu(parent).dom
self.__addItem(parent, file_id, dom)
self.__positionItem(parent, ('Item', file_id), before, after)
@@ -234,11 +233,10 @@
def createMenu(self, parent, icon, name, comment, before=None, after=None):
file_id = self.__writeMenu(None, icon, name, comment)
- self.insertExternalMenu(file_id, parent.menu_id, before, after)
+ self.insertExternalMenu(file_id, parent, before, after)
- def insertExternalMenu(self, file_id, parent_id, before=None, after=None):
+ def insertExternalMenu(self, file_id, par
Bug#554591: [reportbug-ng] wrong variable was searched for supported MUAs
Package: reportbug-ng
Version: 1.11
--- Please enter the report below this line. ---
Hi,
currently reportbug-ng looks at the wrong place for supported MUAs when
checking a changed MUA setting.
Thus any changes to the "Mail Client" setting in the settings dialog are
ignored.
The attached patch fixes this problem.
thanks for your work,
Lars
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.30-2-686
Debian Release: squeeze/sid
990 testing localhost
--- Package information. ---
Depends(Version) | Installed
-+-
python | 2.5.4-2
python-support (>= 0.90.0) | 1.0.6
python2.5| 2.5.4-3
python-debianbts(>= 1.0) | 1.3
python-qt4 | 4.6-1
xdg-utils| 1.0.2-6.1
xterm| 251-1
python-apt | 0.7.13.3
Package's Recommends field is empty.
Package's Suggests field is empty.
--
gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc
diff -ruN reportbug-ng.orig/rngsettingsdialog.py reportbug-ng/rngsettingsdialog.py
--- reportbug-ng.orig/rngsettingsdialog.py 2009-10-25 18:21:49.0 +0100
+++ reportbug-ng/rngsettingsdialog.py 2009-12-22 16:17:26.0 +0100
@@ -22,7 +22,7 @@
from ui import settings
import rnghelpers as rng
-from rnghelpers import Settings
+from rnghelpers import Settings, getMUAString
class RngSettingsDialog(QtGui.QDialog, settings.Ui_Dialog):
@@ -137,8 +137,8 @@
mua = unicode(self.comboBox_mua.currentText())
# translate back
found = False
-for mua_orig, mua_transl in rng.MUA_STRINGS.iteritems():
-if mua_transl == mua:
+for mua_orig in rng.MUA_SYNTAX.keys():
+if getMUAString(mua_orig) == mua:
self.settings.lastmua = mua_orig
found = True
self.logger.debug("Found match for MUA: %s %s" % (mua, mua_orig))
signature.asc
Description: PGP signature
Bug#545374: [alacarte] whitespace patch attached
Package: alacarte
Version: 0.12.4-1
--- Please enter the report below this line. ---
Hi,
the previously mentioned tab/space issue is not present in MainWindow.py
anymore.
But the attached patch fixes another space/tab issue in MenuEditor.py and
additionally removes some trailing whitespaces.
The bug can be closed anyway.
thanks,
Lars
--- System information. ---
Architecture: i386
Kernel: Linux 2.6.30-2-686
Debian Release: squeeze/sid
990 testing localhost
--- Package information. ---
Depends (Version) | Installed
===-+-=
python (>= 2.4) | 2.5.4-2
python-support (>= 0.90.0) | 1.0.6
python-gtk2 (>= 2.13.0) | 2.16.0-1
python-gmenu (>= 2.27.92) | 2.28.0.1-1
gnome-menus(>= 2.27.92) | 2.28.0.1-1
python-gobject (>= 2.15.1) | 2.20.0-1
Recommends (Version) | Installed
==-+-===
gnome-panel| 2.28.0-3
Package's Suggests field is empty.
--
gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc
diff -ruN Alacarte.orig/MenuEditor.py Alacarte/MenuEditor.py
--- Alacarte.orig/MenuEditor.py 2009-12-21 22:59:55.0 +0100
+++ Alacarte/MenuEditor.py 2009-12-22 16:47:32.0 +0100
@@ -48,16 +48,16 @@
self.applications.dom = xml.dom.minidom.parse(self.applications.path)
self.__remove_whilespace_nodes(self.applications.dom)
- self.settings = Menu()
+ self.settings = Menu()
self.settings.tree = gmenu.lookup_tree('settings.menu', gmenu.FLAGS_SHOW_EMPTY|gmenu.FLAGS_INCLUDE_EXCLUDED|gmenu.FLAGS_INCLUDE_NODISPLAY|gmenu.FLAGS_SHOW_ALL_SEPARATORS)
- self.settings.visible_tree = gmenu.lookup_tree('settings.menu')
+ self.settings.visible_tree = gmenu.lookup_tree('settings.menu')
self.settings.tree.sort_key = gmenu.SORT_DISPLAY_NAME
self.settings.visible_tree.sort_key = gmenu.SORT_DISPLAY_NAME
- self.settings.path = os.path.join(util.getUserMenuPath(), self.settings.tree.get_menu_file())
- if not os.path.isfile(self.settings.path):
- self.settings.dom = xml.dom.minidom.parseString(util.getUserMenuXml(self.settings.tree))
- else:
- self.settings.dom = xml.dom.minidom.parse(self.settings.path)
+ self.settings.path = os.path.join(util.getUserMenuPath(), self.settings.tree.get_menu_file())
+ if not os.path.isfile(self.settings.path):
+ self.settings.dom = xml.dom.minidom.parseString(util.getUserMenuXml(self.settings.tree))
+ else:
+ self.settings.dom = xml.dom.minidom.parse(self.settings.path)
self.__remove_whilespace_nodes(self.settings.dom)
self.save(True)
@@ -478,7 +478,7 @@
def __getPath(self, menu, path=None):
if not path:
-path = menu.tree.root.get_menu_id()
+ path = menu.tree.root.get_menu_id()
if menu.get_parent():
path = self.__getPath(menu.get_parent(), path)
path += '/'
signature.asc
Description: PGP signature
Bug#562187: [hamster-applet] applet window is too wide for screen
Package: hamster-applet Version: 2.28.1-1 Severity: normal --- Please enter the report below this line. --- Hi, first of all: the hamster-applet is great! Thanks for your work! The latest version of hamster creates a much wider window when clicking on the applet. Especially for the german translation e.g. in the ClearCase gnome theme the window is wider than my 1024x768 screen. Hamster is only usable for me, if I move it far to the left side of the gnome-panel (the window pops up left aligned to the applet position). The problem is reduced, when I limit the text length of the description label in that window (allowing the line to wrap). But the input field for the current activity is still too wide for my screen. Sadly I don't know enough about GTK to fix this. (the applet window layout is defined in /usr/share/hamster-applet/applet.ui) An horizontally smaller window would be a real usability improvement! Attached you find a screenshot of the window layout on my screen. thanks for your work! Lars --- System information. --- Architecture: i386 Kernel: Linux 2.6.30-2-686 Debian Release: squeeze/sid 990 testing localhost --- Package information. --- Depends(Version) | Installed -+-== libatk1.0-0 (>= 1.20.0) | 1.28.0-1 libc6 (>= 2.1.3) | 2.10.2-2 libcairo2 (>= 1.2.4) | 1.8.8-2 libfontconfig1(>= 2.4.0) | 2.6.0-4.2 libfreetype6 (>= 2.2.1) | 2.3.11-1 libglib2.0-0 (>= 2.16.0) | 2.22.3-1 libgtk2.0-0 (>= 2.18.0) | 2.18.3-1 libpango1.0-0(>= 1.14.0) | 1.26.1-1 gconf2 (>= 2.10.1-2) | 2.28.0-1 python (<< 2.6) | 2.5.4-2 python (>= 2.5) | 2.5.4-2 python-support (>= 0.90.0) | 1.0.6 python-cairo | 1.8.6-1 python-gtk2 (>= 2.12.0) | 2.16.0-1 python-gconf | 2.28.0-1 python-gnomeapplet (>= 2.10.0) | 2.28.0-5 python-evolution (>= 2.10.0) | 2.28.0-5 python-dbus | 0.83.0-1 python-gobject (>= 2.14.0) | 2.20.0-1 python-gnome2| 2.28.0-1 Recommends (Version) | Installed -+-=== python-notify| 0.1.1-2+b1 Package's Suggests field is empty. -- gpg key: https://systemausfall.org/schluessel/lars-devel.0.asc <> signature.asc Description: PGP signature
Bug#921229: the df* plugins don't respect [df*] anymore
Hello Mattia,
thank you for your report!
Could it be, that your plugin configuration files contain a section "df"?
In this case the more specific section ("df") would take precedence over the
wildcard section ("df*").
Or maybe another theory: the wildcards are currently applied a bit loosely:
https://github.com/munin-monitoring/munin/issues/1158
Maybe this could be related?
Cheers,
Lars
Bug#915013: wheel autopkg tests fail (command1 and command2)
Hello Andreas, Am Thu, 7 Feb 2019 22:36:49 +0100 schrieb Andreas Tille : > I admit I have no idea what file "tests is seeked in > >ERROR: file not found: tests > > Any idea how to fix this? the two failed commands in the autopkgtest suite are "command1" and "command2". These are the "unnamed" commands in debian/tests/control. The "named" ones use the "Test:" directive (referring to test script of that name). The "unnamed" ones use "Test-Command:" referring to a command. These are: Test-Command: python2 -m pytest --ignore=debian and Test-Command: python3 -m pytest --ignore=debian When executing this command, the setup.cfg seems to be parsed. There you find: [tool:pytest] addopts = --cov=wheel testpaths = tests Thus the missing "tests" seems to be the "testpaths" value specified above. Maybe upstream moved that directory somewhere else or removed it completely? Cheers, Lars
Bug#921985: munin-node: df plugin fails to get data for /home
Control: merge -1 918851 Hello Marc, Am Sun, 10 Feb 2019 22:55:45 +0100 schrieb Marc Donges : > # Plugins like "df" require access to /home if that is a separate filesystem > ProtectHome=false Indeed, this setting prevents your use case. See the other bug report for this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918851 We are discussing whether there is good way to work around this. Cheers, Lars
Bug#921985: munin-node: df plugin fails to get data for /home
Hello, Am Sat, 16 Feb 2019 16:33:53 +0100 schrieb Marc Donges : > I think to make this less awkward two things would be nice: > > - a option to allow monitoring of /home without editing a non-conffile in > /lib (How is this even done properly? I just edited the service file to > find the cause of my problem, but I suppose it will be overwritten on every > update. Is there a nice way to do this?) By accident I stumbled upon "systemctl edit munin-node". This will open up an empty editor. Here you can add the following: [Service] ProtectHome = read-only This will create a file /etc/systemd/system/munin-node.service.d/override.conf with the above content and in turn override the settings of the system-wide service file. > - a way to alert the admin of the possibly unintended configuration: > df-plugin activated + ProtectHome + Separate /home > Can the df* plugin itself detect the situation and then make a log entry? > That would have severely cut down the time it took me to find this. I took a quick look at it. Here the plugin within the environment simply does not notice that /home is not accessible: it will simply be missing in the output by "df -h". Thus we cannot emit a warning in this case. Or does someone have an idea how to identify such an issue? (and how we should report it) Given that the "ProtectHome" setting allows the "read-only" value, I propose that we should pick this one instead of "yes". I think, we are mainly trying to protect the user from badly written plugins that mess up something with their cleanup procedure and accidentally erase relevant files. "read-only" would prevent this problem. The different problem of munin plugins spying on users on purpose would indeed justify "yes". But I tend to think, that everything is lost anyway, if a user runs random malicious code on his host. What do you think? Cheers, Lars
Bug#905457: munin: general protection fault
Package: munin Followup-For: Bug #905457 Hello Bertrand, On Sat, 04 Aug 2018 22:35:54 +0200, BERTRAND Joël wrote, > I don't understand why perl tries to run /usr/sbin/munin, there is no > such script nor executable. indeed there is no such file shipped in any munin package. I just tried to reproduce this issue on a fresh and up-to-date buster system. But I failed to find this log message here on my host. I could only imagine the following two sources of this log messages (both of which feel equally unlikely): 1) a locally installed munin plugin 2) a cron-job that is not related to the packaged "munin-cron" For 1) you could take a look at /etc/munin/plugins/ and check for non-packaged plugins. For 2) you could temporarily disable the "munin-cron" cron job and check whether the mysterious log message still appears. Or maybe you have a different idea how to trace the origin of this message? Cheers, Lars
Bug#905457: munin: general protection fault
Hello Bertrand, Am Sun, 5 Aug 2018 10:01:58 +0200 schrieb BERTRAND Joël : > Yesterday, after my bug report, I have done a apt dist-upgrade and this > message disappears. Very strange, perl and munin were not upgraded. What a pity - this issue looked mysteriously interesting :) I fail to have an idea, which kind of magic could have pushed this error message line to your log. Let's agree on closing this bug as "unreproducible" and hoping for the monster to never return again? Cheers, Lars
Bug#895868: munin-cron: Fontconfig error: failed reading config file
Source: munin Followup-For: Bug #895868 Hello, I took a look at the bugs reported for fontconfig [1]. I did not find a description of this problem. Maybe someone could report it there? Since munin is likely only affected indirectly by this problem, we should probably solve it in fontconfig, instead of here. Or is this only a local customization / configuration issue? Cheers, Lars [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=fontconfig;dist=unstable
Bug#901729: mysql_innodb: Unusable after upgrade from Jessie to Stretch
Package: munin-plugins-core Version: 2.0.37-2 Followup-For: Bug #901729 Hello Christian, thank you for preparing the patch! I just pushed a commit [1] fixing this issue (based on your patch) to upstream. Thus it will be part of the release (2.0.38) of munin. Cheers, Lars [1] https://github.com/munin-monitoring/munin/commit/455ba7e0f7887be8a449e3b72dfe6bcf0aacf9bd
Bug#772277: munin-async: bashism in /bin/sh script
Package: munin-async Followup-For: Bug #772277 Hi, checkbashism seems to be wrong here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843913 See the source of "sleep": ~# type sleep sleep is hashed (/bin/sleep) Let us wait, until the check in checkbashism is fixed. Cheers, Lars
Bug#767018: munin-plugins-extra: iostat_ios plugin should support configuration
Package: munin-plugins-extra Followup-For: Bug #767018 Hello, munin support vd* device names since v2.0.25. The wrong LVM major block device number is fixed upstream (to be released with v2.0.38). Cheers, Lars
Bug#863231: [Packaging] Bug#863231: munin-plugins-core: apt_all uses different statefiles for reading and writing
Hi, Am Wed, 24 May 2017 09:40:49 + schrieb Holger Levsen : > > Adding the following to /etc/munin/plugin-config.d/munin-node fixed it > > for me: > > > > [apt_all] > > user root > > env.MUNIN_PLUGSTATE /var/lib/munin-node/plugin-state/nobody/ > > > > I'm not sure if that's the correct fix, though. > > seems correct to me… I just checked here, whether it would be sufficient to simply run the cron-job as "nobody" (instead of root). This works for me. This would be preferable (compared to the change above), or? Or maybe I overlooked something? Cheers, Lars
Bug#863231: [Packaging] Bug#863231: munin-plugins-core: apt_all uses different statefiles for reading and writing
Hi, Am Sat, 23 Jun 2018 01:03:44 +0200 schrieb Lars Kruse : > I just checked here, whether it would be sufficient to simply run the cron-job > as "nobody" (instead of root). This works for me. > This would be preferable (compared to the change above), or? > Or maybe I overlooked something? indeed I overlooked something :( The random nature of the "update" action was hiding/postponing the following error messages: W: chmod 0700 of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (1: Operation not permitted) E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) E: Unable to lock directory /var/lib/apt/lists/ W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied) W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied) Running the plugin as root would obviously solve this. But it also leads to issues like #849548 [1]. Let's give the issue another few weeks of time - maybe I will come up with a rewrite of the apt_all plugin. Otherwise we will run apt_all as root (as suggested above). Cheers, Lars [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849548
Bug#767102: munin-plugins-core: df* plugins report warnings for special filesystems on kFreeBSD
Hi, Am Tue, 28 Oct 2014 21:28:51 +0800 schrieb Paul Wise : > [..] > The fix appears to involve figuring out why munin does not use the > freebsd plugins on kFreeBSD, currently the "munin-plugins-core" package has "Architecture: all". We could change this to "hurd-any linux-any kfreebsd-any". > teaching the freebsd plugins about GNU coreutils df > and adding sysfs to ignored filesystem types. I just finished both in upstream. Cheers, Lars
Bug#732149: munin outputs malformed XHTML
Hi, Am Sat, 14 Dec 2013 20:12:03 +0100 schrieb "Marc A. Donges" : > munin’s XHTML output is malformed XML in several places. All relevant occurrences should be fixed now in upstream (to be relased as 2.0.38). Cheers, Lars
Bug#675318: munin-node: postfix_mailstats incorrect delivered message count
Package: munin-plugins-core Version: 2.0.37-2 Followup-For: Bug #675318 Hi, the issue is fixed upstream and will be part of the upcoming releases 2.0.38 and 2.999.9. Cheers, Lars
Bug#839233: munin: race condition when building plugins sometimes resulting in wrong plugin shipped
Hello, Am Fri, 30 Sep 2016 14:55:26 +0200 schrieb Holger Levsen : > from IRC: > > | > https://tests.reproducible-builds.org/debian/rb-pkg/experimental/armhf/diffoscope-results/munin.html > - fascinating. also how this cannot be seen on i386?!? > < ntyni> | race between ./plugins/node.d.linux/netstat.in and > ./plugins/node.d/netstat.in ? > | and "diff ./plugins/node.d.linux/netstat.in > ./plugins/node.d/netstat.in" confirms > > the HTML diffoscope output is attached, the txt output can be seen > at > https://tests.reproducible-builds.org/debian/dbdtxt/experimental/armhf/munin_2.999.3-1.diffoscope.txt > > So as a result, the shipped /usr/shar/munin/plugins/netstat sometimes is > the one from ./plugins/node.d and sometimes it's the one from > ./plugins/node.d.linux ! (Filing this bug only with severity "important" > as it just seems to affect one plugin…) what a mysterious behaviour! I went through the Makefile and failed to find an obvious source of the problem. Thus I started to look for the "barely imaginable" places and found the following ones: 1) The plugins are "compiled" individually by a perl script filter. There is a strict one-to-one mapping from input filenames to output filenames. Thus ordering cannot be an issue here. It _could_ be, that the filtering did not transfer all files (e.g. because the output of "find" was truncated). But this could not have happened without an error from "make". 2) The "OSTYPE" is determined (see debian/ostype_helper) by comparing the output of "uname" with "Linux" and "GNU/kFreeBSD". If there is no match (or "uname" fails silently - why should it?), the "OSTYPE" variable would end up empty. This could be an explanation for the generic plugin being installed instead of the linux-specific one. I added "set -e" to the "ostype_helper" script. In case this problem ever comes back again, we would know, that "ostype_helper" did not cause it. 3) The "compiled" files are copied within the following for loop: for p in build/plugins/node.d/* build/plugins/node.d.$(OSTYPE)/* ; do As far as I understand shell substitution (here: pathname expansion), the two tokens above are evaluated and substituted separately. Thus the resulting items are in proper order (first generic, second OS specific). This loop cannot be shorted, as far as I can tell. Thus it is hard to imagine, that the error happens here. Do you have any ideas? Should we just wait for the next reproducibility error? Cheers, Lars
Bug#698302: munin_stats: wrong values for munin graph
Hi Uwe, I assume, that this issue was caused by "munin_stats" ignoring that cgi-based graph generation was configured? In this case it was fixed in v2.0.27-1. Or what do you think? Cheers, Lars
Bug#806174: apt: uninitialised value MUNIN_PLUGSTATE
Hello Martin,
Am Wed, 25 Nov 2015 14:33:04 +1300
schrieb martin f krafft :
> Package: munin-plugins-extra
> Version: 2.0.25-2
> Severity: minor
> File: /usr/share/munin/plugins/apt
>
> I am seeing this on all hosts running the apt plugin:
>
> Use of uninitialized value $ENV{"MUNIN_PLUGSTATE"} in concatenation (.) or
> string at
> /etc/munin/plugins/apt line 78.
it looks to me as if this issue was fixed before (in v2.0.12) by the following
commit of upstream:
https://github.com/munin-monitoring/munin/commit/2b82c38fec32ba09de7a0d83996e54f07543513c
Do you have an idea, why it failed for you?
Does the problem still exist?
Cheers,
Lars
Bug#895868: closed by Lars Kruse (Re: munin-cron: Fontconfig error: failed reading config file)
Hi Calum,
thank you for reporting your state of the things so quickly!
Am Sat, 23 Jun 2018 23:45:40 +0100
schrieb Calum Mackay :
> > This is probably
> > https://bugs.debian.org/853848https://bugs.debian.org/853848, fixed by
> > upgrading/removing:
> > fonts-beng-extra
> > fonts-deva-extra
> > fonts-gujr-extra
> > fonts-guru-extra
> > fonts-orya-extra, fixed by upgrading/removing: Debian bug 853848 was
> > fixed a year ago, so upgrading won't help this issue.
>
> I purged those pkgs, and the problem remained. The pkg removal resulted in
> various leftovers (with errors), despite --purge:
>
> /etc/fonts/conf.avail/65-0-fonts-guru-extra.conf
> [..]
I took a deeper look at the bug report #853848.
It describes that the error happens during package installation (wrong path
being used in a postinst script).
Thus the package maintainer took the shortcut of fixing the cause ("do not
create the unwanted directory anymore"), but he did not revert the caused damage
("remove the unwanted directory if it is there"):
https://salsa.debian.org/fonts-team/fonts-deva-extra/commit/77b9d92033842893f160d50fb7d67a6edee70911
This is not really great, since it leaves the burden of cleaning up on the
local administrator.
But we are on testing - /things/ may happen :(
The following workaround should clean up the situation for most installations:
find /etc/fonts/conf.avail/ -type d -empty -delete
I have the feeling, that this bug (for the munin package) can remain closed.
And we just hope that all affected users (of these fonts or munin itself) find
this information here helpful for cleaning the situation up manually.
Or how would you think, we should proceed?
Cheers,
Lars
Bug#895868: closed by Lars Kruse
Hello Calum, Am Sun, 24 Jun 2018 22:51:09 +0100 schrieb Calum Mackay : > > The following workaround should clean up the situation for most > > installations: > >find /etc/fonts/conf.avail/ -type d -empty -delete > > interestingly, that finds one remaining entry for me, although I am no longer > seeing the munin-tickled fontconfig errors: > $ find /etc/fonts/conf.avail/ -type d -empty > /etc/fonts/conf.avail/65-0-fonts-smc.conf > should I remove this dir (and/or pkg) too, perhaps? I am not sure, what exactly causes the error messages of fontconfig - maybe it is not even a good idea to be that sensitive regarding files below /etc. But since directories (not files!) with that name are certainly created by mistake, it should be safe to remove them. > > I have the feeling, that this bug (for the munin package) can remain closed. > > And we just hope that all affected users (of these fonts or munin itself) > > find > > this information here helpful for cleaning the situation up manually. > > Yes, definitely so, that was partly the reason I added details of how I > resolved it for my system. Good to hear! Cheers, Lars
Bug#902730: ITP: sharness -- Sharness is a portable shell library to write, run, and analyze automated tests for Unix programs. Since all tests output TAP, the Test Anything Protocol, they can be run
Package: wnpp Severity: wishlist Owner: Lars Kruse * Package name: sharness Version : 1.0.0 Upstream Author : Christian Couder * URL : https://github.com/chriscool/sharness * License : GPL2+ Programming Lang: Shell Description : Sharness is a portable shell library to write, run, and analyze automated tests for Unix programs. Since all tests output TAP, the Test Anything Protocol, they can be run with any TAP harness (e.g. "prove"). Each test is written as a shell script, for example: test_expect_success "Success is reported like this" " echo hello world | grep hello " test_expect_failure "We expect this to fail" " test 1 = 2 " Sharness is used by a few Debian packages as part of their DEP8 tests (via autopkgtest): * gearmand * git-reintegrate * git-remote-bzr * git-remote-hg * hiera-eyaml * jemalloc * mod-gearman * munin * pass-otp * puppet-lint * puppet-module-puppetlabs-concat * puppet-module-puppetlabs-ntp * puppet-module-puppetlabs-stdlib (the list was assembled via https://codesearch.debian.net) Currently these packages embed a copy of the sharness.sh file below debian/tests. I will file bug reports against these packages (including patches) after the sharness package is available, in order to help them getting rid of their embedded code copies. I am part of the munin packaging team, thus the munin package would benefit immediately from this package. I plan to maintain the sharness package for the foreseeable future. I will need a sponsor for uploading this package. Cheers, Lars
Bug#660903: munin: Issue was fixed in v2.0.7
Package: munin Followup-For: Bug #660903 Dear Maintainer, this issue was fixed in munin v2.07 (see commit c6262ac93b): * http://munin-monitoring.org/ticket/1276 Cheers, Lars
Bug#910684: Reopen Bug#910684: fixed in munin 2.0.42-2
Hello, Am Fri, 19 Oct 2018 18:40:04 + schrieb Holger Levsen : > > # failed 1 among 1 test(s) > > 1..1 > > Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/1 subtests > > I don't understand this output and thus I dont find it helpful at all. Indeed: the sharness testing tool does not offer a more readable output for such tests at the moment. I just filed an issue / offer for improvement: https://github.com/chriscool/sharness/issues/85 For now I will add a bit more output to this munin packaging test in order to better understand the problem when looking into the build logs. (to be done in the next days if no one jumps in before and goes for another route) Cheers, Lars
Bug#911656: munin-plugins-core: postgres_x_ALL plugins produce 'FATAL: database "munin" does not exist' errors
Hello Vincas, thank you for your bug report! Could you please check whether reverting the changes introduced with https://github.com/munin-monitoring/munin/commit/d7e138176e9a09b883031544e523e33e5ef9238b would fix this issue for you? Cheers, Lars
Bug#921985: munin-node: df plugin fails to get data for /home
Hello, Am Wed, 20 Feb 2019 16:05:11 +0100 schrieb Steve Schnepp : > I might be naive, but I'm wondering if some debconf dialog to choose at > install time might be an option. Sounds like a good idea to me. So we have the following options: A) mention in README.Debian B) mention in NEWS C) ask via debconf whether a systemd override should be created Personally I would pick A + C. What do you think? Cheers, Lars
Bug#715141: apt_all update cronjob creates error mails when testing and unstable are not in the apt sources
Hello, Am Wed, 20 Feb 2019 13:33:34 + schrieb Holger Levsen : > strangely this commit is in Buster: > > ~/Projects/munin/munin$ git tag --contains 44604624b1c27f6 > 2.0.44 > 2.0.45 > debian/2.0.44-1 > debian/2.0.44-1_bpo9+1 > debian/2.0.44-2 > debian/2.0.45-1 > debian/2.0.45-1_bpo9+1 > > Lars, any idea? indeed I am quite confident that the issue should be fixed. I just forgot to close this bug report. Thanks for the reminder, Jan! @Jan: could you please verify that the issue is fixed for you? At least the error output of David's initial bug report should be impossible, unless your plugin is somehow older or you have another plugin configuration file hiding somewhere below /etc/munin. Cheers, Lars
Bug#923563: freeciv-client-sdl: Fails to start: missing themes/gui-sdl2/human/DejaVuSans.ttf
Package: freeciv-client-sdl Version: 2.6.0-1 Severity: important Dear Maintainer, I tried to run freeciv-sdl2, but sadly it failed with the following output: $ LANG= freeciv-sdl2 2: Didn't find the option file. Creating a new one. 2: Migrating options from sdl to sdl2 client 2: Using Video Output: x11 0: Could not open font: themes/gui-sdl2/human/DejaVuSans.ttf 0: No usable default theme found, aborting! The directory /usr/share/games/freeciv/themes/gui-sdl2/human/ does not contain the font file mentioned above. Thank you for your time! Cheers, Lars -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.19.0-2-686-pae (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages freeciv-client-sdl depends on: ii fonts-arphic-uming0.2.20080216.2-10 ii fonts-dejavu-core 2.37-1 ii fonts-ipafont-gothic 00303-18 ii fonts-unfonts-core1:1.0.2-080608-16 ii freeciv-data 2.6.0-1 ii libbz2-1.01.0.6-9 ii libc6 2.28-7 ii libcurl3-gnutls 7.64.0-1 ii liblzma5 5.2.4-1 ii libsdl2-2.0-0 2.0.9+dfsg1-1 ii libsdl2-gfx-1.0-0 1.0.4+dfsg-3 ii libsdl2-image-2.0-0 2.0.4+dfsg1-1 ii libsdl2-mixer-2.0-0 2.0.4+dfsg1-1 ii libsdl2-ttf-2.0-0 2.0.15+dfsg1-1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages freeciv-client-sdl recommends: ii freeciv-server 2.6.0-1 Versions of packages freeciv-client-sdl suggests: ii freeciv-client-extras 2.6.0-1 ii freeciv-sound-standard 2.6.0-1 -- no debconf information
Bug#926431: cifs-utils: Password containing special character "$" (dollar) only works with prepended backslash
Package: cifs-utils
Version: 2:6.8-2
Severity: normal
Dear Maintainer,
recently I changed my LDAP password to a new one, that contains a "$" character.
Afterwards I failed to mount shares with this new password.
I tried the following approaches:
* interactive mount (e.g. "mount -t cifs -o user=foo //example/share /mnt")
* credential file
(e.g. "mount -t cifs -o user=foo,credentials=bar //example/share /mnt")
* indirect mount via "pam_mount"
In the first two cases I succeed to mount the share, if I prepend the
special character ("$") with a backslash. Thus "pass\$word" works, while
the real password is "pass$word".
The last case ("pam_mount") was obviously impossible to test this way.
I observed the same behaviour with a client on jessie (2:6.4-1) and on
stretch (2:6.7-1).
Thank you for your time!
Cheers,
Lars
PS: this issue does not seem to be related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775051
(I failed to reproduce its problem on my hosts)
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.19.0-3-686-pae (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages cifs-utils depends on:
ii libc6 2.28-8
ii libcap-ng00.7.9-2
ii libkeyutils1 1.6-6
ii libkrb5-3 1.17-2
ii libpam0g 1.3.1-5
ii libtalloc22.1.14-2
ii libwbclient0 2:4.9.5+dfsg-2
cifs-utils recommends no packages.
Versions of packages cifs-utils suggests:
ii keyutils 1.6-6
pn smbclient
pn winbind
-- no debconf information
Bug#926533: linux-image-armmp-lpae: Fail to mount cryptsetup device: missing aes-xts-plain64 cipher
Package: linux-image-armmp-lpae Version: 4.19+104 Severity: normal Dear Maintainer, after upgrading from 4.9.144-3 to 4.19+104 I am not able to mount cryptsetup devices anymore. # cryptsetup luksOpen /dev/lvm-foo/crypto foo Enter passphrase for /dev/lvm-foo/crypto: device-mapper: reload ioctl on failed: No such file or directory Failed to setup dm-crypt key mapping for device /dev/lvm-foo/crypto. Check that kernel supports aes-xts-plain64 cipher (check syslog for more info). device-mapper: remove ioctl on temporary-cryptsetup-3150 failed: No such device or address device-mapper: table ioctl on failed: No such device or address The output of dmesg is: device-mapper: table: 253:8: crypt: Error allocating crypto tfm device-mapper: ioctl: error adding target to table The respective LUKS header of the cryptsetup device looks like this: # cryptsetup luksDump /dev/lvm-foo/crypto LUKS header information for /dev/lvm-foo/crypto Version:1 Cipher name:aes Cipher mode:xts-plain64 Hash spec: sha1 Payload offset: 4096 MK bits:256 ... Maybe the lack of the "aes-xts-plain64" cipher is related to the following? # dpkg -L linux-image-4.9.0-8-armmp-lpae | grep aes /lib/modules/4.9.0-8-armmp-lpae/kernel/drivers/crypto/omap-aes.ko # dpkg -L linux-image-4.19.0-4-armmp-lpae | grep aes [no output] I am using a BananaPi M1 board. Thank you for your time! Cheers, Lars
Bug#926977: munin: Missing test dep on net-tools
Hello Steve, Am Fri, 12 Apr 2019 21:41:34 -0700 schrieb Steve Langasek : > After merging munin 2.0.47-1 into Ubuntu, the node-systemd autopkgtest was > failing on armhf because of a mismatch in the list of plugins being exposed: > [..] > The attached patch fixes the test failure by adding a test dependency on > net-tools. Perhaps it would also make sense for munin-plugins-core to > Recommend: net-tools, I don't know. Thank you for preparing the patch! Regarding the net-tools dependency: I think, we will add it to "Suggests". I attached a patch, that fixes the test failure for both situations (with and without net-tools). We plan to apply it after the release of Buster. Cheers, Lars diff --git a/debian/tests/munin-node/02.plugins.t b/debian/tests/munin-node/02.plugins.t index de777cd9..3d6374f6 100755 --- a/debian/tests/munin-node/02.plugins.t +++ b/debian/tests/munin-node/02.plugins.t @@ -27,7 +27,6 @@ interrupts irqstats load memory -netstat open_files open_inodes proc_pri @@ -51,6 +50,9 @@ EOF echo fw_conntrack echo fw_forwarded_local fi +if [ -x /bin/netstat ]; then + echo netstat +fi } | sort >expected_plugins test_cmp expected_plugins all_without_network_interfaces '
