Bug#783662: slurm-client dependency on plugins is missing
Package: slurm-client Version: 14.03.9-5 Severity: important Dear Maintainer, All commands delivered with slurm-client fail with the following error when the slurm-wlm-basic-plugins is not installed: root@login:~# sinfo sinfo: error: PluginDir: /usr/lib/x86_64-linux-gnu/slurm: No such file or directory sinfo: error: Bad value "/usr/lib/x86_64-linux-gnu/slurm" for PluginDir sinfo: fatal: Unable to process configuration file (same results with other commands such as squeue and so on.) Installation of the plugins fixes the bug: root@login:~# apt-get install slurm-wlm-basic-plugins root@login:~# sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST normal* up infinite 3 down* cn[1-3] I have already successfully applied this patch on slurm packages that we maintain locally: https://github.com/edf-hpc/slurm-llnl/commit/319422a25ec7a952a6ada67ceea161cf12f80d4e The patch adds the dep on slurm-client and also removes it on slurm-wlm package because the dep is already satisfied recursively. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages slurm-client depends on: ii libc6 2.19-18 ii libhwloc5 1.10.0-3 ii libncurses5 5.9+20140913-1+b1 ii libreadline6 6.3-8+b3 ii libtinfo5 5.9+20140913-1+b1 ii munge 0.5.11-1.1+b1 ii ucf 3.0030 slurm-client recommends no packages. slurm-client suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783663: slurm-client package also requires the slurm user
Package: slurm-client Version: 14.03.9-5 Severity: important Dear Maintainer, All commands delivered in slurm-client package actually requires the SlurmUser (slurm in default configuration generator on Debian) to be present on the system: root@login:~# sinfo sinfo: error: Invalid user for SlurmUser slurm, ignored sinfo: fatal: Unable to process configuration file root@login:~# adduser --system slurm root@login:~# sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST normal* up infinite 3 down* cn[1-3] This is arguably an upstream bug since there is no point for Slurm commands to check for this user... But not sure it's easy to fix though. Currently, this user is created in postinst script of slurmd, slurmctld and slurmdbd packages. Since this user is required on all nodes in a slurm cluster, it would probably be more reliable to move user management within slurm-wlm-basic-plugins package because it is installed everywhere. This is specifically what is done in this patch I have successfully applied our local version of slurm packages: https://github.com/edf-hpc/slurm-llnl/commit/74c128212b788930292ea6309a5a0f6f948372cf -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages slurm-client depends on: ii libc6 2.19-18 ii libhwloc5 1.10.0-3 ii libncurses5 5.9+20140913-1+b1 ii libreadline6 6.3-8+b3 ii libtinfo5 5.9+20140913-1+b1 ii munge 0.5.11-1.1+b1 ii ucf 3.0030 slurm-client recommends no packages. slurm-client suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783661: munge service disabled after package install
Package: munge
Version: 0.5.11-1.1+b1
Severity: important
Dear Maintainer,
After munge package installation, the munge systemd service is disabled. This
means that the munge service does not start at boot time.
Currently, munge postinst script only runs update-rc.d to enable munge init
script at boot time. But this command does not enable systemd service:
root@login:~# update-rc.d munge defaults
root@login:~# service munge status
● munge.service - MUNGE authentication service
Loaded: loaded (/lib/systemd/system/munge.service; disabled)
Active: inactive (dead)
Docs: man:munged(8)
The attached proposed patch adds dh-systemd in Build-Depends and makes use of
dh_system_{enable,start} in d/rules to add appropriate code in munge postinst
in order to enable the service after package installation.
-- System Information:
Debian Release: 8.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages munge depends on:
ii adduser 3.113+nmu3
ii libbz2-1.0 1.0.6-7+b3
ii libc62.19-18
ii libgcrypt20 1.6.3-2
ii libmunge20.5.11-1.1+b1
ii zlib1g 1:1.2.8.dfsg-2+b1
munge recommends no packages.
munge suggests no packages.
-- no debconf information
diff -Nru munge-0.5.11/debian/changelog munge-0.5.11/debian/changelog
--- munge-0.5.11/debian/changelog 2014-09-17 23:21:02.0 +0200
+++ munge-0.5.11/debian/changelog 2015-04-28 21:29:20.0 +0200
@@ -1,3 +1,10 @@
+munge (0.5.11-1.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix munge systemd service disable after package installation
+
+ -- Rémi Palancher Tue, 28 Apr 2015 21:27:38 +0200
+
munge (0.5.11-1.1) unstable; urgency=medium
[ Rémi Palancher ]
diff -Nru munge-0.5.11/debian/control munge-0.5.11/debian/control
--- munge-0.5.11/debian/control 2014-09-17 23:18:44.0 +0200
+++ munge-0.5.11/debian/control 2015-04-28 21:15:50.0 +0200
@@ -2,7 +2,7 @@
Section: admin
Priority: extra
Maintainer: Gennaro Oliva
-Build-Depends: debhelper (>= 7.0.0), dh-autoreconf, po-debconf, dpkg-dev (>= 1.13.19), zlib1g-dev, libbz2-dev, libgcrypt11-dev
+Build-Depends: debhelper (>= 7.0.0), dh-autoreconf, po-debconf, dpkg-dev (>= 1.13.19), zlib1g-dev, libbz2-dev, libgcrypt11-dev, dh-systemd
Standards-Version: 3.9.5
Homepage: http://munge.googlecode.com/
diff -Nru munge-0.5.11/debian/rules munge-0.5.11/debian/rules
--- munge-0.5.11/debian/rules 2014-09-17 23:19:20.0 +0200
+++ munge-0.5.11/debian/rules 2015-04-28 21:30:59.0 +0200
@@ -109,7 +109,9 @@
dh_installman debian/create-munge-key.8
install -m644 debian/libmunge2.lintian debian/libmunge2/usr/share/lintian/overrides/libmunge2
dh_compress
+ dh_systemd_enable
dh_installinit
+ dh_systemd_start
dh_installlogrotate
dh_link
dh_strip
Bug#774156: busybox-udeb: udhcpc default.script fails if $router is not set
Package: busybox-udeb Version: 1:1.20.0-7 Severity: important Dear Maintainer, The script /etc/udhcpc/default.script executed by udhcpc within debian-installer fails when DHCP servers give a lease without option 3 (router) with the following error: ~ # udhcpc udhcpc (v1.20.2) started + ip link set eth0 up + ip -4 addr flush dev eth0 + exit 0 Sending discover... Sending select for 10.11.0.11... Lease of 10.11.0.11 obtained, lease time 172800 + do_hostname + cat /proc/sys/kernel/hostname + local current=cn1 + [ -z cn1 ] + [ cn1 = (none) ] + ip -4 addr add 10.11.0.11/255.255.255.0 dev eth0 + [ -n ] + ip -4 route add default via ip: RTNETLINK answers: No such device Even if $router variable is not set, the script enters the for loop that set the routes. It makes the ip command fail because of missing argument. This is a bit annoying since this prevent the other dhcp options (dns servers, domain name and so on) from being processing correctly and then makes netcfg ask questions. The patch attached fixes this by checking if $router is not empty before the for statement. This fixes the bug for me. -- System Information: Debian Release: 7.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff --git a/debian/tree/busybox-udeb/etc/udhcpc/default.script b/debian/tree/busybox-udeb/etc/udhcpc/default.script index a47bdae..bba0d6b 100755 --- a/debian/tree/busybox-udeb/etc/udhcpc/default.script +++ b/debian/tree/busybox-udeb/etc/udhcpc/default.script @@ -66,12 +66,14 @@ case "$1" in ip link set "$interface" mtu "$mtu" fi - # special case for /32 subnets, use onlink when adding routes - [ ".$subnet" = .255.255.255.255 ] \ - && onlink=onlink || onlink= - for r in "$router"; do - ip -4 route add default via "$r" $onlink - done + if [ -n "$router" ]; then + # special case for /32 subnets, use onlink when adding routes + [ ".$subnet" = .255.255.255.255 ] \ + && onlink=onlink || onlink= + for r in "$router"; do +ip -4 route add default via "$r" $onlink + done + fi do_resolv_conf
Bug#772563: librelp0: Segmentation fault when TCP keepalive is enable
Package: librelp0 Version: 1.2.7-2 Severity: important Tags: upstream patch Dear Maintainer, When TCP keepalive is enable in librelp0 and a new TCP connection is initialized, it fails systematically with a segmentation fault. This is particularly annoying when librelp0 is used through rsyslogd and its imrelp plugin since it makes rsyslogd fail with a segmentation fault as soon as clients with omrelp plugin try to connect to the server. Here is the server side rsyslogd configuration excerpt to reproduce this bug: module(load="imrelp") input(type="imrelp" port="2514" KeepAlive="on") After a rebuild of rsyslog and librelp without stripping, here is the backtrace given by GDB when the SIGSEGV happens: $ gdb --args rsyslogd -n (gdb) r Starting program: /usr/sbin/rsyslogd -n [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". rsyslogd: warning: ~ action is deprecated, consider using the 'stop' statement instead [try http://www.rsyslog.com/e/2307 ] [New Thread 0x74990700 (LWP 25975)] [New Thread 0x7418f700 (LWP 25976)] [New Thread 0x7398e700 (LWP 25977)] [New Thread 0x7318d700 (LWP 25978)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7398e700 (LWP 25977)] EnableKeepAlive (sock=17, pSrv=0x6a45d0, pThis=0x0) at tcp.c:688 688 tcp.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 EnableKeepAlive (sock=17, pSrv=0x6a45d0, pThis=0x0) at tcp.c:688 #1 relpTcpAcceptConnReq (ppThis=0x6af6b0, sock=sock@entry=10, pSrv=pSrv@entry=0x6a45d0) at tcp.c:717 #2 0x757390f4 in relpSessAcceptAndConstruct (ppThis=ppThis@entry=0x7398d638, pSrv=pSrv@entry=0x6a45d0, sock=sock@entry=10) at relpsess.c:191 #3 0x75737d57 in handleConnectionRequest (sock=10, pSrv=0x6a45d0, pThis=0x6a44e0) at relp.c:589 #4 engineEventLoopRun (pThis=pThis@entry=0x6a44e0) at relp.c:770 #5 0x757383c7 in relpEngineRun (pThis=0x6a44e0) at relp.c:950 #6 0x759472c8 in ?? () from /usr/lib/rsyslog/imrelp.so #7 0x004560a5 in thrdStarter (arg=0x7fffec000a00) at ../threads.c:212 #8 0x779b0b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #9 0x76ad57bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #10 0x in ?? () The bug happens because the relpTcp_t * parameter of EnableKeepAlive(), named pThis, is NULL when it is called by relpTcpAcceptConnReq(). Therefore the debug print on line tcp.c:688 necessarily segfaults. The patch attached simply makes sure the relpTcp_t struct is well initialized with relpTcpConstruct() before EnableKeepAlive() is called. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages librelp0 depends on: ii libc6 2.19-13 ii libgnutls-deb0-28 3.3.8-5 ii multiarch-support 2.19-13 librelp0 recommends no packages. librelp0 suggests no packages. -- no debconf information Description: avoid SIGSEGV when TCP keepalive is enable Result of a GDB debug session: $ gdb --args rsyslogd -n (gdb) r Starting program: /usr/sbin/rsyslogd -n [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". rsyslogd: warning: ~ action is deprecated, consider using the 'stop' statement instead [try http://www.rsyslog.com/e/2307 ] [New Thread 0x74990700 (LWP 25975)] [New Thread 0x7418f700 (LWP 25976)] [New Thread 0x7398e700 (LWP 25977)] [New Thread 0x7318d700 (LWP 25978)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7398e700 (LWP 25977)] EnableKeepAlive (sock=17, pSrv=0x6a45d0, pThis=0x0) at tcp.c:688 688 tcp.c: Aucun fichier ou dossier de ce type. (gdb) bt #0 EnableKeepAlive (sock=17, pSrv=0x6a45d0, pThis=0x0) at tcp.c:688 #1 relpTcpAcceptConnReq (ppThis=0x6af6b0, sock=sock@entry=10, pSrv=pSrv@entry=0x6a45d0) at tcp.c:717 #2 0x757390f4 in relpSessAcceptAndConstruct (ppThis=ppThis@entry=0x7398d638, pSrv=pSrv@entry=0x6a45d0, sock=sock@entry=10) at relpsess.c:191 #3 0x75737d57 in handleConnectionRequest (sock=10, pSrv=0x6a45d0, pThis=0x6a44e0) at relp.c:589 #4 engineEventLoopRun (pThis=pThis@entry=0x6a44e0) at relp.c:770 #5 0x757383c7 in relpEngineRun (pThis=0x6a44e0) at relp.c:950 #6 0x759472c8 in ?? () from /usr/lib/rsyslog/imrelp.so #7 0x004560a5 in thrdStarter (arg=0x7fffec000a00) at ../threads.c:212 #8 0x779b0b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #9 0x76ad57bd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #10 0x in ?? () The bug
Bug#771218: librelp0 enters an endless loop when send() set errno to EAGAIN endlessly
Package: librelp0
Version: 1.0.0-1
Severity: important
Tags: upstream patch
Dear Maintainer,
While using rsyslog with its relp plugin linked to librelp0, I encountered a
bug where my central rsyslog server entered into an endless loop and it then
basically stopped processing the logs. The rsyslogd process was fully using one
core on the system.
To help understand this behaviour, I ran rsyslog in foreground with debug flag:
# rsyslogd -c5 -n -d
The resulting output can be found in attached file
rsyslog_debug_endless_loop_truncated.log.xz. I largely truncated the file to
significantly reduce its size. Feel free to tell me if you need to have a look
to original file 6MB though. You may notice in the output this repeating line :
"tcpSend returns 0".
After a deeper analysis I figured out that it was due to one particular "client"
node whose TCP socket was in a weird state. Every send() that were performed by
librelp0 on this socket returned -1 and set errno to EAGAIN, endlessly. By
endlessly, I mean approximately 20 days.
Here the backtrace according to GDB on the breakpoint tcp.c:488:
#0 relpTcpSend (pThis=pThis@entry=0x69e1c0, pBuf=,
pLenBuf=pLenBuf@entry=0x7475ead8) at tcp.c:488
#1 0x75f71482 in relpSendbufSend (pThis=0x69bbb0,
pTcp=pTcp@entry=0x69e1c0) at sendbuf.c:131
#2 0x75f71274 in relpSendqSend (pThis=pThis@entry=0x6992d0,
pTcp=pTcp@entry=0x69e1c0) at sendq.c:249
#3 0x75f7133a in relpSendqAddBuf (pThis=0x6992d0, pBuf=, pTcp=0x69e1c0) at sendq.c:170
#4 0x75f6f2a5 in relpSessSendResponse (pThis=pThis@entry=0x69d210,
txnr=, pData=, lenData=) at
relpsess.c:248
#5 0x75f725c9 in relpSCInit (pFrame=pFrame@entry=0x699510,
pSess=pSess@entry=0x69d210) at copen.c:141
#6 0x75f6e863 in relpEngineDispatchFrame (pThis=,
pSess=pSess@entry=0x69d210, pFrame=pFrame@entry=0x699510) at relp.c:474
#7 0x75f7005f in relpFrameProcessOctetRcvd
(ppThis=ppThis@entry=0x69d230, c=10 '\n', pSess=pSess@entry=0x69d210) at
relpframe.c:207
#8 0x75f6ec07 in relpSessRcvData (pThis=0x69d210) at relpsess.c:224
#9 0x75f6e709 in relpEngineRun (pThis=0x6745a0) at relp.c:405
#10 0x0043ae06 in ?? ()
#11 0x779b0b50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#12 0x772eee6d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#13 0x in ?? ()
Function relpSendqSend() has a while loop that loops until there is no
data to send anymore. But with this weird socket state, the loop becomes
endless. When used by rsyslog, this endless loop results in a DOS on the
central rsyslog server.
The attached patch abort-send-loop-after-max-tries.diff is a proposal to fix
this bug. It counts the number of tries, and if it reaches 100 tries,
relpSendqSend() returns RELP_RET_PARTIAL_WRITE. Note that this return value
is already "managed" by relpSendqAddBuf() in some way.
It would probably be better to tell rsyslog about this error, other than a
simple debug message, so that it could then appear in rsyslog own logs and
warn the sysadmins of this weird socket/node. But I'm not familiar with
librepl0 and rsyslog code base so I haven't taken time to get deeper into
this.
-- System Information:
Debian Release: 7.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages librelp0 depends on:
ii libc6 2.13-38+deb7u4
librelp0 recommends no packages.
librelp0 suggests no packages.
-- no debconf information
--- librelp-1.0.0.orig/src/sendq.c 2009-12-01 12:55:08.0 +0100
+++ librelp-1.0.0/src/sendq.c 2014-11-27 13:08:11.870560533 +0100
@@ -237,6 +237,8 @@
{
relpSendqe_t *pEntry;
relpRetVal localRet;
+ const int max_tries = 100;
+ int nb_tries = 0;
ENTER_RELPFUNC;
RELPOBJ_assert(pThis, Sendq);
@@ -253,7 +256,13 @@
*/
CHKRet(relpSendqDelFirstBuf(pThis));
pEntry = pThis->pRoot; /* as we deleted from the root, the is our next entry */
- } else if(localRet != RELP_RET_PARTIAL_WRITE) {
+ } else if(localRet == RELP_RET_PARTIAL_WRITE) {
+ if(nb_tries >= max_tries) {
+pThis->pEngine->dbgprint("relpSendqSend() gives up after %d partial writes\n", nb_tries);
+ABORT_FINALIZE(localRet);
+ } else
+nb_tries++;
+ } else {
ABORT_FINALIZE(localRet);
}
}
rsyslog_debug_endless_loop_truncated.log.xz
Description: Binary data
Bug#761651: munge: post-installation fails with systemd
Package: munge Version: 0.5.11-1 Severity: important Dear Maintainer, The installation of munge package on Jessie fails because of the bad exit code of the post-installation script: # apt-get install munge Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libmunge2 The following NEW packages will be installed: libmunge2 munge 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 103 kB of archives. After this operation, 434 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.fr.debian.org/debian/ jessie/main libmunge2 amd64 0.5.11-1 [18.9 kB] Get:2 http://ftp.fr.debian.org/debian/ jessie/main munge amd64 0.5.11-1 [84.2 kB] Fetched 103 kB in 6s (16.6 kB/s) Selecting previously unselected package libmunge2. (Reading database ... 40136 files and directories currently installed.) Preparing to unpack .../libmunge2_0.5.11-1_amd64.deb ... Unpacking libmunge2 (0.5.11-1) ... Selecting previously unselected package munge. Preparing to unpack .../munge_0.5.11-1_amd64.deb ... Unpacking munge (0.5.11-1) ... Processing triggers for man-db (2.6.7.1-1) ... Setting up libmunge2 (0.5.11-1) ... Setting up munge (0.5.11-1) ... Job for munge.service failed. See 'systemctl status munge.service' and 'journalctl -xn' for details. invoke-rc.d: initscript munge, action "start" failed. dpkg: error processing package munge (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for libc-bin (2.19-10) ... Errors were encountered while processing: munge E: Sub-process /usr/bin/dpkg returned an error code (1) This is due to systemd not being able to start munge daemon after installation. Here is what systemctl reports about this service: root@jessiepkgtest:~# systemctl status munge.service munge.service - MUNGE authentication service Loaded: loaded (/lib/systemd/system/munge.service; disabled) Active: failed (Result: exit-code) since Mon 2014-09-15 12:14:25 CEST; 50s ago Docs: man:munged(8) Process: 1572 ExecStart=/usr/sbin/munged (code=exited, status=1/FAILURE) Sep 15 12:14:25 jessiepkgtest munged[1572]: munged: Error: Failed to check keyfile "/etc/munge/munge.key":...tory Sep 15 12:14:25 jessiepkgtest systemd[1]: munge.service: control process exited, code=exited status=1 Sep 15 12:14:25 jessiepkgtest systemd[1]: Failed to start MUNGE authentication service. Sep 15 12:14:25 jessiepkgtest systemd[1]: Unit munge.service entered failed state. Actually, munged process exited with exit code 1 because the munge key was not available. I can see 2 ways to fix this bug: - create the key if not present in post-installation script (similarly to what ssh-server does with SSH host keys) - add a ConditionPathExists on /etc/munge/munge.key in the [Unit] section of munged.service There are probably other solutions though... -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages munge depends on: ii adduser 3.113+nmu3 ii libbz2-1.0 1.0.6-7 ii libc62.19-10 ii libgcrypt11 1.5.4-2 ii libmunge20.5.11-1 ii zlib1g 1:1.2.8.dfsg-1 munge recommends no packages. munge suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
