Bug#325950: NMU to DELAYED-5
hello, i fixed that bug in an NMU to DELAYED-5 on gluck. if nobody objects, the packages will reach unstable within 5-6 days. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325993: NMU and patch
hello, i just uploaded a NMU to fix that bug into the DELAYED-5 queue on gluck. the patch is attached. ... jonas diff -rNu fuse-2.3.0.orig/debian/fuse-utils.postrm fuse-2.3.0/debian/fuse-utils.postrm --- fuse-2.3.0.orig/debian/fuse-utils.postrm2005-10-03 00:13:59.0 +0200 +++ fuse-2.3.0/debian/fuse-utils.postrm 2005-10-03 00:19:39.0 +0200 @@ -12,24 +12,21 @@ } case $1 in + remove) +dpkg-statoverride --remove /usr/bin/fusermount 2/dev/null || true + ;; + purge) ucf --purge $CONFFILE rm -f $CONFFILE -dpkg-statoverride --remove /usr/bin/fusermount 2/dev/null || true ;; failed-upgrade|upgrade) ;; - remove) -if is_true $FUSE_GROUPDELETE [[ -n $FUSE_GROUP ]]; then - dpkg-statoverride --remove /usr/bin/fusermount 2/dev/null || true - fi - ;; - *) echo postrm called with unknown argument \`$1' 2 -exit 1 +exit 0 ;; esac
Bug#325993: NMU and patch
sorry, here is the complete patch (forgot to insert changelog entry last
time).
...
jonas
diff -rNu fuse-2.3.0.orig/config.log fuse-2.3.0/config.log
--- fuse-2.3.0.orig/config.log 1970-01-01 01:00:00.0 +0100
+++ fuse-2.3.0/config.log 2005-10-03 00:34:45.0 +0200
@@ -0,0 +1,266 @@
+This file contains any messages produced by compilers while
+running configure, to aid debugging if configure makes a mistake.
+
+It was created by fuse configure 2.3.0, which was
+generated by GNU Autoconf 2.59. Invocation command line was
+
+ $ ./configure --host=i486-linux-gnu --build=i486-linux-gnu --prefix=/usr
--mandir=${prefix}/share/man --infodir=${prefix}/share/info
--disable-kernel-module
+
+## - ##
+## Platform. ##
+## - ##
+
+hostname = resivo
+uname -m = i686
+uname -r = 2.6.12-9-amd64
+uname -s = Linux
+uname -v = #1 Fri Sep 23 11:23:57 CEST 2005
+
+/usr/bin/uname -p = unknown
+/bin/uname -X = unknown
+
+/bin/arch = i686
+/usr/bin/arch -k = unknown
+/usr/convex/getsysinfo = unknown
+hostinfo = unknown
+/bin/machine = unknown
+/usr/bin/oslevel = unknown
+/bin/universe = unknown
+
+PATH: /home/jonas/bin
+PATH: /usr/local/bin
+PATH: /usr/bin
+PATH: /bin
+PATH: /usr/bin/X11
+PATH: /usr/games
+
+
+## --- ##
+## Core tests. ##
+## --- ##
+
+configure:1522: checking for a BSD-compatible install
+configure:1577: result: /usr/bin/install -c
+configure:1588: checking whether build environment is sane
+configure:1631: result: yes
+configure:1696: checking for gawk
+configure:1725: result: no
+configure:1696: checking for mawk
+configure:1712: found /usr/bin/mawk
+configure:1722: result: mawk
+configure:1732: checking whether make sets $(MAKE)
+configure:1752: result: yes
+configure:1951: checking build system type
+configure:1969: result: i486-pc-linux-gnu
+configure:1977: checking host system type
+configure:1991: result: i486-pc-linux-gnu
+configure:2011: checking for style of include used by make
+configure:2039: result: GNU
+configure:2072: checking for i486-linux-gnu-gcc
+configure:2088: found /usr/bin/i486-linux-gnu-gcc
+configure:2098: result: i486-linux-gnu-gcc
+configure:2380: checking for C compiler version
+configure:2383: i486-linux-gnu-gcc --version /dev/null 5
+i486-linux-gnu-gcc (GCC) 4.0.2 (Debian 4.0.2-1)
+Copyright (C) 2005 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions. There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+configure:2386: $? = 0
+configure:2388: i486-linux-gnu-gcc -v /dev/null 5
+Using built-in specs.
+Target: i486-linux-gnu
+Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release i486-linux-gnu
+Thread model: posix
+gcc version 4.0.2 (Debian 4.0.2-1)
+configure:2391: $? = 0
+configure:2393: i486-linux-gnu-gcc -V /dev/null 5
+i486-linux-gnu-gcc: '-V' option must have argument
+configure:2396: $? = 1
+configure:2419: checking for C compiler default output file name
+configure:2422: i486-linux-gnu-gcc -Wall -g -O2 conftest.c 5
+configure:2425: $? = 0
+configure:2471: result: a.out
+configure:2476: checking whether the C compiler works
+configure:2482: ./a.out
+configure:2485: $? = 0
+configure:2502: result: yes
+configure:2509: checking whether we are cross compiling
+configure:2511: result: no
+configure:2514: checking for suffix of executables
+configure:2516: i486-linux-gnu-gcc -o conftest -Wall -g -O2 conftest.c 5
+configure:2519: $? = 0
+configure:2544: result:
+configure:2550: checking for suffix of object files
+configure:2571: i486-linux-gnu-gcc -c -Wall -g -O2 conftest.c 5
+configure:2574: $? = 0
+configure:2596: result: o
+configure:2600: checking whether we are using the GNU C compiler
+configure:2624: i486-linux-gnu-gcc -c -Wall -g -O2 conftest.c 5
+configure:2630: $? = 0
+configure:2633: test -z || test ! -s conftest.err
+configure:2636: $? = 0
+configure:2639: test -s conftest.o
+configure:2642: $? = 0
+configure:2655: result: yes
+configure:2661: checking whether i486-linux-gnu-gcc accepts -g
+configure:2682: i486-linux-gnu-gcc -c -g conftest.c 5
+configure:2688: $? = 0
+configure:2691: test -z || test ! -s conftest.err
+configure:2694: $? = 0
+configure:2697: test -s conftest.o
+configure:2700: $? = 0
+configure:2711: result: yes
+configure:2728: checking for i486-linux-gnu-gcc option to accept ANSI C
+configure:2798: i486-linux-gnu-gcc -c -Wall
Bug#325993: NMU and patch
i don't know what's the matter today, but the build of fuse is somehow screwed up, and therefore even the second patch was not enough. finally, here's the correct one. ... jonas diff -rNu fuse-2.3.0.orig/debian/changelog fuse-2.3.0/debian/changelog --- fuse-2.3.0.orig/debian/changelog2005-10-03 00:42:04.0 +0200 +++ fuse-2.3.0/debian/changelog 2005-10-03 00:41:39.0 +0200 @@ -1,3 +1,11 @@ +fuse (2.3.0-4.1) unstable; urgency=low + + * Non-maintainer upload. + * run 'dpkg-statoverride --remove ...' at remove time (closes: +#325993) + + -- Jonas Meurer [EMAIL PROTECTED] Mon, 3 Oct 2005 00:40:58 +0200 + fuse (2.3.0-4) unstable; urgency=low * Added info about fuse-source in fuse-utils. (Closes: #322549) diff -rNu fuse-2.3.0.orig/debian/fuse-utils.postrm fuse-2.3.0/debian/fuse-utils.postrm --- fuse-2.3.0.orig/debian/fuse-utils.postrm2005-10-03 00:42:04.0 +0200 +++ fuse-2.3.0/debian/fuse-utils.postrm 2005-10-03 00:40:49.0 +0200 @@ -12,24 +12,21 @@ } case $1 in + remove) +dpkg-statoverride --remove /usr/bin/fusermount 2/dev/null || true + ;; + purge) ucf --purge $CONFFILE rm -f $CONFFILE -dpkg-statoverride --remove /usr/bin/fusermount 2/dev/null || true ;; failed-upgrade|upgrade) ;; - remove) -if is_true $FUSE_GROUPDELETE [[ -n $FUSE_GROUP ]]; then - dpkg-statoverride --remove /usr/bin/fusermount 2/dev/null || true - fi - ;; - *) echo postrm called with unknown argument \`$1' 2 -exit 1 +exit 0 ;; esac
Bug#325950: patch for the NMU
hello, here is the patch for the NMU. only a changelog entry, as rebuilding the package is sufficient. ... jonas diff -rNu graveman-0.3.12-4.orig/debian/changelog graveman-0.3.12-4/debian/changelog --- graveman-0.3.12-4.orig/debian/changelog 2005-10-03 00:46:47.0 +0200 +++ graveman-0.3.12-4/debian/changelog 2005-10-02 02:49:59.0 +0200 @@ -1,3 +1,10 @@ +graveman (0.3.12-4-2.1) unstable; urgency=low + + * Non-maintainer upload. + * rebuilt against libflac7 for flac transition (closes: #325950) + + -- Jonas Meurer [EMAIL PROTECTED] Sun, 2 Oct 2005 02:49:57 +0200 + graveman (0.3.12-4-2) unstable; urgency=low * debian/patches/10_de.po.patch: Added. Thanks to Jens Seidel
Bug#321816: NMU to close 3 bugs
hello,
i just uploaded a NMU that fixes 3 bugs to the DELAYED-5 queue on
gluck. patch is attached.
...
jonas
diff -rNu siege-2.61.orig/debian/changelog siege-2.61/debian/changelog
--- siege-2.61.orig/debian/changelog2005-10-03 01:39:01.0 +0200
+++ siege-2.61/debian/changelog 2005-10-03 01:32:51.0 +0200
@@ -1,3 +1,15 @@
+siege (2.61-2.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * add single quotes to the EOF in utils/siege.config.in (closes:
+#323684)
+ * apply patch from Robert Waldner [EMAIL PROTECTED] to fix construction of
+http headers (closes: #329182)
+ * install sample siegerc to /etc/siege and use that if no ~/.siegerc
+exists. use patch from tollef fog heen. (closes: #321816)
+
+ -- Jonas Meurer [EMAIL PROTECTED] Mon, 3 Oct 2005 01:32:10 +0200
+
siege (2.61-2) unstable; urgency=low
* Fixed siege.config scropt. Closes: #306952.
diff -rNu siege-2.61.orig/debian/rules siege-2.61/debian/rules
--- siege-2.61.orig/debian/rules2005-10-03 01:39:01.0 +0200
+++ siege-2.61/debian/rules 2005-10-03 01:38:16.0 +0200
@@ -49,7 +49,7 @@
dh_installdirs /usr/bin /etc/siege
# Add here commands to install the package into debian/siege.
- $(MAKE) install prefix=$(CURDIR)/debian/siege
+ $(MAKE) install prefix=$(CURDIR)/debian/siege
SIEGERC=$(CURDIR)/debian/siege/etc/siege
# fix unquoted _EOF_ in siege.config
sed -e 23 s/_EOF_/'_EOF_'/
$(CURDIR)/debian/siege/usr/bin/siege.config
$(CURDIR)/debian/siege/usr/bin/siege.config.new
diff -rNu siege-2.61.orig/src/hash.c siege-2.61/src/hash.c
--- siege-2.61.orig/src/hash.c 2003-07-09 22:22:38.0 +0200
+++ siege-2.61/src/hash.c 2005-10-03 01:27:33.0 +0200
@@ -182,6 +182,7 @@
int x;
NODE *node;
+ if (key == NULL) { return 1; }
x = hash_genkey( this-size, key );
for( node = this-table[x]; node != NULL; node = node-next ){
if( !strcmp( node-key, key )){
diff -rNu siege-2.61.orig/src/http.c siege-2.61/src/http.c
--- siege-2.61.orig/src/http.c 2004-11-19 15:47:21.0 +0100
+++ siege-2.61/src/http.c 2005-10-03 01:28:52.0 +0200
@@ -374,7 +374,11 @@
else{
h-auth.type.proxy = BASIC;
}
- tmp = strchr( line, '=' );
+ tmp = strchr( line, ':' );
+ if (tmp == NULL) {
+printf(I shat myself so hard..\n);
+return NULL;
+ }
tmp++;
if( tmp[0] == '' ){ tmp++; tmp[strlen(tmp)-1] = '\0'; }
strncpy( h-auth.realm.proxy, tmp, strlen( tmp ));
diff -rNu siege-2.61.orig/utils/siege.config.in siege-2.61/utils/siege.config.in
--- siege-2.61.orig/utils/siege.config.in 2004-09-11 19:13:13.0
+0200
+++ siege-2.61/utils/siege.config.in2005-10-03 01:21:44.0 +0200
@@ -20,4 +20,4 @@
echo
exit
fi
-cat $rcfile _EOF_
+cat $rcfile '_EOF_'
Bug#314976: NMU in DELAYED-5
hello, i just uploaded directvnc_0.7.5-6.1 to the DELAYED-5 upload queue on gluck. it is built against the latest libdirectfb (0.9.22-7). patch is attached. ... jonas diff -rNu directvnc-0.7.5.orig/debian/changelog directvnc-0.7.5/debian/changelog --- directvnc-0.7.5.orig/debian/changelog 2005-10-03 17:23:48.0 +0200 +++ directvnc-0.7.5/debian/changelog2005-10-03 17:23:28.0 +0200 @@ -1,3 +1,14 @@ +directvnc (0.7.5-6.1) unstable; urgency=low + + * Non-maintainer upload. + * rebuild against libdirectfb-0.9-22 for transition (closes: #314976) + * bumped standards-version to 3.6.2 (no changes needed) + * updated fsf address to make lintian happy + * change xlibs-dev Build-Depends to x-dev, after searching docs and source +i believe that only some x headers are needed to build. + + -- Jonas Meurer [EMAIL PROTECTED] Mon, 3 Oct 2005 17:22:37 +0200 + directvnc (0.7.5-6) unstable; urgency=low * Documented display size restriction, closes: #248009. diff -rNu directvnc-0.7.5.orig/debian/control directvnc-0.7.5/debian/control --- directvnc-0.7.5.orig/debian/control 2005-10-03 17:23:48.0 +0200 +++ directvnc-0.7.5/debian/control 2005-10-03 17:22:31.0 +0200 @@ -2,8 +2,8 @@ Section: misc Priority: optional Maintainer: Ola Lundqvist [EMAIL PROTECTED] -Build-Depends: debhelper ( 4.0.0), libdirectfb-dev (= 0.9.20-1), zlib1g-dev, libjpeg62-dev, pkg-config, xlibs-dev -Standards-Version: 3.5.10 +Build-Depends: debhelper ( 4.0.0), libdirectfb-dev (= 0.9.22-7), zlib1g-dev, libjpeg62-dev, pkg-config, x-dev +Standards-Version: 3.6.2 Package: directvnc Architecture: any diff -rNu directvnc-0.7.5.orig/debian/copyright directvnc-0.7.5/debian/copyright --- directvnc-0.7.5.orig/debian/copyright 2005-10-03 17:23:48.0 +0200 +++ directvnc-0.7.5/debian/copyright2005-10-03 16:45:35.0 +0200 @@ -29,5 +29,5 @@ You should have received a copy of the GNU General Public License with your Debian GNU/Linux system, in /usr/share/common-licenses/GPL, or with the debarchiver source package as the file COPYING. If not, write to the Free - Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA - 02111-1307, USA. + Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + 02110-1301, USA.
Bug#325993: NMU and patch
On 04/10/2005 Bartosz Fenski aka fEnIo wrote: On Mon, Oct 03, 2005 at 12:29:38AM +0200, Jonas Meurer wrote: i just uploaded a NMU to fix that bug into the DELAYED-5 queue on gluck. the patch is attached. I doubt it was DELAYED-5 since it's now available in archive. Anyway thanks for fixing it, cause I'm rather busy now. you're correct. accidentally i uploaded it to DELAYED-0 instead of DELAYED-5. sorry for that. ... jonas signature.asc Description: Digital signature
Bug#333460: fonty silently overwrites /etc/console-tools/config.d/fonty
Package: fonty Version: 1.0-23 Severity: serious Justification: Policy 10.7.3 hello, the latest upgrade of fonty has overwritten my local settings in /etc/console-tools/config.d/fonty. It would be better to handle this file as a configuration file as defined in the debian policy. The upgrade did not even preserve a backup copy (for example a .dpkg-old file), it just erased my local settings. There are several cases where local modifications are required in /etc/console-tools/config.d/fonty, especially as the debconf configuration dialog at install/upgrade does not list fonts from other packages (like fonty-rg). It would be great if that could be improved. ... jonas -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-1-amd64 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages fonty depends on: ii console-data2002.12.04dbs-49 Keymaps, fonts, charset maps, fall ii console-tools 1:0.2.3dbs-57Linux console and font utilities ii debconf [debconf-2.0] 1.4.58 Debian configuration management sy fonty recommends no packages. -- debconf information: * fonty/charset: iso15 (Western European + euro) * fonty/restart: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306906: python2.2-mysqldb: Connection leak
On 29/04/2005 Daniel Knauth wrote: The mysql-python version shipped with Debian 3.1 has a connection leak that makes the database unusable if any Python client is under load. Obviously, this affects *all* mysql clients, not just Python clients. It has been fixed in the upstream mysql-python 1.2.0 release. a new python-mysqldb version with python2.2 support is uploaded to unstable, but as python2.2-mysqldb is considered as 'new' in unstable, it is hold in the NEW queue. to close this rc bug but still keep python2.2-mysqldb in sarge, i'dd suggest to push the new 1.2.1c2-1 python-mysqldb into sarge. bye jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325973: qscintilla: rebuild for c++ transition [NMU prepared]
Package: qscintilla
Version: 1.5.1-1
Severity: grave
Tags: patch
Justification: renders package unusable
hello,
qscintilla needs to be rebuild for the c++ transition. i prepared a NMU
and uploaded as 5-day NMU.
see the attached patch.
bye
jonas
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-8-amd64
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
diff -rNu qscintilla-1.5.1.old/debian/changelog
qscintilla-1.5.1/debian/changelog
--- qscintilla-1.5.1.old/debian/changelog 2005-09-01 01:51:41.0
+0200
+++ qscintilla-1.5.1/debian/changelog 2005-09-01 01:52:15.0 +0200
@@ -1,3 +1,17 @@
+qscintilla (1.5.1-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * build against latest libqt3-mt and libstdc++6 for c++ abi transition
+ * rename libqscintilla5 to libqscintilla5c2, make both library and devel
+packages conflict with libqscintilla5
+ * adapt versions for libqt3-mt-dev and qt3-dev-tools at build-depends
+ * remove g++ from build-depends as it's build-essential anyway
+ * add '-rm -f qt/Makefile' to section in debian/rules, as suggested at
+bugs.debian.org/267408
+I don't close the bug as i don't know whether that finally fixes it.
+
+ -- Jonas Meurer [EMAIL PROTECTED] Wed, 31 Aug 2005 23:07:41 +0200
+
qscintilla (1.5.1-1) unstable; urgency=low
* New upstream release
diff -rNu qscintilla-1.5.1.old/debian/control qscintilla-1.5.1/debian/control
--- qscintilla-1.5.1.old/debian/control 2005-09-01 01:51:41.0 +0200
+++ qscintilla-1.5.1/debian/control 2005-09-01 01:52:15.0 +0200
@@ -3,13 +3,15 @@
Priority: optional
Maintainer: Ricardo Javier Cardenes Medina [EMAIL PROTECTED]
Uploaders: Torsten Marek [EMAIL PROTECTED]
-Build-Depends: debhelper ( 4.0.0), libqt3-mt-dev (= 3:3.1.1), qt3-dev-tools
(= 3:3.1.1-2), g++ (= 2:3.2)
-Standards-Version: 3.6.1.0
+Build-Depends: debhelper ( 4.0.0), libqt3-mt-dev (= 3:3.3.4), qt3-dev-tools
(= 3:3.3.4)
+Standards-Version: 3.6.2
-Package: libqscintilla5
+Package: libqscintilla5c2
Section: libs
Architecture: any
Depends: ${shlibs:Depends}
+Conflicts: libqscintilla5
+Replaces: libqscintilla5
Description: Qt source code editing component based on Scintilla
Scintilla is a free source code editing component. It has features found
in standard editing components, as well as features especially useful
@@ -20,8 +22,8 @@
Package: libqscintilla-dev
Section: libdevel
Architecture: all
-Depends: libqscintilla5 (= ${Source-Version})
-Conflicts: libqscintilla0c102 ( 0.3-5)
+Depends: libqscintilla5c2 (= ${Source-Version})
+Conflicts: libqscintilla5
Description: Qt source code editing component - development files
Scintilla is a free source code editing component. It has features found
in standard editing components, as well as features especially useful
diff -rNu qscintilla-1.5.1.old/debian/libqscintilla5.install
qscintilla-1.5.1/debian/libqscintilla5.install
--- qscintilla-1.5.1.old/debian/libqscintilla5.install 2005-09-01
01:51:41.0 +0200
+++ qscintilla-1.5.1/debian/libqscintilla5.install 1970-01-01
01:00:00.0 +0100
@@ -1,3 +0,0 @@
-usr/lib/*.so.*
-usr/lib/qt3/plugins/designer/*.so
-usr/share/qt3/translations/*.qm
diff -rNu qscintilla-1.5.1.old/debian/libqscintilla5c2.install
qscintilla-1.5.1/debian/libqscintilla5c2.install
--- qscintilla-1.5.1.old/debian/libqscintilla5c2.install1970-01-01
01:00:00.0 +0100
+++ qscintilla-1.5.1/debian/libqscintilla5c2.install2005-09-01
01:52:15.0 +0200
@@ -0,0 +1,3 @@
+usr/lib/*.so.*
+usr/lib/qt3/plugins/designer/*.so
+usr/share/qt3/translations/*.qm
diff -rNu qscintilla-1.5.1.old/debian/rules qscintilla-1.5.1/debian/rules
--- qscintilla-1.5.1.old/debian/rules 2005-09-01 01:51:41.0 +0200
+++ qscintilla-1.5.1/debian/rules 2005-09-01 01:52:15.0 +0200
@@ -60,6 +60,7 @@
-$(MAKE) -C qt clean
-$(MAKE) -C designer clean
-find -name 'Makefile' -exec rm {} \;
+ -rm -f qt/Makefile
-rm -rf tmplib
dh_clean
Bug#325977: sip-qt3: rebuild for c++ transition [NMU]
Package: sip-qt3
Version: 3.10.2-1
Severity: grave
Tags: patch
Justification: renders package unusable
hello,
i rebuilt sip-qt3 against new libqt3-mt and libstdc++6 and
made a 5-day NMU for sip-qt3.
see attached patch.
bye
jonas
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-8-amd64
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
diff -rNu sip-qt3-3.10.2.old/debian/changelog sip-qt3-3.10.2/debian/changelog
--- sip-qt3-3.10.2.old/debian/changelog 2005-09-01 02:08:34.0 +0200
+++ sip-qt3-3.10.2/debian/changelog 2005-09-01 02:09:34.0 +0200
@@ -1,3 +1,15 @@
+sip-qt3 (3.10.2-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * build against latest libqt3-mt and libstdc++6 for c++ abi transition
+(closes: #)
+ * adapt versions for libqt3-mt-dev and qt3-dev-tools at build-depends
+ * build-depend on python2.3 instead of python (= 2.3), python ( 2.4)
+ * remove python2.2-sip-dev|python2.1-sip-dev from sip suggests, as these
+packages don't even exist.
+
+ -- Jonas Meurer [EMAIL PROTECTED] Thu, 1 Sep 2005 02:06:56 +0200
+
sip-qt3 (3.10.2-1) unstable; urgency=low
* New upstream release
diff -rNu sip-qt3-3.10.2.old/debian/control sip-qt3-3.10.2/debian/control
--- sip-qt3-3.10.2.old/debian/control 2005-09-01 02:08:34.0 +0200
+++ sip-qt3-3.10.2/debian/control 2005-09-01 02:06:33.0 +0200
@@ -2,13 +2,13 @@
Section: devel
Priority: optional
Maintainer: Ricardo Javier Cardenes Medina [EMAIL PROTECTED]
-Build-Depends: debhelper (= 4.0.0), python (= 2.3), python ( 2.4),
python-dev, libqt3-mt-dev (= 3:3.1.1), qt3-dev-tools (= 3:3.1.1-2), autoconf,
bison, flex
+Build-Depends: debhelper (= 4.0.0), python2.3, python-dev, libqt3-mt-dev (=
3.3.4-7), qt3-dev-tools (= 3:3.3.4-7), autoconf, bison, flex
Standards-Version: 3.5.10
Package: sip
Architecture: any
Depends: ${shlibs:Depends}
-Recommends: python2.3-sip-dev|python2.2-sip-dev|python2.1-sip-dev
+Recommends: python2.3-sip-dev
Conflicts: libsip
Description: Python/C++ bindings generator
SIP is a tool for generating bindings for C++ classes with some ideas
Bug#325982: sip4-qt3: rebuild for c++ transition (NMU)
Package: sip4-qt3 Version: 4.2.1-1 Severity: grave Tags: patch Justification: renders package unusable hello, i rebuilt sip4-qt3 against libqt3-mt-dev and libstdc++6 and uploaded that as a 5-day NMU. see attached patch. bye jonas -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-8-amd64 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) diff -rNu sip4-qt3-4.2.1.old/debian/changelog sip4-qt3-4.2.1/debian/changelog --- sip4-qt3-4.2.1.old/debian/changelog 2005-09-01 03:21:37.0 +0200 +++ sip4-qt3-4.2.1/debian/changelog 2005-09-01 03:20:07.0 +0200 @@ -1,3 +1,12 @@ +sip4-qt3 (4.2.1-1.1) unstable; urgency=low + + * Non-maintainer upload. + * build against latest libqt3-mt and libstdc++6 for c++ abi transition +(closes: ) + * adapt versions for libqt3-mt-dev and qt3-dev-tools at build-depends + + -- Jonas Meurer [EMAIL PROTECTED] Thu, 1 Sep 2005 03:18:40 +0200 + sip4-qt3 (4.2.1-1) unstable; urgency=low * New upstream release diff -rNu sip4-qt3-4.2.1.old/debian/control sip4-qt3-4.2.1/debian/control --- sip4-qt3-4.2.1.old/debian/control 2005-09-01 03:21:37.0 +0200 +++ sip4-qt3-4.2.1/debian/control 2005-09-01 03:20:51.0 +0200 @@ -3,8 +3,8 @@ Priority: optional Maintainer: Ricardo Javier Cardenes Medina [EMAIL PROTECTED] Uploaders: Torsten Marek [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.0.0), python, python2.3-dev, python2.4-dev, libqt3-mt-dev (= 3:3.1.1), qt3-dev-tools (= 3:3.1.1-2) -Standards-Version: 3.6.1.0 +Build-Depends: debhelper (= 4.0.0), python, python2.3-dev, python2.4-dev, libqt3-mt-dev (= 3:3.3.3), qt3-dev-tools (= 3:3.3.3-7) +Standards-Version: 3.6.2 Package: sip4 Architecture: any
Bug#326035: valknut: rebuild for c++ transition [NMU]
Package: valknut Version: 0.3.7-1 Severity: grave Tags: patch Justification: renders package unusable hello, i rebuilt valknut against latest libstdc++6 and libqt3-mt for the c++ transition. see attached patch. bye jonas -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-8-amd64 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) diff -rNu valknut-0.3.7.old/debian/changelog valknut-0.3.7/debian/changelog --- valknut-0.3.7.old/debian/changelog 2005-09-01 13:19:49.0 +0200 +++ valknut-0.3.7/debian/changelog 2005-09-01 13:18:13.0 +0200 @@ -1,3 +1,12 @@ +valknut (0.3.7-1.1) unstable; urgency=low + + * Non-maintainer upload. + * rebuilt against libstdc++6 and libqt3-mt for c++ transition (closes: +#) + * fix a small typo in package description (closes: #310846) + + -- Jonas Meurer [EMAIL PROTECTED] Thu, 1 Sep 2005 13:16:55 +0200 + valknut (0.3.7-1) unstable; urgency=high * New upstream release (Closes: #289643, #269952, #265284, #270096, #286234) diff -rNu valknut-0.3.7.old/debian/control valknut-0.3.7/debian/control --- valknut-0.3.7.old/debian/control2005-09-01 13:19:49.0 +0200 +++ valknut-0.3.7/debian/control2005-09-01 13:21:37.0 +0200 @@ -13,7 +13,7 @@ Connect. Valknut was earlier known as dcgui-qt. . Valknut has many features, such as searching on all public servers without - connecting, downloading a file from multible locations, connecting to + connecting, downloading a file from multiple locations, connecting to multiple servers, and support for multiple languages. Package: dcgui-qt @@ -21,4 +21,4 @@ Depends: valknut Description: Dummy package for upgrading dcgui-qt to valknut This package depends valknut, a renamed dcgui-qt. This can be safely - removed after update. \ No newline at end of file + removed after update.
Bug#325973: qscintilla: rebuild for c++ transition [NMU prepared]
On 01/09/2005 Ricardo Javier Cardenes Medina wrote: qscintilla needs to be rebuild for the c++ transition. i prepared a NMU and uploaded as 5-day NMU. see the attached patch. We were waiting for the new stable release to rebuild and upload. This is specially interesting for QScintilla, as the soname changes an so there is no need to add the c2 to the package name. I'll remove the NMU and upload the new package. ok, that's great. bye jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325973: NMU patch is wrong
On 01/09/2005 Matthias Klose wrote: The patch must not remove the existing conflicts. thanks for the hint. anyway the maintainer will remove the NMU and upload a new version. bye jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326035: valknut: rebuild for c++ transition [NMU]
severity 326035 normal thanks On 01/09/2005 Steve Langasek wrote: i rebuilt valknut against latest libstdc++6 and libqt3-mt for the c++ transition. see attached patch. Valknut depends on libdc0, which has not yet undergone the C++ ABI transition. Although you may have been able to build valknut on one architecture, there's no guarantee that it will build on all archs before libdc0c2 is uploaded, due to ABI incompatibilities. you're correct. i've removed the valknut NMU files from gluck.debian.org:~tfheen/DELAYED/3-day/ and canceled the NMU this way. the bugreport has been downgraded to normal. sorry, i simply missed the depend on libdc0 when checking the build-depends. ...jonas signature.asc Description: Digital signature
Bug#398799: modprobe -q dm-crypt breaks initscripts
Package: cryptsetup Version: 2:1.0.4-8 Severity: grave Justification: renders package unusable unfortunately we introduced a new RC bug in cryptsetup 1.0.4-7. The initscripts both should use 'set -e' and therefore fail for every single error that occurs. unfortunately the 'modprobe -q dm-crypt' at do_start() in cryptdisks.functions fails if the module isn't present: $ modprobe -q dm-crypt || echo failed failed $ one way would be to remove the 'set -e' from the initscripts, but in bug #390354 Goswin Brederlow asked for 'set -e' in the initscripts explicitely. what do you think about the bug? i would prefer a way where modprobe is only run when the module is available, but i don't know of any easy way to implement that. if you've no simple solution either, maybe we should remove the 'set -e' for now and search for better solutions post etch. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355156: [Pkg-cryptsetup-devel] Bug#355156: cryptsetup: luksOpen does not work with readonly media anymore
On 03/03/2006 Bastian Kleineidam wrote: after upgrading cryptsetup I was not able to use luksOpen on a DVD image file. Downgrading to 2:1.0.1-16 makes it work again, so something in the upgrade broke things. Here is the command line log with the old 1.0.1 version: $ cryptsetup --readonly luksOpen /dev/hdc _image Enter LUKS passphrase: key slot 0 unlocked. $ .. and the new version: $ cryptsetup --readonly luksOpen /dev/hdc _image Enter LUKS passphrase: Aufruf fehlgeschlagen: No key available with this passphrase. hello bastian, could you try whether the --readonly flag works for normal encrypted filesystems on a harddisk? for me it works. how do you create encrypted cds/dvds? do you use a patched cdrecord? ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355156: [Pkg-cryptsetup-devel] Bug#355156: cryptsetup: luksOpen does not work with readonly media anymore
On 09/03/2006 Bastian Kleineidam wrote: You wrote: Do you have the image still on disk? Can you try to open it via the loopback driver? losetup /dev/loopX image cryptsetup --readonly /dev/loopX _image The losetup case works. Everything I do on disk works fine, only on DVD it fails. I debugged a little and found out that the difference between disk and DVD is the lib/utils.c:sector_size() return value: for my disc (dev/hdaX), it is 512, on DVD (/dev/hdc) it is 2048. The sector size is used in the read_blockwise() function, together with some alignment code I don't really grok. Perhaps this is where things go wrong? i've tried to reproduce this bug, and indeed luksOpen fails for me with a similar error message. i tried also plain dm-crypt, and discovered that 'cryptsetup create' doesn't fail. the created device is mountable and contains all the data which i put into the encrypted iso image. in other words, the bug must be related to luks, it's not reproducible when using plain dm-crypt. just wanted to let you know, in case that you are not already aware of it. ... jonas signature.asc Description: Digital signature
Bug#355156: [Pkg-cryptsetup-devel] Bug#355156: cryptsetup: luksOpen does not work with readonly media anymore
On 12/03/2006 Clemens Fruhwirth wrote: Execuse me for being not highly verbose on this issue. I mailed Bastian in private a tarball with a fix. I haven't Cc'ed bugs.debian.org as I was not sure whether the bug tracking system handles attachments correctly. (Does it?) yes, the but tracking system works perfectly well with attachments. However, we fixed the bug. The problem was that I restricted the length (number of sectors) of a temporary dm-crypt mapping. However for devices with non-512 sector size like DVDs, the length as well as the start must be aligned to (device_sector_size/512). I will wrap up an rc3 as soon as I have had time to take care of your error message proposals. great. would you like to send me the patch for this 'readonly' bug anyway? i plan to upload a new package within the next days, as i fixed some minor bugs and added support for openssl encrypted keyfiles. it would be great to have a fix for this bug as well. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397012: idesk segfaults
On 04/11/2006 Steve Langasek wrote: On Sat, Nov 04, 2006 at 01:34:30PM +0100, Jonas Meurer wrote: since some time now, idesk segfaults on my system. I even tried to rebuild the package, but that doesn't help. see the output of 'strace idesk' attached. Please provide a gdb backtrace, not just an strace. I guess that it is not very helpful, as idesk is built with dh_strip. anway, see it attached. ... jonas [EMAIL PROTECTED]:~$ gdb idesk GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /usr/bin/idesk (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Idesk starting in :0.0 [idesk] Background's source not found. Cannot determine file extension of: (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Unknown file format: Program received signal SIGSEGV, Segmentation fault. 0x2ac6ef33e1ff in __imlib_SetMaxXImageCount () from /usr/lib/libImlib2.so.1 (gdb) detach Detaching from program: /usr/bin/idesk, process 14682 (gdb) quit [EMAIL PROTECTED]:~$
Bug#397012: idesk segfaults
On 05/11/2006 Steve Langasek wrote: anway, see it attached. Program received signal SIGSEGV, Segmentation fault. 0x2ac6ef33e1ff in __imlib_SetMaxXImageCount () from /usr/lib/libImlib2.so.1 (gdb) detach Detaching from program: /usr/bin/idesk, process 14682 (gdb) quit [EMAIL PROTECTED]:~$ This isn't a backtrace. Please get a backtrace using the 'bt' command within gdb. sorry. i hope to have the correct output attached this time. if it would be helpful to rebuild idesk with debugging information and run strace/gdb against this package, i could do this as well. i just don't know how to do that exactly, but maybe removing dh_strip from debian/rules is all i need to do? ... jonas [EMAIL PROTECTED]:~$ gdb idesk GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /usr/bin/idesk (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Idesk starting in :0.0 [idesk] Background's source not found. Cannot determine file extension of: (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Unknown file format: Program received signal SIGSEGV, Segmentation fault. 0x2ac6ef33e1ff in __imlib_SetMaxXImageCount () from /usr/lib/libImlib2.so.1 (gdb) bt #0 0x2b6141b201ff in __imlib_SetMaxXImageCount () from /usr/lib/libImlib2.so.1 #1 0x0030 in ?? () #2 0x0030 in ?? () #3 0x005ec930 in ?? () #4 0x00553440 in ?? () #5 0x2b6141ae8d14 in imlib_blend_image_onto_image () from /usr/lib/libImlib2.so.1 #6 0x0040b708 in ?? () #7 0x00408b6c in ?? () #8 0x004053ae in ?? () #9 0x00405beb in ?? () #10 0x004069e5 in ?? () #11 0x00406a6e in ?? () #12 0x0042e113 in std::operator+char, std::char_traitschar, std::allocatorchar () #13 0x00430444 in std::operator+char, std::char_traitschar, std::allocatorchar () #14 0x2b61426d34ca in __libc_start_main () from /lib/libc.so.6 #15 0x00404bca in ?? () #16 0x7fff69402d18 in ?? () #17 0x in ?? () (gdb) detach Detaching from program: /usr/bin/idesk, process 14682 (gdb) quit [EMAIL PROTECTED]:~$
Bug#397012: idesk segfaults
On 05/11/2006 Anibal Avelar wrote: Do you have some directory inside of .idesktop directory? or Did you define the Background.Source tag with some directory inside of .idesktop directory? because the program has a bug with this. Please move the directory to other location. I don't know if this fix your problem. Please, you cand send me the .ideskrc file and the output for the comand ls -la .idesktop i neither have any directories inside ~/.idesktop/ nor have a background image stored there. See the ~/.ideskrc file attached. content of ~/.idesktop is: [EMAIL PROTECTED]:~$ ls -la ~/.idesktop/ total 80 drwxr-xr-x 2 jonas jonas 4096 Oct 27 15:44 . drwxr-x--x 108 jonas jonas 8192 Nov 5 21:18 .. -rw-r--r-- 1 jonas jonas 152 Sep 9 14:51 audacity.lnk -rw-r--r-- 1 jonas jonas 201 Sep 12 06:02 cdrom1.lnk -rw-r--r-- 1 jonas jonas 179 Sep 12 05:39 data.lnk -rw-r--r-- 1 jonas jonas 160 Sep 12 05:35 digikam.lnk -rw-r--r-- 1 jonas jonas 204 Oct 7 17:36 firefox.lnk -rw-r--r-- 1 jonas jonas 151 Sep 12 05:35 gimp.lnk -rw-r--r-- 1 jonas jonas 161 Oct 25 03:19 gnomebaker.lnk -rw-r--r-- 1 jonas jonas 155 Sep 12 05:35 gpdf.lnk -rw-r--r-- 1 jonas jonas 160 Sep 12 05:35 gvim.lnk -rw-r--r-- 1 jonas jonas 193 Sep 9 00:03 home.lnk -rw-r--r-- 1 jonas jonas 162 Sep 9 14:58 hydrogen.lnk -rw-r--r-- 1 jonas jonas 137 Sep 9 14:57 lmms.lnk -rw-r--r-- 1 jonas jonas 193 Sep 25 11:57 oowriter.lnk -rw-r--r-- 1 jonas jonas 174 Sep 9 14:56 rhythmbox.lnk -rw-r--r-- 1 jonas jonas 174 Sep 9 14:43 rosegarden.lnk -rw-r--r-- 1 jonas jonas 137 Oct 25 18:07 wired.lnk -rw-r--r-- 1 jonas jonas 174 Sep 12 05:34 xsmbrowser.lnk [EMAIL PROTECTED]:~$ I'm working in the 0.7.6 version. Soon it will be ready. Many bugs were fixed. drop me a line as soon as you've a package publically available. I look forward to test it. ... jonas table Config FontName: Arial FontSize: 12 FontColor: #7FB580 Locked: true Shadow: true ShadowColor: #4A4B21 ShadowX: 1 ShadowY: 2 Bold: false ClickDelay: 300 IconSnap: true SnapWidth: 100 SnapHeight: 100 SnapOrigin: TopLeft SnapShadow: false SnapShadowTrans: 200 CaptionPlacement: Bottom CaptionOnHover: false HighContrast: false FillStyle: FillHLine #FontNameTip: helvetica #FontSizeTip: 9 #ForeColorTip: #FF #BackColorTip: #FF #PaddingX: 10 #PaddingY: 10 #Transparency: 75 #ToolTip.FontSize: 11 #ToolTip.FontName: gothic #ToolTip.ForeColor: #FF #ToolTip.BackColor: #FF #ToolTip.CaptionOnHover: true #ToolTip.CaptionPlacement: Right #Background.Delay: 1 #Background.Source: /srv/data/images/bg/ Background.File: /srv/data/images/bg/zwille1280.jpg Background.Mode: Scale Background.Color: #00 end table Actions Lock: control right doubleClk Reload: middle doubleClk Drag: left hold EndDrag: left singleClk Execute[0]: left doubleClk Execute[1]: right doubleClk end
Bug#397012: idesk segfaults
On 06/11/2006 Steve Langasek wrote: i neither have any directories inside ~/.idesktop/ nor have a background image stored there. See the ~/.ideskrc file attached. I can't reproduce the crash on amd64 using the provided .ideskrc alone. Can you provide a minimal test case for the crash, including images and any parts of your .idesktop that are needed in order to trigger the crash? ok, even with only one file (gimp.lnk) in ~/.idesktop/, idesk crashes. I used the .ideskrc file that you already know, and the following inside ~/.idesktop/gimp.lnk: table Icon Caption: Gimp Icon: /usr/share/icons/crystalsvg/48x48/apps/gimp.png X: 30 Y: 730 Command[0]: /usr/bin/gimp CaptionTip: Gimp end Also, do you have any tiffs anywhere in your config? I notice that bug #381177 has just been closed in libimlib2... no, only png images. i could rebuild libimlib2 with DEB_BUILD_OPTIONS=nostrip and send again the gdb backtrace and strace output. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503101: [pkg-cryptsetup-devel] Bug#503101: cryptsetup: Cryptsetup kills wireless
Hey Michael, On 22/10/2008 Michael Pobega wrote: When I installed cryptsetup on my Eee PC (using debian-eeepc and the madwifi drivers) and rebooted, my wireless would not work. dmesg | tail would just say Wireless off everytime I turned it back on with Fn+2. After recovering /boot/initrd-`uname -r`.bak the wireless works again. I'm not exactly sure what about it killed it, but whatever cryptsetup appended to my initrd killed my wireless. I doubt that cryptsetup really stops your wireless from working. Instead, something else might have changed since you last recreated the initramfs file that causes this bug. What happens if you simply remove cryptsetup and regenerate the initramfs file afterwards? Is it possible to reproduce the bug over and over again (i.e: install cryptsetup - system is broken. remove cryptsetup - system works. install cryptsetup - system is broken. remove cryptsetup ...) greetings, jonas signature.asc Description: Digital signature
Bug#503101: [pkg-cryptsetup-devel] Bug#503101: Bug#503101: cryptsetup: Cryptsetup kills wireless
On 22/10/2008 Jonas Meurer wrote: On 22/10/2008 Michael Pobega wrote: When I installed cryptsetup on my Eee PC (using debian-eeepc and the madwifi drivers) and rebooted, my wireless would not work. dmesg | tail would just say Wireless off everytime I turned it back on with Fn+2. After recovering /boot/initrd-`uname -r`.bak the wireless works again. I'm not exactly sure what about it killed it, but whatever cryptsetup appended to my initrd killed my wireless. I doubt that cryptsetup really stops your wireless from working. Instead, something else might have changed since you last recreated the initramfs file that causes this bug. What happens if you simply remove cryptsetup and regenerate the initramfs file afterwards? Is it possible to reproduce the bug over and over again (i.e: install cryptsetup - system is broken. remove cryptsetup - system works. install cryptsetup - system is broken. remove cryptsetup ...) Hey, any news about the bug? I'm absolutely sure that your wifi troubles don't have anything to do with cryptsetup. Please provide more information. Unfortunately I'm unable to reproduce the bug, as I've no hardware with wireless hardware. greetings, jonas signature.asc Description: Digital signature
Bug#503101: [pkg-cryptsetup-devel] Bug#503101: cryptsetup: Cryptsetup kills wireless
package cryptsetup severity 503101 normal thanks On 25/10/2008 Michael Pobega wrote: On Sat, Oct 25, 2008 at 01:06:47AM +0200, Jonas Meurer wrote: On 22/10/2008 Jonas Meurer wrote: I doubt that cryptsetup really stops your wireless from working. Instead, something else might have changed since you last recreated the initramfs file that causes this bug. What happens if you simply remove cryptsetup and regenerate the initramfs file afterwards? Is it possible to reproduce the bug over and over again (i.e: install cryptsetup - system is broken. remove cryptsetup - system works. install cryptsetup - system is broken. remove cryptsetup ...) any news about the bug? I'm absolutely sure that your wifi troubles don't have anything to do with cryptsetup. Please provide more information. Unfortunately I'm unable to reproduce the bug, as I've no hardware with wireless hardware. I think the problem lies in HAL. When I keep the device activated it works fine, but if I use my hotkey (Fn+F2) the device refuses to reload, dmesg reports that the device didn't respond properly and couldn't be loaded. So did you test whether removing cryptsetup fixes the bug? Or does it appear with any new created initramfs file no mind whether cryptsetup ist installed or not? Please try to apt-get remove cryptsetup and make sure that the initramfs is recreated. On the other hand the functionality of your hotkey should not depend on the initramfs as long as you don't want to use the hotkey early in the boot process. I feel that I put this bug in the wrong place, I'll bring it up with madwifi when I get the chance, I'm sorry for wasting your time. No problem, better to report it against the wrong package than not to report it at all. Please try to debug it further to find out which package it belongs to. For now I simply lowered the severity to normal as we're in the last phase of lenny release process, and release-critical bugs delay the release even more. If you're confident that this bug is release-critical and thus needs to be fixed for lenny, you'll have to do further debugging, reasign it to the correct package, append more information about how to reproduce it and then raise the severity again. greetings, jonas signature.asc Description: Digital signature
Bug#493848: marked as done
On 09/08/2008 Debian Bug Tracking System wrote: Date: Sat, 09 Aug 2008 12:47:03 + From: Jonas Meurer [EMAIL PROTECTED] Subject: Bug#493848: fixed in cryptsetup 2:1.0.6-6 To: [EMAIL PROTECTED] Source: cryptsetup Source-Version: 2:1.0.6-6 We believe that the bug you reported is fixed in the latest version of cryptsetup, which is due to be installed in the Debian FTP archive: [...] Changes: cryptsetup (2:1.0.6-6) unstable; urgency=high . * Don't cat keyfile into pipe for do_noluks(). cryptsetup handles --key-file=- different for luks and plain dm-crypt mappings. This time really (closes: #493848). Thus again upload with urgency=high. Marco, Yussuf, Sebastian, could you give cryptsetup 2:1.0.6-6 a try an report whether it really fixes the bug for you? You can find the package at http://packages.debian.org/sid/cryptsetup Thanks in advance. greetings, jonas signature.asc Description: Digital signature
Bug#478268: [Pkg-cryptsetup-devel] Bug#478268: cryptsetup: LUKS device no more recognized at boot
On 28/04/2008 Luca Capello wrote: Hi there! With the (not so new) cryptsetup version [1], whichever LUKS passhprase I enter at boot I get the same error with 3 different kernels (2.6.24-1-amd64, 2.6.25-rc8-amd64 and 2.6.25-trunk-amd64): = device-mapper: table: 254:0: crypt: unknown target type device-mapper: ioctl: error adding target to table device-mapper: ioctl: device doesn't appear to be in the dev hash table. Command failed: No key available with this passhprase. = Hey Luca, is /dev/sda2 an encrypted root partition? If this is the case, then I believe that some issues with the initramfs scripts are the reason here. do you get a busybox rescue prompt after the cryptsetup failure? If so, please give us the output of 'cat /proc/modules'. You could also try running 'modprobe dm-mod dm-crypt sha256 aes' and then rerun /scripts/local-top/cryptroot. This is a bug in cryptsetup_2:1.0.6-1: simply downgrading to the previous version (2:1.0.6~pre1+svn45-1) is enough to solve it. Since I thought this could be caused by the default hash being changed to ripemd160, I (re)read the cryptsetup NEWS.Debian and then guessed I was OK (I use LUKS and the entire disk encryption has been set up by the Debian Installer). However, this doesn't seem the case, hence the severity set to critical. As you use luks encryption, the hash doesn't matter here. cryptsetup ignores hash settings for luks devices. To me it seems like some module is missing/not being loaded. But I might be wrong. As in /usr/share/doc/cryptsetup/README.initramfs.gz, since I use LUKS my /etc/crypttab contains a very simple line: sda2_crypt /dev/sda2 none luks That one looks correct. greetings, jonas signature.asc Description: Digital signature
Bug#478268: [Pkg-cryptsetup-devel] Bug#478268: cryptsetup: LUKS device no more recognized at boot
severity 478268 important thanks Hey Luca, On 28/04/2008 Luca Capello wrote: The only partion not encrypted on my system is /dev/sda1, i.e. /boot. Thus, /dev/sda2 is the LVM PV which contains /, /home, swap and four others /mnt LVs. I just tried to reproduce your bug, but so far I failed. I installed debian/testing with encrypted /dev/hda2 as LVM PV containing / and /home, and I used cryptsetup 1.0.6-1. At first boot after successfull install the system correctly starts the cryptroot partition. As you're the only one reporting this bug, I do believe that either your setup is broken or you discovered a cornercase. I'm thus downgrading severity to important. do you get a busybox rescue prompt after the cryptsetup failure? No busybox rescue prompt, after having failed for three times cryptsetup again starts asking me for the passhprase and after three more failures the system blocks (but I still see what I type) on: [...] And the machine restart :-( Booting with the break kernel option (as suggested at bug #466573 [1]) causes the machine to reboot before prompting for the cryptsetup password, at least with kernel 2.6.25-trunk-amd64. That's indeed strange. I'm not initramfs expert, but I thought that something like break=init or break=bottom should give you a rescue prompt. greetings, jonas signature.asc Description: Digital signature
Bug#487056: setting package to cryptsetup-udeb cryptsetup, tagging 487056
# Automatically generated email from bts, devscripts version 2.10.30 # via tagpending # # cryptsetup (2:1.0.6-3) unstable; urgency=low # # * Change reference to docbook xml v4.2 driver file from an online version #to a local one in the manpage files, as the build process should not #depend on internet access. Add docbook-xml to build-depends. Thanks to #Lucas Nussbaum [EMAIL PROTECTED]. (closes: #487056) # package cryptsetup-udeb cryptsetup tags 487056 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477203: [Pkg-cryptsetup-devel] Bug#477203: cryptsetup: LUKS passphrase sometimes in cleartext
On 21/04/2008 Daniel Blaschke wrote: I have an encrypted /home partition and usplash is installed. Whenever I'm not quick enough entering the LUKS passphrase, usplash times out and in order to continue the boot process I need to switch to tty 8 where I can enter the passphrase. And here's the security problem: As I type, the passphrase appears as cleartext on the screen... Hello Daniel, Could you try whether cryptsetup 1.0.6-2 fixes the bug? The way how the initramfs prompts for the passphrase has been changes in 1.0.6-2, an external binary called askpass has been introduces by David Härdeman and is used now for passphrase retrieval. We hope that askpass fixes the issue you described here. greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471576: audacious: Segmentation fault
Package: audacious Version: 1.5.0-1 Severity: grave Justification: renders package unusable Hello, Since some days, audacious segfaults on my debian/unstable amd64 system. Unfortunately it doesn't give any additional information: $ audacious Segmentation fault I removed ~/.config/audacious, but that didn't change the situation. Even rebuilding the package didn't fix the segfault. I might rebuild with debug symbols and provide the strace output within the next days, but currently i'm to busy to do so. greetings, jonas -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-4-amd64-resivo Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages audacious depends on: ii audacious-plugins 1.5.0-1 Base plugins for audacious ii dbus1.1.20-1 simple interprocess messaging syst ii gtk2-engines-pixbuf 2.12.9-2 Pixbuf-based theme for GTK+ 2.x ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libaudclient1 1.5.0-1 audacious D-Bus remote control lib ii libc6 2.7-9GNU C Library: Shared libraries ii libcairo2 1.4.14-1 The Cairo 2D vector graphics libra ii libdbus-1-3 1.1.20-1 simple interprocess messaging syst ii libdbus-glib-1-20.74-1 simple interprocess messaging syst ii libglib2.0-02.16.1-2 The GLib library of C routines ii libgtk2.0-0 2.12.9-2 The GTK+ graphical user interface ii libice6 2:1.0.4-1X11 Inter-Client Exchange library ii libmcs1 0.7.0-1 Abstraction library to store confi ii libmowgli1 0.6.1-1 a high performance development fra ii libpango1.0-0 1.20.0-1 Layout and rendering of internatio ii libsamplerate0 0.1.2-5 audio rate conversion library ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libx11-62:1.0.3-7X11 client-side library Versions of packages audacious recommends: ii audacious-plugins-extra 1.5.0-1Various extra plugins for audaciou ii unzip 5.52-10De-archiver for .zip files -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390794: apache2-mpm-prefork: /usr/sbin/apache2 not executable
Package: apache2-mpm-prefork Version: 2.2.3-1 Severity: grave Justification: renders package unusable hello, with the latest apache2-mpm-prefork upgrade, /usr/sbin/apache2 has become unexecutable. the permissions now are -rw-r--r--. /etc/init.d/apache2 therefore exites silently. ... jonas -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-amd64-resivo Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages apache2-mpm-prefork depends on: ii apache2.2-common2.2.3-1 Next generation, scalable, extenda ii libapr1 1.2.7-6 The Apache Portable Runtime Librar ii libaprutil1 1.2.7+dfsg-2 The Apache Portable Runtime Utilit ii libc6 2.3.6.ds1-5 GNU C Library: Shared libraries ii libdb4.34.3.29-6 Berkeley v4.3 Database Libraries [ ii libdb4.44.4.20-8 Berkeley v4.4 Database Libraries [ ii libexpat1 1.95.8-3.3 XML parsing C library - runtime li ii libldap22.1.30-13+b1 OpenLDAP libraries ii libpcre36.7-1Perl 5 Compatible Regular Expressi ii libpq4 8.1.4-7 PostgreSQL C client library ii libsqlite3-03.3.7-1 SQLite 3 shared library ii libuuid11.39-1.1 universally unique id library apache2-mpm-prefork recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409835: mixxx: freezes my system completely
Package: mixxx Version: 1.4.2-1.1 Severity: grave Justification: renders package unusable Hello, mixxx freezes my system when i start it in a terminal emulator. I guess that this is due to hardware acceleration, used for direct rendering. This discussion seems to discuss exactly the bug that i discovered: http://sourceforge.net/forum/forum.php?thread_id=1637045forum_id=156157 I don't know whether this bug is related to the amd64 architecture, or to my Matrox G450 graphics controller, so i set severity to grave. Here is the output of 'glxinfo': [EMAIL PROTECTED]:~$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig OpenGL vendor string: VA Linux Systems Inc. OpenGL renderer string: Mesa DRI G400 20050609 AGP 1x OpenGL version string: 1.2 Mesa 6.5.1 OpenGL extensions: GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_compression, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_logic_op, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_IBM_rasterpos_clip, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_OES_read_format, GL_SGIS_generate_mipmap, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x25 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x26 24 tc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x27 24 tc 0 24 0 r y . 8 8 8 0 0 0 0 16 16 16 0 0 0 Slow 0x28 24 tc 0 24 0 r . . 8 8 8 0 0 0 0 16 16 16 0 0 0 Slow 0x29 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x2a 24 tc 0 24 0 r . . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x2b 24 dc 0 24 0 r y . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x2c 24 dc 0 24 0 r . . 8 8 8 0 0 0 0 0 0 0 0 0 0 None 0x2d 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x2e 24 dc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 None 0x2f 24 dc 0 24 0 r y . 8 8 8 0 0 0 0 16 16 16 0 0 0 Slow 0x30 24 dc 0 24 0 r . . 8 8 8 0 0 0 0 16 16 16 0 0 0 Slow 0x31 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x32 24 dc 0 24 0 r . . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow display: :0 screen: 1 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
Bug#410821: mysql-server-5.0: mysqld dies with '*** glibc detected *** double free or corruption (!prev): 0x08dd1dd0 ***'
Package: mysql-server-5.0 Version: 5.0.32-3 Severity: grave Justification: causes non-serious data loss Hello, Since yesterday, we do have mysql crashs on one of our servers running debian/etch. We had this crash once yesterday night, and once today. The error log in /var/log/syslog is: Feb 13 17:02:32 merkur86 mysqld[15652]: *** glibc detected *** double free or corruption (!prev): 0x08b26088 *** Feb 13 17:02:32 merkur86 mysqld[15652]: mysqld got signal 6; Feb 13 17:02:32 merkur86 mysqld[15652]: This could be because you hit a bug. It is also possible that this binary Feb 13 17:02:32 merkur86 mysqld[15652]: or one of the libraries it was linked against is corrupt, improperly built, Feb 13 17:02:32 merkur86 mysqld[15652]: or misconfigured. This error can also be caused by malfunctioning hardware. Feb 13 17:02:32 merkur86 mysqld[15652]: We will try our best to scrape up some info that will hopefully help diagnose Feb 13 17:02:32 merkur86 mysqld[15652]: the problem, but since we have already crashed, something is definitely wrong Feb 13 17:02:32 merkur86 mysqld[15652]: and this may fail. Feb 13 17:02:32 merkur86 mysqld[15652]: Feb 13 17:02:32 merkur86 mysqld[15652]: key_buffer_size=16777216 Feb 13 17:02:32 merkur86 mysqld[15652]: read_buffer_size=131072 Feb 13 17:02:32 merkur86 mysqld[15652]: max_used_connections=16 Feb 13 17:02:32 merkur86 mysqld[15652]: max_connections=100 Feb 13 17:02:32 merkur86 mysqld[15652]: threads_connected=14 Feb 13 17:02:32 merkur86 mysqld[15652]: It is possible that mysqld could use up to Feb 13 17:02:32 merkur86 mysqld[15652]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K Feb 13 17:02:32 merkur86 mysqld[15652]: bytes of memory Feb 13 17:02:32 merkur86 mysqld[15652]: Hope that's ok; if not, decrease some variables in the equation. Feb 13 17:02:32 merkur86 mysqld[15652]: Feb 13 17:02:32 merkur86 mysqld[15652]: thd=0x8b186d0 Feb 13 17:02:32 merkur86 mysqld[15652]: Attempting backtrace. You can use the following information to find out Feb 13 17:02:32 merkur86 mysqld[15652]: where mysqld died. If you see no messages after this, something went Feb 13 17:02:32 merkur86 mysqld[15652]: terribly wrong... Feb 13 17:02:32 merkur86 mysqld[15652]: Cannot determine thread, fp=0xb0e78558, backtrace may not be correct. Feb 13 17:02:32 merkur86 mysqld[15652]: Stack range sanity check OK, backtrace follows: Feb 13 17:02:32 merkur86 mysqld[15652]: 0x81c0649 Feb 13 17:02:32 merkur86 mysqld[15652]: 0xb7cfb947 Feb 13 17:02:32 merkur86 mysqld[15652]: 0xb7cfd0c9 Feb 13 17:02:32 merkur86 mysqld[15652]: 0xb7d30fda Feb 13 17:02:32 merkur86 mysqld[15652]: 0xb7d3889f Feb 13 17:02:32 merkur86 mysqld[15652]: 0xb7d38942 Feb 13 17:02:32 merkur86 mysqld[15652]: 0x8484df3 Feb 13 17:02:32 merkur86 mysqld[15652]: 0x81dbc5d Feb 13 17:02:32 merkur86 mysqld[15652]: 0x81dd188 Feb 13 17:02:32 merkur86 mysqld[15652]: 0x81ddb94 Feb 13 17:02:32 merkur86 mysqld[15652]: 0xb7f640bd Feb 13 17:02:32 merkur86 mysqld[15652]: 0xb7d9e93e Feb 13 17:02:32 merkur86 mysqld[15652]: New value of fp=(nil) failed sanity check, terminating stack trace! Feb 13 17:02:32 merkur86 mysqld[15652]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved Feb 13 17:02:32 merkur86 mysqld[15652]: stack trace is much more helpful in diagnosing the problem, so please do Feb 13 17:02:32 merkur86 mysqld[15652]: resolve it Feb 13 17:02:32 merkur86 mysqld[15652]: Trying to get some variables. Feb 13 17:02:32 merkur86 mysqld[15652]: Some pointers may be invalid and cause the dump to abort... Feb 13 17:02:32 merkur86 mysqld[15652]: thd-query at (nil) is invalid pointer Feb 13 17:02:32 merkur86 mysqld[15652]: thd-thread_id=66 Feb 13 17:02:32 merkur86 mysqld[15652]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains Feb 13 17:02:32 merkur86 mysqld[15652]: information that should help you find out what is causing the crash. I already did this 'stack trace': [ copied the 0x... hex digits to mysqld.stack] # cp /usr/share/doc/mysql-server-5.0/mysqld.sym.gz # gzip -d mysqld.sym.gz # resolve_stack_dump -s mysqld.sym -n mysqld.stack 0x81c0649 handle_segfault + 681 0xb7cfb947 _end + -1352585609 0xb7cfd0c9 _end + -1352579591 0xb7d30fda _end + -1352366838 0xb7d3889f _end + -1352335921 0xb7d38942 _end + -1352335758 0x8484df3 free_root + 67 0x81dbc5d _Z16dispatch_command19enum_server_commandP3THDPcj + 509 0x81dd188 _Z10do_commandP3THD + 136 0x81ddb94 handle_one_connection + 2308 0xb7f640bd _end + -1350060563 0xb7d9e93e _end + -1351917970 We do have a mysql backup script running every 30 Minutes. Maybe this one is the reason for the crash, but regardless whatever the reason may be, mysqld should not crash ever. See the script mysql-backup.sh attached. ... jonas -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to
Bug#410821: Which data loss?
On 13/02/2007 Philippe Cloutier wrote: Justification: causes non-serious data loss Which data loss does this cause? The data that you submit before the server crashs. ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403426: [Pkg-cryptsetup-devel] Bug#403426: kernel corrupts LUKS partition header on arm
On 29/12/2006 Martin Michlmayr wrote: * Clemens Fruhwirth [EMAIL PROTECTED] [2006-12-29 11:52]: I just added the r!=bsize case to error checking and an error message as well. ... The changes are also in subversion. This particular change didn't make any difference. I still get the header conversion message when I only apply the patch from utils.c. Can you give me more information about this bug? I'm currently preparing a new upload of cryptsetup 1.0.4+svn22, which is identical with the current upstream svn snapshot. does this version fix bug #403426, or does it still occur? ... jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453692: hplip: 2.7.10-3 fails to build from source
Package: hpijs Version: 2.7.10-3 Severity: serious Justification: no longer builds from source hello, according to http://buildd.debian.org/build.cgi?pkg=hplip;ver=2.7.10-3 the package does not build from source on any of the architectures. that results in a new hpijs-ppds package being available on the mirrors, but being uninstallable as the required hpijs binary package is not built. greetings, jonas -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-6-amd64-resivo Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hpijs depends on: ii ghostscript [gs- 8.61.dfsg.1~svn8187-2.1 The GPL Ghostscript PostScript/PDF ii gs-gpl 8.61.dfsg.1~svn8187-2.1 Transitional package ii libc62.7-3 GNU C Library: Shared libraries ii libgcc1 1:4.2.2-4 GCC support library ii libjpeg626b-14 The Independent JPEG Group's JPEG ii libsnmp155.4.1~dfsg-4SNMP (Simple Network Management Pr ii libssl0.9.8 0.9.8g-3SSL shared libraries ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3 ii libusb-0.1-4 2:0.1.12-8 userspace USB programming library hpijs recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440519: ivtv-source: modprobe ivtv-fb fails
Package: ivtv-source Version: 1.0.2-1 Severity: grave Justification: renders package unusable Hello, I'm running a selfcompiled kernel which is built from unstables most recent linux-source-2.6.22 (2.6.22-4), and built ivtv modules using module-assistent. Both ivtv-fb and saa717x are built fine, but if i try to load ivtv-fb, the kernel gives the following error messages to dmesg/syslog: ivtv_fb: disagrees about version of symbol ivtv_vapi_result ivtv_fb: Unknown symbol ivtv_vapi_result ivtv_fb: disagrees about version of symbol ivtv_udma_alloc ivtv_fb: Unknown symbol ivtv_udma_alloc ivtv_fb: disagrees about version of symbol ivtv_udma_unmap ivtv_fb: Unknown symbol ivtv_udma_unmap ivtv_fb: disagrees about version of symbol ivtv_vapi ivtv_fb: Unknown symbol ivtv_vapi ivtv_fb: disagrees about version of symbol ivtv_udma_prepare ivtv_fb: Unknown symbol ivtv_udma_prepare ivtv_fb: disagrees about version of symbol ivtv_cards ivtv_fb: Unknown symbol ivtv_cards ivtv_fb: disagrees about version of symbol ivtv_udma_setup ivtv_fb: Unknown symbol ivtv_udma_setup my kernel .config is attached. ... jonas -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64-resivo Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ivtv-source depends on: ii bzip2 1.0.3-7high-quality block-sorting file co ii debhelper 5.0.53 helper programs for debian/rules ii dpatch2.0.27 patch maintenance system for Debia ii module-assistant 0.10.11tool to make module package creati ivtv-source recommends no packages. -- no debconf information # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22 # Fri Aug 31 16:11:48 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set
Bug#586161: bug#586162 [bash-completion,cryptsetup] decide who should ship completion for cryptsetup
hey, i just removed the bash-comletion file from cryptsetup svn. with the upload of 2:1.1.2-2, cryptsetup will no longer ship this file. thus i suggest to add a Conflicts: cryptsetup ( 2:1.1.2-2) to bash-completion in order to fix bug #586161. i'll upload cryptsetup 2:1.1.2-2 within the next days. greetings, jonas signature.asc Description: Digital signature
Bug#586120: [pkg-cryptsetup-devel] Bug#586120: device-mapper: reload ioctl failed: Invalid argument
hey, On 16/06/2010 clayton wrote: # cryptsetup create backcrypt /dev/sda2 Enter passphrase: device-mapper: reload ioctl failed: Invalid argument Can you post dmsetup table when this fails? greetings, jonas signature.asc Description: Digital signature
Bug#586120: [pkg-cryptsetup-devel] Bug#586120: device-mapper: reload ioctl failed: Invalid argument
Hey Clayton, On 27/06/2010 Clayton wrote: On Sat, 26 Jun 2010 12:32:02 +0200 Jonas Meurer jo...@freesources.org wrote: On 16/06/2010 clayton wrote: # cryptsetup create backcrypt /dev/sda2 Enter passphrase: device-mapper: reload ioctl failed: Invalid argument Can you post dmsetup table when this fails? Hi Jonas, Sad to say, I think the original symptom I reported may have been due to finger problems associated with the recent shuffling of device names. The encrypted partition is on USB drive that used to be assigned sda when it was plugged in. Now the internal hard drive is assigned sda, and the USB drive gets assigned sdb. Not sure how I missed that are you sure that this is the case? what does 'blkid /dev/sda' and 'blkid /dev/sdb' return? for a plain dm-crypt encrypted device, no filesystem should be detected. also you should take a look at /var/log/syslog, and at /dev/disk/by-id/ in order to find out which device is the encrypted partition on external USB drive. So now: cryptsetup create backcrypt /dev/sdb2 works. this should work for _any_ block device, regardless whether it contains encrypted fs or not. thus the success of above command does not indicate that /dev/sdb2 is the correct device. BUT!!: when I try to mount the partition, this happens: # mount /media/backcrypt/ mount: wrong fs type, bad option, bad superblock on /dev/dm-0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so (Nothing at all is showing up in /var/log/messages associated with this event) /etc/fstab contains: /dev/mapper/backcrypt /media/backcrypt ext3 rw,,user 0 0 # ll /dev/mapper/backcrypt lrwxrwxrwx 1 root root 7 Jun 27 11:50 /dev/mapper/backcrypt - ../dm-0 Again, the fstab entry has not changed for years, and this is a monthly routine that has worked consistently for years. There is also another, unencrypted, ext3 partition on this USB drive that continues to mount just fine. what does 'blkid /dev/mapper/backcrypt' return? the default key size and cipher mode changed for plain dm-crypt in cryptsetup package 2:1.1.0-1. it seems like you don't use /etc/crypttab at all, where key size and cipher mode can be configured. again, 'cryptsetup create' doesn't fail if either passphrase or cipher/ hash/keysize are wrong. thus the only way to verify successfull setup is to check the content of unlocked device. try the following (these where the old defaults for cryptsetup before 1.1.0): # cryptsetup --key-size 128 --cipher aes-cbc-plain create backcrypt /dev/sdb2 and see what 'blkid /dev/mapper/backcrypt' returns in that case. greetings, jonas signature.asc Description: Digital signature
Bug#586120: [pkg-cryptsetup-devel] Bug#586120: device-mapper: reload ioctl failed: Invalid argument
Hey Clayton, On 28/06/2010 Clayton wrote: On Sun, 27 Jun 2010 11:35:31 +0200 Jonas Meurer jo...@freesources.org wrote: On 27/06/2010 Clayton wrote: On Sat, 26 Jun 2010 12:32:02 +0200 Jonas Meurer jo...@freesources.org wrote: are you sure that this is the case? what does 'blkid /dev/sda' and 'blkid /dev/sdb' return? for a plain dm-crypt encrypted device, no filesystem should be detected. desktop1:/media# blkid /dev/sdc1 /dev/sdc1: LABEL=HDEXT115 UUID=8dd61b60-2aeb-4b00-a056-a86223d6e47c TYPE=ext3 desktop1:/media# blkid /dev/sdc2 desktop1:/media# blkid /dev/sda1 /dev/sda1: UUID=9fe8865b-d220-468b-b7a4-bf58b16fe562 TYPE=ext3 desktop1:/media# blkid /dev/sda2 /dev/sda2: UUID=4102f17e-4c54-4ae7-bcfe-00fe90391454 TYPE=swap So sdc2 is showing no file system, consistent with an encrypted device ok, indeed /dev/sdc2 should be the one containing the encrypted device. So now: cryptsetup create backcrypt /dev/sdb2 works. this should work for _any_ block device, regardless whether it contains encrypted fs or not. thus the success of above command does not indicate that /dev/sdb2 is the correct device. That possibility never occurred to me I am now seeing as well that it does not complain about a bad password, either BUT!!: when I try to mount the partition, this happens: # mount /media/backcrypt/ mount: wrong fs type, bad option, bad superblock on /dev/dm-0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so what does 'blkid /dev/mapper/backcrypt' return? # blkid /dev/mapper/backcrypt /dev/mapper/backcrypt: UUID=77f77add-7913-459a-bf81-d88b70323ad6 SEC_TYPE=ext2 TYPE=ext3 and then it gives me the above error message again when I try to mount it. that's strange. what does 'fsck.ext3 /dev/mapper/backcrypt' return? the default key size and cipher mode changed for plain dm-crypt in cryptsetup package 2:1.1.0-1. it seems like you don't use /etc/crypttab at all, where key size and cipher mode can be configured. KISS has meant up until now: don't need crypttab, don't want to mess with it. I am guessing that this may be about to change what is KISS? in my eyes it's better to use crypttab, as you can set cipher, hash and key size as well as other options there, and the cryptdisks initscript will unlock the device automatically at boot. but in the end, it's your decision. again, 'cryptsetup create' doesn't fail if either passphrase or cipher/ hash/keysize are wrong. thus the only way to verify successfull setup is to check the content of unlocked device. try the following (these where the old defaults for cryptsetup before 1.1.0): # cryptsetup --key-size 128 --cipher aes-cbc-plain create backcrypt /dev/sdb2 and see what 'blkid /dev/mapper/backcrypt' returns in that case. Well, this is interesting, I too was expecting this to work but it did not: cryptsetup --key-size 128 --cipher aes-cbc-plain create backcrypt /dev/sdc2 mount still fails in the same way, and now # blkid /dev/mapper/backcrypt outputs exactly nothing. If I remove the device and go back to # cryptsetup create backcrypt /dev/sdc2 I then get, again # blkid /dev/mapper/backcrypt /dev/mapper/backcrypt: UUID=77f77add-7913-459a-bf81-d88b70323ad6 SEC_TYPE=ext2 TYPE=ext3 and still a broken mount command. This crypto partition was created several years ago. I wonder if creation defaults have changed more then once since then? which cryptsetup version did you use before the upgrade? take a look at /var/log/dpkg.log if you're unsure. did you already try to downgrade to the old cryptsetup version and see, whether it works again? ah, and i was wrong with the changed defaults. the only change to plain dm-crypt was the cipher change from aes-cbc-plain to aes-cbc-essiv:sha256. so you should try this one instead: # cryptsetup -c aes-cbc-plain create backcrypt /dev/sdc2 But, if the device has not been truly unlocked because of a crypto problem, should blkid be seeing an ext3 file system? it's strange indeed. maybe your ext3 filesystem is damaged for some reason? greetings, jonas signature.asc Description: Digital signature
Bug#566136: Removing packages which depend from Zope2 ?
hey Andreas, On 25/01/2010 Andreas Tille wrote: I did not followed the discussion closely any more about the Zope 2 issue but apt-cache has no hits for zope2 any more. This lets me assume that zope2 is not supported in Debian any more and so we should probably drop packages depending from it. Please tell me whether my assumption about Zope 2 is true and I'll turn this bug into a ROM bug for ftpmaster. i still hope to have zope2.12 in debian in time for squeeze. unfortunately the build system is rather complex for zope2.12, thus i didn't have time to package zope2.12 yet. greetings, jonas signature.asc Description: Digital signature
Bug#583387: no longer shipping static libraries causes cryptsetup FTBFS
Package: libdevmapper-dev Version: 2:1.02.47-1 Severity: grave hey, the most recent upload of lvm2 source package, which removed static libraries from the lib*-dev packages breaks build process of cryptsetup. cryptsetup staticly links against libdevmapper, as the library is located in /usr/lib, and cryptsetup needs to be invoked before /usr is mounted. please either bring brack the static library, or move the dynamic library to /lib. unfortunately i just uploaded a new version of cryptsetup which failed to build on all architectures for that reason. thus a prompt fix would be much appreciated. don't know if other packages are affected as well. greetings, jonas signature.asc Description: Digital signature
Bug#583387: closed by Bastian Blank wa...@debian.org (Re: Bug#583387: no longer shipping static libraries causes cryptsetup FTBFS)
hey, On 27/05/2010 Bastian Blank wrote: On Thu, May 27, 2010 at 04:00:59PM +0200, Jonas Meurer wrote: cryptsetup staticly links against libdevmapper, This is not allowed under normal circumstances. Does the security team know about? as the library is located in /usr/lib, and cryptsetup needs to be invoked before /usr is mounted. please either bring brack the static library, or move the dynamic library to /lib. Please show evidence for this behaviour. Both lvm2 and dmsetup uses this library and works fine without /usr available and all the versions I know have the lib in /lib. Closing as no bug. sorry, you're right. cryptsetup doesn't even link staticly against devmapper libraries, it only does so for libgcrypt and libgpg-error. security team is aware of that. but still the most recent update of libdevmapper broke cryptsetup build. see the build logs at https://buildd.debian.org/pkg.cgi?pkg=cryptsetup: make[3]: Entering directory `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1/src' gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -DDATADIR=\/usr/share\ -DLOCALEDIR=\/usr/share/locale\ -DLIBDIR=\/usr/lib\ -DPREFIX=\/usr\ -DSYSCONFDIR=\/usr/etc\ -DVERSION=\1.1.1\ -D_GNU_SOURCE -Wall -Wall -g -O2 -MT cryptsetup-cryptsetup.o -MD -MP -MF .deps/cryptsetup-cryptsetup.Tpo -c -o cryptsetup-cryptsetup.o `test -f 'cryptsetup.c' || echo './'`cryptsetup.c mv -f .deps/cryptsetup-cryptsetup.Tpo .deps/cryptsetup-cryptsetup.Po /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wall -g -O2 -all-static -o cryptsetup cryptsetup-cryptsetup.o ../lib/libcryptsetup.la -lgcrypt -lgpg-error -lselinux -lsepol -lpopt libtool: link: gcc -Wall -Wall -g -O2 -static -o cryptsetup cryptsetup-cryptsetup.o ../lib/.libs/libcryptsetup.a -luuid -L/lib -ldevmapper -lpthread /usr/lib/libgcrypt.a /usr/lib/libgpg-error.a -lselinux -lsepol /usr/lib/libpopt.a /usr/bin/ld: cannot find -ldevmapper collect2: ld returned 1 exit status make[3]: *** [cryptsetup] Error 1 make[3]: Leaving directory `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 i can reproduce this bug with libdevmapper-dev 2:1.02.47-1. greetings, jonas signature.asc Description: Digital signature
Bug#583387: closed by Bastian Blank wa...@debian.org (Re: Bug#583387: no longer shipping static libraries causes cryptsetup FTBFS)
hey, On 27/05/2010 Bastian Blank wrote: On Thu, May 27, 2010 at 07:13:01PM +0200, Jonas Meurer wrote: but still the most recent update of libdevmapper broke cryptsetup build. see the build logs at https://buildd.debian.org/pkg.cgi?pkg=cryptsetup: make[3]: Entering directory `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1/src' gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -DDATADIR=\/usr/share\ -DLOCALEDIR=\/usr/share/locale\ -DLIBDIR=\/usr/lib\ -DPREFIX=\/usr\ -DSYSCONFDIR=\/usr/etc\ -DVERSION=\1.1.1\ -D_GNU_SOURCE -Wall -Wall -g -O2 -MT cryptsetup-cryptsetup.o -MD -MP -MF .deps/cryptsetup-cryptsetup.Tpo -c -o cryptsetup-cryptsetup.o `test -f 'cryptsetup.c' || echo './'`cryptsetup.c mv -f .deps/cryptsetup-cryptsetup.Tpo .deps/cryptsetup-cryptsetup.Po /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Wall -g -O2 -all-static -o cryptsetup cryptsetup-cryptsetup.o ../lib/libcryptsetup.la -lgcrypt -lgpg-error -lselinux -lsepol -lpopt libtool: link: gcc -Wall -Wall -g -O2 -static -o cryptsetup cryptsetup-cryptsetup.o ../lib/.libs/libcryptsetup.a -luuid -L/lib -ldevmapper -lpthread /usr/lib/libgcrypt.a /usr/lib/libgpg-error.a -lselinux -lsepol /usr/lib/libpopt.a /usr/bin/ld: cannot find -ldevmapper collect2: ld returned 1 exit status make[3]: *** [cryptsetup] Error 1 make[3]: Leaving directory `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 i can reproduce this bug with libdevmapper-dev 2:1.02.47-1. This is not the same version then already in unstable. So you can't even show on which side it break. As you link with -static, it will only consider static libs. yes, this is the most recent devmapper version in unstable. at least it is the one available at packages.debian.org, on my local system, and being used on the buildds: https://buildd.debian.org/fetch.cgi?pkg=cryptsetup;ver=2%3A1.1.1-1;arch=i386;stamp=1274915533 Selecting previously deselected package libdevmapper1.02.1. Unpacking libdevmapper1.02.1 (from .../libdevmapper1.02.1_2%3a1.02.47-1_i386.deb) ... [...] Selecting previously deselected package libdevmapper-dev. Unpacking libdevmapper-dev (from .../libdevmapper-dev_2%3a1.02.47-1_i386.deb) ... [...] Setting up libdevmapper1.02.1 (2:1.02.47-1) ... [...] Setting up libdevmapper-dev (2:1.02.47-1) ... However the question is: why did it build on your system for the initial upload. Out-of-date system? yes, i missed to update my pbuilder environment before building cryptsetup, thus it used old libdevmapper. from local build-log: Selecting previously deselected package libdevmapper-dev. Unpacking libdevmapper-dev (from .../libdevmapper-dev_2%3a1.02.45-1_amd64.deb) ... [...] Setting up libdevmapper-dev (2:1.02.45-1) ... i just rechecked, and the now up-to-date pbuilder environment fails to build cryptsetup, while after downgrading libdevmapper1.02.1 and libdevmapper-dev the packages build fine. so it's definitely connected to the devmapper package upgrade. greetings, jonas signature.asc Description: Digital signature
Bug#576488: [pkg-cryptsetup-devel] Bug#576488: still present
hey, On 06/05/2010 Frederik Vanrenterghem wrote: Package: cryptsetup Version: 2:1.1.0-2.1 I still get this error (evmc_activate is not available) using kernel 2.6.32-4 and 2.6.32-5 on AMD64. I can't boot the system. 2.6.32-3 boots fine. please provide more information about your setup, the used versions, etc. do you use evms? does evms have a initramfs hook which installes the evms binary into the initramfs? what is the exact output of 'update-initramfs -u'? and please attach initramfs.log after executing 'sh -x mkinitramfs -o /tmp/initramfs.debug 2initramfs.log' greetings, jonas signature.asc Description: Digital signature
Bug#493848: [EMAIL PROTECTED]: [pkg-cryptsetup-devel] crypttab problem]
Package: cryptsetup Version: 2:1.0.6-4 Severity: grave forwarding a bug reported by Marco Gatti to the pkg-cryptsetup-devel mailinglist. greetings, jonas - Forwarded message from Marco Gatti [EMAIL PROTECTED] - Date: Mon, 4 Aug 2008 12:24:41 +0200 From: Marco Gatti [EMAIL PROTECTED] Subject: [pkg-cryptsetup-devel] crypttab problem To: [EMAIL PROTECTED] Using Lenny with an encrypted partition on a secondary disk the new version of cryptsetup doesn't work anymore with this line configured in /etc/crypttab: backup /dev/hdb1 /path/to/file.key hash=sha512 The device get created but there's no chance to mount it since it doesn't find any proper filesystem (even forcing it in the mount options). If i run cryptsetup manually it works and i see all my data: cryptsetup create backup /dev/hdb1 --key-file=/path/to/file.key --hash=sha512 I've tried to look at the documentation and the changes but didn't find if i'm doing something wrong (and i've been using this setup for years...). System Information: Debian Release: lenny Kernel: Linux 2.6.25.14 #1 SMP PREEMPT Mon Aug 4 10:26:20 CEST 2008 i686 GNU/Linux Package: ii cryptsetup 2:1.0.6-4 configures encrypted block devices Versions of packages cryptsetup depends on: ii dmsetup2:1.02.27-3The Linux Kernel Device Mapper userspace library ii libc6 2.7-10 GNU C Library: Shared libraries ii libdevmapper1.02.1 2:1.02.27-3The Linux Kernel Device Mapper userspace library ii libpopt0 1.14-4 lib for parsing cmdline parameters ii libuuid1 1.41.0-3 universally unique id library -- Linux Registered User #398764 - http://counter.li.org/ [EMAIL PROTECTED] User - http://www.boincstats.com/signature/user_833490.gif ___ pkg-cryptsetup-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-cryptsetup-devel - End forwarded message - signature.asc Description: Digital signature
Bug#493848: [pkg-cryptsetup-devel] Bug#493848: Still a problem
On 07/08/2008 Sebastian Moster wrote: there still seems to be a problem concerning the key-file parameter when read from /etc/crypttab. With 2:1.0.6-5, the script produces now the command cat keyfile | cryptsetup -c -s --key-file=- create which seems to be correct. However, this does somehow not produce the same result as if I call manually cryptsetup -c ... -s --key-file=keyfile So when I call the second version, I can mount the encrypted partitions whithout problems. With the first version, and especially when booting, they cannot be mounted. you're right. I was able to reproduce the bug. It seems like 'cryptsetup create' for plain dm-crypt mappings treats keyfiles different from luksOpen. David: the only solution I can imagine for lenny is to revert do_noluks() to not use cat for keyfiles at all. What do you think about that? greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#548570: minirok segfaults
hey adeodato, On 15/10/2009 Adeodato Simó wrote: + Jonas Meurer (Sun, 27 Sep 2009 12:30:28 +0200): Package: minirok Version: 2.0-1 Severity: grave Justification: renders package unusable hello, minirok segfaults on my up-to-date debian/unstable system: Hello Jonas, this was caused by an incompatibility in PyQt 4.6. I believe I have fixed the problem. Before doing an upload, would you mind testing the packages at [1] (they are sort of 2.1~rc1)? Thanks! [1]: http://chistera.yi.org/~adeodato/tmp/2009-10-15/minirok_2.1~r768-1_all.deb indeed, that package fixes the segfault for me. thanks for your great work! greetings, jonas signature.asc Description: Digital signature
Bug#507721: [pkg-cryptsetup-devel] Bug#507721: cryptsetup: Sometimes initrd ends up missing conf/conf.d/cryptroot file in it
tags 507721 + help thanks Hello, I just tried to understand the whole issue. I'll try to describe what I got so far, please tell me If i got something wrong: On 03/12/2008 Christian Jaeger wrote: I did install the system using the capabilities of the Debian installer to create encrypted root partitions and LVM setups, and it worked for some time; probably the first occurrence of the problem was when I already started compiling and installing kernels manually (from kernel.org's Git, using make install and make modules_install), although this too worked upon the first (few?) kernel version(s). And, again, sometimes it still works, like when I installed 2.6.27.5 I could not reproduce the problem. This is also documented on a bug I reported against initramfs-tools, here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug= Does this mean, that you've chosen 'Guided - use entire disk and setup encrypted LVM' at the debian installer partitioner? And you didn't change that setup except compiling custom kernels, right? --- Logical volume --- LV Name/dev/main/root VG Namemain LV UUIDM51c6n-rw9j-vKBU-UnIJ-GvXD-nVw0-7yisre LV Write Accessread/write LV snapshot status source of /dev/main/root_snap_23nov [INACTIVE] LV Status available # open 2 LV Size17.43 GB Current LE 4462 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:2 [...] novo:~# dmsetup ls plain-rootextend-real (253, 8) main-root (253, 2) sda8_crypt(253, 0) plain-gpgbackups (253, 5) plain-rootextend_snap_23nov-cow (253, 10) plain-rootextend_snap_23nov (253, 11) plain-plainswap2 (253, 12) plain-media (253, 6) main-root_snap_23nov (253, 4) plain-rootextend (253, 9) plain-plainswap (253, 7) main-root-real(253, 1) plain-spdvd (253, 13) main-root_snap_23nov-cow (253, 3) Ok, that one looks like you've much more dm-crypt mappings than a default setup. you do have main-root, main-root-real, main-root_snap_23nov and root_snap_23nov. novo:~# l /dev/dm-0 brw-rw 1 root disk 253, 0 2008-12-03 21:00 /dev/dm-0 thus dm-0 is sda8_crypt novo:~# cat /etc/crypttab sda8_crypt /dev/sda8 none luks novo:~# novo:~# cat /etc/fstab |perl -wne 'print if m|\s/\s|' /dev/mapper/main-root / reiserfs defaults,noatime0 1 novo:~# ok, you use main-root as rootfs, and main-root depends on main-root-real, which itself depends on sda8_crypt, correct? is this the reason why your LVM over dm-crypt setup has one more level than the usual setups? Could you try to explain what the reason is why your setup fails while others work? and if the missing recursion of get_lvm_deps() is really the reason, why does it only fail on some kernels for you? I'm not confident that you tracked the real bug. And as David Härdeman, the one who wrote all the cryptroot initramfs scripts, isn't available currently, i hesitate to apply your patch. greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507721: [pkg-cryptsetup-devel] Bug#507721: cryptsetup: Sometimes initrd ends up missing conf/conf.d/cryptroot file in it
On 16/12/2008 Christian Jaeger wrote: Christian Jaeger wrote: and if the missing recursion of get_lvm_deps() is really the reason, why does it only fail on some kernels for you? As I did say in my previous mails, I don't know. And I don't know whether it's got anything to do with kernels. Or the order in which something is initialized at boot, or the phase of moon, or maybe whether I've got snapshots running. Hey, I've tested now with and without snapshots and it's clearly the culprit. See the attached observation log. You can see (1) that while there is a snapshot on the root volume, on my setup, the current cryptsetup from Debian is broken; it is *not* broken if I remove the snapshot. (2) I see confirmed that my patch works for me in both cases. So, I hope now you've got at least something to reproduce the case. Ok, I spend some hours on debugging the issue and finally was able to reproduce it. Yes, it's correct that creating a lv snapshot seems to add another level of mapping. the device main-root no longer directly depends on the physical volume, but instead depends on main-root-real, and that one finally depends on the physical volume. I did some tests with a recursive get_lvm_deps(), and it seems to work as expected. Thanks for your great debugging work, Christian. I wouldn't have been able to track down this bug that soon without your invaluable help. Same goes to Ben Hutchings and Yves-Alexis Perez. You rock! I've just prepared cryptsetup 1.0.6-7 with this bug and several others fixed. Would you mind testing the packages before I actually upload them to unstable and ask for inclusion in lenny? Many changes since 1.0.6-6 are documentation improvements, but there are also some code fixes in initscripts, initramfs scripts and keyscripts. you can find the packages at http://people.debian.org/~mejo/cryptsetup/ greetings, jonas signature.asc Description: Digital signature
Bug#507721: [pkg-cryptsetup-devel] Bug#507721: cryptsetup: Sometimes initrd ends up missing conf/conf.d/cryptroot file in it
On 16/12/2008 Christian Jaeger wrote: I've just prepared cryptsetup 1.0.6-7 with this bug and several others fixed. Would you mind testing the packages before I actually upload them to unstable and ask for inclusion in lenny? Many changes since 1.0.6-6 are documentation improvements, but there are also some code fixes in initscripts, initramfs scripts and keyscripts. you can find the packages at http://people.debian.org/~mejo/cryptsetup/ I've tested with my now usual cheap approach, i.e. checking the contents of the generated initrd (I can't boot right now because of some other ongoing work). Your version didn't work according to this testing, as can be seen from the attached observation log. I've then done one change, namely remove the double quotes from $depnode http://christianjaeger.ch/dyn/pubgit/gitweb?p=cryptroot-debugging.git;a=commitdiff;h=ac6be141ffbb8bf05d6f6a3f57bf67c4fb2a8dbf and with this it now works. When I made my comment about not using double quotes there I really meant it, I saw from the debugging session that $depnode has like 5-10 spaces and/or tabs appended. Yes, it's true that $depnode had spaces added. I initially added an extra sed at the end of the line to remove those trailing whitespaces, somehow this change didn't make it into the packages I built. I think that quoting variables should be done where possible, so now the code actually looks like the following: [...] depnode=$(dmsetup ls | sed -n s/\\([^ ]*\\) *($maj, $min)/\\1/p | sed -e s/[ \t]*$//) [...] depnode=$(dmsetup ls | sed -n s/\\([^ ]*\\) *($maj, $min)/\\1/p | sed -e s/[ \t]*$//) if [ $(dmsetup table $depnode 2 /dev/null | cut -d' ' -f3) != crypt ]; then get_lvm_deps $depnode continue fi [...] I've updated the packages at http://people.debian.org/~mejo/cryptsetup/, could you test them again? greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507721: [pkg-cryptsetup-devel] Bug#507721: cryptsetup: Sometimes initrd ends up missing conf/conf.d/cryptroot file in it
On 17/12/2008 Christian Jaeger wrote: Jonas Meurer wrote: if [ $(dmsetup table $depnode 2 /dev/null | cut -d' ' -f3) != crypt ]; then get_lvm_deps $depnode It seems you have missed that in the first line above, $depnode is *not* quoted. So going these extra steps to be safe and quote the variable in the second line is pointless. This is what I did mean when I said ~since it is used unquoted anyway above. Correct would be: if [ $(dmsetup table $depnode 2 /dev/null | cut -d' ' -f3) != crypt ]; then You're right, but i'm not sure about the quotes inside quotes. Is that a clean solution either? greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507721: [pkg-cryptsetup-devel] Bug#507721: cryptsetup: Sometimes initrd ends up missing conf/conf.d/cryptroot file in it
On 17/12/2008 Christian Jaeger wrote: Correct would be: if [ $(dmsetup table $depnode 2 /dev/null | cut -d' ' -f3) != crypt ]; then You're right, but i'm not sure about the quotes inside quotes. Is that a clean solution either? Yes, that's the clean way, to the best of my knowledge. Note: it does not add double quotes around what the $depnode variable contains; but instead those *are* those same kinds of quotes that you are using in the second line. Shell quoting isn't straightforward to understand or to explain (at least I haven't taken the time to hunt down or write myself an explanation), but once you got it you can verify that it is precise. Thanks, I just read some shell and posix docs to be sure, and it seems like you're correct: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03 So I applied that change as well and built the packages again. could you give them a try and report whether they work for you? I already tested them on similar setups, but you doing extra testing doesn't hurt. greetings, jonas signature.asc Description: Digital signature
Bug#540157: Bug#540158: doesnt use invoke-rc.d
hey, On 06/08/2009 Holger Levsen wrote: during a test with piuparts I noticed your package starts processes where it shouldnt. This is very probably due to not using invoke-rc.d as mandated by policy 9.3.3.2. This is seriously disturbing! ;-) See http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 and /usr/share/doc/sysv-rc/README.invoke-rc.d.gz as well as /usr/share/doc/sysv-rc/README.policy-rc.d.gz From the attached log (scroll to the bottom...): Setting up zope2.11-sandbox (2.11.3-1) ... . daemon process started, pid=17342 Processing triggers for python-support ... [...] 0m41.7s ERROR: FAIL: Processes are running inside chroot: i suggest to fix these bugs the following way: patch the initscripts to support INSTANCE=instance or ZEOSERVER=zeoserver as second argument ($2) and start the particular given server/instance. then fix all zope-debhelper scripts to use invoke-rc.d with appropriate arguments instead of using dzhandle zeoctl|zopectl directly. i already commited the relevant changes to zope-debhelper, zope2.11 and zope2.10 to the svn repository. only package that is left is zope3. i left that one open to others as i don't know nothing about zope3. any objections? if not, i would suggest to upload zope-debhelper within the next days, wait until it reached unstable and then upload zope3/zope2.11/zope2.10 with build-depends on new zope-debhelper. only drawback is, that building old zope3/2.11/2.10/... packages with new zope-debhelper will break. do you think that adding a Breaks: header to zope-debhelper for old zope packages would be necessary? greetings, jonas signature.asc Description: Digital signature
Bug#540159: Bug#540158: doesnt use invoke-rc.d
hello again, On 08/08/2009 Jonas Meurer wrote: On 06/08/2009 Holger Levsen wrote: during a test with piuparts I noticed your package starts processes where it shouldnt. This is very probably due to not using invoke-rc.d as mandated by policy 9.3.3.2. This is seriously disturbing! ;-) See http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 and /usr/share/doc/sysv-rc/README.invoke-rc.d.gz as well as /usr/share/doc/sysv-rc/README.policy-rc.d.gz From the attached log (scroll to the bottom...): Setting up zope2.11-sandbox (2.11.3-1) ... . daemon process started, pid=17342 Processing triggers for python-support ... [...] 0m41.7s ERROR: FAIL: Processes are running inside chroot: i suggest to fix these bugs the following way: patch the initscripts to support INSTANCE=instance or ZEOSERVER=zeoserver as second argument ($2) and start the particular given server/instance. then fix all zope-debhelper scripts to use invoke-rc.d with appropriate arguments instead of using dzhandle zeoctl|zopectl directly. i already commited the relevant changes to zope-debhelper, zope2.11 and zope2.10 to the svn repository. only package that is left is zope3. i left that one open to others as i don't know nothing about zope3. any objections? if not, i would suggest to upload zope-debhelper within the next days, wait until it reached unstable and then upload zope3/zope2.11/zope2.10 with build-depends on new zope-debhelper. only drawback is, that building old zope3/2.11/2.10/... packages with new zope-debhelper will break. do you think that adding a Breaks: header to zope-debhelper for old zope packages would be necessary? ok, after discussing this with kobold, i finally implemented the following changes: - zope-debhelper uses invoke-rc.d in maintainer scripts - dzhandle uses invoke-rc.d for DZRestartPendingInstances.run() - zope2.1[01] init scripts support [ZEOSERVER|INSTANCE]=... as second argument - zope-common breaks zope2.[789] and old zope2.1[01] packages - zope-debhelper adds depends on recent zope-common to packages that use dh_installzope* - zope2.1[01] build-depend on recend zope-debhelper and pre-depend on recent zope-common please test the packages (especially install|upgrade|remove|purge) with as many different setups as possible (no|one|many zope instances, zope2.1[01]-sandbox installed|upgraded|...). you can find all packages (amd64 and i386) at http://people.debian.org/~mejo/zope/ i'll upload zope-common and zope-debhelper to unstable within the next days if nobody objects. once both are in unstable for one or two days, i'll upload zope2.10 and zope2.11 as well. greetings, jonas signature.asc Description: Digital signature
Bug#544773: [pkg-cryptsetup-devel] Bug#544773: Update to cryptsetup 2:1.0.7-2 breaks booting
hey, On 04/09/2009 Paul Millar wrote: On Thursday 03 September 2009 19:43:28 Jonas Meurer wrote: [...] please run the following command: # sh -x mkinitramfs -o /tmp/initramfs 2/tmp/initramfs.log and send /tmp/initramfs.log to the bugreport. Attached. Incidentally, I opened up the resulting initrd image (/tmp/initramfs) and found that the conf/conf.d/cryptsetup file is still absent. The problem is at least reproducible on this laptop. thanks. please also send me the output of the following commands: # ls -l /dev/mapper # cat /etc/mtab i guess that you discovered the same bug as #544487. could you try downgrading to cryptsetup 2:1.0.7-1, regenerating the initramfs and see whether the bug disappears? if it's related to device files in /dev/mapper being links to /dev/dm-* then the bug should be reproducible with old cryptsetup as well. greetings, jonas signature.asc Description: Digital signature
Bug#548570: minirok segfaults
Package: minirok Version: 2.0-1 Severity: grave Justification: renders package unusable hello, minirok segfaults on my up-to-date debian/unstable system: $ minirok Traceback (most recent call last): File /usr/bin/minirok, line 9, in module minirok.main.main() File /usr/share/minirok/minirok/main.py, line 73, in main main_window = mw.MainWindow() File /usr/share/minirok/minirok/main_window.py, line 31, in __init__ self.right_side = right_side.RightSide(self.main_view, main_window=self) File /usr/share/minirok/minirok/right_side.py, line 31, in __init__ self.playlist_view.setModel(self.proxy) File /usr/share/minirok/minirok/playlist.py, line 1011, in setModel self.header().setup_from_config() File /usr/share/minirok/minirok/playlist.py, line 1308, in setup_from_config self.CONFIG_OPTION, QtCore.QStringList())) TypeError: argument 2 to map() must support iteration KCrash: Application 'minirok' crashing... sock_file=/home/resivo/.kde/socket-resivo/kdeinit4__0 the 'KDE Crash Handler' lists the following 'Developer Information': Application: Minirok (minirok), signal: Segmentation fault [Current thread is 1 (Thread 0x7f9aa6b9a6f0 (LWP 10842))] Thread 2 (Thread 0x7f9a8f020950 (LWP 10844)): #0 0x7f9aa678fb89 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f9aa39d2469 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4 #2 0x7f9aa0062ce5 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtCore.so #3 0x0048efc5 in PyEval_EvalFrameEx () #4 0x0049023c in PyEval_EvalCodeEx () #5 0x004d9652 in ?? () #6 0x004186a3 in PyObject_Call () #7 0x0041f3a4 in ?? () #8 0x004186a3 in PyObject_Call () #9 0x004893e2 in PyEval_CallObjectWithKeywords () #10 0x7f9aa03ae7e5 in ?? () from /usr/lib/pymodules/python2.5/sip.so #11 0x7f9aa007005f in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtCore.so #12 0x7f9aa00852f1 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtCore.so #13 0x7f9aa39d1475 in ?? () from /usr/lib/libQtCore.so.4 #14 0x7f9aa678bf9a in start_thread () from /lib/libpthread.so.0 #15 0x7f9aa5e7656d in clone () from /lib/libc.so.6 #16 0x in ?? () Thread 1 (Thread 0x7f9aa6b9a6f0 (LWP 10842)): [KCrash Handler] #5 0x7f9aa3fc7833 in QWidget::releaseShortcut(int) () from /usr/lib/libQtGui.so.4 #6 0x7f9aa4343c98 in ?? () from /usr/lib/libQtGui.so.4 #7 0x7f9aa4344762 in QLabel::~QLabel() () from /usr/lib/libQtGui.so.4 #8 0x7f9aa4d5dd04 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so #9 0x7f9aa3ac5861 in QObjectPrivate::deleteChildren() () from /usr/lib/libQtCore.so.4 #10 0x7f9aa3fd06a2 in QWidget::~QWidget() () from /usr/lib/libQtGui.so.4 #11 0x7f9aa4edf3d6 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so #12 0x7f9aa4e8c772 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so #13 0x7f9aa03acf79 in ?? () from /usr/lib/pymodules/python2.5/sip.so #14 0x0045e0d5 in ?? () #15 0x00445b33 in ?? () #16 0x7f9aa03ab1ab in ?? () from /usr/lib/pymodules/python2.5/sip.so #17 0x7f9aa03abac4 in ?? () from /usr/lib/pymodules/python2.5/sip.so #18 0x7f9aa03acf81 in ?? () from /usr/lib/pymodules/python2.5/sip.so #19 0x0045e0d5 in ?? () #20 0x7f9aa03ae9c2 in sip_api_common_dtor () from /usr/lib/pymodules/python2.5/sip.so #21 0x7f9aa4edf3b9 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so #22 0x7f9aa3ac5861 in QObjectPrivate::deleteChildren() () from /usr/lib/libQtCore.so.4 #23 0x7f9aa3fd06a2 in QWidget::~QWidget() () from /usr/lib/libQtGui.so.4 #24 0x7f9aa439d210 in QSplitter::~QSplitter() () from /usr/lib/libQtGui.so.4 #25 0x7f9aa4c8e798 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so #26 0x7f9aa3ac5861 in QObjectPrivate::deleteChildren() () from /usr/lib/libQtCore.so.4 #27 0x7f9aa3fd06a2 in QWidget::~QWidget() () from /usr/lib/libQtGui.so.4 #28 0x7f9a9ea30eb5 in KMainWindow::~KMainWindow() () from /usr/lib/libkdeui.so.5 #29 0x7f9a9ade6c9d in sipKXmlGuiWindow::~sipKXmlGuiWindow() () from /usr/lib/pymodules/python2.5/PyKDE4/kdeui.so #30 0x7f9a9adb534d in ?? () from /usr/lib/pymodules/python2.5/PyKDE4/kdeui.so #31 0x7f9aa03acf79 in ?? () from /usr/lib/pymodules/python2.5/sip.so #32 0x0045e0d5 in ?? () #33 0x0041f933 in ?? () #34 0x004387c2 in ?? () #35 0x00445b33 in ?? () #36 0x00445b33 in ?? () #37 0x0045e15c in ?? () #38 0x00444047 in ?? () #39 0x00445e4a in PyDict_SetItem () #40 0x00447e56 in _PyModule_Clear () #41 0x004a34c4 in PyImport_Cleanup () #42 0x004aeed6 in Py_Finalize () #43 0x00414037 in Py_Main () #44 0x7f9aa5dc85c6 in __libc_start_main () from /lib/libc.so.6 #45 0x004139d9 in _start () greetings, jonas -- System Information: Debian Release:
Bug#548861: upgrade fails with E: Internal Error, Could not perform immediate configuration (2) on perl
Package: perl Version: 5.10.1-3 Severity: serious hello, perl upgrade fails on my up-to-date debian/unstable system: # apt-get install libperl5.10 perl-base perl perl-doc perl-modules Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: groff The following packages will be upgraded: libperl5.10 perl perl-base perl-doc perl-modules 5 upgraded, 0 newly installed, 0 to remove and 6 not upgraded. Need to get 0B/16.2MB of archives. After this operation, 532kB of additional disk space will be used. E: Internal Error, Could not perform immediate configuration (2) on perl greetings, jonas -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-6-amd64-resivo (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages perl depends on: ii libc6 2.9-26GNU C Library: Shared libraries ii libdb4.7 4.7.25-8 Berkeley v4.7 Database Libraries [ ii libgdbm3 1.8.3-6 GNU dbm database routines (runtime ii perl-base 5.10.0-25 minimal Perl system ii perl-modules 5.10.0-25 Core Perl modules ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime Versions of packages perl recommends: ii make 3.81-6 An utility for Directing compilati ii netbase 4.37 Basic TCP/IP networking system Versions of packages perl suggests: ii libterm-readline-gnu-perl 1.19-2 Perl extension for the GNU Readlin ii perl-doc 5.10.0-25 Perl documentation -- no debconf information signature.asc Description: Digital signature
Bug#514294: lurker kde4 mimelib
Hey Sune and Barry, I sent you this mail some days ago, and still didn't get a response. Now that kde4 is in unstable and lurker ftbfs I'd really fix the issue, but I don't know how to proceed. A comment from you on the questions below would be very valuable to me. On 17/03/2009 Sune Vuorela wrote: On Tuesday 17 March 2009 18:29:14 Jonas Meurer wrote: on final issue remains: I saw that the package build-depends on kdelibs4, which is from kde3. But I thought that the bugreport was filed by Sune to get rid of kde3 in the long term. It is still unclear wether we can get rid of the kde3 libraries for squeeze. I hope it is, but I don't think it is realistic. But mimelib should be enough self-containing to not require any parts of KDE - and mimelib don't expose any parts of kde abi to the outside. It should be doable, it is just a matter of doing it. Is this build dependency required at all? An if it is, how do you intend to workaround it once kde3 will be removed from debian/unstable? I managed to get rid of the kdelibs build-dependency by simply replacing #else # include kde/kdemacros.h # define DW_EXPORT KDE_EXPORT #endif with #else # define DW_EXPORT #endif in mimelib/config.h. So indeed a mimelib source package which is independent from any kde libraries shouldn't be a problem. i'm willing to maintain it in debian, but some issues remain unclear for me, and i'dd highly appreciate your options about them: - it seems like mimelib doesn't have any real upstream anymore. kdepim contains it, and several stanalone tarballs can be found anywhere in the web. Barry, how did you find the tarball at ftp.crocodile.org? or did you build it on your own? all mimelib versions i can find via google (from kde svn, from lurkers sourceforge page, from different linux distributions) slightly differ from each other, and i'm really unsure about which one is the most recent one. for example, i didn't find any mimelib version where the documentation files do contain (VCS?) $Revision and $Date entries. Only your version from ftp.crocodile.org does have them. - when I build mimelib from a seperate source-package, how to coordinate this with existing mimelib packages from kdepim sources? sure, I'll have to conflict and replace them, but how to name the library package? and do I need to introduce a new SONAME? another possibility would be to stop building mimelib packages from kdepim sources and keep both soname and binary package names the same. sorry if these questions do sound dump, but i don't have any experience with library packaging yet :-/ greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514294: lurker kde4 mimelib
Hey Barry, On 07/04/2009 Barry deFreese wrote: On Tuesday 17 March 2009 18:29:14 Jonas Meurer wrote: i'm willing to maintain it in debian, but some issues remain unclear for me, and i'dd highly appreciate your options about them: - it seems like mimelib doesn't have any real upstream anymore. kdepim contains it, and several stanalone tarballs can be found anywhere in the web. Barry, how did you find the tarball at ftp.crocodile.org? or did you build it on your own? all mimelib versions i can find via google (from kde svn, from lurkers sourceforge page, from different linux distributions) slightly differ from each other, and i'm really unsure about which one is the most recent one. for example, i didn't find any mimelib version where the documentation files do contain (VCS?) $Revision and $Date entries. Only your version from ftp.crocodile.org does have them. Hi Jonas, my apologies, I thought I had responded to your previous e-mail. I ran into a similar situation. I basically googled around based on the package and the author. There are mutiple versions flying around but they are all based on the same lib from the same author. The ftp.crocodile.org was the most original I could find. Then I added patches based on the modifications that were made in the mimelib stuff in the kdepim package. I just compared different versions and I have to say it's really a mess. No version is nearly similar to another one. I don't even understand how you built the mimelib packages at people.debian.org from the tarball at ftp.crocodile.org. The diff between your and the ftp.crocodile.org tarball has more than 1 lines. I now have five different versions of mimelib available: - your debian package from people.debian.org/~bdefreese - the kdepim3 source package from debian/squeeze - the source tarball from ftp.crocodile.org - the source tarball from sourceforge.net/projects/lurker - the svn snaphost from svn.kde.org I could just pick up one, finish the packaging, and upload it. But to be honest, I would like to first sort out why all these versions do have tens of thousands of changes each. I don't expect from you to help me with this, the only thing where you could help is: how exactly did you put the package at people.debian.org together? Is it really based on the tarball from ftp.crocodile.org? - when I build mimelib from a seperate source-package, how to coordinate this with existing mimelib packages from kdepim sources? sure, I'll have to conflict and replace them, but how to name the library package? and do I need to introduce a new SONAME? another possibility would be to stop building mimelib packages from kdepim sources and keep both soname and binary package names the same. I'm certainly no expert on library packaging yet but I would name the library package according to the soname if possible. (I think I did that in my package). kdepim is going to be removed isn't it? If not, we have a larger problem as mimelib shouldn't be a seperate package and shipped in kdepim. If the package name and soname differ from the kdepim one then yes, adding a Provides and Replaces (and possibly even Conflicts) would be appropriate. Unfortunately, as you mention I can't even install or build the kdepim mimelib now so I can't even tell you what the current soname is. :( kdepim3 is gone from debian/unstable now, so it shouldn't be a problem to upload source package mimelib with binary packages libmimelib1 and libmimelib1-dev any more. The libmimelib1c2a package has libmimelib.so.1 as soname. If I want to keep the soname, I'll have to ensure abi compatibility. How can I check that in case that I use a different source than kdepim3? I guess most changes from the other tarballs are just minor fixes, but how can I go sure? greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514294: lurker: request for help
tag 514294 +help thanks Package: lurker Version: 2.1-13 Followup-For: Bug #514294 Hello, I don't know what to do about that bugreport. I understand that mimelib from kde3libs cannot stay in the archive forever, and mimelib from kde4libs will introduce lots of new dependencies. Still lurker depends on a mimelib. nearly all c++ files from lurker sources do contain several mimelib header includes. And I don't know of another, stand-alone mimelib that lurker could be ported to. A very bad solution would be to copy mimelib sources to lurker source package, and link to them statically. As already mentioned, upstream seems to be MIA currently, so I'll find to have a solution within debian rather than asking him for help. I hereby request help for this bugreport. greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514294: lurker kde4 mimelib
Hey Barry, On 17/03/2009 Barry deFreese wrote: A while back Sune asked me to look at ripping mimelib out. I found the seperated upstream source for it and applied the same patches that kdepim uses. I have put the source package here: http://people.debian.org/~bdefreese/mimelib/ Of course it would mean maintaining another package but you should be able to build/link against it. Thanks for the pointer. Packaging mimelib as a seperate source package in debian seems like a good solution to bug#514294. Do you intend to upload it soon? on final issue remains: I saw that the package build-depends on kdelibs4, which is from kde3. But I thought that the bugreport was filed by Sune to get rid of kde3 in the long term. Is this build dependency required at all? An if it is, how do you intend to workaround it once kde3 will be removed from debian/unstable? greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514294: lurker kde4 mimelib
Hello, On 17/03/2009 Sune Vuorela wrote: On Tuesday 17 March 2009 18:29:14 Jonas Meurer wrote: on final issue remains: I saw that the package build-depends on kdelibs4, which is from kde3. But I thought that the bugreport was filed by Sune to get rid of kde3 in the long term. It is still unclear wether we can get rid of the kde3 libraries for squeeze. I hope it is, but I don't think it is realistic. But mimelib should be enough self-containing to not require any parts of KDE - and mimelib don't expose any parts of kde abi to the outside. It should be doable, it is just a matter of doing it. Is this build dependency required at all? An if it is, how do you intend to workaround it once kde3 will be removed from debian/unstable? I managed to get rid of the kdelibs build-dependency by simply replacing #else # include kde/kdemacros.h # define DW_EXPORT KDE_EXPORT #endif with #else # define DW_EXPORT #endif in mimelib/config.h. So indeed a mimelib source package which is independent from any kde libraries shouldn't be a problem. i'm willing to maintain it in debian, but some issues remain unclear for me, and i'dd highly appreciate your options about them: - it seems like mimelib doesn't have any real upstream anymore. kdepim contains it, and several stanalone tarballs can be found anywhere in the web. Barry, how did you find the tarball at ftp.crocodile.org? or did you build it on your own? all mimelib versions i can find via google (from kde svn, from lurkers sourceforge page, from different linux distributions) slightly differ from each other, and i'm really unsure about which one is the most recent one. for example, i didn't find any mimelib version where the documentation files do contain (VCS?) $Revision and $Date entries. Only your version from ftp.crocodile.org does have them. - when I build mimelib from a seperate source-package, how to coordinate this with existing mimelib packages from kdepim sources? sure, I'll have to conflict and replace them, but how to name the library package? and do I need to introduce a new SONAME? another possibility would be to stop building mimelib packages from kdepim sources and keep both soname and binary package names the same. sorry if these questions do sound dump, but i don't have any experience with library packaging yet :-/ greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534013: zope2.10: FTBFS: /bin/sh: line 0: cd: z: No such file or directory
Hello Lucas, On 21/06/2009 Lucas Nussbaum wrote: Package: zope2.10 Version: 2.10.8-1 Severity: serious User: debian...@lists.debian.org Usertags: qa-ftbfs-20090620 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part: tar xfz Zope-2.10.8-final.tgz test -d debian/patched || install -d debian/patched cd z CFLAGS=-Wall -g -O2 ./configure \ --prefix=/build/user-zope2.10_2.10.8-1-amd64-315F5a/zope2.10-2.10.8/debian/zope2.10/usr/lib/zope2.10 \ --with-python=/usr/bin/python2.4 /bin/sh: line 0: cd: z: No such file or directory make: *** [build-arch-stamp] Error 1 About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot. Internet was not accessible from the build systems. could you provide the exact command that your archive rebuild uses to build a package? if you take a look at debian/rules, there are several more commands in unpack-stamp than just the 'tar xfz'. According to your logfile, the build-arch-stamp and patch-stamp targets are executed in the middle of the unpack-stamp target. I'm unable to reproduce that bug in a clean amd64 debian/unstable pbuilder chroot. here's the relevant parts of debian/rules: ZOPE := zope$(ZVER) PACKAGE := zope$(ZVER) DEBIAN:= $(shell pwd)/debian/$(PACKAGE) [...] unpack: unpack-stamp unpack-stamp: tar xfz $(ZBASE).tgz mv $(ZBASE) z touch unpack-stamp [...] build: build-arch build-indep build-arch: unpack-stamp patch-stamp build-arch-stamp build-arch-stamp: cd z CFLAGS=$(CFLAGS) ./configure \ --prefix=$(DEBIAN)/usr/lib/$(ZOPE) \ --with-python=$(PYTHONBIN) cd z make touch build-arch-stamp according to your logfile, the build system ran target build-arch-stamp just in between of 'tar xfz $(ZBASE).tgz' and 'mv $(BASE) z': [...] dpkg-source: info: building zope2.10 in zope2.10_2.10.8-1.dsc debian/rules build tar xfz Zope-2.10.8-final.tgz test -d debian/patched || install -d debian/patched cd z CFLAGS=-Wall -g -O2 ./configure \ --prefix=/build/user-zope2.10_2.10.8-1-amd64-315F5a/zope2.10-2.10.8/debian/zope2.10/usr/lib/zope2.10 \ --with-python=/usr/bin/python2.4 /bin/sh: line 0: cd: z: No such file or directory make: *** [build-arch-stamp] Error 1 make: *** Waiting for unfinished jobs dpatch apply-all applying patch deb-zopeconf to ./ ... failed. make: *** [patch-stamp] Error 1 mv Zope-2.10.8-final z touch unpack-stamp dpkg-buildpackage: error: debian/rules build gave error exit status 2 [...] the same applies to your bugreport #533975 against zope2.11. greetings, jonas signature.asc Description: Digital signature
Bug#534013: zope2.10: FTBFS: /bin/sh: line 0: cd: z: No such file or directory
On 02/07/2009 Lucas Nussbaum wrote: if you take a look at debian/rules, there are several more commands in unpack-stamp than just the 'tar xfz'. According to your logfile, the build-arch-stamp and patch-stamp targets are executed in the middle of the unpack-stamp target. I'm unable to reproduce that bug in a clean amd64 debian/unstable pbuilder chroot. here's the relevant parts of debian/rules: [...] Actually, the relevant part is before that: ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += -j$(NUMJOBS) endif You seem to be missing some dependencies between your rules. ah, thanks for the hint. I hope to have fixed that now, could you give the packages at http://people.debian.org/~mejo/zope2.11/ give a try? greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534013: zope2.10: FTBFS: /bin/sh: line 0: cd: z: No such file or directory
Hello again, On 03/07/2009 Lucas Nussbaum wrote: On 03/07/09 at 04:17 +0200, Jonas Meurer wrote: On 02/07/2009 Lucas Nussbaum wrote: if you take a look at debian/rules, there are several more commands in unpack-stamp than just the 'tar xfz'. According to your logfile, the build-arch-stamp and patch-stamp targets are executed in the middle of the unpack-stamp target. I'm unable to reproduce that bug in a clean amd64 debian/unstable pbuilder chroot. here's the relevant parts of debian/rules: [...] Actually, the relevant part is before that: ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += -j$(NUMJOBS) endif You seem to be missing some dependencies between your rules. ah, thanks for the hint. I hope to have fixed that now, could you give the packages at http://people.debian.org/~mejo/zope2.11/ give a try? Bah, if you just removed the lines about that, I would suggest uploading it, since it's unlikely to break ;) what I actually did, is trying to fix the dependencies of different targets. only issue that I don't know what to do about, is that the dpatch patch(-stamp) target would need to depend on the unpack(-stamp) target. but I don't know how to define that dependency, as the dpatch patch(-stamp) target isn't defined in debian/rules directly but rather in the dpatch include file /usr/share/dpatch/dpatch.make. greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540157: Bug#540158: doesnt use invoke-rc.d
hey, On 09/08/2009 Jonas Meurer wrote: ok, after discussing this with kobold, i finally implemented the following changes: - zope-debhelper uses invoke-rc.d in maintainer scripts - dzhandle uses invoke-rc.d for DZRestartPendingInstances.run() - zope2.1[01] init scripts support [ZEOSERVER|INSTANCE]=... as second argument - zope-common breaks zope2.[789] and old zope2.1[01] packages - zope-debhelper adds depends on recent zope-common to packages that use dh_installzope* - zope2.1[01] build-depend on recend zope-debhelper and pre-depend on recent zope-common please test the packages (especially install|upgrade|remove|purge) with as many different setups as possible (no|one|many zope instances, zope2.1[01]-sandbox installed|upgraded|...). you can find all packages (amd64 and i386) at http://people.debian.org/~mejo/zope/ i'll upload zope-common and zope-debhelper to unstable within the next days if nobody objects. once both are in unstable for one or two days, i'll upload zope2.10 and zope2.11 as well. as nobody except kobold commented on this yet, i just went ahead and uploaded zope2.10 and zope2.11 to unstable. zope-common/zope-debhelper were already uploaded two days ago. greetings, jonas signature.asc Description: Digital signature
Bug#542928: [pkg-cryptsetup-devel] Bug#542928: cryptsetup fail with kernel 2.6.30-6
hello, On 22/08/2009 Guillaume JAOUEN wrote: Since upgrade of the kernel to 2.6.30-6, my laptop fail to start and doesn't ask for the lucks passphrase so my LVM setup can't start and the system lost debian-root and debian-swap filesystem... Rebooting with 2.6.29 old kernel start properly. thanks for your bugreport. in order to detect the problem it would be very useful if you could provide further information: - do you use a selfcompiled kernel, or did you install the default debian kernel (in package linux-image-2.6.30-1-amd64)? - if you use a selfcompiled kernel, could you attach the .config of both the working 2.6.29 kernel and the broken 2.6.30 kernel? - when you boot the broken 2.6.30 kernel, what exactly happens? do you get some message like 'root filesystem not found'? do you see an emergency shell of the initramfs? - from the initramfs shell, please give the output of 'cat /proc/crypto' and 'cat /proc/modules'. you can do that by saving the output into a logfile on the boot fs. i.e. if your boot partition is /dev/sda1, do the following: mount /dev/sda1 /boot cat /proc/crypto /boot/proc_crypto_log cat /proc/modules /boot/proc_modules_log afterwards reboot with the working 2.6.29 kernel and attach both logfiles from /boot to your reply mail. greetings, jonas signature.asc Description: Digital signature
Bug#542928: [pkg-cryptsetup-devel] Bug#542928: Bug#542928: cryptsetup fail with kernel 2.6.30-6
hey again, On 25/08/2009 Guillaume JAOUEN wrote: I use a standard sid install with only nvidia proprietary driver : thanks for the information. i run several debian/sid installations with linux-image-2.6.30-1-amd64 (2.6.30-6) without any issues, and so far I was unable to reproduce the bug you reported. let's see ... This kernel also runs on a Xen hypervisor. It supports only unpriviledged (domU) operation. so the system on which you discovered the bug runs as domU, right? Output during boot : debian kernel 2.6.30-1-amd64 ... failure : failed to assemble all array volume group debian not found. skipping volume group debian. unable to find LVM volume debian/root volume group debian not found. skipping volume group debian. unable to find LVM volume debian/swap_1 done. begin : waiting for root file system... done gave up waiting for root device. common problems : - boot args cat /proc/cmdline - check rootdelay =(did the system wait long enough?) - check root =(did the system wait for the right device?) - missing modules ( cat /proc/modules) ALERT! /dev/mapper/debian-root does not exist dropping to a shell. busybox V.1.13.3 (debian 1:1.13.3-1) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty: job control turned off. (initramfs) do you use lvm? seems like the lvm setup is broken. in case that your root device is on lvm (the default for guided encrypted partitioning in debian-installer), then that might be the real issue here. output of cat /proc /cmdline : (initramfs) root=/dev/mapper/debian-root ro output of mount /dev/sda1 /boot/ : mount: mounting /dev/sda1 on /boot/ failed no such file or directory. output of ls / : bin boot ( I had to create it with mkdir) ok, and is it possible to mount /dev/sda1 after creating /boot? i.e. 'mkdir /boot mount -t ext3 /dev/sda1 /boot' output of ls /dev/sd* : sda sda1 sda2 sda5 from the initramfs, please give the output of 'for dev in /dev/sda[125]; do echo $dev:; fstype $dev; done' I can't mount any file system, they are in ext3 format. what is the exact error message if you try to mount them? on your system (booted with a working kernel), please give the output of /etc/fstab and /etc/crypttab. greetings, jonas signature.asc Description: Digital signature
Bug#542928: [pkg-cryptsetup-devel] Bug#542928: Bug#542928: cryptsetup fail with kernel 2.6.30-6
hey, On 26/08/2009 Guillaume JAOUEN wrote: You'll find in this mail all the output log. I add also dmesg output dpkg get-selections, lshw and lspci output. I hope it may help you understand what's happening : - dpkg-gzt-selections.txt was made under 2.6.29-2 kernel boot. - cat-proc-crypto.log was made under 2.6.30-1 kernel boot. - cat-proc-crypto-2.6.29-2.log was made under 2.6.29-2 kernel boot. - cat-proc-devices.log was made under 2.6.30-1 kernel boot. - cat-proc-devices-2.6.29-2.log was made under 2.6.29-2 kernel boot. - cat-proc-modules.log was made under 2.6.30-1 kernel boot. - cat-proc-modules-2.6.29-2.log was made under 2.6.29-2 kernel boot. - config-2.6.29-2-amd64 and config-2.6.30-1-amd64 were generated into /boot - dmesg.log was made under 2.6.30-1 kernel boot. - dmesg.2.6.29-2.log was made under 2.6.29-2 kernel boot. - lshw-2.6.29-2.log was made under 2.6.29-2 kernel boot. - lspci-2.6.29-2.log was made under 2.6.29-2 kernel boot. - ps-aux.log was made under 2.6.30-1 kernel boot. - uname.log was made under 2.6.30-1 kernel boot. - cat-etc-crypttab-2.6.29-2.log was made under 2.6.29-2 kernel boot. - cat-etc-fstab-2.6.29-2.log was made under 2.6.29-2 kernel boot. With these elements I hope I give you the maximum details about my hardware and software configuration. ok, i just tried to reproduce the bug with similar setup (lvm over luks) and a selfcompiled kernel using your config-2.6.30-1-amd64, but i failed. the system still boots as expected. My laptop doesn't use xen hypervisor even if the kernel message display this information. some of the xen packages you've installed don't exist in the archive any longer, xen 3.2 has been replaced by xen 3.4 in the meanwhile. I agree with you when you're saying that the lvm setup is broken that's what my system complain about since the upgrade of the kernel and it's link to the fact that as the device /dev/sda5 isn't decrypted, my lvm setup wasn't available on boot process. in another mail you wrote: Output during boot : debian kernel 2.6.30-1-amd64 ... failure : failed to assemble all array volume group debian not found. skipping volume group debian. unable to find LVM volume debian/root unable to find LVM volume debian/swap_1 done. begin : waiting for root file system... done gave up waiting for root device. common problems : - boot args cat /proc/cmdline - check rootdelay =(did the system wait long enough?) - check root =(did the system wait for the right device?) - missing modules ( cat /proc/modules) ALERT! /dev/mapper/debian-root does not exist dropping to a shell. busybox V.1.13.3 (debian 1:1.13.3-1) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty: job control turned off. (initramfs) could you verify that this is the exact output you get at trying to boot the broken linux kernel 2.6.30-1-amd64? this is the output i get at booting with a linux kernel 2.6.30-1-amd64 built with your kernel config: Volume group debian not found Skipping volume group debian Unable to find LVM volume debian/root Volume group debian not found Skipping volume group debian Unable to find LVM volume debian/swap_1 Unlocking the disk /dev/hda2 (hda2_crypt) Enter passphrase: the LVM errors are harmless. they only appear for the reason that lvm is started both before and after cryptroot. that's to support both lvm over luks and luks over lvm setups. if the boot output above is what you get, then a broken initramfs file which misses the cryptroot initramfs script might be the reason. please attach the output of the following commands as well (from a working system, i.e. with kernel 2.6.29-1-amd64): ls -al /boot/ [ -f /boot/grub/menu.lst ] cat /boot/grub/menu.lst [ -f /boot/grub/grub.conf ] cat /boot/grub/grub.conf and attach /tmp/initramfs-2.6.30-1-amd64.log after executing sh -x mkinitramfs --supported-target-version=2.6.30-1-amd64 \ -o /tmp/initramfs-2.6.30-1-amd64 2/tmp/initramfs-log greetings, jonas signature.asc Description: Digital signature
Bug#542928: [pkg-cryptsetup-devel] Bug#542928: Bug#542928: cryptsetup fail with kernel 2.6.30-6
hey, On 27/08/2009 Guillaume JAOUEN wrote: I start again the laptop with kernel 2.6.30-1 amd64 and write carefully the output during the boot : ... Begin : Assembling all MD arrays... mdadm : No arrays found in config file or automatically Failure : failed to assemble all arrays. done. Volume group debian not found Skipping volume group debian Unable to find LVM volume /debian/root Volume group debian not found Skipping volume group debian Unable to find LVM volume /debian/swap_1 done. up to here, everything seems fine: mdadm is started but no software raid configured, then lvm is started but no volume group available yet. Begin: Waiting for root file system... done Gave up waiting for root device. that one indicates that the root device is not available to cryptroot. for some reason, the encrypted device (/dev/sda5) is not available. either missing hardware driver or wrong device might be reasons. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Check root= (did the system wait for the right device ?) - Missing modules (cat /proc/modules;ls /dev) ALERT! /dev/mapper/debian-root does not exist. Dropping to a shell ! BusyBox v1.13.3 (Debian 1:1.13.3-1) built-in shell (ash). Enter 'help' for a list of built-in commands. /bin/sh : can't access tty : job control turned off (initramfs) in the initramfs emergency shell, please give output of the following commands: cat /conf/conf.d/cryproot ls -al /dev/sda5 and if the device file exists, try unlocking it manually: cryptsetup luksOpen /dev/sda5 sda5_crypt lvm vgchange -a y ls -al /dev/mapper/debian-root if the device doesn't exist, then please give output of 'ls -al /dev' from initramfs as well. You'll find the output of this command in attachement : dell-xps:/boot/grub# sh -x mkinitramfs --supported-target-version=2.6.30-1-amd64 \ -o /tmp/initramfs-2.6.30-1-amd64 2/tmp/initramfs-log dell-xps:/boot/grub# sorry, the command was wrong. please use the following instead: sh -x mkinitramfs -o /tmp/initramfs 2.6.30-1-amd64 2/tmp/initramfs.log and attach /tmp/initramfs.log to the mail. also, please update your initramfs, try to reboot with the broken kernel afterwards and seee whether that helps: mv /boot/initramfs-2.6.30-1-amd64 /boot/initramfs-2.6.30-1-amd64.orig update-initramfs -c -k 2.6.30-1-amd64 sorry for asking that many questions, but i simply don't have a straight idea what the problem on your system might be. apparently the same kernel and system setup works for me. greetings, jonas signature.asc Description: Digital signature
Bug#543667: [Python-modules-team] Bug#543667: The same
hey, On 27/08/2009 Nahuel ANGELINETTI wrote: I have the same problem today, and I do not find the new package, where can I find it? Or at least the source to build it myself? i've uploaded a fixed package today (1.2.2-10). it should be available on the mirrors tomorrow. until then you can find it at debian incoming: http://incoming.debian.org/python-mysqldb_1.2.2-10_amd64.deb http://incoming.debian.org/python-mysqldb_1.2.2-10_i386.deb greetings, jonas signature.asc Description: Digital signature
Bug#544669: [pkg-cryptsetup-devel] Bug#544669: cryptsetup: /sbin/blkid is not in initramfs
reassign 544669 util-linux
severity 544669 normal
tag 544669 +patch
thanks
hey,
On 02/09/2009 Mario 'BitKoenig' Holbe wrote:
cryptsetup 1.0.7-2 recommends to replace vol_id and un_vol_id by blkid
and un_blkid. Both of these scripts depend on /sbin/blkid.
However, /sbin/blkid is not available in the initramfs image.
thanks for the bugreport. cryptroot doesn't support checkscripts, thus
check and precheck options are ignored for cryptroot devices anyway. i'm
downgrading severity to normal for that reason.
Considering your changelog statement that udev will remove vol_id soon,
I'm not sure whether this bug should really be fixed in cryptsetup
itself or if /sbin/blkid should be included in the initramfs either by
initramfs-tools or util-linux directly.
yes, you're correct. util-linux should copy blkid to the initramfs
directly. initramfs-tools will need to be migrated to blkid anyway.
currently it's using vol_id. so the propper fix for this is to ship
/usr/share/initramfs-tools/hooks/util-linux within util-linux. the
script should contain something like:
---snip---
#!/bin/sh -e
PREREQ=
prereqs()
{
echo $PREREQ
}
case $1 in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
copy_exec /sbin/blkid
---snap---
this mail downgrades the bug to normal, adds the 'patch' tag, and
reassigns it to the package 'util-linux'.
greetings,
jonas
signature.asc
Description: Digital signature
Bug#544773: [pkg-cryptsetup-devel] Bug#544773: Update to cryptsetup 2:1.0.7-2 breaks booting
hey, On 02/09/2009 Paul Millar wrote: After upgrading a few packages (listed below) I discovered my laptop was unable to boot. The laptop uses a Luks partition with LVM (this was using a standard guided partitioning option back when I was installing Debian). The boot fails at around the same time I would normally be prompted for the passphrase to unlock the Luks partition. One (or more) of the upgraded packages triggered a rebuild of the initrd. Suspecting that this might be the cause of the problem, I tried adjusting the boot process. Using grub's built-in editor, I changed the initrd from the usual value to the backup copy (which has the filename with .bak appended). When booting from the backup copy of the initrd the computer booted without any problem. I then took the two initrd images, unpacked them and compared their contents. There was a number of differences, but the most noticable change was that the file: conf/conf.d/cryptroot that was present in the backup initrd was missing in the new initrd. This file contained cryptographic options for establishing the LVM ontop of the Luks partition. I've copied the contents here: target=sdb2_crypt,source=/dev/sda2,key=none,rootdev,lvm=vedrfolnir-root target=sdb2_crypt,source=/dev/sda2,key=none,lvm=vedrfolnir-swap_1 Suspecting that the absence of this file was causing the problem, I copied the missing conf/conf.d/cryptroot file into the new initrd's contents and repacked the initrd file. Booting off this modified version of new initrd was successful. Therefore, I conclude that the laptop was unable to boot due to the missing conf/conf.d/cryptroot file in the initrd. it seems like the initramfs generation process is broken. unfortunately i'm unable to reproduce the bug on several different setups. please run the following command: # sh -x mkinitramfs -o /tmp/initramfs 2/tmp/initramfs.log and send /tmp/initramfs.log to the bugreport. greetings, jonas signature.asc Description: Digital signature
Bug#544773: [pkg-cryptsetup-devel] Bug#544773: Update to cryptsetup 2:1.0.7-2 breaks booting
hey, On 03/09/2009 Linus Lüssing wrote: Yes, I'm having the same problem here. I updated cryptsetup yeseterday to 2:1.07-2 and now I can't boot my usual 2.6.30-1-amd64 anymore. My other kernels on this machine seem unaffected, just my usual kernel-image does not boot. So I can select/boot 2.6.30-1-686, 2.6.29-2-amd64 or 2.6.29-2-686 with grub-pc for example. please send /tmp/initramfs.log to the bugreport after running the following command: # sh -x mkinitramfs -o /tmp/initramfs 2.6.30-1-amd64 2/tmp/initramfs.log greetings, jonas signature.asc Description: Digital signature
Bug#576488: [pkg-cryptsetup-devel] Bug#576488: cryptroot: boot script assumes to be run in initramfs
hey maks, On 05/04/2010 maximilian attems wrote: initramfs-tools 0.94 will break cryptsetup cryptroot boot script. The Ubuntu feature of pre-cached order got merged, will add a versioned breaks on cryptsetup their is a patch in Ubuntu cryptsetup for the situation, including it here. thanks for merging. i'm away on holidays right now, without access to gpg key. unfortunately and additionally i've troubles with my mail server as well. two raid5 harddisks decided to break at once. in short: i'll not be able to upload a fixed cryptsetup package within the next week. thus it would be great if you could NMU cryptsetup with the patch for this bug applied. greetings, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554506: (ugly) patch which should fix dm-crypt-on-lvm setups
Hello,
Again I tried to work on this bugreport. I'm absolutely sure that
different bugs are spotted. Most people are hitting the following bug:
the debian-installer was changed to configure devices in fstab and
crypttab in the 'UUID=...' style some time ago. this works for most
systems, with the exception of 'dm-crypt on lvm' setups, where the
encrypted devices are on top of lvm.
the reason is, that the cryptroot initramfs script tries to determine
the volume group from the source device string if the source device is
not available at boot. in the past that was possible for source devices
like '/dev/mapper/vg01-root_crypt'. the lvm volume group is 'vg01'.
for source devices specified as 'UUID=...' this is not possible any
longer.
the only fix i can see, is make the cryptroot initramfs hook determine
the underlying lvm volume group (if any) at mkinitramfs time, and write
the name of the volume group to /conf/conf.d/cryptroot. this information
can be used by the initramfs script at boot time in order to activate
the volume group before trying to unlock the encrypted (logical volume)
device.
i now prepared some ugly patches against cryptroot-hook and
cryptroot-script, that implement what I described above.
the implementation is still very ugly but on my test systems it works.
please give the attached patches a try and see whether they finally fix
the issue for you.
even better would be suggestions on how to improve the implementations,
i.e. provide a more elegant solution.
comments #15, #40, #45, #82, #87, #113, #118 and #123 are about
different issues, which aren't related to this bug.
greetings,
jonas
--- /usr/share/initramfs-tools/hooks/cryptroot.orig
+++ /usr/share/initramfs-tools/hooks/cryptroot
@@ -230,6 +230,9 @@
lvm=*)
OPTIONS=$OPTIONS,$opt
;;
+ lvm_vg=*)
+OPTIONS=$OPTIONS,$opt
+;;
keyscript=*)
opt=${opt#keyscript=}
if [ ! -x /lib/cryptsetup/scripts/$opt ] [ ! -x $opt ]; then
@@ -338,7 +341,7 @@
}
add_device() {
- local node nodes opts lastopts i count
+ local node nodes node_deps node_maj node_min node_depnode node_vg opts lastopts i count
nodes=$1
opts= # Applied to all nodes
lastopts= # Applied to last node
@@ -374,6 +377,18 @@
nodes=$lvmnodes
fi
+ # Check for dm-crypt on lvm
+ node_deps=$(dmsetup deps $nodes 2/dev/null | sed 's/[^:]*: *//;s/[ (]//g;s/)/ /g')
+ if [ -n $node_deps ]; then
+ node_maj=$(echo ${node_deps%,*} | sed -e s/^[ \t]*//g)
+ node_min=$(echo ${node_deps#*,} | sed -e s/[ \t]*$//g)
+ node_depnode=$(dmsetup ls | sed -n s/\\([^ ]*\\) *($node_maj, $node_min)/\\1/p | sed -e s/[ \t]*$//)
+ node_vg=$(lvdisplay /dev/mapper/$node_depnode 2/dev/null | sed -r -e s|^ +VG Name +([^ ]+) *$|\1|;tx;d;:x)
+ if [ -n $node_vg ]; then
+ lastopts=lvm_vg=$node_vg
+ fi
+ fi
+
# Prepare to setup each node
count=$(echo $nodes | wc -w)
i=1
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot.orig
+++ /usr/share/initramfs-tools/scripts/local-top/cryptroot
@@ -100,6 +100,9 @@
lvm=*)
cryptlvm=${x#lvm=}
;;
+ lvm_vg=*)
+ cryptlvm_vg=${x#lvm_vg=}
+ ;;
keyscript=*)
cryptkeyscript=${x#keyscript=}
;;
@@ -142,28 +145,32 @@
activate_vg()
{
local vg
- vg=${1#/dev/mapper/}
-
- # Sanity checks
- if [ ! -x /sbin/lvm ]; then
- message cryptsetup: lvm is not available
- return 1
- elif [ $vg = $1 ]; then
- message cryptsetup: lvm device name ($vg) does not begin with /dev/mapper/
- return 1
- fi
+ if [ -n $cryptlvm_vg ]; then
+ vg=$cryptlvm_vg
+ else
+ vg=${1#/dev/mapper/}
+
+ # Sanity checks
+ if [ ! -x /sbin/lvm ]; then
+ message cryptsetup: lvm is not available
+ return 1
+ elif [ $vg = $1 ]; then
+ message cryptsetup: lvm device name ($vg) does not begin with /dev/mapper/
+ return 1
+ fi
- # Make sure that the device contains at least one dash
- if [ ${vg%%-*} = $vg ]; then
- message cryptsetup: lvm device name ($vg) does not contain a dash
- return 1
- fi
+ # Make sure that the device contains at least one dash
+ if [ ${vg%%-*} = $vg ]; then
+ message cryptsetup: lvm device name ($vg) does not contain a dash
+ return 1
+ fi
- # Split volume group from logical volume.
- vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
+ # Split volume group from logical volume.
+ vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
- # Reduce padded --'s to -'s
- vg=$(echo ${vg} | sed -e 's#--#-#g')
+ # Reduce padded --'s to -'s
+ vg=$(echo ${vg} | sed -e 's#--#-#g')
+ fi
lvm vgchange -ay ${vg}
return $?
signature.asc
Description: Digital signature
Bug#554506: (ugly) patch which should fix dm-crypt-on-lvm setups
Hey Christoph,
On 04/11/2010 Christoph Anton Mitterer wrote:
I haven't fully looked at this so perhaps it's unrelated,...
But one main problem I see here (that may be related), is that lvm's
init-scripts are simply wrong, and abusing some things.
I've already told Bastian this and there are even several bugs open.
The problem is that lvm's init script simply doesn't to an lvchange -ay
but try to detect the LV holding root.
And it does this in a wrong way by using the root= kernel param (which
is the final device, containing the root-fs)
Most lvm/dm-crypt realted I've seen were simply solvable by letting the
lvm initscript just do an lvchange -ay (thereby making all LVs
available) and then using dmcrypt/cryptsetup as normal.
while this bug is not related to init scripts at all, your suggestions
makes a lot of sense to me. after all, i don't see a reason to detect
the volume group with complicated dmsetup, sed and lvdisplay invokations
instead of just activating all volume groups globally in the initramfs.
attached patch removes any vg-guessing magic from the initramfs
cryptroot script, just invoking 'lvm vgchange -ay' instead.
thanks for the comment, Christoph!
greetings,
jonas
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot.orig
+++ /usr/share/initramfs-tools/scripts/local-top/cryptroot
@@ -141,46 +141,31 @@
activate_vg()
{
- local vg
- vg=${1#/dev/mapper/}
-
# Sanity checks
if [ ! -x /sbin/lvm ]; then
message cryptsetup: lvm is not available
return 1
- elif [ $vg = $1 ]; then
- message cryptsetup: lvm device name ($vg) does not begin with /dev/mapper/
- return 1
fi
- # Make sure that the device contains at least one dash
- if [ ${vg%%-*} = $vg ]; then
- message cryptsetup: lvm device name ($vg) does not contain a dash
+ # Detect available volume groups
+ vgs=$(lvm vgs --noheadings -o vg_name | sed -e s/^[ \t]*\(.*\)[ \t]*$/\1/g)
+ if [ -z $vgs ]; then
+ message cryptsetup: no lvm volume groups found
return 1
fi
- # Split volume group from logical volume.
- vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
-
- # Reduce padded --'s to -'s
- vg=$(echo ${vg} | sed -e 's#--#-#g')
-
- lvm vgchange -ay ${vg}
+ lvm vgchange -ay
return $?
}
activate_evms()
{
local dev module
- dev=${1#/dev/evms/}
# Sanity checks
if [ ! -x /sbin/evms_activate ]; then
message cryptsetup: evms_activate is not available
return 1
- elif [ $dev = $1 ]; then
- message cryptsetup: evms device name ($vg) does not begin with /dev/evms/
- return 1
fi
# Load modules used by evms
@@ -219,8 +204,8 @@
# Make sure the cryptsource device is available
if [ ! -e $cryptsource ]; then
- activate_vg $cryptsource
- activate_evms $cryptsource
+ activate_vg
+ activate_evms
fi
# If the encrypted source device hasn't shown up yet, give it a
@@ -320,7 +305,7 @@
if [ -z $cryptlvm ]; then
message cryptsetup: lvm fs found but no lvm configured
return 1
- elif ! activate_vg /dev/mapper/$cryptlvm; then
+ elif ! activate_vg; then
# disable error message, LP: #151532
#message cryptsetup: failed to setup lvm device
return 1
signature.asc
Description: Digital signature
Bug#554506: (ugly) patch which should fix dm-crypt-on-lvm setups
Hey Christoph,
On 04/11/2010 Christoph Anton Mitterer wrote:
I haven't fully looked at this so perhaps it's unrelated,...
But one main problem I see here (that may be related), is that lvm's
init-scripts are simply wrong, and abusing some things.
I've already told Bastian this and there are even several bugs open.
The problem is that lvm's init script simply doesn't to an lvchange -ay
but try to detect the LV holding root.
And it does this in a wrong way by using the root= kernel param (which
is the final device, containing the root-fs)
Most lvm/dm-crypt realted I've seen were simply solvable by letting the
lvm initscript just do an lvchange -ay (thereby making all LVs
available) and then using dmcrypt/cryptsetup as normal.
while this bug is not related to init scripts at all, your suggestions
makes a lot of sense to me. after all, i don't see a reason to detect
the volume group with complicated dmsetup, sed and lvdisplay invokations
instead of just activating all volume groups globally in the initramfs.
attached patch removes any vg-guessing magic from the initramfs
cryptroot script, just invoking 'lvm vgchange -ay' instead.
thanks for the comment, Christoph!
greetings,
jonas
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot.orig
+++ /usr/share/initramfs-tools/scripts/local-top/cryptroot
@@ -141,46 +141,31 @@
activate_vg()
{
- local vg
- vg=${1#/dev/mapper/}
-
# Sanity checks
if [ ! -x /sbin/lvm ]; then
message cryptsetup: lvm is not available
return 1
- elif [ $vg = $1 ]; then
- message cryptsetup: lvm device name ($vg) does not begin with /dev/mapper/
- return 1
fi
- # Make sure that the device contains at least one dash
- if [ ${vg%%-*} = $vg ]; then
- message cryptsetup: lvm device name ($vg) does not contain a dash
+ # Detect available volume groups
+ vgs=$(lvm vgs --noheadings -o vg_name | sed -e s/^[ \t]*\(.*\)[ \t]*$/\1/g)
+ if [ -z $vgs ]; then
+ message cryptsetup: no lvm volume groups found
return 1
fi
- # Split volume group from logical volume.
- vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
-
- # Reduce padded --'s to -'s
- vg=$(echo ${vg} | sed -e 's#--#-#g')
-
- lvm vgchange -ay ${vg}
+ lvm vgchange -ay
return $?
}
activate_evms()
{
local dev module
- dev=${1#/dev/evms/}
# Sanity checks
if [ ! -x /sbin/evms_activate ]; then
message cryptsetup: evms_activate is not available
return 1
- elif [ $dev = $1 ]; then
- message cryptsetup: evms device name ($vg) does not begin with /dev/evms/
- return 1
fi
# Load modules used by evms
@@ -219,8 +204,8 @@
# Make sure the cryptsource device is available
if [ ! -e $cryptsource ]; then
- activate_vg $cryptsource
- activate_evms $cryptsource
+ activate_vg
+ activate_evms
fi
# If the encrypted source device hasn't shown up yet, give it a
@@ -320,7 +305,7 @@
if [ -z $cryptlvm ]; then
message cryptsetup: lvm fs found but no lvm configured
return 1
- elif ! activate_vg /dev/mapper/$cryptlvm; then
+ elif ! activate_vg; then
# disable error message, LP: #151532
#message cryptsetup: failed to setup lvm device
return 1
signature.asc
Description: Digital signature
Bug#554506: (ugly) patch which should fix dm-crypt-on-lvm setups
Hey Alasdair, thanks for your comments. On 04/11/2010 Alasdair G Kergon wrote: If the complex processing doesn't work for everyone then yes, simplify it and activate everything always. To do it the other way you need logic something like: Every time you boot, check if the stack of devices necessary to be activated has changed, and if so, update the information for use next time it boots. At boot time, try the last stack known to work first. If it doesn't work, try any other different saved stacks from earlier boots. If none of them work then fall back to activating everything. In other words make the initramfs code robust enough to cope with the unexpected! I now changed the initramfs code to always activate all volume groups: both before cryptsetup in case the source device is not available, and after cryptsetup in case the unlocked device contains lvm data. this way, the complicated and error-prone volume group -guessing code is not needed anymore. greetings, jonas signature.asc Description: Digital signature
Bug#626294: segmentation fault at opening imap folder
Package: mutt Version: 1.5.21-5 Severity: grave Hello, Since the upgrade to mutt 1.5.21-5, mutt occasionally crashes with a segmentation fault at opening a IMAP maildir folder. It doesn't matter, which IMAP folder is opened. I didn't discover this bug with mutt 1.5.21-4, with the exactly same configuration and IMAP server. The IMAP server in question is a Courier IMAP SSL 4.4.0-2 on debian/lenny. The output of a strace of the segmentation fault is attached to this mail. Greetings, jonas -- Package-specific info: Mutt 1.5.21 (2010-09-15) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 2.6.38-1-amd64-resivo (x86_64) ncurses: ncurses 5.9.20110404 (compiled with 5.9) libidn: 1.20 (compiled with 1.20) hcache backend: tokyocabinet 1.4.37 Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/usr/share/mutt SYSCONFDIR=/etc EXECSHELL=/bin/sh MIXMASTER=mixmaster To contact the developers, please mail to mutt-...@mutt.org. To report a bug, please visit http://bugs.mutt.org/. misc/am-maintainer-mode features/ifdef features/xtitles features/trash-folder features/purge-message features/imap_fast_trash features/sensible_browser_position features-old/patch-1.5.4.vk.pgp_verbose_mime features/compressed-folders features/compressed-folders.debian debian-specific/Muttrc debian-specific/Md.etc_mailname_gethostbyname.diff debian-specific/use_usr_bin_editor.diff debian-specific/correct_docdir_in_man_page.diff debian-specific/dont_document_not_present_features.diff debian-specific/document_debian_defaults debian-specific/assumed_charset-compat debian-specific/467432-write_bcc.patch debian-specific/566076-build_doc_adjustments.patch misc/define-pgp_getkeys_command.diff misc/gpg.rc-paths misc/smime.rc upstream/531430-imapuser.patch upstream/537818-emptycharset.patch upstream/543467-thread-segfault.patch upstream/542817-smimekeys-tmpdir.patch upstream/548577-gpgme-1.2.patch upstream/553321-ansi-escape-segfault.patch upstream/568295-references.patch upstream/547980-smime_keys-chaining.patch upstream/528233-readonly-open.patch upstream/228671-pipe-mime.patch upstream/383769-score-match.patch upstream/578087-header-strchr.patch upstream/603288-split-fetches.patch upstream/537061-dont-recode-saved-attachments.patch upstream/608706-fix-spelling-errors.patch upstream/620854-pop3-segfault.patch upstream/611412-bts-regexp.patch upstream/624058-gnutls-deprecated-set-priority.patch upstream/624085-gnutls-deprecated-verify-peers.patch upstream/584138-mx_update_context-segfault.patch upstream/619216-gnutls-CN-validation.patch upstream/611410-no-implicit_autoview-for-text-html.patch upstream/path_max mutt.org -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64-resivo (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mutt depends on: ii libc6 2.13-2 Embedded GNU C Library: Shared lib ii libcomerr21.41.12-4 common error description library ii libgnutls26 2.10.5-1+b1the GNU TLS library - runtime libr ii libgpg-error0 1.10-0.3 library for common error values an ii libgpgme111.2.0-1.3 GPGME - GnuPG Made Easy ii libgssapi-krb5-2 1.9+dfsg-1+b1 MIT Kerberos runtime libraries - k ii libidn11 1.20-1 GNU Libidn library, implementation ii libk5crypto3 1.9+dfsg-1+b1 MIT Kerberos runtime libraries - C ii libkrb5-3 1.9+dfsg-1+b1 MIT Kerberos runtime libraries ii libncursesw5 5.9-1 shared libraries for terminal hand ii libsasl2-22.1.23.dfsg1-8 Cyrus SASL - authentication abstra ii libtokyocabinet8 1.4.37-6.1 Tokyo Cabinet Database Libraries [ Versions of packages mutt recommends: ii exim4-daemon-light [mail- 4.76-1 lightweight Exim MTA (v4) daemon ii libsasl2-modules 2.1.23.dfsg1-8 Cyrus SASL - pluggable authenticat ii locales
Bug#626711: convirt fails to start (config file missing)
Package: convirt Version: 2.0.1-5 Severity: grave Hello, Seems like convirt is missing the configuration file. /etc/convirt is not created at installation time. /usr/share/convirt/src/convirt/web/convirt/development.ini is a dangling to /etc/convirt/development.ini. For that reason, the daemon fails to start: # /etc/init.d/convirt start Starting Convirt: PID file is /var/run/convirt/paster.pid No virtualenv found, will try to use TG2 installed in the system Log file: /var/log/convirt/paster.log grep: /usr/share/convirt/src/convirt/web/convirt/development.ini: No such file or directory has no value. /root/.ssh/id_rsa does not exist. Setting it to /root/.ssh/id_rsa. /root/.ssh/id_rsa not found, Key based Authentication will not be used. Starting ConVirt using virtualenv : Default character encoding is utf-8 Error starting ConVirt. Please consult /var/log/convirt/paster.log for more details. Greetings, jonas -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64-resivo (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages convirt depends on: ii dbconfig-common 1.8.47 common framework for packaging dat ii debconf [debconf-2.0] 1.5.39 Debian configuration management sy ii dnsmasq 2.57-1 A small caching DNS proxy and DHCP ii expect 5.44.1.15-4 A program that can automate intera ii libjs-jquery1.5.1-1 JavaScript library for dynamic web ii libjs-mochikit 1.4.2-3 JavaScript library inspired by Pyt ii libmysqlclient-dev 5.1.56-1 MySQL database development files ii libxenstore3.0 4.1.0-3 Xenstore communications library fo ii python 2.6.6-14 interactive high-level object-orie ii python-babel0.9.6-1 tools for internationalizing Pytho ii python-beaker 1.5.4-4 cache and session library ii python-mysqldb 1.2.2-10+b3 A Python interface to MySQL ii python-paramiko 1.7.6-6 Make ssh v2 connections with Pytho ii python-paste1.7.5.1-1tools for using a Web Server Gatew ii python-setuptools 0.6.15-2 Python Distutils Enhancements (set ii python-support 1.0.13 automated rebuilding support for P ii python-turbogears2 2.0.3-2 Python web application framework ii python-zope.sqlalchemy 0.4-7Minimal Zope/SQLAlchemy transactio ii socat 1.7.1.3-1multipurpose relay for bidirection ii ssh 1:5.8p1-4secure shell client and server (me ii uml-utilities 20070815-1.1 User-mode Linux (utility programs) ii wget1.12-3.1 retrieves files from the web Versions of packages convirt recommends: ii mysql-client-5.1 [mysql-clien 5.1.56-1 MySQL database client binaries ii mysql-server-5.1 [mysql-serve 5.1.56-1 MySQL database server binaries and convirt suggests no packages. -- Configuration Files: /etc/default/convirt changed [not included] -- debconf information: convirt/internal/reconfiguring: false * convirt/mysql/method: unix socket convirt/passwords-do-not-match: convirt/missing-db-package-error: abort convirt/dbconfig-reinstall: false * convirt/dbconfig-install: true convirt/dbconfig-upgrade: true convirt/upgrade-error: abort * convirt/mysql/admin-user: root convirt/remove-error: abort convirt/install-error: abort convirt/dbconfig-remove: convirt/purge: false * convirt/db/app-user: convirt convirt/upgrade-backup: true convirt/database-type: mysql convirt/internal/skip-preseed: true convirt/remote/port: * convirt/db/dbname: convirt convirt/remote/host: convirt/remote/newhost: signature.asc Description: Digital signature
Bug#626715: convirt fails to start (sqlalchemy.exc.ArgumentError)
Package: convirt Version: 2.0.1-5 Severity: grave Hey again, after I copied development.ini from the convirt source package to /etc/convirt/, convirt dies with another error: # /etc/init.d/convirt start Starting Convirt: PID file is /var/run/convirt/paster.pid No virtualenv found, will try to use TG2 installed in the system Log file: /var/log/convirt/paster.log Using /var/lib/convirt/identity/cms_id_rsa Agent pid 14803 Identity added: /var/lib/convirt/identity/cms_id_rsa (/var/lib/convirt/identity/cms_id_rsa) ssh key added to agent. Starting ConVirt using virtualenv : Default character encoding is utf-8 Error starting ConVirt. Please consult /var/log/convirt/paster.log for more details. and /var/log/convirt/paster.log contains the following: /usr/lib/pymodules/python2.6/tw/core/view.py:223: DeprecationWarning: object.__new__() takes no parameters obj = object.__new__(cls, *args, **kw) Traceback (most recent call last): File /usr/bin/paster, line 18, in module command.run() File /usr/lib/pymodules/python2.6/paste/script/command.py, line 84, in run invoke(command, command_name, options, args[1:]) File /usr/lib/pymodules/python2.6/paste/script/command.py, line 123, in invoke exit_code = runner.run(args) File /usr/lib/pymodules/python2.6/paste/script/command.py, line 218, in run result = self.command() File /usr/lib/pymodules/python2.6/paste/script/serve.py, line 276, in command relative_to=base, global_conf=vars) File /usr/lib/pymodules/python2.6/paste/script/serve.py, line 313, in loadapp **kw) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 204, in loadapp return loadobj(APP, uri, name=name, **kw) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 224, in loadobj global_conf=global_conf) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 248, in loadcontext global_conf=global_conf) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 278, in _loadconfig return loader.get_context(object_type, name, global_conf) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 409, in get_context section) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 431, in _context_from_use object_type, name=use, global_conf=global_conf) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 361, in get_context global_conf=global_conf) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 248, in loadcontext global_conf=global_conf) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 285, in _loadegg return loader.get_context(object_type, name, global_conf) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 561, in get_context object_type, name=name) File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 587, in find_egg_entry_point possible.append((entry.load(), protocol, entry.name)) File /usr/lib/python2.6/dist-packages/pkg_resources.py, line 1954, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) File /usr/share/convirt/src/convirt/web/convirt/convirt/config/middleware.py, line 4, in module from convirt.config.app_cfg import base_config File /usr/share/convirt/src/convirt/web/convirt/convirt/config/app_cfg.py, line 19, in module from convirt import model File /usr/share/convirt/src/convirt/web/convirt/convirt/model/__init__.py, line 78, in module from convirt.core.platforms.kvm.KVMNode import KVMNode File /usr/share/convirt/src/convirt/web/convirt/convirt/core/platforms/kvm/KVMNode.py, line 48, in module class KVMNode(VNode): File /usr/lib/python2.6/dist-packages/sqlalchemy/ext/declarative.py, line 1175, in __init__ _as_declarative(cls, classname, cls.__dict__) File /usr/lib/python2.6/dist-packages/sqlalchemy/ext/declarative.py, line 1128, in _as_declarative (c, cls, inherited_table.c[c.name]) sqlalchemy.exc.ArgumentError: Column 'migration_port' on class class 'convirt.core.platforms.kvm.KVMNode.KVMNode' conflicts with existing column 'managed_nodes.migration_port' Removing PID file /var/run/convirt/paster.pid Greetings, jonas -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-1-amd64-resivo (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages convirt depends on: ii dbconfig-common 1.8.47 common framework for packaging dat ii debconf [debconf-2.0] 1.5.39 Debian configuration management sy ii dnsmasq 2.57-1 A small caching DNS proxy and DHCP ii expect 5.44.1.15-4 A program that can automate intera ii libjs-jquery1.5.1-1 JavaScript library for dynamic web ii libjs-mochikit
Bug#659182: [pkg-cryptsetup-devel] Bug#659182: dangling .so symlink
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Michael, Am 11.02.2012 04:54, schrieb Michael Biebl: tags 659182 + patch pending thanks Hi, as I haven't gotten a reply so far and seen no updates in the pkg svn, I've prepared a fix and uploaded to DELAYED/2. debdiff is attached. Please consider applying this patch in your next upload. If I should delay or cancel the NMU, please let me know. sorry for not replying earlier. I'll try to upload a fixed package tomorrow myself. Please cancel the NMU. Reason is that I invented another RC bug with 2:1.4.1-1 and would like to fix that one with the upload as well. It needs some testing first though. Thanks for the patch, it's much better than my fix in the SVN repository. I'll use it. Regards, jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPNvnhAAoJEFJi5/9JEEn+Iu0QAIVGrVCqLzFrQDZuC7MCh0Tw dJFlrAoPdxzAf0ktnQGzbjGRgfmVTzDrpSqRoGlM8O0KXf8XG39Y16S+ctPreo7a Acp3bHvgCnYcOznVGRlF4aW4XzOZCFkUpD9Ons3/Pfm0iCkw67kzzG9Hmfe4uRG8 WqMBZzy5InLoD+EZDz6m3Sz1xKi3U7/YIMMM6J2+AuMFp/wt18PQD3cT2JeVSii5 BJcPaC3kK3/JW5ST5VyjhCQz8/Bx8HdJihx4eMffuh/+POHhdULZGyxPRVRd4ccg cODASEyciZ2NtmwO++roUdvUXgrovhYPSz18Rp/Qv63Nlrp00nnUT+41N7hh2gUU Uk7OIOwFvU1IIu8YA5XlJMX8n1HMPhyffs79ghrd+d5WumOkPqBoJY4/2fE0nSQE 0WHY4MbzPXN6lVIIGLcj/q2QID2fuF8izawQ4Moa1yzTleb3kIdzt1P+3uIfy4qi kLH6Oj6oGQpA2BAlJWEVeEJBPR53MzTlJS4cysf/kZnzg0zqcTfFhcLFDx7iVz+B Et+bKoANJ4bU8WaEvNt9sOxMEgzQbi6q/7enopdcOTGcHCrF2APnPY1n9VKHzCUe 7FQyKMSvchKtIrEcX8IRL/n6HB+MGfQPuragGTlYnPdqV9Njsw1Q6di+JG0HsA/Z fVP0jGGgQfpN6RTsyU3G =f45S -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659182: [pkg-cryptsetup-devel] Bug#659182: dangling .so symlink
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 12.02.2012 11:15, schrieb Michael Biebl: Hi Jonas, On 12.02.2012 00:29, Jonas Meurer wrote: Am 11.02.2012 04:54, schrieb Michael Biebl: If I should delay or cancel the NMU, please let me know. sorry for not replying earlier. I'll try to upload a fixed package tomorrow myself. Please cancel the NMU. Reason is that I invented another RC bug with 2:1.4.1-1 and would like to fix that one with the upload as well. It needs some testing first though. If you upload 2:1.4.1-2 before my NMU hits the archive, my NMU will automatically be rejected. No harm done. If you take more time to upload your package, my NMU will make it possible to rebuild the reverse dependencies so packages in unstable are installable again. Apparently you are ok with the technical solution for the fix, so I see no harm in letting the NMU just proceed? You're right. Thanks for the hints. Regards, jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPN7iAAAoJEFJi5/9JEEn+W1EP/3IkWBB2FTO/ucgfHICJ9g4i nVNTtpH3z7/8Spwi4th97GzNWorl9lQU8WeCTihXoM+hg9X6RAkgymg82UH48JxY GuLZ8S1zABR9E+GNXWgP8qHVJwWsU4PyiZQKDhVDfOhekLBlAQaQnU8ipkvW71jb AvRn5nCD9gKESc15nMvl7pvwN9TWoWibW0mUMU/tnIDe/qZksVM0+6bAmjg65gMv xkISmwGPhv5uql5o5oJa2qlCrrPVA0u5mWY9O9IRlJQdzYmzxUoCB+q2ranWJbJD ySja91cvExH1yTYj4TKp4iAmI/tdSIwj3JRoHOO6N65D63Iy7dtY1Dea1+ygXVUp BNpu5eHZe4TInfRJu/6nUohv/UhY0VPLnpVkLYBLaNOsAWLdSegh6qXEI0/VQp6N eYZVizOYgj2T6uRFq7G8QGoZDHw0RnSlzX3kN+Zn5ybyDaxiNFqMRPyQ3rX+isRW X7Bs5Pz98EoK7vgmHAZZw0fIyMEwoCPDxXccpd3nVGm5tOR5+hgofhrGM1hhdbRx p6xf0IYOVvt7Y+7jZwk7HHa1FuMMRcoDVMQ4ksz8I8yidPqeIAy4Hida4g76HLfl VFUB1522KMq+sacJry9Bghe7b/nnmY2JyqFH9LOkIPIC19N/+Oit/Is+DUsOQNlx 2vswcJPopSoHIqr2goW9 =9Kyw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659688: [pkg-cryptsetup-devel] Bug#659688: cryptsetup: LVM on cryptsetup won't boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Roland, Am 13.02.2012 09:35, schrieb Roland Mas: Package: cryptsetup Version: 2:1.4.1-2 Severity: critical To be honest I don't agree with you on the severity of this bug. I understand that the changes in LVM handling of cryptroot initramfs script that I introduced in package version 2:1.4.1-1 may have brokeen your setup. But on the other hand your setup is very special and custom and I actually wasn't aware that it had been supported before. Note that although this bug was introduced at version 2:1.4.1-1, it is different from #659235: my PVs and LVs and VGs don't have dashes in their name. The current sequence: grub loads the kernel and the initramfs; the kernel boots; the initramfs looks for the root filesystem but cannot find it because it's not available yet; cryptsetup asks for a passphrase, which I type; cryptsetup: lvm fs found but no lvm configured. After some time I get dropped into a shell. In that shell, I can see the LVs as inactive, and I enable them with lvm lvchange -P -a y vg_mirexpress/root (and ditto for vg_mirexpress/swap), then ^D and the boot sequence starts again normally (it reloads my hibernated system). Are you confident that the bug didn't exist in 2:1.3.1-3 yet? Actually the only change in activating LVM volume groups from 2:1.3.1-3 to 2:1.4.1-1 was, that the option --sysinit is given to vgchange now. Please remove --sysinit option from line 156 of /usr/share/initramfs-tools/scripts/local-top/cryptroot, update your initramfs with 'update-initramfs -u' and see whether the problem disappears. 2:1.4.1-1 introduced much more changes in the initramfs cryptroot hook than in the initramfs cryptroot script. Maybe these changes introduced the bug you reported. Any messages given by 'update-initramfs -u' would be helpful to identify possible problems here. It's possible that the problem comes from the need for -P (--partial) in the commands I quote: as may be found in the configuration snippets below, the LUKS key to one of the PVs used in LVM is stored on the filesystem on another LV of the same VG; this means that the first activation of the VG needs to be done with the -P/--partial flag, so the available LVs (including root) are activated and the boot sequence may proceed. Regards, jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPOZa9AAoJEFJi5/9JEEn+nWsQAI5M2V6A4tJPxuanMfedggZq ZE6dvN6SBFUsQbCUKjHzVo4bGnPk4mhwYhsfdCOXzjBEvhfxfIYdwC62W92lm5fM FJnFypnFKbQE6HnRHruDsKt5+is2KqYEcdIkeFpiuA+TXdEw9TE59oOgrSfOt3d2 SugWL7EleUvM+Ez0Sd9zLr8YyXAonh5v2hkDOPaLRMVra8rjtBzyT6sYbioGH4S6 VZX8buhWp7PiP6ziEkmAMgDp504Is1sK4semHfRtcHblu5Tgdv6sQmBzPUMqFcvL tTlKBf08qzEVjunWX2RsCkyDMx1px6j32qgOezj1/vS3Pk/8bcp2dUbdrrkUjyYp WITrsKLDtff1XIRXZ5ysQLl3f3SOqIMUPRORoa3a9N1dDdO5wOwYdK7PTsVQw9XG LNLsECWftL6k9tTM7ruZZ3gp69dQXJQkoLdIlpROc4gUkHnCx7QawUUOwkH2JME4 hOY53YbNQP/z/iUihqT/YNnd+L/3NXDg+tNQNz94nH0irmMDfyq7KhEc0C4Jlfbe FBQ8dmuBZ/pPBAxRsefrBKZkv2H/njqbLGrb6vn12ZVijz0x8RH8oO9ddIdF2CH7 hfK+U0F8X3gChz0yj7cOqhe62xjXRR6zJ0wsrSI8VZSKXnLGlaRg7eNBTW7JiLxV WEAiZ+IflQtz+XnNA8hl =dzpd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682416: Bug renders package unusable
severity 682416 grave thanks Hello, this bug renders the package smstools mostly unusable for many users. I discovered the same bug. I can confirm, that the new upstream 3.1.15 fixes the bug. 3.1.15 has no changes apart from this fix, thus I suggest to push it into wheezy despite the freeze. Regards, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656552: zope2.12-sandbox: fails to upgrade from testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Arnau, Am 22.11.2012 11:56, schrieb Arnaud Fontaine: Ivo De Decker ivo.dedec...@ugent.be writes: [...] In other words: the package creates an (empty) zope instance in the postinst, but fails to install if such an instance exists. This makes a reinstall fail. It seems the relevant parts of these scripts come from zope-debhelper, so this bug probably originates there. Thank you so much for investigating this issue. IMHO, we can set 'zope-common/remove-instance-without-data' to remove by default, as there is no point at aborting by default if there is no data. What do you think? I fully agree with you. Thanks a lot for working on zope2.12/zope-common packages for wheezy! Your work is much appreciated. Kind regards, jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQsIyaAAoJEFJi5/9JEEn+BEIP/Rs8AY6nGHPVV93w7WMhyUum aLzHpZvbb8bcNWfKnhqWIWYIF2WMwq18yGsVUknIZiXl8F8Y+7I0lKktQtpzW+EG RtN5jutC3tr+46qg7JbdQC4844phH39D0c31bsSpV3XF4E6BJ/Vq81qZKDfJRx7a stH+wg2OSTdBdqHVIYJSqGUh1VnWtN48GMAFN3ssCWwjkn6WC4VsUVhD8tKg+Xls o9CDqOq36rACUt+Z6oqYrOxmJf7chQVwEc8POzwi5siW61sl2+g2Ci30W0mp3Jf+ r7HzQ/KbIk4GX2kM+ua1IQ8wFyUowoDh6kFAWI8ONSWKQnJ46/cZQsF6ODEsghrd 3D/ssQ9V6rOHFBCzs+xah/BKrZCcApR7j1wuw7VNKn0qNhOh1iKjLaCJfLqyB8Ae yYvVMmH05eV3XyEg84RaFcoJHMmbO+3QCOxNv2Gad2N56XmVrInXrYtDKI9RM5CF pE6BXuv6XShWrRT/9FAXhL8YvTpd71j9YvUZoeHbbeP4Ste4w8d4CuQA9Dta/iPS epKaTacR3Bm00SNlygcAPsFVyg0j58Ng/mX7Bbb5iV/VORE+6Vby5/c+wS68lB5d mArN+EleXmj1L1Z2j5/rllOl0efukYhha2eW4weoMTPENVtmVWvQJjq/FJNmkjgw 1Vt5VW1WArywtvodkWQ0 =Li+z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677127: [pkg-cryptsetup-devel] Bug#677127: relocation error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Milan, Am 12.06.2012 17:43, schrieb Milan Broz: On 06/11/2012 09:31 PM, p...@spth.de wrote: /sbin/crpytsetup: relocation error: /sbin/cryptsetup: symbol crypt_activate_by_key_file_offste, version CRYPTSETUP_1.0 not defined in file libcryptsetup.so.4 with link time reference just if it helps: crypt_activate_by_key_file_offset was added in 1.4.2 libcryptsetup, library is backward compatible but not forward compatible of course. Isn't possible that you have in initramfs old libcryptsetup.4 but new cryptsetup binary? (it should have proper version set, so it should be visible even for *.so symlink) Yup, that might be the problem. I realized that cryptsetup-bin (2:1.4.3-1) depends on libcryptsetup4 (= 2:1.4). Obviously this versioned depenency is to lax. It seems like the symbols file for libcryptsetup4 is broken. It lists all symbols with a wildcard and gives libcryptsetup4 (= 2:1.4) as minimum dependency. This is wrong as soon as new symbols are added to the library without bumping the soname. Investigating right now and trying to fix ;) Regards, jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP14HNAAoJEFJi5/9JEEn+PS0P/Rmz4oM6OYhn+/3ui9/O/dna 6bKNiKYMsq5p37Gc8ChXSSNkT8AQ44AkbYiowxmgap8F+nQF6vj547KwUbtCqIi6 2iwfiIHal6L/oKCc8r7vbDLZpSYf80Kyrw58+DsSpZuzlIqHAA8lK1gHMKT8g8yU ABOB+WOdODhow3txDAScibZqZYXM3J12PjuHIKfEjZuJxJTVSZSck1/o8IXCdhiR X3YdCMLcoBjhYc6nRjjlB3+HbJwt677fIGVv/aWQuogzjmZoQfyHMuU9B1X6kbJB 384zlPM6y2vKWoEKAMp1hqJDS0aKhopqUMLyyK6NW2YrMBjaUwyLksi5h/UNhyJC wqdQhskXpBgm43Zp4FCKwUWJohc/qwJw/lpWmA124cqEF4oWzB1W6oWpvJLGst0W XnwZn2xep8w7qLAqeUd90v16YtBSw5izoMt6NrC5hHgJUlJHg9yofxVUiO0sAqyA icjJzmsHxrYg+uuyPO/pyp+QsGBmLRmyajmHq5uR0BYcf2QuZd5JZ71HtO/hDRmV 26VOiVZE5Vp2klhiasQZKY1gHRIQ8LSUkRVUUoZ1wdLLg7NX/bn5enr10eAzlOpe bITk2VhRfQa3fiDcUpsS90F7sHIgqOSjRSljnz7cYbrBvqR7zd0j3L/v/PQ4+zk5 9mcnHtIqy1VCciCZsoqG =5lVz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714210: DRBD 8.3 userland incompatible with 8.4 kernel modules
Package: drbd8-utils Version: 2:8.3.13-2 Severity: grave Hello, as the subject already mentions, DRBD 8.3 userland in jessie/testing is incompatible with DRBD 8.4 kernel modules from the 3.9 linux package. DRBD kernel modules are at 8.4 branch in upstream linux kernel since kernel release 3.8. Ubuntu already ships DRBD 8.4 userland for this reason within Raring (13.04). Please consider to upgrade DRBD userland to 8.4. For now DRBD is unusable in Debian sid/unstable and jessie/testing. Kind regards, jonas -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710356: Duplicate bugreports, please include in next stable update
Hello, I believe that bugs #701084 and #710356 are duplicates. In other words, #710356 should be closed now that nagios3 3.4.1-4 was uploaded :) And I would suggest to incorporate the patch into prospective uploads to stable-security and/or oldstable-security. It's a very nasty bug with an easy fix. The patch is unlikely to break anything else. Kind regards, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710356: [Pkg-nagios-devel] Bug#710356: Info received (Fix for wheezy?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 09.12.2013 12:09, schrieb Jasir Baftijari: Hi, Hello Jasir, why I can't see the new Version 3.4.1-3+deb7u1? # aptitude versions nagios3 Paket nagios3: i 3.4.1-3 stable 500 The package is in wheezy-proposed-updates. It's not part of the official Debian Wheezy packages yet. Very likely it will be included in wheezy with the next point release though. Afaik this should happen within the next four weeks. In the meantime you can install it from proposed-updates: http://www.debian.org/releases/proposed-updates.html Kind regards, jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSpjdSAAoJEBvzc5c7ZRqnkwYP/itpyzHzjwee48YBresApytQ t1NMwRMIVdfNlk0rkzm2uy3a+F3BQYiYayn6g48gA2s6HXofcDhgLWEFMOCexmOZ hcT73npvEz7KNaVXccLNinKuM+3i8ldyc7eYAwI7oMnSqhc05GBT8bOcL7TXZ2Dg MeZmx/Rb15QGTn95L80V0pCC4/GwvuVUTn6p3nNiGSjPaggUPFMh6ssqponHrCum u5s1cThx1SCleDx9X8awZNv/vPkWC5VMMiGp3BqYPdu8WBhaGNIFaOZPMXPhfIsD ZTaw0e76ApMo3qZ68h3vA/WaA9ODjU3g4zYzk4oqtyFbsz/AC1hm2Z3KI22u34F3 w7POefgydyCFMsdeLQ8T2c5sY09uxPYn4SH3XgvyggL7UgyRb9uUD11XVUgD8FLK wSS9jj+Mn2StRUCURo5mlxMuWgWKemyxchNajVBeNGnpxm/0V+Eio4sSbV+Ua4/+ 7P2ut7uEFAjNKGor6JQRQYN/Q3G3rfV9N8hacloi/1juK+MhTAdFCzpApGVCV8xb jVVbtOWwxxnLoO1aOEijGhYa99vM5GNa6x8s4GBEoBw9LUVsa0nbZD2hJmiPuU8w OoBc3rCBerelTJWDrCmxbIu9OlltgG9NoWtts/8xSBWPHyq1cMt4NQ3halxNniLI s/4wd6G9lHCDX54TiGAm =q9T/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710356: [Pkg-nagios-devel] Bug#710356: Fix for wheezy?
Hello, Am 2013-11-04 10:10, schrieb Jasir Baftijari: Hello, i'm waiting for wheezy, too. Please Upload the fix to wheezy asap. Hopefully this bug will be fixed through an upload to wheezy-updates within the next days. I'm awaiting the approval of debian-release for the upload at the moment. Kind regards, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758755: [pkg-cryptsetup-devel] Bug#758755: libcryptsetup4-udeb: depends on libgcrypt20-udeb, which doesn't exist
Hi Cyril, Am 2014-08-21 01:10, schrieb Cyril Brulebois: Package: libcryptsetup4-udeb Version: 2:1.6.6-1 Severity: grave Justification: renders package unusable Hi, your package is no longer installable, because it now depends on libgcrypt20-udeb, which is nowhere to be found. now that you report the bugs I realize that I should have checked myself. @GnuTLS-Maint: what's the reason for not shipping a libgcrypt20-udev yet? Do you intend to fix #758756 soon? Likely a bug in libgcrypt20 (which builds no udeb but leads you to get a dependency on it) which I'm about to file. I don't see it in the archive or in NEW at least. The switch to libgcrypt20 seems premature to me. I see. Reason for the switch to gcrypt 1.6 was the recent Whirlpool cipher bug in gcrypt 1.5.3: http://lists.gnupg.org/pipermail/gcrypt-devel/2014-January/002889.html http://www.saout.de/pipermail/dm-crypt/2014-January/003799.html http://www.saout.de/pipermail/dm-crypt/2014-February/003956.html Also see section '8.3 Gcrypt after 1.5.3 breaks Whirlpool' in cryptsetup FAQ: https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#8._Issues_with_Specific_Versions_of_cryptsetup Kind regards, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758755: [pkg-cryptsetup-devel] Bug#758755: Bug#758756: libgcrypt20: missing udeb: libgcrypt20-udeb
Hey Andreas and Cyril, Am 21.08.2014 um 19:25 schrieb Cyril Brulebois: Andreas Metzler ametz...@bebt.de (2014-08-21): On 2014-08-21 Cyril Brulebois k...@debian.org wrote: Package: libgcrypt20 [...] but there's no libgcrypt20-udeb! (in the archive or in NEW) [...] I have just uploaded 1.6.1-3 with the udeb included. I hope NEW processing works out well. Thanks a lot Andreas, it's much appreciated! I'll try poking ftpmasters to see if it can get accepted soon. That'd avoid thinking about a revert on the cryptsetup side. Thanks for your help Cyril. Does this mean, that you're ok with cryptsetup keeping libgcrypt20 dependency now that the corresponding udeb will be in Debian soon? Sorry that I didn't coordinate with debian-boot. I simply didn't think about the consequences enough. I guess that's due to me not being involved in library transitions too often :-/ *sorry* Kind regards, jonas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
