Bug#895170: desktop-file-utils: won't configure because of XDG_DATA_DIRS
Package: desktop-file-utils Version: 0.23-3 Severity: important Dear Maintainer, * What led up to the situation? I was installing debian in a chroot. The installation of desktop-file-utils failed at the configuration step. * What exactly did you do (or not do) that was effective (or ineffective)? dpkg --configure desktop-file-utils would fail without explaining the reason, except to say that the configuration script failed. I ran the /var/lib/dpkg/info/desktop-file-utils.postinst script manually without the -q option to update-desktop-database and found out that it was complaining about paths from the environment, then used env | grep to identify the culprit: the environment variable XDG_DATA_DIRS had an inappropriate value inherited from outside the chroot. Note that XDG defines several environment variables, and that system configuration scripts should ignore all such user variables. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.86 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages desktop-file-utils depends on: ii libc6 2.27-3 ii libglib2.0-0 2.56.0-4 desktop-file-utils recommends no packages. desktop-file-utils suggests no packages. -- no debconf information
Bug#580310: /usr/lib/common-lisp/bin/gclcvs.sh is way out of date
Package: gclcvs Version: 2.7.0-99 Severity: grave Tags: squeeze Justification: renders package unusable /usr/lib/common-lisp/bin/gclcvs.sh is outdated. Note only does it use the wrong package for clc, if you fix that bug, the script still doesn't work. Note that making GCL work with CLC might require ASDF 1.716, which was recently modified for GCL. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (600, 'unstable'), (550, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gclcvs depends on: ii common-lisp-controller 7.2 Common Lisp source and compiler ma ii debconf 1.5.32 Debian configuration management sy ii emacs [emacsen] 23.1+1-5 The GNU Emacs editor (metapackage) ii emacs23 [emacsen] 23.1+1-5 The GNU Emacs editor (with GTK+ us ii gcc 4:4.4.2-3The GNU C compiler ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library ii libreadline66.1-1GNU readline and history libraries ii libx11-62:1.3.3-3X11 client-side library ii tcl8.4 8.4.19-4 Tcl (the Tool Command Language) v8 ii tk8.4 8.4.19-4 Tk toolkit for Tcl and X11, v8.4 - ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime gclcvs recommends no packages. Versions of packages gclcvs suggests: pn gclcvs-docnone (no description available) -- debconf information excluded -- debsums errors found: debsums: changed file /usr/lib/common-lisp/bin/gclcvs.sh (from gclcvs package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572538: gclcvs dies at startup when run by non-root user
Package: gclcvs Version: 2.7.0-98 Severity: grave Justification: renders package unusable gclcvs just dies at startup when run by non-root user, and strace shows nothing but this: execve(/usr/lib/gcl-2.7.0/unixport/saved_ansi_gcl, [/usr/lib/gcl-2.7.0/unixport/save..., -eval, (quit)], [/* 97 vars */] unfinished ... +++ killed by SIGKILL +++ or execve(/usr/lib/gcl-2.7.0-prof//unixport/saved_ansi_gcl, [/usr/lib/gcl-2.7.0-prof//unixpor...], [/* 97 vars */] unfinished ... +++ killed by SIGKILL +++ I was wondering how come clc could compile its thing at all, and found that root has no problem running gcl: strace -o /tmp/foo /usr/lib/gcl-2.7.0/unixport/saved_ansi_gcl -eval '(quit)' GCL (GNU Common Lisp) 2.7.0 ANSIFeb 3 2010 05:59:20 Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl) Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC) Modifications of this banner must retain notice of a compatible license Dedicated to the memory of W. Schelter Use (help) to get some basic information on how to use GCL. Temporary directory for compiler files set to /tmp/root/ ~ more /tmp/foo execve(/usr/lib/gcl-2.7.0/unixport/saved_ansi_gcl, [/usr/lib/gcl-2.7.0/unixport/save..., -eval, (quit)], [/* 99 vars */]) = 0 brk(0) = 0x2a05000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7febd0566000 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory) I tried running a program that does brk(0) and it works. SIGKILL is particularly interesting error to get. Maybe I'm hitting some kind of limit? Yet I have never had problem in the past. Either running as a user or as root, I have: # limit cputime unlimited filesizeunlimited datasizeunlimited stacksize 8MB coredumpsize0kB memoryuse unlimited maxproc unlimited descriptors 1024 memorylockedunlimited addressspaceunlimited maxfilelocksunlimited sigpending 16382 msgqueue819200 nice0 rt_priority 99 This is weird. Has been happening for many months, but I have only started looking into it now. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (600, 'unstable'), (550, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gclcvs depends on: ii common-lisp-controller 7.1 Common Lisp source and compiler ma ii debconf1.5.27Debian configuration management sy ii emacs [emacsen]23.1+1-5 The GNU Emacs editor (metapackage) ii emacs-snapshot [emacse 1:20091002-1 The GNU Emacs editor (development ii emacs-snapshot-nox [em 1:20091002-1 The GNU Emacs editor (without X su ii emacs23 [emacsen] 23.1+1-5 The GNU Emacs editor (with GTK+ us ii gcc4:4.3.3-9 The GNU C compiler ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libgmp3c2 2:4.3.1+dfsg-3Multiprecision arithmetic library ii libreadline6 6.0-5 GNU readline and history libraries ii libx11-6 2:1.2.2-1 X11 client-side library ii tcl8.4 8.4.19-4 Tcl (the Tool Command Language) v8 ii tk8.4 8.4.19-4 Tk toolkit for Tcl and X11, v8.4 - ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime gclcvs recommends no packages. Versions of packages gclcvs suggests: pn gclcvs-docnone (no description available) -- debconf information: gclcvs/default_gcl_prof: gclcvs/default_gcl_ansi: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#371077: mount: Installing nfs-common solved this problem for me. Error message was unhelpful.
Package: mount Version: 2.13.1.1-1 Followup-For: Bug #371077 I had the same bug (or is it really the same? if my solution doesn't solve it for the submitter, we should split this bug in two). A NFS share I knew worked on a nearly identical machine had stopped working on a modified clone, with the same useless error message: mount: wrong fs type, bad option, bad superblock on foo.bar:/baz/quux/, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.type helper program) In some cases useful info is found in syslog - try dmesg | tail or so After I apt-get install nfs-common (which had been removed by aptitude when I had removed the nfs server from the clone), it worked well. Indeed, the newly required /sbin/mount.nfs program is in said package. The debian version of mount should probably have a more useful error message and explicitly suggest installing the nfs-common package. So this is a documentation bug at this point. The upstream program should also recognize the condition and have a more explicit error message. Debian needs to override the message anyway. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.2-42.asl.2.intel.fc3 (SMP w/4 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mount depends on: ii libblkid1 1.41.3-1 block device id library ii libc6 2.7-16 GNU C Library: Shared libraries ii libselinux1 2.0.65-5 SELinux shared libraries ii libuuid1 1.41.3-1 universally unique id library mount recommends no packages. Versions of packages mount suggests: ii nfs-common1:1.1.4-1 NFS support files common to client -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504103: free() error in dash under memory pressure
Package: dash Version: 0.5.4-9 Severity: normal I ran the cl-launch integrated test suite, a shell script that may be overstressing the string allocation in dash, and got the error: *** glibc detected *** dash: free(): invalid pointer: 0x0805d740 *** I don't know what causes this, and it's not 100% reproducible, as some runs of my test suite exhibit the bug (at different stages of the test), and some do not. In any case, dash seems to be doing a double free or something. To maybe reproduce the bug, you can get cl-launch_2.09.sh as well as a few common lisp implementations, and run the test suite in a temporary directory then dash may eventually bork after a few hundreds of tests. mkdir /tmp/foo cd /tmp/foo wget http://fare.tunes.org/files/cl-launch/cl-launch_2.09.sh apt-get install clisp gcl gclcvs cmucl sbcl ./cl-launch_2.09.sh -l 'clisp cmucl gcl gclcvs sbcl' -B eval 'TEST_SHELLS=dash ; tests' I get the following failure: ../cl-launch_2.09.sh -l 'gcl gclcvs clisp cmucl sbcl' -B eval 'TEST_SHELLS=dash ; tests' Using test shell dash cl-launch --lisp gcl --no-include --init ... --execute -- ... success with test 00 :-) cl-launch --lisp gcl --no-include --init ... --output ... ; out.sh ... success with test 01 :-) cl-launch --lisp clisp --include ... --file ... --init ... --output ... ; out.sh ... success with test 253 :-) cl-launch --lisp clisp --update ... --include ... --file ... --init ... --execute -- ... *** glibc detected *** dash: free(): invalid pointer: 0x0805d740 *** === Backtrace: = /lib/i686/cmov/libc.so.6[0xb7dfd614] /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7dff816] dash[0x805168f] dash[0x804c071] dash[0x804b8c2] dash[0x804beee] dash[0x804b10c] dash[0x804b18f] dash[0x804b10c] dash[0x804b10c] dash[0x804ba1f] dash[0x804bf6f] dash[0x804b10c] dash[0x804b10c] dash[0x804b3c8] dash[0x804b10c] dash[0x804b10c] dash[0x804ba1f] dash[0x804bf6f] dash[0x804b10c] dash[0x804ba1f] dash[0x804bf6f] dash[0x804b10c] dash[0x804b18f] dash[0x804b18f] dash[0x804ba1f] dash[0x804bf6f] dash[0x804b10c] dash[0x804b10c] dash[0x804ba1f] dash[0x804bf6f] dash[0x804b10c] dash[0x804b10c] dash[0x804b18f] dash[0x804ba1f] dash[0x804bf6f] dash[0x804b10c] dash[0x804b10c] dash[0x804b10c] dash[0x804b3c8] dash[0x804b10c] dash[0x804b2b1] dash[0x804b10c] dash[0x804b10c] dash[0x804ba1f] dash[0x804bf6f] dash[0x804b10c] dash[0x804b18f] dash[0x804ba1f] dash[0x804bf6f] dash[0x804b10c] dash[0x804b18f] dash[0x80512ca] dash[0x805153e] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7da5455] dash[0x8049821] === Memory map: 08048000-0805b000 r-xp 07:05 169968 /bin/dash 0805b000-0805c000 rw-p 00013000 07:05 169968 /bin/dash 0805c000-080a rw-p 0805c000 00:00 0 [heap] b7c0-b7c21000 rw-p b7c0 00:00 0 b7c21000-b7d0 ---p b7c21000 00:00 0 b7d81000-b7d8d000 r-xp 07:05 164511 /lib/libgcc_s.so.1 b7d8d000-b7d8e000 rw-p b000 07:05 164511 /lib/libgcc_s.so.1 b7d8e000-b7d8f000 rw-p b7d8e000 00:00 0 b7d8f000-b7ee4000 r-xp 07:05 341456 /lib/i686/cmov/libc-2.7.so b7ee4000-b7ee5000 r--p 00155000 07:05 341456 /lib/i686/cmov/libc-2.7.so b7ee5000-b7ee7000 rw-p 00156000 07:05 341456 /lib/i686/cmov/libc-2.7.so b7ee7000-b7eea000 rw-p b7ee7000 00:00 0 b7f0b000-b7f0d000 rw-p b7f0b000 00:00 0 b7f0d000-b7f27000 r-xp 07:05 880776 /lib/ld-2.7.so b7f27000-b7f29000 rw-p 0001a000 07:05 880776 /lib/ld-2.7.so bfd1-bfd27000 rw-p bfd1 00:00 0 [stack] e000-f000 ---p 00:00 0 [vdso] FAILURE with test 254 :-( You may restart from this test with: ./cl-launch_2.09.sh -l gcl gclcvs clisp cmucl sbcl -B tests 254 or ./cl-launch_2.09.sh -l gcl gclcvs clisp cmucl sbcl -B tests 252 You may re-run just this test with: ./cl-launch_2.09.sh -B redo_test dash clisp exec update inc1 file init -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.16.9-blefuscu Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dash depends on: ii libc6 2.7-12 GNU C Library: Shared libraries dash recommends no packages. -- debconf information: dash/sh: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469178: gclcvs 2.7.0-84 uninstallable: requires exact obsolete version of binutils-dev
Package: gclcvs Version: 2.7.0-84 Severity: grave Justification: renders package unusable The package has a binutils-dev (= 2.18.1~cvs20071027-999) requirement that makes it unusable for anyone that didn't install it precisely when that now obsolete version of binutils was current. Why such a requirement? The mind boggles. No wonder no one has installed a new gclcvs in ages... Package: gclcvs Priority: optional Section: interpreters Installed-Size: 176772 Maintainer: Camm Maguire [EMAIL PROTECTED] Architecture: i386 Version: 2.7.0-84 Depends: binutils-dev (= 2.18.1~cvs20071027-999), binutils-dev (= 2.18.1~cvs20071027-1), common-lisp-controller, debconf (= 1.2.0), emacs22 | emacsen, gcc, libc6 (= 2.7-1), libgmp3c2, libice6 (= 1:1.0.0), libncurses5 (= 5.6+20071006-3), libreadline5 (= 5.2), libsm6, libx11-6, libxaw7, libxext6, libxmu6, libxt6, tcl8.4 (= 8.4.5), tk8.4 (= 8.4.5) Suggests: gclcvs-doc Filename: pool/main/g/gclcvs/gclcvs_2.7.0-84_i386.deb -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.16.9-blefuscu Locale: LANG=en_US, LC_CTYPE=en_US.iso-8859-1 (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US.iso-8859-1) Shell: /bin/sh linked to /bin/bash -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382582: common-lisp-controller: c-l-c fails to exclude /usr/lib/sbcl and such from cache
Package: common-lisp-controller Version: 6.2 Severity: minor While compiling a program with sbcl and c-l-c, I realized that c-l-c wasn't excluding directories such as /usr/lib/sbcl from its cache, recompiling in-cache fasl's for source code instead of using the precompiled fasl's. Same applies for other lisp implementations. cl-launch fixed a similar with its function exclude-from-cache. Note: if c-l-c ends up using the very same mechanism as cl-launch, it would be nice if the interface was similar enough that cl-launch could just import the relevant symbols in a #+common-lisp-controller. In any case, you're welcome to borrow code from cl-launch. PS: I see you depend on a package named realpath. In debian systems, readlink --canonicalize now does the same thing. Of course, in older Linux systems, BSD systems, etc., readlink doesn't have option --canonicalize. Sigh. PPS: unrelatedly, I found more bugs in cl-launch and ECL when using a system, and the bug has a long reach when the system has dependencies. Sigh. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.9-blefuscu Locale: LANG=en_US.iso-8859-1, LC_CTYPE=en_US.iso-8859-1 (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US.iso-8859-1) Versions of packages common-lisp-controller depends on: ii bash 3.1-5 The GNU Bourne Again SHell ii cl-asdf 1.99-2 Another System Definition Facility ii debconf [debconf-2.0] 1.5.2 Debian configuration management sy ii debianutils 2.16.2 Miscellaneous utilities specific t ii perl 5.8.8-6Larry Wall's Practical Extraction ii realpath 1.10 Return the canonicalized absolute common-lisp-controller recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382247: gclcvs segfaults during c-l-c initialization
Package: gclcvs Version: 2.7.0-54 Severity: grave Justification: renders package unusable gclcvs.sh seems to not have been updated for the latest common-lisp-controller, and dies horribly on both i386 and amd64 architectures. On amd64, the error is as follows: COMMON-LISP-CONTROLLER/usr/lib/common-lisp/bin/gclcvs.sh: line 58: 7556 Bus error $gcl_bin !INSTALL_CLC! On i386, I get the following error instead: COMMON-LISP-CONTROLLERSegmentation violation: c stack ok:signalling error/usr/lib/common-lisp/bin/gclcvs.sh: line 58: 6462 Segmentation fault $gcl_bin !INSTALL_CLC! Full log (on i386) follows. Note that bug #347560 still bites me when I try to remove the package: a directory '/' is created, and the feeble attempt to remove it with rm fails; rmdir would be required instead. --8--8--8--8--8--8--8--8--8-- Unpacking gclcvs (from .../gclcvs_2.7.0-54_i386.deb) ... Setting up gclcvs (2.7.0-54) ... gclcvs.sh Uninstalling clc image and purging object cache ... chown: `cl-builder.cl-builder': invalid user rm: cannot remove `': Is a directory gclcvs.sh Installing clc as /usr/lib/gcl-2.7.0/unixport/saved_clc_gcl ... GCL (GNU Common Lisp) 2.7.0 ANSIDec 23 2005 04:17:17 Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd) Binary License: GPL due to GPL'ed components: (READLINE BFD UNEXEC) Modifications of this banner must retain notice of a compatible license Dedicated to the memory of W. Schelter Use (help) to get some basic information on how to use GCL. #COMMON-LISP package COMMON-LISP NIL COMMON-LISP #COMMON-LISP-USER package Loading /usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp Finished loading /usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp T #COMMON-LISP-CONTROLLER package COMMON-LISP-CONTROLLERSegmentation violation: c stack ok:signalling error/usr/lib/common-lisp/bin/gclcvs.sh: line 58: 6462 Segmentation fault $gcl_bin !INSTALL_CLC! (in-package :common-lisp) (unless (fboundp 'load-time-value) (defun load-time-value (obj) obj) (export (find-symbol LOAD-TIME-VALUE))) (in-package :common-lisp-user) (load $clc_src/common-lisp-controller/common-lisp-controller.lisp) (in-package :common-lisp-controller) (init-common-lisp-controller $gcl_clc :version 3) (defun send-clc-command (command package) Overrides global definition. (multiple-value-bind (exit-code signal-code) (si::system (c-l-c:make-clc-send-command-string command package gclcvs)) (if (and (zerop exit-code) (zerop signal-code)) (values) (error Error during ~A of ~A for ~A~%Please see /usr/share/doc/common-lisp-controller/REPORTING-BUGS.gz (ecase command (:recompile recompilation) (:remove removal)) package gclcvs (in-package :asdf) (defun run-shell-command (control-string rest args) Interpolate ARGS into CONTROL-STRING as if by FORMAT, and synchronously execute the result using a Bourne-compatible shell, with output to *verbose-out*. Returns the shell's exit code. (let ((command (apply #'format nil control-string args))) (format *verbose-out* ; $ ~A~% command) (si::system command) ; even less *verbose-out* )) (si:save-system $image)) !INSTALL_CLC! Error building send-clc-command dpkg: error processing gclcvs (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: gclcvs E: Sub-process /usr/bin/dpkg returned an error code (1) --8--8--8--8--8--8--8--8--8-- # dpkg --purge gclcvs (Reading database ... 263914 files and directories currently installed.) Removing gclcvs ... gclcvs.sh Uninstalling clc and restoring pristine orig image ... rm: cannot remove `': Is a directory gclcvs.sh Uninstalling clc and restoring pristine orig image ... rm: cannot remove `': Is a directory remove/gclcvs: purging byte-compiled files for emacs21 remove/gclcvs: purging byte-compiled files for xemacs21 Purging configuration files for gclcvs ... --8--8--8--8--8--8--8--8--8-- -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages gclcvs depends on: ii debconf [debconf-2.0] 1.5.2 Debian configuration management sy ii gcc 4:4.1.1-5 The GNU C compiler ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-3 Multiprecision arithmetic library ii libncurses5 5.5-2 Shared libraries for terminal hand ii libreadline5 5.1-7 GNU
