Bug#1023007: Reassign to texlive-binaires (configuration fails due to "Illegal instruction" on i386)
reassign 1023007 texlive-binaries 2022.20220321.62855-4 retitle 1023007 luatex: on i386 "illegal instruction" prevents configuration of tex-common thanks I forgot to mention that the CPU is an Athlon XP without SSE2 support: # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP 2600+ stepping: 0 cpu MHz : 1913.337 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall bugs: fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass bogomips: 3826.67 clflush size: 32 cache_alignment : 32 address sizes : 34 bits physical, 32 bits virtual power management: ts Regards
Bug#974991: sagemath: segfault on startup
Package: sagemath Version: 9.2-1 Severity: important Dear Maintainers, Starting sage in a terminal to get a prompt makes it segfault (it seems related to pari). The end of the terminal output follows and the complete log file is attached. Sage also segfaults when started by jupyter. --- $ sage [...] 3310 return new_gen(pari_float) SignalError: Segmentation fault ** Oops, Sage crashed. We do our best to make it stable, but... A crash report was automatically generated with the following information: - A verbatim copy of the crash traceback. - A copy of your input history during this session. - Data on your current Sage configuration. It was left in the file named: '/home/restricted/.ipython/Sage_crash_report.txt' If you can email this file to the developers, the information in it will help them in understanding and correcting the problem. You can mail it to: sage-support at sage-supp...@googlegroups.com with the subject 'Sage Crash Report'. If you want to do it now, the following command will work (under Unix): mail -s 'Sage Crash Report' sage-supp...@googlegroups.com < /home/restricted/.ipython/Sage_crash_report.txt In your email, please also include information about: - The operating system under which the crash happened: Linux, macOS, Windows, other, and which exact version (for example: Ubuntu 16.04.3, macOS 10.13.2, Windows 10 Pro), and whether it is 32-bit or 64-bit; - How Sage was installed: using pip or conda, from GitHub, as part of a Docker container, or other, providing more detail if possible; - How to reproduce the crash: what exact sequence of instructions can one input to get the same crash? Ideally, find a minimal yet complete sequence of instructions that yields the crash. To ensure accurate tracking of this issue, please file a report about it at: http://trac.sagemath.org Hit to quit (your terminal may close): --- -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (800, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (99, 'xenial-updates'), (99, 'xenial-security'), (99, 'xenial'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages sagemath depends on: ii curl 7.72.0-1 ii cysignals-tools 1.10.2+ds-5 ii cython3 0.29.21-3 ii ecl 20.4.24+ds-2 ii eclib-tools 20190909-3+b1 ii fflas-ffpack 2.4.3-2 ii flintqs 1:1.0-3+b1 ii gap-atlasrep 2.1.0-3 ii gap-dev 4.11.0-4 ii gap-online-help 4.11.0-4 ii gap-primgrp 3.4.0-1 ii gap-smallgrp 1.4.1-1 ii gap-table-of-marks1.2.9-1 ii gap-transgrp 2.0.4-1 ii gfan 0.6.2-2 ii glpk-utils4.65-2 ii gmp-ecm 7.0.4+ds-5 ii ipython3 7.19.0-1 ii iso-codes 4.5.0-1 ii jmol 14.6.4+2016.11.05+dfsg1-4 ii lcalc 1.23+dfsg-11+b1 ii less 551-2 ii libatlas3-base [libblas.so.3] 3.10.3-10 ii libblas3 [libblas.so.3] 3.9.0-3 ii libbraiding0 1.0-1+b1 ii libbrial-groebner31.2.10-1+b1 ii libbrial3 1.2.10-1+b1 ii libc6 2.31-4 ii libcdd-tools 094j-2 ii libcliquer1 1.21-2 ii libec520190909-3+b1 ii libecm1 7.0.4+ds-5 ii libflint-2.6.32.6.3-3 ii libflint-arb2 1:2.18.1-3 ii libgap7 4.11.0-4 ii libgcc-s1 10.2.0-17 ii libgd32.3.0-2 ii libgiac0
Bug#903638: ksh: cannot enable job control from command line (option -m ineffective)
Package: ksh Version: 93u+20120801-3.1 Severity: normal Tags: fixed-upstream Hello, For more details on how to test this, see https://github.com/att/ast/issues/517. It has been fixed upstream, probably in the same commit as bug #862326. Regards
Bug#862326: ksh: 'set -m' is broken in non-interactive shells: ksh stops after each external command
package ksh tags fixed-upstream thanks Hello, This bug is fixed upstream; I just tested it inside stable with the code from https://github.com/att/ast. The commit fixing it could be 848d1997 (Fix job control if ksh is started as login shell, 2018-03-26). Regards
Bug#893490: 90x11-common_ssh-agent: enable users to disable or configure ssh-agent
Package: x11-common
Version: 1:7.7+19
Severity: minor
Tags: patch
This change closes #658124 ("x11-common: Xsession should not start
ssh-agent (should be a user-level choice)") as well as #642012
("x11-common: ssh-agent Xsession script does not check if gpg-agent will
enable SSH support").
It makes it possible for the users to disable ssh-agent (for example if
gpg-agent has option enable-ssh-support) by setting $STARTSSHAGENT to
empty in ~/.xsessionrc, and to pass extra ssh-agent by setting
$SSHAGENTARGS in it.
The default behaviour is not changed.
Regards
>From b83ec9e283f69e648e93f5e4afa886a7756a11c0 Mon Sep 17 00:00:00 2001
From: "G.raud" <gr...@gmx.com>
Date: Mon, 19 Mar 2018 11:18:08 +0100
Subject: [PATCH] 90x11-common_ssh-agent: enable users to disable or configure
ssh-agent
This closes #658124 as well as #642012 as it allows the user to
"manually" disable ssh-agent when enabling enable-ssh-support in
gpg-agent.
---
debian/local/Xsession.d/90x11-common_ssh-agent | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/debian/local/Xsession.d/90x11-common_ssh-agent b/debian/local/Xsession.d/90x11-common_ssh-agent
index 5397434..28a2a5d 100644
--- a/debian/local/Xsession.d/90x11-common_ssh-agent
+++ b/debian/local/Xsession.d/90x11-common_ssh-agent
@@ -1,24 +1,27 @@
# $Id: 90x11-common_ssh-agent 305 2005-07-03 18:51:43Z dnusinow $
# This file is sourced by Xsession(5), not executed.
-STARTSSH=
+#STARTSSHAGENT= can be set in $USERXSESSIONRC
SSHAGENT=/usr/bin/ssh-agent
-SSHAGENTARGS=
+#SSHAGENTARGS= can be set in $USERXSESSIONRC
-if has_option use-ssh-agent; then
- if [ -x "$SSHAGENT" ] && [ -z "$SSH_AUTH_SOCK" ] \
- && [ -z "$SSH2_AUTH_SOCK" ]; then
-STARTSSH=yes
-if [ -f /usr/bin/ssh-add1 ] && cmp -s $SSHAGENT /usr/bin/ssh-agent2; then
- # use ssh-agent2's ssh-agent1 compatibility mode
- SSHAGENTARGS=-1
-fi
+if has_option use-ssh-agent \
+ && [ -x "$SSHAGENT" ] && [ -z "$SSH_AUTH_SOCK" ] \
+ && [ -z "$SSH2_AUTH_SOCK" ]; then
+ if [ -z "${STARTSSHAGENT+set}" ]; then
+STARTSSHAGENT=yes
fi
+ if [ -f /usr/bin/ssh-add1 ] && cmp -s $SSHAGENT /usr/bin/ssh-agent2; then
+# use ssh-agent2's ssh-agent1 compatibility mode
+SSHAGENTARGS="-1 $SSHAGENTARGS"
+ fi
+else
+STARTSSHAGENT=
fi
-if [ -n "$STARTSSH" ]; then
+if [ -n "$STARTSSHAGENT" ]; then
STARTUP="$SSHAGENT $SSHAGENTARGS ${TMPDIR:+env TMPDIR=$TMPDIR} $STARTUP"
fi
# vim:set ai et sts=2 sw=2 tw=80:
--
2.16.2
Bug#855463: e2image: attempt to seek into a pipe
On Tue, Aug 22, 2017 at 06:15:27PM -0400, Theodore Ts'o wrote:
> On Sat, Feb 18, 2017 at 06:13:53PM +0100, G.raud wrote:
> > Package: e2fsprogs
> > Version: 1.42.12-2+b1
> > Severity: normal
> >
> > e2image tries to seek into an ouput to stdout ("-"), even when it is a
> > pipe:
> >
> > --
> > # LC_ALL=C e2image /dev/mapper/debian-var - | cat >test
> > e2image 1.42.12 (29-Aug-2014)
> > seek_set: Illegal seek
> > --
> >
> > According the manpage, only the raw and qcow2 formats require seeking
> > into the output.
>
> Actually, the manage states that only the raw mode supports using
> stdout:
>
>If image-file is -, then the output of e2image will be sent to
>standard output, so that the output can be piped to another
>program, such as gzip(1). (Note that this is currently only
>supported when creating a raw image file using the -r option, since
>the process of creating a normal image file, or QCOW2 image
>currently requires random access to the file, which cannot be done
>using a pipe. This restriction will hopefully be lifted in a
>future version of e2image.)
Either I misread that part or the manpage in jessie was erroneous.
> The fact that e2image doesn't work on "normal" e2image files is a
> long-standing short-coming. But note that it's really an obsolete
> format. The raw or qcow image formats are actually far more useful,
> and the primary use cases of e2image today. The only reason why
> "normal" is still used to describe the original e2image format is for
> historical reasons.
To avoid that someone else makes the same mistake, I suggest to put a
warning message to stderr in case such a combination of options is
selected, because "seek_set: Illegal seek" implies a programming error.
Regards
--
G.raud
Bug#855463: e2image: attempt to seek into a pipe
Package: e2fsprogs
Version: 1.42.12-2+b1
Severity: normal
e2image tries to seek into an ouput to stdout ("-"), even when it is a
pipe:
--
# LC_ALL=C e2image /dev/mapper/debian-var - | cat >test
e2image 1.42.12 (29-Aug-2014)
seek_set: Illegal seek
--
According the manpage, only the raw and qcow2 formats require seeking
into the output.
Bug#855246: e2image: "Value too large for defined data type" while writing file bigger than 2GiB
Package: e2fsprogs Version: 1.43.3-1 Severity: important An strace of the failing e2image program giving an image file size just below 2GiB (on a 32 bit platform): -- # LC_ALL=C strace e2image /dev/mapper/share share.img 2>&1 | tail -n15 lseek(4, 4096, SEEK_CUR)= 2147471360 lseek(4, 4096, SEEK_CUR)= 2147475456 lseek(4, 4096, SEEK_CUR)= 2147479552 lseek(4, 4096, SEEK_CUR)= -1 EOVERFLOW (Value too large for defined data type) munmap(0xb76e4000, 135168) = 0 write(2, "e2image", 7e2image) = 7 write(2, ": ", 2: ) = 2 write(2, "Value too large for defined data"..., 37Value too large for defined data type) = 37 write(2, " ", 1 )= 1 write(2, "while writing inode table", 25while writing inode table) = 25 ioctl(2, TCGETS, 0xbff65a1c)= -1 ENOTTY (Inappropriate ioctl for device) write(2, "\n", 1 ) = 1 exit_group(1) = ? +++ exited with 1 +++ -- The following commands writing to stdout and writing to a raw file complete successfully and give files that seem usable: -- # LC_ALL=C e2image /dev/mapper/share - > share.img # LC_ALL=C e2image -r /dev/mapper/share share.raw -- According to the webpage http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Value-too-large-for-defined-data-type "It means that your version of the utilities were not compiled with large file support enabled." -- System Information: Debian Release: 9.0 APT prefers unstable Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) Versions of packages e2fsprogs depends on: ii e2fslibs1.43.3-1 ii libblkid1 2.29.1-1 ii libc6 2.24-9 ii libcomerr2 1.43.3-1 ii libss2 1.43.3-1 ii libuuid12.29.1-1 ii util-linux 2.29.1-1 e2fsprogs recommends no packages.
Bug#855235: mdadm --size -G: size is truncated below 4TiB (on a 32bit platform)
Package: mdadm Version: 3.3.2-5+deb8u1 Severity: normal On a raid5 array with 4 components (array size 5778520512KiB, used dev size 1932563136KiB): -- # mdadm --grow --size 11557041024 /dev/md/entrepot mdadm: component size of /dev/md/entrepot unchanged at 1932563136K unfreeze # mdadm --grow --size 5778520512 /dev/md/entrepot ## BUG mdadm: component size of /dev/md/entrepot has been set to 1483553216K unfreeze # mdadm --grow --size 1932563136K /dev/md/entrepot mdadm: component size of /dev/md/entrepot has been set to 1932563136K unfreeze # mdadm -G --size 3500G /dev/md/entrepot mdadm: component size of /dev/md/entrepot unchanged at 1932563136K unfreeze -- In the second case the size of ~5,3TiB is truncated to 1,3TiB (-4TiB). In the first case the value given of 10,6TiB is too large; it could be seen as 2,6TiB but not 0,6TiB (<=1932563136KiB) so we could presume that a size below 4TiB would not be truncated which the 4th example confirms. I do not know what is the maximum size accepted by md for a component, but if the truncation happens outside mdadm (e.g. in the kernel), at least a check should be added to mdadm. The limit of 4TiB is the one of a 32bit address of sectors of 1KiB; I cannot test this bug on a 64 bit platform. -- System Information: Debian Release: 8.7 bug reported on another computer; here is some manual info: kernel debian linux-image-3.16.0-4-686-pae 3.16.36-1+deb8u2 processor AMD Athlon 32bit mono core
Bug#848906: trying to raise attention to this bug with a patch
package initramfs-tools-core
severity 848906 important
thanks
The patch against 0.126 (still valid against 0.127) modifying
/usr/share/initramfs-tools/scripts/local follows.
--- /usr/share/initramfs-tools/scripts/local 2016-04-17 21:39:22.0 +0200
+++ /usr/share/initramfs-tools/scripts/local.new 2016-12-18 17:05:13.419988203 +0100
@@ -55,10 +55,15 @@
modprobe ubi mtd=$UBIMTD
DEV="${dev_id}"
return
fi
+ # Detect (some) invalid device names
+ if [ -z "${dev_id}" ]; then
+ panic "Empty root device name deteted. Try passing root= bootarg."
+ fi
+
# Don't wait for a device that doesn't have a corresponding
# device in /dev and isn't resolvable by blkid (e.g. mtd0)
if [ "${dev_id#/dev}" = "${dev_id}" ] &&
[ "${dev_id#*=}" = "${dev_id}" ]; then
DEV="${dev_id}"
@@ -136,17 +141,20 @@
# FIXME This has no error checking
modprobe ${FSTYPE}
checkfs ${ROOT} root "${FSTYPE}"
- # FIXME This has no error checking
# Mount root
if [ "${FSTYPE}" != "unknown" ]; then
mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} ${rootmnt}
else
mount ${roflag} ${ROOTFLAGS} ${ROOT} ${rootmnt}
fi
+ # Basic error checking
+ if [ $? != 0 ] || { command -v mountpoint >/dev/null 2>&1 && ! mountpoint ${rootmnt}; }; then
+ panic "ALERT! The root fs failed to be mounted. Dropping to a shell."
+ fi
}
local_mount_fs()
{
read_fstab_entry "$1"
@@ -167,13 +175,16 @@
if [ "$MNT_PASS" != 0 ]; then
checkfs "$MNT_FSNAME" "$MNT_DIR" "${MNT_TYPE}"
fi
- # FIXME This has no error checking
# Mount filesystem
mount ${roflag} -t "${MNT_TYPE}" -o "${MNT_OPTS}" "$MNT_FSNAME" "${rootmnt}${MNT_DIR}"
+ # Basic error checking
+ if [ $? != 0 ] || { command -v mountpoint >/dev/null 2>&1 && ! mountpoint ${rootmnt}; }; then
+ panic "ALERT! The '${MNT_DIR}' fs failed to be mounted. Dropping to a shell."
+ fi
}
mountroot()
{
local_mount_root
Bug#848906: /init: missing critical mount failure detection
Package: initramfs-tools-core
Version: 0.126
Severity: normal
Tags: patch
I experienced a failure to boot because root was set to an empty value
(which seems a rather common problem caused by grub). However the /init
passed the mounting step without stopping (and without complaining too
much).
The next failure detection is $init inexistence in /root and it is this
one that is triggered to stop the /init and start a shell. (In passing
please note that this detection sets $init to an empty value which is
very inconvenient since it prevents the possibility to fix the problem
in the panic shell before resuming the /init, which in my case was not
possible anyways due to missing executables in the initramfs; I suggest
not to set $init to an empty value, so that the original $init value is
available for inspection in the panic shell.)
The error actually triggered is very misleading because /init does not
detect the failure of its main purpose: mounting /root.
I join a patch to make basic checks after mounting both /root and /root/usr.
It optionally calls mountpoint that could be available (for example in
recent versions of busybox).
It also adds a check that $ROOT is not empty (which could additionaly
test for other obviously invalid values), placed right before the code
that possibly decides to skip the part that makes the root device appear
in /dev. This is because an empty $ROOT is a frequent problem and
because the test to detect non /dev devices (like UBI) is too broad.--- /usr/share/initramfs-tools/scripts/local 2016-04-17 21:39:22.0 +0200
+++ /usr/share/initramfs-tools/scripts/local.new 2016-12-18 17:05:13.419988203 +0100
@@ -55,10 +55,15 @@
modprobe ubi mtd=$UBIMTD
DEV="${dev_id}"
return
fi
+ # Detect (some) invalid device names
+ if [ -z "${dev_id}" ]; then
+ panic "Empty root device name deteted. Try passing root= bootarg."
+ fi
+
# Don't wait for a device that doesn't have a corresponding
# device in /dev and isn't resolvable by blkid (e.g. mtd0)
if [ "${dev_id#/dev}" = "${dev_id}" ] &&
[ "${dev_id#*=}" = "${dev_id}" ]; then
DEV="${dev_id}"
@@ -136,17 +141,20 @@
# FIXME This has no error checking
modprobe ${FSTYPE}
checkfs ${ROOT} root "${FSTYPE}"
- # FIXME This has no error checking
# Mount root
if [ "${FSTYPE}" != "unknown" ]; then
mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} ${rootmnt}
else
mount ${roflag} ${ROOTFLAGS} ${ROOT} ${rootmnt}
fi
+ # Basic error checking
+ if [ $? != 0 ] || { command -v mountpoint >/dev/null 2>&1 && ! mountpoint ${rootmnt}; }; then
+ panic "ALERT! The root fs failed to be mounted. Dropping to a shell."
+ fi
}
local_mount_fs()
{
read_fstab_entry "$1"
@@ -167,13 +175,16 @@
if [ "$MNT_PASS" != 0 ]; then
checkfs "$MNT_FSNAME" "$MNT_DIR" "${MNT_TYPE}"
fi
- # FIXME This has no error checking
# Mount filesystem
mount ${roflag} -t "${MNT_TYPE}" -o "${MNT_OPTS}" "$MNT_FSNAME" "${rootmnt}${MNT_DIR}"
+ # Basic error checking
+ if [ $? != 0 ] || { command -v mountpoint >/dev/null 2>&1 && ! mountpoint ${rootmnt}; }; then
+ panic "ALERT! The '${MNT_DIR}' fs failed to be mounted. Dropping to a shell."
+ fi
}
mountroot()
{
local_mount_root
Bug#809385: fbi: Please build ida from fbida now that libmotif is free
Package: fbi Version: 2.09-1+b1 Severity: wishlist I can build fbida 2.10 (https://www.kraxel.org/releases/fbida/fbida-2.10.tar.gz) with motif enabled on Debian jessie. Please enable libmotif during the configuration so that the program ida is built. Regards, -- G.raud Meyer
Bug#747228: posh: wrong NL escapes inside 2 levels of process substitution
Package: posh Version: 0.12.3 Severity: normal The canonical example is: $ printf %s %s\n $( printf %s\n $(printf %s\n 'START\ NOLINE') ) that prints STARTNOLINE\n instead of START\\ NOLINE\n. This is an incorrect behaviour according to http://pubs.opengroup.org/onlinepubs/95399/utilities/xcu_chap02.html#tag_02_06_03: Any valid shell script can be used for command, except a script consisting solely of redirections which produces unspecified results. Note that this bug is found in pdksh but it has been fixed in mksh; Debian stable has a non buggy pdksh 40.9.20120630-7 (provided by mksh) while pdksh PD KSH v5.2.14 99/07/13.2 is buggy. See the joined script for more examples. Regards -- G.raud Meyer #!/bin/posh NL=' ' echo This is incorrect behaviour printf %s %s\n $( printf %s\n $(printf %s\n 'START\ NOLINE') ) printf %s %s\n $( printf %s %s\n $( printf %s %s\n $(printf %s\n 'START\ NOLINE') ) ) echo This is a workaround printf %s %s\n $( printf %s %s\n $(printf %s\n 'START\'$NL'LINE') ) echo These are cases that do not exhibit the behaviour printf %s %s\n $(printf %s\n 'START\ LINE') printf %s %s\n $( printf %s %s\n $(printf %s\n 'START\ LINE') ) printf %s %s\n $( printf %s %s\n $(printf %s\n 'START LINE') )
Bug#537043: in Debian! (vorbisgain: invalid tempfile name (longer than 255 chars))
On Sat, Jan 12, 2013 at 08:59:39PM +0100, Daniel Martí wrote: On Fri, Jan 11, 2013 at 01:44:20PM +0100, G.raud wrote: Please remove the patch 0001-temp_files.patch that introduces a bug without fixing anything anymore. Thank you for noticing. I will prepare a new version to be pushed to sid soon. Any news on that? The fix consists only in removing this patch and refreshing the others (the disabling of code relating to keeping the mtime is done differently by another patch). -- G.raud -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741657: /etc/profile.d/bash_completion.sh: non portable return from a dot script
Package: bash-completion Version: 1:2.1-2 Severity: normal Calling return to stop processing a dot script is not portable to the Heirloom Bourne Shell (http://heirloom.sourceforge.net/sh.html) which stops processing the script as wanted but which prints a spurious cannot return when not in function. To test: argv0 /usr/local/5bin/sh -sh /etc/profile.d/bash_completion.sh can be easily made not to call return by wrapping it in an if fi: if [ -n $BASH_VERSION ] [ -n $PS1 ] [ -z $BASH_COMPLETION_COMPAT_DIR ]; then 'script' fi -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (800, 'unstable'), (500, 'oldstable-updates'), (500, 'testing'), (500, 'stable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bash-completion depends on: ii bash 4.2+dfsg-1 ii dpkg 1.17.6 bash-completion recommends no packages. bash-completion 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#598238: 'dash -x' segfaults on the command 'test !'
package dash retitle 598238 'dash -x' segfaults on the command 'test !' found 598238 0.5.7-4 tag 598238 + upstream fixed-upstream patch thanks This bug is fixed in commit b34499f5c851d1a70db95b56bd02eff0329d4a1a titled [BUILTIN] Fixed argument parsing crash in test from http://git.kernel.org/cgit/utils/dash/dash.git. Simplest case: dash -xc 'test !' Other cases: dash -xc 'test ! !' dash -xc 'test ! ! ! !' -- G.raud -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674709: unsort: upstream fixed FTBFS on hurd-i386: IOV_MAX not defined
It seems that upstream (https://git.fruit.je/unsort) has fixed this issue. There are also additional improvements. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737083: pulseaudio: ALSA cannot be used directly when pulseaudio is installed
Package: pulseaudio Version: 2.0-6.1 Severity: important When pulseaudio is installed, the file '/usr/share/alsa/alsa.conf.d/pulse.conf' is loaded and it seems that the result is that pulseaudio is automatically started (when it is not already running) whenever ALSA is used. Thus if a user explicitly requested an ALSA device outputting to a hardware card (other than pulse), this device cannot be opened anymore because the hardware device is already opened by pulseaudio. The ALSA device null still works but pulseaudio is started nonetheless! To my knowledge, the only way to make ALSA usable again, is to put the file '/usr/share/alsa/alsa.conf.d/pulse.conf' aside, which requires administrative privileges. This is unacceptable since a normal user should still have the option not to use pulseaudio. I would suggest that you devise a way to clear the config of 'pulse.conf' from a user '.asoundrc' or disable the file 'pulse.conf' by default or maybe ask about it in debconf. Note that the function loaded by the afore-mentioned file is named 'conf_load_if_running', which suggests that it should load the files that set pulse as the default ouput device only if pulseaudio is already running, but in fact it starts pulseaudio itself. PS. Please add to README.Debian an explanation of how to do disable pulseaudio: how to disbale the autostart of the X session (both system-wide and per user) and how to disable the automatic switching of ALSA to pulseaudio. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (800, 'stable'), (500, 'stable-updates'), (300, 'testing'), (99, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pulseaudio depends on: ii adduser 3.113+nmu3 ii consolekit0.4.5-3.1 ii libasound21.0.25-4 ii libasound2-plugins1.0.25-2 ii libc6 2.13-38 ii libcap2 1:2.22-1.2 ii libdbus-1-3 1.6.8-1+deb7u1 ii libfftw3-33.3.2-3.1 ii libgcc1 1:4.7.2-5 ii libice6 2:1.0.8-2 ii libltdl7 2.4.2-1.1 ii liborc-0.4-0 1:0.4.16-2 ii libpulse0 2.0-6.1 ii libsamplerate00.1.8-5 ii libsm62:1.2.1-2 ii libsndfile1 1.0.25-5 ii libspeexdsp1 1.2~rc1-7 ii libstdc++64.7.2-5 ii libsystemd-daemon044-11+deb7u4 ii libsystemd-login0 44-11+deb7u4 ii libtdb1 1.2.10-2 ii libudev0 175-7.2 ii libwebrtc-audio-processing-0 0.1-2 ii libx11-6 2:1.5.0-1+deb7u1 ii libx11-xcb1 2:1.5.0-1+deb7u1 ii libxcb1 1.8.1-2+deb7u1 ii libxtst6 2:1.2.1-1+deb7u1 ii lsb-base 4.1+Debian8+deb7u1 ii udev 175-7.2 Versions of packages pulseaudio recommends: ii gstreamer0.10-pulseaudio 0.10.31-3+nmu1 pn pulseaudio-module-x11 none pn rtkit none Versions of packages pulseaudio suggests: ii paman 0.9.4-1 ii paprefs 0.9.10-1 ii pavucontrol 1.0-1 ii pavumeter 0.9.3-4 ii pulseaudio-utils 2.0-6.1 -- 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#737083: pulseaudio: ALSA cannot be used directly when pulseaudio is installed
package pulseaudio retitle 737083 pulseaudio: let ALSA alone be still easy to use by non administrators severity 737083 normal thanks On Thu, Jan 30, 2014 at 03:42:09AM +0100, G.raud wrote: Note that the function loaded by the afore-mentioned file is named 'conf_load_if_running', which suggests that it should load the files that set pulse as the default ouput device only if pulseaudio is already running, but in fact it starts pulseaudio itself. Setting 'autospawn = no' in $HOME/.pulse/client.conf (or /etc/pulse/client.conf) changes the behaviour of the ALSA hook to not autostart pulseaudio. This should be the default as it allows one to still use ALSA as before when pulseaudio has not been started and because most users requiring pulseaudio either know how to start it or will have it started by an X session or GNOME. There should still be a way to clear the config of '/usr/share/alsa/alsa.conf.d/pulse.conf' by a user without administrative privileges, for those who know that they do not want to run pulseaudio and would not want to find themselves using it without knowing. PS. Please add to README.Debian an explanation of how to do disable pulseaudio: how to disbale the autostart of the X session (both system-wide and per user) and how to disable the automatic switching of ALSA to pulseaudio. Whether you change the default config of client.conf or not, you should document 'autospawn = no' too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719757: openmotif: please package the man-pages separately so that they can be installed along with Lesstif
Package: openmotif Version: openmotif Severity: wishlist Having the OpenMotif manual pages in a separate package libmotif-doc instead of inside libmotif-dev would allow this new package not to conflict with any Lesstif packages; thus it would be possible to have some Motif manual pages installed along with Lesstif. Regards -- G.raud Meyer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715243: RFP: ngjackpsa -- simple LADSPA hosts for the JACK Audio Connection Kit
Package: wnpp Severity: wishlist * Package name : ngjackpsa Version : 1.0 Upstream Author : G.raud Meyer graud chez gmx.com * URL : https://gna.org/projects/ngjackspa * License : GPL v2 Programming Lang: C, C++ Description : simple LADSPA hosts for the JACK Audio Connection Kit ng-jackspa is a set of simple user interfaces that host a LADSPA plugin, providing JACK ports for its audio inputs and outputs, and dynamic setting of its control inputs. Additionally, the plugin controls can be exported to or controlled by control voltages on standard JACK audio ports. For a better description see the online documentation at http://home.gna.org/ngjackspa/. All the dependencies are already part of Debian (LADSPA SDK, JACK, ncurses, gtkmm-2.4, Qt 4, glib-2.0). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#473917: emacs22: not Debian specific (Please document that `show-paren-mode' is influenced by `blink-matching-paren-distance')
This is not Debian specific and minor. I lost control of my address @hotmail.com; can I close this bug nonetheless? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547469: (no subject)
found 547469 23.2+1-7+squeeze1 thanks should this bug, originally submitted against emacs22, be cloned for emacs23? should it be tagged upstream and submitted upstream? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556794: Bug #556794 fixed (sh-mode[bash]: in `#$(date)' date highlighted as a program inside a comment)
fixed 556794 23.2+1-7+squeeze1 thanks The version stable does not exhibit this bug anymore. I do not know when it was fixed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547469: cloned for emacs23 (perl-mode: $' not recognized as a variable)
clone 547469 -1 reassign -1 emacs23-common 23.2+1-7+squeeze1 thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697911: perl-mode: $' is not recognized as a var but as a start of a string instead
Package: emacs23-common Version: 23.2+1-7+squeeze1 Severity: normal This is Bugs #526715 and #547469 reported again against emacs23 instead of emacs22 (because it failed to be cloned). $ cat EOF test.pl #!/usr/bin/perl $_ = 'truc'; /ru/; print $'; print \n; EOF $ emacs23 -q test.pl It is strange that this problem was marked as fixed in emacs22 yet is found in emas23. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697912: sh-mode[bash]: $# ${#param} $? not highlighted as parameters
Package: emacs23-common
Version: 23.2+1-7+squeeze1
Severity: normal
This is Bug #526715 reported again against emacs23 instead of emacs22.
The parameters ${#param}, $#, $? are highlighted correctly in
sh-mode[sh] but not in sh-mode[bash].
$ cat EOF test.sh
#!/bin/sh
echo $# $? $$ ${#SHELL} ${SHELL}
EOF
$ cat EOF test.bash
#!/bin/bash
echo $# $? $$ ${#SHELL} ${SHELL}
EOF
$ emacs23 -q test.sh test.bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537043: in Debian! (vorbisgain: invalid tempfile name (longer than 255 chars))
found 537043 0.37-2 tags - upstream tags + patch thanks This bug never existed in upstream, so I untagged upstream. This bug is still present in the current sid (vorbisgain/0.37-2) but is changed in behaviour. vorbisgain does not crash anymore but fails to open the output file. $ vorbisgain $(perl -e 'print Ax236').ogg Analyzing files... Gain | Peak | Scale | New Peak | Track --++---+--+-- -4.47 dB | 34022 | 0.60 | 20336 | .ogg Couldn't open '' for output: No such file or directory The upstream version does not have this bug: $ ./vorbisgain $(perl -e 'print Ax251').ogg Analyzing files... Gain | Peak | Scale | New Peak | Track --++---+--+-- -4.47 dB | 34022 | 0.60 | 20336 | ../AAA.ogg Upstream has perfectly fixed the problem of the temp filename uniqueness by using mktemp() in version 0.37, whereas Debian has, for this version 0.37, updated its previous patch that used to fix the problem by introducing this bug relating to the size limit! Please remove the patch 0001-temp_files.patch that introduces a bug without fixing anything anymore. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686628: lnrename: rename.pl sibling to rename symlink targets
Package: perl Version: 5.14.2-12 Severity: wishlist Tags: patch I modified the Perl distribution file shipped with Debian that is named rename(.pl), so that it renames the target inside symlinks. It is joined to this message. The modified script, lnrename, is very useful when rename.pl is used and there are symbolic links pointing to the renamed files, since a similar command can fix broken symlinks. In Debian there is currently nothing similar available yet, to my knowledge, at least nothing that is not graphical. I think it should be included in the perl deb because it is based on rename that is already there. If it cannot, can you suggest a package that could include it? The name `lnrename' is just a suggestion. -- G.raud lnrename Description: Attachment: lnrename
Bug#686408: ksh: trap: resetting an ignored signal to default gives unpredictable result
Package: ksh
Version: 93u+20120628-1
Severity: normal
Dear Maintainer,
With this script:
$ cat EOF sigtest.sh
#!/bin/ksh
function f {
trap - INT
sleep 2
}
trap '' INT
f
trap -p INT
sleep 2
EOF
the `trap -p INT' statement gives a strange result with non-printable chars,
whether the f Korn-style function was interrupted or not by SIGINT. It shows
that the handler of SIGINT in the shell was modified by f; according to the
manpage, that should not happen. If the script is interrupted after f has
returned, I get the error message:
^C./sig_test.sh[9]: weird_data: not found [No such file or directory]
The strange result can be for example ` új81'. The fact that the script fails
to execute any handler is certainly a bug.
Something not too surprising would be to have `trap - INT' inside a Korn
function make the trap exit the function, as if no `trap '' INT' had been given
before the call to f, which is what happens when the signal is not ignored.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (800, 'unstable'), (500, 'stable-updates'), (500, 'testing'),
(500, 'stable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 2.6.32-5-core2 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages ksh depends on:
ii libc6 2.13-35
ksh recommends no packages.
ksh 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#621797: moc: Mono mixing switch does not work
I confirm that moc:amd64 has this bug in versions 2.5.0~alpha4+svn20120224-1 (stable) and 2.5.0~alpha4+svn20091009-1+b2 (unstable) wether with jack or alsa output, and that moc:i386 stable does not have this bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658425: better patches (script: new option to return the exit status of the forked command)
The first patch sent with the bug report did not allow script to fail in the case where the forked command did not exit normally, which makes it of little use if one really needs to detect a failure. I join two patches, only one of which can be applied (the second is richer in features): * both patches will make 'script -e' return the exit status of the forked command (if there is one) * both patches will make 'script -ee' fail if the forked command does not exit normally (for example if it is killed) * one patch will furthermore make 'script -eee' raise the same signal that killed the forked command, so that script wraps the forked command transparently; for example this will make an interactive shell report the error associated with the signal that killed the forked command This a request for upstream, but it can be applied in Debian only since the change is backward compatible (the behaviour changes only if the -e option is given), and it can be reviewed by the Debian maintainer before being possibly submitted upstream. Regards util-linux-2.17.2_script-ee.20120213.patch Description: Attachment: util-linux-2.17.2_script-ee.20120213.patch util-linux-2.17.2_script-eee.20120213.patch Description: Attachment: util-linux-2.17.2_script-eee.20120213.patch
Bug#658425: script: new option to return the exit status of the forked command
Source: util-linux Version: 2.17.2-9 Severity: wishlist Tags: patch From the man page of script: -c This makes it easy for a script to capture the output of a program that behaves differently when its stdout is not a tty. I think it should be possible to furthermore capture the exit status of the program. For example: $ script -c e2fsck -v /dev/foo e2fsck.log used in a script does not allow one to know if the check failed or not (without analyzing the log), and piping the output of fsck instead of wrapping it with script makes fsck refuse to do an interactive repair. That's why I wrote a patch, attached to this mail, that adds a command line option -e that makes script exit with the same exit status as the monitored program. util-linux_script-e.20120201.patch Description: Attachment: util-linux_script-e.20120201.patch
