Bug#371135: [Pkg-cryptsetup-devel] Bug#371135: About Bug#371135: suggestion

[Jonas Meurer]

On 16/06/2006 Mika Bostrom wrote:
> >yes, but initially the idea was to only check where we can be absolutely
> >sure that the check has no corner cases.
> 
>   I claim that this is impossible. There is no way to be absolutely sure
> about non-destructiveness of the operation. I'll try to explain.
> 
> [...]
>
> >in this case we will never find a known fstype on the cryptsetup target
> >device, as the random key will always differ.
> [...]
> >- check per default only if we might destroy data
> >- check per default only if the check is secure, has no corner cases
> >- support any other kind of check, but don't activate it per default
> 
>   With changing keys there is absolutely no way to identify what is
> valid swap space area. I see two possible approaches that _might_ be
> _theoretically_ doable:
> 
>   1. If crypttab defines an encrypted swap, use vol_id check for both
>  the created mapping AND the actual device.
> 
>   2. Use Jari Ruusu's watermark attack and explicitly disallow ESSIV
>  encryption mode for swap.
> 
> 
>   Trouble with case 1 is that it still does not catch a human error: The
> user could have fe. encrypted /home along with swap, and mixed the
> devices for these two lines. The additional test only catches the case
> that encrypted swap is erroneously defined on top of an unencrypted
> filesystem. 

exactly. in my opinion the following would be the best checksystem:

encrypted swap with a static key:
- check source device with vol_id, skip if any FS is found.
- if not, check destination device for a swap FS, skip if not
  found.

encrypted swap with a random key:
- check source device with vol_id, skip if any FS is found.
- explicitly warn in README.Debian that data loss is likely
  if a device with [i.e. encrypted] content is used.

in general, all plain dm-crypt source devices should be checked for
'unknown volume type' before cryptsetup is started. if any known FS is
found, the partition is not encrypted with plain dm-crypt.

for LUKS partitions, we already check with 'cryptsetup isLuks'.

so except for LUKS, the precheck needs to be improved for all cases.
postcheck only needs to be updated for swap with static key.

...
 jonas


signature.asc
Description: Digital signature

Bug#373987: splashy: why depend on console-tools?

[Jonas Meurer]

Package: splashy
Version: 0.1.8-1
Severity: important

hello,

why does splashy depend on console-tools? what does it use from
console-tools that kbd does not provide? i cannot find any reason to
explicitly depend on console-tools.

...
 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.17-rc3-1-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403426: [Pkg-cryptsetup-devel] Bug#403426: kernel corrupts LUKS partition header on arm

[Jonas Meurer]

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#369108: [Pkg-zope-developers] Bug#369108: zope-tinytableplus: dummy package zope-tinytable still needed?

[Jonas Meurer]

On 27/05/2006 Stefan Huehner wrote:
> Package: zope-tinytableplus
> Severity: wishlist
> 
> 
> Hi,
> your package build an dummy package named 'zope-tinytable'.
> In sarge there hasn't been a package namend zope-tinytable so
> i suspect that this dummy ins't needed for sarge -> etch upgrades.
> 
> Is this still needed or can it be removed?

you're correct, the transitional package can safely be removed.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#369439: chgpasswd terminates after asking for a password

[Jonas Meurer]

Package: passwd
Version: 1:4.0.15-10
Severity: normal

hello,

unfortunately, the new chgpasswd tool does not work as expected.
according to docs and it's model 'chpasswd' it reads a string with the
format "group_name:password" from standard input.
obviously, this does not work.

if i execute 'echo "jonas:password" | chgpasswd', i get a prompt:
Password:
and after two seconds it terminates with the following error message:
chgpasswd: PAM authentication failed

chgpasswd should not ask anything, as it's intended to be used in
scripts, and gets all information via stdin.

i am the one who initially submitted chgpasswd to you, and as far as i
remember, you forwarded it to upstream who added it to the shadow/passwd
package. i'm pretty sure that the original version (which was written by
wesley terpstra) worked.

wesley, do you have a copy of the chgpasswd.c that you submitted to me?

...
 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.17-rc3-1-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages passwd depends on:
ii  debianutils  2.16.1  Miscellaneous utilities specific t
ii  libc62.3.6-10GNU C Library: Shared libraries
ii  libpam-modules   0.79-3.1Pluggable Authentication Modules f
ii  libpam0g 0.79-3.1Pluggable Authentication Modules l
ii  libselinux1  1.30-1  SELinux shared libraries
ii  login1:4.0.15-10 system login tools

passwd recommends no packages.

-- debconf information:
  passwd/password-mismatch:
* passwd/username: jonas
  passwd/password-empty:
  passwd/md5: false
  passwd/user-uid:
  passwd/shadow: true
  passwd/username-bad:
* passwd/user-fullname: jonas
  passwd/make-user: true
  passwd/title:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#369439: [Pkg-shadow-devel] Bug#369439: chgpasswd terminates after asking for a password

[Jonas Meurer]

tag 369439 +patch
thanks

On 30/05/2006 Christian Perrier wrote:
> > if i execute 'echo "jonas:password" | chgpasswd', i get a prompt:
> > Password:
> > and after two seconds it terminates with the following error message:
> > chgpasswd: PAM authentication failed
> > 
> > chgpasswd should not ask anything, as it's intended to be used in
> > scripts, and gets all information via stdin.
> 
> 
> I suspect (without checking) that this could be related to the utility
> being PAMified. We currently don't use PAM for chpasswd in Debian and
> we probably should do so as well for chgpasswd.

absolutely correct. i tried disabling PAM for chgpasswd, and it worked
as expected. a patch is attached.

> We're currently considering to re-enable PAM for all utilities,
> without, however, using a PAM configuration file for each. We will
> probably have all utilities use the same PAM configuration file than
> passwd. But that's another story...

does that imply, that chpasswd and chgpasswd ask for a password? or is
this due to the missing configuration file currently? in any case, the
current behaviour of chpasswd is the expected one, the behaviour of
chgpasswd is not the expected one.

...
 jonas
diff -rNu shadow-4.0.15.orig/debian/patches/504_undef_USE_PAM.dpatch 
shadow-4.0.15/debian/patches/504_undef_USE_PAM.dpatch
--- shadow-4.0.15.orig/debian/patches/504_undef_USE_PAM.dpatch  2006-05-30 
16:02:54.0 +0200
+++ shadow-4.0.15/debian/patches/504_undef_USE_PAM.dpatch   2006-05-30 
16:08:46.0 +0200
@@ -1,5 +1,5 @@
-Goal: Do not use PAM for chage, chpasswd, groupadd, groupdel, groupmod
-  newusers, useradd, userdel, usermod (keep them low-level)
+Goal: Do not use PAM for chage, chpasswd, chgpasswd, groupadd, groupdel,
+  groupmod newusers, useradd, userdel, usermod (keep them low-level)
 Fixes: #283961, #162181, #162199, #162228.
 
 Note:
@@ -30,6 +30,18 @@
  
  #ident "$Id: chpasswd.c,v 1.34 2005/10/19 15:21:07 kloczek Exp $"
  
+Index: shadow-4.0.15/src/chgpasswd.c
+===
+--- shadow-4.0.15.orig/src/chgpasswd.c 2006-05-30 15:32:11.0 +0200
 shadow-4.0.15/src/chgpasswd.c  2006-05-30 15:33:24.0 +0200
+@@ -28,6 +28,7 @@
+  */
+ 
+ #include 
++#undef USE_PAM
+ 
+ #ident "$Id: chgpasswd.c,v 1.1 2006/03/05 22:12:38 kloczek Exp $"
+ 
 Index: shadow-4.0.15/src/groupadd.c
 ===
 --- shadow-4.0.15.orig/src/groupadd.c  2006-03-08 19:32:11.928876405 +0100
diff -rNu shadow-4.0.15.orig/debian/patches/504_undef_USE_PAM.nolibpam 
shadow-4.0.15/debian/patches/504_undef_USE_PAM.nolibpam
--- shadow-4.0.15.orig/debian/patches/504_undef_USE_PAM.nolibpam
2006-05-30 16:02:54.0 +0200
+++ shadow-4.0.15/debian/patches/504_undef_USE_PAM.nolibpam 2006-05-30 
15:41:18.0 +0200
@@ -9,7 +9,8 @@
 -chage_LDADD= $(LDADD) $(LIBPAM) $(LIBAUDIT) $(LIBSELINUX)
 +chage_LDADD= $(LDADD) $(LIBAUDIT) $(LIBSELINUX)
  chfn_LDADD = $(LDADD) $(LIBPAM) $(LIBSELINUX)
- chgpasswd_LDADD = $(LDADD) $(LIBPAM) $(LIBSELINUX)
+-chgpasswd_LDADD = $(LDADD) $(LIBPAM) $(LIBSELINUX)
++chgpasswd_LDADD = $(LDADD) $(LIBSELINUX)
  chsh_LDADD = $(LDADD) $(LIBPAM) $(LIBSELINUX)
 -chpasswd_LDADD = $(LDADD) $(LIBPAM) $(LIBSELINUX)
 +chpasswd_LDADD = $(LDADD) $(LIBSELINUX)


signature.asc
Description: Digital signature

Bug#369439: [Pkg-shadow-devel] Bug#369439: chgpasswd terminates after asking for a password

[Jonas Meurer]

On 30/05/2006 Tomasz Kłoczko wrote:
> Dnia 29-05-2006, pon o godzinie 21:10 +0200, Jonas Meurer napisał(a):
> > unfortunately, the new chgpasswd tool does not work as expected.
> > according to docs and it's model 'chpasswd' it reads a string with the
> > format "group_name:password" from standard input.
> > obviously, this does not work.
> 
> Do you have /etc/pam.d/chgpasswd file ?

no, i didn't.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#369439: [Pkg-shadow-devel] Bug#369439: chgpasswd terminates after asking for a password

[Jonas Meurer]

On 30/05/2006 Christian Perrier wrote:
> > > I suspect (without checking) that this could be related to the utility
> > > being PAMified. We currently don't use PAM for chpasswd in Debian and
> > > we probably should do so as well for chgpasswd.
> > 
> > absolutely correct. i tried disabling PAM for chgpasswd, and it worked
> > as expected. a patch is attached.
> 
> 
> Confirmed. With th exact same patch indeed. Thanks for reporting and
> taking care of helping tracking this down.
> 
> If you don't mind, we'll wait for the new upstream version, that's due
> very soon, to make a new upload.

no problem ,-)

...
 jonas


signature.asc
Description: Digital signature

Bug#369575: [Pkg-cryptsetup-devel] Bug#369575:

[Jonas Meurer]

On 31/05/2006 David Härdeman wrote:
> Tobias Gruetzmacher wrote:
> > When using the current cryptsetup from unstable with pmount, the
> > passwort prompt does not show
> 
> I think this is due to the patch in #364153.
>
> [...]
> 
> Jonas, will you prepare a fix or should I?

ok, i prepared a fix, and uploaded i386 packages (1.0.3-2) to
http://people.debian.org/~mejo/cryptsetup/

tobias, could you check if these fix your bug?

if yes, we should upload tomorrow, as it fixes a serious bug and three
others as well.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#369575: [Pkg-cryptsetup-devel] Bug#369575:

[Jonas Meurer]

On 02/06/2006 Tobias Gruetzmacher wrote:
> On Fri, Jun 02, 2006 at 02:42:52PM +0200, Jonas Meurer wrote:
> > ok, i prepared a fix, and uploaded i386 packages (1.0.3-2) to
> > http://people.debian.org/~mejo/cryptsetup/
> > 
> > tobias, could you check if these fix your bug?
> 
> No, it does not. I think the problem is that the previously used getpass
> wrote directly to /dev/tty, therefore circumventing input/output
> redirection of the parent process. I think pmount redirects stdout
> somewhere and the password prompt of cryptsetup gets lost. I suspect
> this is really a pmount bug and not a problem with cryptsetup...

i'm not sure about that. the cryptsetup prompt is a critical output, it
should always appear, even if stdout and stderr are redirected.

i think that this is the reason why getpass was used before.

david: are you capable of writing a patch that reverts this, and writes
the prompt directly to /dev/tty again?
maybe STDERR just needs to be changed to /dev/proc/self/fd/0?

and stderr is still a better solution than stdout, don't you think so?

...
 jonas


signature.asc
Description: Digital signature

Bug#370302: [Pkg-cryptsetup-devel] Bug#370302: the attachment

[Jonas Meurer]

On 04/06/2006 General Stone wrote:
> Ups :-(

sorry, but this one is not readable. looks like a gnupg encrypted
attachment. you need to send the patches as plain attachment.

...
 jonas


signature.asc
Description: Digital signature

Bug#370302: [Pkg-cryptsetup-devel] Bug#370302: a better recommendation for cryptdisks.functions

[Jonas Meurer]

On 04/06/2006 David Härdeman wrote:
> >2) The swap-check-script use the "strings" tool which is in "/usr/bin"
> >  :-/. "egrep" can work with binarys so that work with "strings" is
> >  needless.
> 
> A better solution would be to use fstype from klibc or libvol from 
> udev to identify filesystem types.

fstype is in /usr/lib, but vol_id from udev is at /lib/udev/vol_id, and
seems like exactly what we want. for example:
# /lib/udev/vol_id -t /dev/sda4

i'll see whether i find time to implement it in the next days.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#370302: [Pkg-cryptsetup-devel] Bug#370302: a better recommendation for cryptdisks.functions

[Jonas Meurer]

Hello General,

thanks for the patches, details below.

On 04/06/2006 General Stone wrote:
> In the attachment are patches for a better support on decrypted keys and
> to fix some little typing errors.

i didn't find any fixed typos, did you miss them in the patch?

> 1) seperate the init-script and the decrypt-scripts so that anybody can
>write his own decrypt-script without modify the init-script. The
>decrypted key must be in "/tmp/cryptdisk.key" were it will be removed
>after added a crypted disk.

good idea, i will implement it soon.

> 2) The swap-check-script use the "strings" tool which is in "/usr/bin"
>:-/. "egrep" can work with binarys so that work with "strings" is
>needless.

also a good idea, but using vol_id from udev seems like a even better
one. still the scripts could use a fallback, if udev is not installed.

> 3) "/etc/keys" <-- which keys? better is "/etc/disk-keys"!?

i don't see the point here. what's wrong with /etc/keys? i don't think
that most people like a new directory for every key type. and it's only
a recommentation, nobody is forced to store his/her keys there.

...
 jonas


signature.asc
Description: Digital signature

Bug#369575: [Pkg-cryptsetup-devel] Bug#369575:

[Jonas Meurer]

On 04/06/2006 David Härdeman wrote:
> >i think that this is the reason why getpass was used before.
> >
> >david: are you capable of writing a patch that reverts this, and writes
> >the prompt directly to /dev/tty again?
> >maybe STDERR just needs to be changed to /dev/proc/self/fd/0?
> 
> I've attached a new version of 01_terminal_timeout.dpatch which uses 
> /dev/tty if possible and stderr otherwise. I haven't tested it though, 
> so perhaps it would be best if Jonas could make a new test package and 
> Tobias could verify that I didn't screw things up? 

great, new packages prepared. cryptsetup 1.0.3-2 available at
http://people.debian.org/~mejo/cryptsetup/ please give them a try,
Tobias, and report whether they fixed your bug.

...
 jonas

ps: the packages have also a new vol_id check script to check for any
known filesystem types.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#370302: [Pkg-cryptsetup-devel] Bug#370302: a better recommendation for cryptdisks.functions

[Jonas Meurer]

On 05/06/2006 General Stone wrote:
> > also a good idea, but using vol_id from udev seems like a even better
> > one. still the scripts could use a fallback, if udev is not installed.
> 
> I don't use udev but for anybody and in general it is better and finer.
> Yes you have right and udev should be recommend.

i prepared cryptsetup 1.0.3-2 packages which have a new default vol_id
check, which checks for any known filesystem per default and fails only
if no one is found. you can give a particular fs type with the new
checkargs option in /etc/crypttab. if the swap option is used, the check
will only succeed if the target device contains a swap partion.

the ext2, xfs and swap check scripts are depreciated now, but i kept
them in the package for now, as they don't do any harm. the swap check
doesn't use /usr/bin/strings any more.

please give the package a try and report whether this is what you
wanted.

the decrypt_key functions will be added soon.

...
 jonas


signature.asc
Description: Digital signature

Bug#370302: [Pkg-cryptsetup-devel] Bug#370302: a better recommendation for cryptdisks.functions

[Jonas Meurer]

On 04/06/2006 David Härdeman wrote:
> On Sun, Jun 04, 2006 at 09:38:28PM +0200, Jonas Meurer wrote:
> >>1) seperate the init-script and the decrypt-scripts so that anybody can
> >>   write his own decrypt-script without modify the init-script. The
> >>   decrypted key must be in "/tmp/cryptdisk.key" were it will be removed
> >>   after added a crypted disk.
> >
> >good idea, i will implement it soon.
> 
> Writing a key to /tmp might not be a good idea since it could be 
> recoverable later.

yes, better pipe it through stdin.

> Why not change the semantics of /etc/crypttab so that the third column 
> (keyfile) is interpreted as a script if the file exists and has the 
> executable bit set. If so, the script is executed and its stdout is 
> piped to cryptsetup via stdin.
> 
> Sounds ok?

yes, sounds like a nice feature, but i'm not sure whether implementing
more non-obvious features is good.
and adding one more option for the options field in /etc/crypttab is more
obvious than extending the usage of the keyfile field.
also, the keyfile still needs to be passed to the script, otherwise you
need an own script for every encrypted disk.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#409835: mixxx: freezes my system completely

[Jonas Meurer]

On 07/02/2007 Paul Brossier wrote:
> severity 409835 important
> thanks 
> 
> On Mon, Feb 05, 2007 at 09:16:34PM +0100, Jonas Meurer wrote:
> > 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.
> 
> If mixxx manages to crash your X server, then it's likely a problem in
> the server. If the whole system collapses, then it could well be a
> problem in the kernel driver of your video card.
> 
> Could you confirm you can not ping your machine anymore? or light the
> leds of the keyboard?

Hey Paul,

The machine was really frozen, but now i changed the graphics
controller, and mixxx doesn't freeze the system any more. I don't know
whether it was the hardware (Matrox G400 DH) or whether the xorg mga
driver is broken, but at least now with a geforce 4 TI and the
proprietary nvidia x-driver it doesn't freeze any longer.

> > 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.
> 
> mixxx could also be improved substantially on the graphic rendering
> side, and this bug is important.

Do you think that the bug should be kept open then? Maybe just rename it
to 'improve the graphic rendering' and downgrade severity to wishlist?

> it would also be useful to know if other applications using 3d
> acceleration are working fine on your machine.

This finally was the point where i got that something needs to be wrong
with my hardware/xdriver. Every single application with 3d acceleration
froze my system.

btw: Do you already work on debian packages for mixxx 1.5.0?

greetings
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#410821: mysql-server-5.0: mysqld dies with '*** glibc detected *** double free or corruption (!prev): 0x08dd1dd0 ***'

[Jonas Meurer]

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 t

Bug#410821: mysql-server-5.0: mysqld dies with '*** glibc detected *** double free or corruption (!prev): 0x08dd1dd0 ***'

[Jonas Meurer]

On 13/02/2007 Steve Langasek wrote:
> On Tue, Feb 13, 2007 at 06:46:22PM +0100, Jonas Meurer wrote:
> > 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
> 
> Could you try running mysqld under valgrind?  It's likely in this scenario
> that the bug lies far away from the point where glibc detects it; valgrind
> is usually the best way to find out where that is.

The bug appeared on a production machine, so debugging is somewhat
difficult. One admin considered that the mysql server crash was produced
by a particular zope application, but we were not able to reproduce it
yet.

The crash didn't appear in the last three days, by the way. So if you
like, we could lower severity of the bug to important and tag it as
unreproducible for now.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#402417: [EMAIL PROTECTED]: [Pkg-cryptsetup-devel] Bug#402417: handle chainmode/essiv "plain" correctly]

[Jonas Meurer]

On 02/01/2007 David Härdeman wrote:
> >I need some advice regarding this bug. Unforuntately i don't know
> >nothing about initramfs, and David Härdeman, the one who usually does
> >all the cryptsetup initramfs stuff, is unavailable currently.
> >
> >Could somebody comment on this patch, so that the fix can make it into
> >etch in case that it is ok?
> 
> I've done a quick check (and I wont have time to comment more until I 
> return from my vacation):
> 
> 1) renaming variables is a separate issue and should not be done
> 
> 2) "-a" is a bashism so I think we should avoid it even though it seems to 
> be supported by the initramfs shell
> 
> So just change the first check (around 240) from:
> 
> if [ -n "$blockcipher" ]; then
> 
> to
> 
> if [ -n "$blockcipher" ] && [ "$blockcipher" != "plain" ]; then
> 
> and the corresponding line (looks like line 244) from:
> 
> if [ -n "$ivhash" ]; then
> 
> to
> 
> if [ -n "$ivhash" ] && [ "$ivhash" != "plain" ]; then

ok, i've commited the two-line change to svn, but i'm currently waiting
for a fix for #403426 and a new upstream (1.0.5) before uploading.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#402417: [Pkg-cryptsetup-devel] Bug#402417: cryptsetup: fails to mount encrypted root

[Jonas Meurer]

On 11/12/2006 David Härdeman wrote:
> On Sun, December 10, 2006 11:15, Enrico Gatto said:
> > When booting a system with encrypted root, the boot fails to a busybox
> > shell. The /usr/share/initramfs-tools/scripts/local-top/cryptroot script
> > correctly recognizes root /dev/mapper/croot and put it in NEWROOT, but
> > then this variable is no more used nor passed to
> > /usr/share/initramfs-tools/scripts/local script, so it tries to mount
> > /dev/evms/root as root device and fails.
> 
> Hi,
> 
> could you please provide me with your /etc/crypttab, /etc/fstab, a list of
> your boot parameters and a description of your setup (I assume you use a
> combination of evms and crypto?)

Hey David,

Did you already take a look at this bug?

Frans Pop didn't push cryptsetup 2:1.0.4+svn16-1 into etch yet because
of this bug.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400611: mozilla-tabextensions: replaces the startpage with a clear tab instead of opening a new one

[Jonas Meurer]

Package: mozilla-tabextensions
Version: 2.1.2006031301-2
Severity: normal

Hello,

After upgrading to iceweasel 2.0+dfsg-1 and mozilla-tabextensions
2.1.2006031301-2, the behaviour directly after starting iceweasel
changed:
the startpage (that i configured in iceweasels preferences) still is
loaded at the beginning, but if i press + to open a new tab,
the startpage is silently replaced by a clear tab. in the past a new
(second) tab was opened instead.

I regard this as a bug as long as it is not configurable. But
unfortunately i didn't find any propper configuration settings.

...
 jonas

-- System Information:
Debian Release: 4.0
  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-6-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages mozilla-tabextensions depends on:
ii  iceweasel 2.0+dfsg-1 lightweight web browser based on M

mozilla-tabextensions recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400615: mozilla-tabextensions: no close button for tabs with iceweasel 2.0+dfsg-1

[Jonas Meurer]

Package: mozilla-tabextensions
Version: 2.1.2006031301-2
Severity: important

Hello,

Unfortunately i cannot find any 'close' buttons for tabs when using the
tabextensions plugin in iceweasel 2.0+dfsg-1.
I loaded the presets for heavy users just to be sure that my local
changes didn't produce this bug.
But still i neither see a 'close' button in the tab itself, nor at the
right side of the tabbar.

If i disable the tabextensions plugin, at least the 'close' button in
the tab is visible.

The 'close' button on the right side of the tabbar is always invisible,
even though i enabled it in the preferences. but that seems to be a bug
in iceweasel itself.

...
 jonas

-- System Information:
Debian Release: 4.0
  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-6-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages mozilla-tabextensions depends on:
ii  iceweasel 2.0+dfsg-1 lightweight web browser based on M

mozilla-tabextensions recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400600: [Pkg-cryptsetup-devel] Bug#400600: please clarify role of /lib/cryptsetup/cryptdisks.functions

[Jonas Meurer]

On 27/11/2006 David Härdeman wrote:
> >But now these scripts just exit with an OK status if this file is not
> >present/readable... Under my assumption above it should be a grave error
> >instead.
> 
> No, because the init scripts can under some conditions still be left on 
> your system even after you've removed the cryptsetup package. Checking 
> in init.d scripts for some necessary components and silently exiting if 
> they're missing is quite common.
> 
> Example - /etc/init.d/postgresql-8.1
> line 17:  [ -r /usr/share/postgresql-common/init.d-functions ] || exit 0
>
> >It would be nice if README.Debian provided documentation how the scripts 
> >are intended to work together.
> 
> Why? If the cryptdisks.functions script is missing even though you haven't 
> removed the cryptsetup package from your system something is seriously 
> broken.

I agree with that opinion. Init scripts and other configuration files
stay on your system if the package is removed but not purged. Therefore
it is even better if the scripts silently exit in this situation.

Robert do you have any objections against closing this bugreport?

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#414326: cryptsetup: cryptsetup starting its disks should have "verify" as default

[Jonas Meurer]

On 11/03/2007 Joerg Jaspert wrote:
> Package: cryptsetup
> Version: 2:1.0.4+svn26-1
> Severity: important
> 
> I think that could also be critical, as it breaks unrelated software
> (the whole system). But as the temporary workaround is easy, lets go
> with important. Maybe serious, as IMO this is release critical, but that
> should get decided by release team
> 
> It also silently changes behaviour between sarge and etch.
> 
> The thing is simple - as subject says the option "verify" should be
> default for entries in crypttab. One can always type one letter wrong,
> and should not be left with a broken system. (Imaging having all of the
> system except / on cryptofoo).

So you suggest to ask for the passphrase twice at normal cryptsetup
startup? Do you suggest it for 'cryptsetup create' only, or also for
'cryptsetup luksOpen'?

I'm not sure whether I understand your point. You say, that the system
breaks at boot if a wrong password is typed. But that might even happen
when you need to enter it twice. Consequently, should we ask thousands
of times for the password, just to be sure that typos are unlikely?

Typing every password twice is quite annoying, and i don't believe that
many users share your thoughts about doing so by default.
Instead I encourage you to use the verify option where you need it.

I also don't understand why you claim this bug being (IYO) release critical.

Your interpretation that it "breaks [...] (the whole system)" is illogical.
Typos are user mistakes, I don't see how i may prevent them from a
maintainers point of view.
In fact you may find thousands of examples where user mistakes end up in
the system being unbootable. Are all these release-critical bugs in your
eyes?

Sorry if i simply didn't get the point, maybe you could try to explain
with other words in this case.

David, what do you think about this bugreport? Do you share my doubts?

greetings,
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#414326: cryptsetup: cryptsetup starting its disks should have "verify" as default

[Jonas Meurer]

merge 414326 412064
thanks

On 18/03/2007 Joerg Jaspert wrote:
> On 10962 March 1977, Jonas Meurer wrote:
> >> The thing is simple - as subject says the option "verify" should be
> >> default for entries in crypttab. One can always type one letter wrong,
> >> and should not be left with a broken system. (Imaging having all of the
> >> system except / on cryptofoo).
> 
> > So you suggest to ask for the passphrase twice at normal cryptsetup
> > startup? Do you suggest it for 'cryptsetup create' only, or also for
> > 'cryptsetup luksOpen'?
> 
> luksOpen.
> And maybe verify isnt the right option to use, but to fail immediately
> right after one error is plain wrong. Try an older cryptsetup package,
> it asked 3 times if you entered a passphrase wrong.

Ah, then you experience the same bug as described in #412064.
The problem here is, that cryptsetup no longer accepts the --tries
option. I'm working on a fix for that.

> > I also don't understand why you claim this bug being (IYO) release
> > critical.
> 
> It does work differently to sarge, in a broken way. You dont even have
> the chance to correct a simple typo.

Sorry, but cryptsetup in sarge didn't even have LUKS support, so retries
in case that a wrong password was supplied were completely impossible.

cryptsetup (20050111-3) in sarge had only support for plain dm-crypt
encryption, were you have no way to check for the correct password
anyway.

> > Your interpretation that it "breaks [...] (the whole system)" is illogical.
> > Typos are user mistakes, I don't see how i may prevent them from a
> > maintainers point of view.
> 
> Just ask 3 times. Or more than once.
> 
> > In fact you may find thousands of examples where user mistakes end up in
> > the system being unbootable. Are all these release-critical bugs in your
> > eyes?
> 
> If they change a perfectly working behaviour from earlier revisions,
> yes.

I doubt that we get a fix for this bug into etch, as cryptsetup has a
udeb.

greetings
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#411657: Transition from sarge-etch for zope packages

[Jonas Meurer]

On 21/02/2007 Fabio Tranchitella wrote:
> * 2007-02-21 15:17, A Mennucc wrote:
> > > 
> > > Depends: python (>= 2.4) | python2.4, ...
> > > 
> > > would do the trick, leaving the old python package around without removing
> > > python2.3, but I'm not even sure and to say the truth I do not understand
> > > why the dependency on python2.4 has been replaced with python (>= 2.4).
> > 
> > quite on the opposite, I fail to see why this would help.
> > May you explain better?
> 
> Because zope-common requires python (>= 2.4), which conflicts with
> the sarge version of python2.3. So far, so good.
> 
> If the user managed to install zope-common, he already has installed
> python2.4 in his system (because zope-common only works with python2.4)
> from sarge-backports, testing or unstable.
> 
> In this scenario, the dependency block "python (>= 2.4) | python2.4" is
> satisfied because python2.4 is already installed and apt does not have to
> install the new python package, which would lead to the python2.3 removal.
> 
> Urgh, my english is terrible.. Is it more clear now? I do not know if this
> would actually work, and all I need now is a god fix for #411657.

If i understand it correctly, zope-common should depend on python2.4,
but not on python (>= 2.4), and use python2.4 directly.

This would avoid an upgrade of the default python package and just
introduce the new python2.4 package. This way, the old python (<= 2.3),
python2.3 and zope2.7 could stay on the upgraded system.

But maybe I'm just mixing up things.

greetings
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#411657: Transition from sarge-etch for zope packages

[Jonas Meurer]

On 21/02/2007 Fabio Tranchitella wrote:
> * 2007-02-21 17:33, Jonas Meurer wrote:
> > If i understand it correctly, zope-common should depend on python2.4,
> > but not on python (>= 2.4), and use python2.4 directly.
> > 
> > This would avoid an upgrade of the default python package and just
> > introduce the new python2.4 package. This way, the old python (<= 2.3),
> > python2.3 and zope2.7 could stay on the upgraded system.
> 
> Sure, and it used to be so, but Matthias Klose (python maintainer) uploaded
> a new release of zope-common which depends on python (>= 2.4) two weeks
> ago.
> 
> This is why I'm asking here.

So is there any reason for this, Matthias?

Otherwise this change should be reverted, shouldn't it?

...
 jonas


signature.asc
Description: Digital signature

Bug#397012: idesk segfaults

[Jonas Meurer]

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

[Jonas Meurer]

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#398799: modprobe -q dm-crypt breaks initscripts

[Jonas Meurer]

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#364153: [Pkg-cryptsetup-devel] Bug#364153: cryptsetup: timeout option leaves terminal in bad state

[Jonas Meurer]

On 13/05/2006 David Härdeman wrote:
> >i've tested your patch, and it seems to work perfectly well.
> >but unfortunately this is only the case for the luks* features of
> >cryptsetup. Plain 'cryptsetup create' still leaves the terminal in a bad
> >state after terminating the passphrase prompt.
> 
> I can't reproduce this. Both luks and non-luks seem to leave the 
> terminal in a state which is fine. Looking at the code in lib/setup.c, 
> both luks and non-luks use the same function (get-key) so if one works, 
> both should work.

you're absolutely correct. i cannot reproduce it either. i don't know
how i got the impression, that 'cryptsetup create' still left the
terminal in a bad state after terminating the prompt.
sorry for the confusion.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#364153: [Pkg-cryptsetup-devel] Bug#364153: cryptsetup: timeout option leaves terminal in bad state

[Jonas Meurer]

On 13/05/2006 Andres Salomon wrote:
> On Sat, 2006-05-13 at 22:40 +0200, Jonas Meurer wrote:
> > On 13/05/2006 David Härdeman wrote:
> > > >i've tested your patch, and it seems to work perfectly well.
> > > >but unfortunately this is only the case for the luks* features of
> > > >cryptsetup. Plain 'cryptsetup create' still leaves the terminal in a bad
> > > >state after terminating the passphrase prompt.
> > > 
> > > I can't reproduce this. Both luks and non-luks seem to leave the 
> > > terminal in a state which is fine. Looking at the code in lib/setup.c, 
> > > both luks and non-luks use the same function (get-key) so if one works, 
> > > both should work.
> > 
> > you're absolutely correct. i cannot reproduce it either. i don't know
> > how i got the impression, that 'cryptsetup create' still left the
> > terminal in a bad state after terminating the prompt.
> > sorry for the confusion.
> 
> Cool, so there's no additional fixes necessary for the patch then?

correct. again, sorry for the noise.

greetings
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#368446: cupsys-driver-gutenprint fails to install/upgrade

[Jonas Meurer]

Package: cupsys-driver-gutenprint
Version: 4.3.99+cvs20060521-1
Severity: important

hello,

At upgrading cupsys-driver-gutenprint, apt-get idles forever after
running '/usr/sbin/cups-genppdconfig.5.0 -u'.

a short look at the postinst script shows, that
'/usr/sbin/cups-genppdconfig.5.0' is invoked without an option after
'/usr/sbin/cups-genppdconfig.5.0 -u'.

on the console, '/usr/sbin/cups-genppdconfig.5.0' gives an error message
without options, but maybe this is the reason for the infinite delay in
the install/upgrade process.

greetings
 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.16-8-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages cupsys-driver-gutenprint depends on:
ii  cupsys  1.1.23-15Common UNIX Printing System(tm) - 
ii  libc6   2.3.6-9  GNU C Library: Shared libraries
ii  libcupsimage2   1.1.23-15Common UNIX Printing System(tm) - 
ii  libcupsys2  1.1.23-15Common UNIX Printing System(tm) - 
ii  libgutenprint2  4.3.99+cvs20060521-1 runtime for the Gutenprint printer
ii  libjpeg62   6b-13The Independent JPEG Group's JPEG 
ii  libpng12-0  1.2.8rel-5.1 PNG library - runtime
ii  libtiff43.8.2-2  Tag Image File Format (TIFF) libra
ii  perl5.8.8-4  Larry Wall's Practical Extraction 
ii  zlib1g  1:1.2.3-11   compression library - runtime

Versions of packages cupsys-driver-gutenprint recommends:
ii  evince [postscript-viewe 0.4.0-1+b1  Document (postscript, pdf) viewer
ii  gnome-gv [postscript-vie 1:2.12.0-1  GNOME PostScript viewer
ii  gs-esp [postscript-viewe 8.15.1.dfsg.1-2 The Ghostscript PostScript interpr
ii  gs-gpl [postscript-viewe 8.50-1.1The GPL Ghostscript PostScript int
ii  gv [postscript-viewer]   1:3.6.1-13  PostScript and PDF viewer for X

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#368446: cupsys-driver-gutenprint fails to install/upgrade

[Jonas Meurer]

On 22/05/2006 Roger Leigh wrote:
> I need to add a build-depends, build-conflict or set DIALOG in
> configure, I think.  Could you attach a copy of your
> /usr/sbin/cups-genppdconfig.5.0 so I can compare?  This might be a
> peculiarity to the amd64 buildd (but is stil a bug in the packaging
> which needs correcting).

ok, attached.

...
 jonas
#! /usr/bin/perl -w
# $Id: cups-genppdconfig.in,v 1.12 2005/08/02 20:27:31 rleigh Exp $
# A user-friendly dialog-based wrapper for cups-genppd(8).
# Copyright (C) 2002 Roger Leigh <[EMAIL PROTECTED]>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

use strict;
use File::Basename;
use File::Find;
use File::Temp qw(tempfile unlink0);
use IO::Handle;
use Getopt::Std;
use POSIX;

sub init_data();
sub init_defaults();
sub main_menu();
sub display_help;
sub choose_printers;
sub choose_languages;
sub choose_location;
sub create_ppds;
sub create_dir($);
sub dialog_read($$);
sub dialog_read_list ([EMAIL PROTECTED]);

my $DIALOG = "";# version of dialog to call
my $BACKTITLE = "Gutenprint CUPS PPD creation"; # dialog screen title
my %printers;   # master list of printers
my %languages;  # master list of languages
my @used_printers;  # printer PPDs on system
my @used_languages; # languages used on system
my @chosen_printers = ();   # chosen printers
my @chosen_languages = ();  # chosen languages
my $version = "5.0";
my $chosen_location = "/usr/share/cups/model/gutenprint/$version";
# chosen PPD prefix
my $silent = 0; # no dialog


# Set chosen_location from command-line.
our $opt_d;
our $opt_u;
getopts('d:u');
if ($opt_d) {
$chosen_location = create_dir($opt_d);
}

# Initialise everything
init_data();
init_defaults();

# Run non-interactively if `-u' was specified.
if ( $opt_u ) {
$silent = 1;
create_ppds;
exit 0;
}

while (my $option = main_menu()) { # Display main menu and run selection
if ($option eq "Help") {
display_help();
} elsif ($option eq "Printers") {
choose_printers();
} elsif ($option eq "Languages") {
choose_languages();
} elsif ($option eq "Directory") {
choose_location();
} elsif ($option eq "Create") {
create_ppds();
} elsif ($option eq "Exit") {
exit 0;
} else {
die "Invalid menu option: $option";
}
}

exit 0;


#
# init_data() - Populate master printer and language hashes.
#
sub init_data() {
my $model;
my $desc;
my $lang;
# Get printer drivers and descriptions, then store in a hash.
open GENPPD, "cups-genppd.$version -M -v |" or die "can't fork 
cups-genppd.$version: $!";
while () {
($model, $desc) = /([\w-]+)\W+(.*)/;
chomp ($model);
chomp ($desc);
$printers{$model} = $desc;
}
close GENPPD or die "can't close cups-genppd.$version pipe: $!";
# Get available languages, then store in hash.
open GENPPD, "cups-genppd.$version -L |" or die "can't fork 
cups-genppd.$version: $!";
while () {
$lang = $_;
chomp ($lang);
$languages{$lang} = "(No description)";
}
$languages{"en"} = "US English";
close GENPPD or die "can't close cups-genppd.$version pipe: $!";
# Set defaults
@chosen_languages = ("en");
}


#
# init_defaults() - Get defaults from PPD files and directories.
#
sub init_defaults() {
# Find all PPD files that we could regenerate
my %found_ppds;
if (-d $chosen_location) {
find({wanted => \&find_printers}, $chosen_location);
foreach (@used_printers) {
my $tmp;
$tmp = basename($_);
chomp ($tmp);
$tmp =~ s/(^.*)\.ppd.*/$1/;
$found_ppds{$tmp} = "" if $printers{$tmp};
}
}
@chosen_printers = ();
foreach (sort keys %found_ppds) {
push @chosen_printers, $_;
}

# Find all language directories that could be used
my %found_langs;
if (-d $chosen_location) {
find({wanted => \&find_languages}, $chosen_location);
foreach (@used_languages) {
my $tmp;
$tmp = basename($_);
chomp ($tmp);
$fo

Bug#368446: cupsys-driver-gutenprint: patch for cups-genppdupdate.5.0

[Jonas Meurer]

On 22/05/2006 Roger Leigh wrote:
> "Felix C. Stegerman" <[EMAIL PROTECTED]> writes:
> 
> > * Roger Leigh <[EMAIL PROTECTED]> [2006-05-22 21:21]:
> >> I've uploaded a new build (at the same location).
> >
> > It installed just fine.
> 
> Super, thanks.
> 
> Jonas, if you could verify it fixes the problem for you as well, I'll
> upload tomorrow.

yes, it fixes the bug. thanks for the quick fix to both you and Felix.

...
 jonas


signature.asc
Description: Digital signature

Bug#376588: ITP: cryptomount -- a utility for accessing encrypted filesystems

[Jonas Meurer]

On 03/07/2006 Baruch Even wrote:
> * Package name: cryptomount
>   Version : 1.0.1
>   Upstream Author : rwpenney«AT»users«DOT»sourceforge«DOT»net
> * URL : http://cryptmount.sourceforge.net/
> * License : GPLv2 or later
>   Programming Lang: C
>   Description : a utility for accessing encrypted filesystems
> 
> cryptomount enables the user to simply create and mount an encrypted
> device based on dm-crypt. It can handle either a raw device or a loop
> mounted file as the base for dm-crypt.
> 
> It offers the following advantage:
> 
> * access to improved functionality in the kernel
> * transparent support for filesystems stored on either raw disk
>   partitions or loopback files
> * separate encryption of filesystem access keys, allowing access
>   passwords to be changed without re-encrypting the entire
>   filesystem
> * storing multiple encrypted filesystems within a single disk
>   partition, using a designated subset of blocks for each
> * rarely used filesystems do not need to be mounted at system
>   startup
> * un-mounting of each filesystem is locked so that this can only be
>   performed by the user that mounted it, or the superuser
> * encrypted filesystems compatible with cryptsetup
> * encrypted access-keys are compatible with openssl

hello Baruch,

i like the idea of cryptomount, as it seems to have advantages over
cryptsetup. for example cryptsetup does not support to store multiple
filesystems on one disk out of the box.

nevertheless most of cryptmount seems like a reinvention of cryptsetup,
or cryptdisks.

do you know the cryptsetup package from debian? we have a rather complex
initscript called cryptdisks there, which implements lots of additional
features for encrypted disks.
additional, cryptsetup has support for LUKS devices, which cryptomount
doesn't have.

maybe you're interested in joining the maintainer group:
Debian Cryptsetup Team <[EMAIL PROTECTED]>

we could maintain cryptomount as an additional package or discuss the
possibility to merge the advantages into cryptsetup/cryptdisks.

David Härdeman currently tries to reimplement cryptdisks (the
initscript) as a standalone wrapper for cryptsetup, written in c.
the idea is to implement a system similar to mount, with a /etc/crypttab
and similar syntax.

maybe we can join our efforts to develop a good implementation for
encrypted harddisks in debian :-)

greetings
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381973: keysize is limited

[Jonas Meurer]

reassign 381973 partman-crypto
bye

hello,

the reason for your luksOpen error is indeed an unsupported keysize. the
keysize must always be a multiple of 8 bits, and it is limited. see
output of /proc/crypto for limitations.

sha256 supports 256 bits, if you need a bigger key, use cipher sha384.

partman-crypto should limit the keysize for the sha256 cipher to 256.

i will add a note to the cryptsetup manpage.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#315693: need more information regarding [Cryptoloop filesystem incompatible between woody and sarge]

[Jonas Meurer]

hello,

can you give me more information about the bug?

which kernel do you run under woody when you create the encrypted
device? can you submit the output of 'uname -a'?

the same for sarge when it fails to setup/mount.

you said, that even in a woody chroot, started from a sarge system,
you're not able to access the encrypted device.
this leads to the fact that the running kernel is responsible for the
failture.

my assumption is, that the 'serpent' cipher from 2.4 kernels is
incompatible to the one from 2.6 kernels.

in this case, the bug would be related to the linux kernel, not to the
cryptsetup package.

in any case, you used losetup all the time, so crypto loop from the
kernel was used.
cryptsetup uses dm-crypt. it is compatible with crypto loop as long as
the same cipher is used, but so far i don't see where cryptsetup is used
to produce the bug.

the best would be, if you could give exact information about
- the woody system you used to create the crypto loop device
- the sarge system you used when mouunting the crypto loop device failed
- the exact commands you used.

i cannot even create the encrypted device in the way you did it:

# losetup -e serpent -k 128 /dev/loop0 /dev/vg00/test
Password: *password*
ioctl: LOOP_SET_STATUS: Invalid argument

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#315693: [Pkg-cryptsetup-devel] Bug#315693: need more information regarding [Cryptoloop filesystem incompatible between woody and sarge]

[Jonas Meurer]

On 20/08/2006 To [EMAIL PROTECTED] wrote:
> the best would be, if you could give exact information about
> - the woody system you used to create the crypto loop device
> - the sarge system you used when mouunting the crypto loop device failed
> - the exact commands you used.
> 
> i cannot even create the encrypted device in the way you did it:
> 
> # losetup -e serpent -k 128 /dev/loop0 /dev/vg00/test
> Password: *password*
> ioctl: LOOP_SET_STATUS: Invalid argument

ok, this was due to a stupid fault on my side. i missed to load the
'cryptoloop' module before running 'losetup -e serpent'.

but according to the commands you used, you didn't setup the loopback
device before mounting the encrypted device.

if you set up /dev/sda1 as /dev/loop0 once, you need to redo that before
mounting /dev/sda1.

/dev/sda1 will be the plain encrypted device - and only the loopback
device, set up exactly like the first time - is able to be mounted.

i.e.:

in woody:
# losetup -e serpent -k 128 /dev/loop0 /dev/sda1
# mkfs.ext2 /dev/loop0
[ fill /dev/loop0 with data ]

in sarge:
# losetup -e serpent -k 128 /dev/loop0 /dev/sda1
# mount -t ext2 /dev/loop0 /mnt/

this one for sure doesn't work:
# mount -t ext2 /dev/sda1 /mnt/

Dominik, please give us more information about how to reproduce the bug.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#384061: linux-source-2.6.17: 2.6.17-6 fails to compile on amd64

[Jonas Meurer]

Package: linux-source-2.6.17
Version: 2.6.17-6
Severity: important

hello,

linux-source-2.6.17 2.6.17-5 and 2.6.17-6 both break to compile when i
use make-kpkg from kernel-package 10.053:

$ make-kpkg --rootcmd fakeroot --initrd --append-to-version -4-amd64-resivo 
--revision 2.6.17-6 kernel_image
[...]
  AS  .tmp_kallsyms1.o
  LD  .tmp_vmlinux2
  KSYM.tmp_kallsyms2.S
  AS  .tmp_kallsyms2.o
  LD  vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  AS  arch/x86_64/boot/bootsect.o
  LD  arch/x86_64/boot/bootsect
  AS  arch/x86_64/boot/setup.o
  LD  arch/x86_64/boot/setup
  AS  arch/x86_64/boot/compressed/head.o
  CC  arch/x86_64/boot/compressed/misc.o
objdump: arch/x86_64/boot/compressed/.tmp_misc.o: File format is
ambiguous
objdump: Matching formats: elf32-i386 elf32-i386-freebsd
  OBJCOPY arch/x86_64/boot/compressed/vmlinux.bin
  GZIParch/x86_64/boot/compressed/vmlinux.bin.gz
  LD  arch/x86_64/boot/compressed/piggy.o
  LD  arch/x86_64/boot/compressed/vmlinux
  OBJCOPY arch/x86_64/boot/vmlinux.bin
objcopy: arch/x86_64/boot/compressed/vmlinux: File format is ambiguous
objcopy: Matching formats: elf32-i386 elf32-i386-freebsd
make[2]: *** [arch/x86_64/boot/vmlinux.bin] Error 1
make[1]: *** [bzImage] Error 2
make[1]: Leaving directory `/usr/src/linux-source-2.6.17'
make: *** [debian/stamp-build-kernel] Error 2

...
 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.17-3-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages linux-source-2.6.17 depends on:
ii  binutils  2.17-2 The GNU assembler, linker and bina
ii  bzip2 1.0.3-3high-quality block-sorting file co

Versions of packages linux-source-2.6.17 recommends:
ii  gcc  4:4.1.1-6   The GNU C compiler
ii  libc6-dev [libc-dev] 2.3.6.ds1-2 GNU C Library: Development Librari
ii  make 3.81-2  The GNU version of the "make" util

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#384478: xmms2-core: no manpage fore xmms2-launcher

[Jonas Meurer]

Package: xmms2-core
Version: 0.2DrFeelgood-3
Severity: normal


hello,

xmms2-core misses a manpage for xmms2-launcher. xmms2d(8) manpage
refers to xmms2-launcher(1) in the "SEE ALSO" section, so i believe that
a xmms2-launcher manpage exists.

maybe you simply missed to include it into the package.

...
 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.17-3-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages xmms2-core depends on:
ii  libc62.3.6.ds1-3 GNU C Library: Shared libraries
ii  libglib2.0-0 2.10.3-3The GLib library of C routines
ii  libsqlite3-0 3.3.7-1 SQLite 3 shared library
ii  xmms2-plugin-alsa0.2DrFeelgood-3 XMMS2 - ALSA output

xmms2-core recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#384640: tilda: Config options "Display on all workspaces" and "Do not show in taskbar" have no effect

[Jonas Meurer]

Package: tilda
Version: 0.09.2-1
Severity: important

hello,

when i tried tilda today, i recognized, that the two most interesting
options (for me) don't have any effect.

"Display on all workspaces" and "Do not show in taskbar" both don't
work.

Tilda always appears in the taskbar, regardless whether the option is
enabled or not, and it never appears on all workspaces, only on the one
where i started it.

I run icewm as window manager on a debian/unstable amd64 system.

...
 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.17-3-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages tilda depends on:
ii  libatk1.0-0  1.12.1-1The ATK accessibility toolkit
ii  libc62.3.6.ds1-3 GNU C Library: Shared libraries
ii  libcairo21.2.4-1 The Cairo 2D vector graphics libra
ii  libconfuse0  2.5-2   Library for parsing configuration 
ii  libfontconfig1   2.3.2-7 generic font configuration library
ii  libglib2.0-0 2.10.3-3The GLib library of C routines
ii  libgtk2.0-0  2.8.20-1The GTK+ graphical user interface 
ii  libncurses5  5.5-2   Shared libraries for terminal hand
ii  libpango1.0-01.12.3-2Layout and rendering of internatio
ii  libvte4  1:0.12.2-3  Terminal emulator widget for GTK+ 
ii  libx11-6 2:1.0.0-8   X11 client-side library
ii  libxcursor1  1.1.5.2-5   X cursor management library
ii  libxext6 1:1.0.0-4   X11 miscellaneous extension librar
ii  libxfixes3   1:3.0.1.2-4 X11 miscellaneous 'fixes' extensio
ii  libxft2  2.1.8.2-8   FreeType-based font drawing librar
ii  libxi6   1:1.0.0-5   X11 Input extension library
ii  libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library
ii  libxrandr2   2:1.1.0.2-4 X11 RandR extension library
ii  libxrender1  1:0.9.0.2-4 X Rendering Extension client libra

tilda recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379737: [Pkg-cryptsetup-devel] Bug#379737: cryptsetup: cannot handle UTF-8 in passphrase

[Jonas Meurer]

On 28/08/2006 Robert Bihlmeyer wrote:
> >>There is a caveat: if someone has a latin1 locale, sets a passphrase with
> >>non-ascii characters, and later changes to a utf8 locale, he is subsequently
> >>locked out of his data.
> >
> > Well, that goes for both cryptsetup during the initramfs stage and
> > during normal use of the system, so it's something that will have to
> > be addressed sooner or later by the user anyway.
> 
> Correct. But during normal use the user can set her console to
> non-UTF8. Cryptosetup could also use large translation tables
> (glibc's?) that may not be available in initramfs.
> 
> People that encrypted CDRs with latin1-passphrases will see this
> problem (during normal use) for some time.

as i understood, not if they still use latin1 locales.

> >>My other solution (normalising the passphrase to UTF-8 always) would have no
> >>such problems, but it's a rather big hammer -- we can't put big translation
> >>tables on initramfs I guess.
> >
> > Well, it wouldn't work simply because we can't know which encoding to
> > convert from (i.e. was the old input in iso8859-1, or in iso8859-15,
> > or something else).
> 
> The idea is to translate to UTF-8 on luksAddKey time. To be more
> concrete:
> 
> 1. Old passwords that are not UTF-8 are "lost" and need to be manually
>fixed. Should be documented.
> 2. Newly created keys always get their passphrases translated from
>whatever encoding is active (as per LANG and LC_*) to UTF-8.
> 3. initramfs always sets the terminal into UTF-8 mode, so new
>passwords will work without a hitch.
> 
> The feature from bullet 2 will probably need /usr/lib/gconv, but it
> is not needed for the version put onto initramfs. (That was my main
> fear, to bloat the initramfs by 5 megs or more.)

i don't support this request. it will break to much.

it's not that we should care for every corner case. if you want special
(localized) characters in your password, it's your job to check for
locale settings.

and from my understanding, your proposal still can break with different
keyboard layouts used for luksFormat and luksOpen. especially if the
charset has been changed, converted, whatsoever.

> For legacy compatibility (e.g. old CDRs) cryptsetup could take a
> --encoding=X parameter that translated from the current encoding
> (usually UTF-8) to X so that passphrases encoded in X are still
> usable.

it's not the job of cryptsetup to deal with encodings at all. i don't
know any commandline software that requires password prompt and that
deals with encodings.

it's the users job to configure his/her console properly.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#385328: webalizer: new german localizing file available

[Jonas Meurer]

Package: webalizer
Version: 2.01.10-30.1
Severity: minor
Tags: patch

hello,

at ftp://ftp.mrunix.net/pub/webalizer/lang/ you can find updated
language files for webalizer. i'm unable to appraise the other language
files, but at least the german one is a great improvement compared to
the one currently shipped with upstream webalizer 2.01.10.

according to the timestamps, most of the files are updates of the
upstream ones.

by the way, do you have contact to the upstream maintainers? to they
still actively develop webalizer?

i attached webalizer_lang.german.

...
 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.17-3-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages webalizer depends on:
ii  debconf [debconf-2.0]  1.5.3 Debian configuration management sy
ii  libc6  2.3.6.ds1-4   GNU C Library: Shared libraries
ii  libdb4.2   4.2.52+dfsg-1 Berkeley v4.2 Database Libraries [
ii  libgd2-xpm 2.0.33-5  GD Graphics Library version 2
ii  libgeoip1  1.3.17-1  A non-DNS IP-to-country resolver l
ii  libpng12-0 1.2.8rel-5.2  PNG library - runtime
ii  zlib1g 1:1.2.3-13compression library - runtime

webalizer recommends no packages.

-- debconf information:
* webalizer/logfile: /var/log/apache/access.log.1
* webalizer/doc_title: Usage Statistics for resivo
  webalizer/upgrading:
* webalizer/directory: /var/www/webalizer
* webalizer/upgrade2011030:
/*
   webalizer_lang.german

   Webalizer V2.0x language support file for German.
   28-May-1998 translated by Dirk Meyer <[EMAIL PROTECTED]>
   31-May-1998 portions by Bernd Dau <[EMAIL PROTECTED]>
   31-May-1998 modified for level 1.1 support <[EMAIL PROTECTED]>
   02-Jun-1998 translation level 1.1 by Dirk Meyer <[EMAIL PROTECTED]>
   30-Jun-1998 typing errors fixed by Dirk Kocherscheidt <[EMAIL PROTECTED]>
   23-Jul-1998 modified for level 1.2 support <[EMAIL PROTECTED]>
   01-Aug-1998 translation redone by SysWolf <[EMAIL PROTECTED]>
   09-Oct-1998 changes added by Soren Gust <[EMAIL PROTECTED]>
   09-Oct-1998 changes added by Martin Kraemer <[EMAIL PROTECTED]>
   24-Dec-1998 names of countries by Dirk Kocherscheidt <[EMAIL PROTECTED]>
   24-Dec-1998 grammar and spelling by Dirk Meyer <[EMAIL PROTECTED]>
   10-Jan-1999 improvements by Winfried Trümper <[EMAIL PROTECTED]>
   05-Mrz-1999 improvements by Winfried Trümper <[EMAIL PROTECTED]>
   06-Mrz-1999 new usage by Dirk Meyer <[EMAIL PROTECTED]>
   08-Mar-1999 Updated HTTP 1.1 response codes by Yves Lafon ([EMAIL PROTECTED])
   09-Mrz-1999 new result codes by Dirk Meyer <[EMAIL PROTECTED]>
   24-May-1999 fixed umlaut coding by Arne Blankerts <[EMAIL PROTECTED]>
   11-Jun-1999 clean-up by Wolfgang Schemmel <[EMAIL PROTECTED]>
   12-Jun-1999 remove english terms by Dirk Meyer <[EMAIL PROTECTED]>
   28-Jun-1999 Modified for level 1.3 support ([EMAIL PROTECTED])
   05-Jul-1999 Add. German translations by Gerald Erdmann ([EMAIL PROTECTED])
   28-Jul-1999 fixed umlaut coding by Dirk Meyer <[EMAIL PROTECTED]>
   04-Feb-2000 Minor fixes by Marcus Schommer <[EMAIL PROTECTED]>
   22-Feb-2000 Modified for level 2.0 support ([EMAIL PROTECTED])
   05-Feb-2000 level 2.0 by Dirk Meyer <[EMAIL PROTECTED]>
   16-Jun-2003 grammar and spelling by Dirk Randhahn <[EMAIL PROTECTED]>

   Language files are named using the following convention:

   webalizer_lang.LANGUAGE

   where 'LANGUAGE' is the name of the language the file is
   translated into (ie: webalizer_lang.russian for russian).
   Either copy the desired language file to webalizer_lang.h
   or create a symbolic link, then re-compile.

   If you translate this file into a different language, please
   send a copy to [EMAIL PROTECTED]

*/

/***/
/* DEFINE LANGUAGE NAME here   */
/***/

char *language  = "German";

/***/
/* */
/* Informational messages  */
/* */
/* These messages are only displayed while The Webalizer is being run, */
/* usually to the screen, and are not part of the HTML output. */
/* */
/***/

/* these are only used in timing totals */
/* Format:   XXX records (XXX ignored, XXX bad) in X.XX seconds*/
char *msg_records = "Einträge";
char *msg_addresses="Adressen";
char 

Bug#385317: [Pkg-cryptsetup-devel] Bug#385317: cryptsetup: cannot start encrypted swap with static key

[Jonas Meurer]

On 30/08/2006 Sam Couter wrote:
> Package: cryptsetup
> Version: 1.0.3-3
> 
> With the following line in /etc/crypttab:
> 
> cswap   /dev/mapper/rootvg-swap   /etc/keys/swap.key   swap
> 
> 
> The cryptdisks script fails to start the encrypted swap device:
> 
> laptop:/lib/cryptsetup/checks# /etc/init.d/cryptdisks start
> Starting remaining crypto disks... cswap(starting)
>  - The device /dev/mapper/cswap contains a filesystem type swap.
> 
>  - the check for '/dev/mapper/cswap' failed. /dev/mapper/cswap contains data.
>  - removing the crypto device cswap
> croot(running) done.

hello sam,

this is a known bug, already documented in bug #379771.

the upload of cryptsetup 1.0.4~rc2-1, fixing this bug as well as many
others is currently pending due to build issues.

...
 jonas


signature.asc
Description: Digital signature

Bug#256357: Processed: tagging 256357

[Jonas Meurer]

On 26/08/2006 Eduard Bloch wrote:
> Please tell me any good reason for adding this patch. AFAICS it does the
> same thing as aespipe does, but using the dm-crypt format. I wish the
> author would provide a separate tool for doing in-pipe encryption
> instead of patching external software. His reason "I had to use scripts"
> does not make sense looking at the example with the mkisofs pipe, nor
> "my scripts were not flexible enough". What does that mean, adding
> another command in the command chain is too complicated? 

the author lists advantages of a cdrecord command-line option at
http://burbon04.gmxhome.de/linux/CDREncryption.html#why

> And the code flow itself should be easy enough to convert it to a pipe
> filter tool. 
> 
> Something like aes-pipe (dm-crypt-pipe?) with the internals exchanged.
> 
> It would even beat the last reason "or simply were not flexible enough".
> With a pipe, you can choose which encoder you want to use.

i understand your objections, and i don't doubt that a in-pipe tool
would have other advantages over this implementation.

but arguing this way you could as well say that support for plugins or
modules in cdrecord would be even better.

unfortunately i've no skills to write a in-pipe tool.
Creating encrypted CDs/DVDs is currently quite complicated for
unexperienced users. You need to know about the loopback device and
cryptsetup.
that's why i thought that it would be great have this patch applied
against cdrtools/cdrkit in debian.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#386400: libssl0.9.8: services to restart: ssh (not openssh-server) and tor

[Jonas Meurer]

Package: libssl0.9.8
Version: 0.9.8b-3
Severity: normal

hello,

the init.d script of openssh-server is still called 'ssh', not
'openssh-server'.
currently, libssl0.9.8.postinst checks for 'openssh-server' and
therefore misses to restart ssh per default.

additionally, the postinst should also check for 'tor', which uses
libssl0.9.8 as well.

...
 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.17-3-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages libssl0.9.8 depends on:
ii  debconf [debconf-2.0]1.5.3   Debian configuration management sy
ii  libc62.3.6.ds1-4 GNU C Library: Shared libraries
ii  zlib1g   1:1.2.3-13  compression library - runtime

libssl0.9.8 recommends no packages.

-- debconf information:
* libssl0.9.8/restart-services: exim4 apache2 ssh tor 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381921: why is this bug still open?

[Jonas Meurer]

hello david,

do you still any objections against closing this bug?

i think that it should be closed for exactly the reason you gave in your
last posting.

and in any case it does not belong to cryptsetup.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#315693: [Pkg-cryptsetup-devel] Bug#315693: need more information regarding [Cryptoloop filesystem incompatible between woody and sarge]

[Jonas Meurer]

On 29/08/2006 Dominik Vogt wrote:
> > which kernel do you run under woody when you create the encrypted
> > device?
> 
> 2.6.11.11 under both, the Woody and the Sarge system.
> 
> > can you submit the output of 'uname -a'?
> 
> Unfortunately not since I don't have the woody system anymore.  In
> any case, I installed the Woody system from the latest CD release
> back then (3.0r4 I think).

i've problems with reproducing the situation. in a woody chroot with
bindmounted /dev and /proc, losetup doesn't ask for a password:

# losetup -e serpent -k 128 /dev/loop0 /dev/vg00/test
#

normally it should ask for a password here. maybe i will find time to
install a full woody system on an old harddrive later, but currently i'm
too busy to further investigate this bug.

...
 jonas


signature.asc
Description: Digital signature

Bug#388539: xserver-xorg-video-mga: FTBFS due to missing Build-Depends on quilt

[Jonas Meurer]

Package: xserver-xorg-video-mga
Version: 1:1.4.1.dfsg.1-3
Severity: normal

xserver-xorg-video-mga 1:1.4.1.dfsg.1-3 fails to build from source due
to missing Build-Depends on quilt.

...
 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.17-5-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages xserver-xorg-video-mga depends on:
ii  libc62.3.6.ds1-4 GNU C Library: Shared libraries
ii  xserver-xorg-core2:1.0.2-10  X.Org X server -- core server

xserver-xorg-video-mga recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#380155: ivtv: create seperate source packages for different major releases

[Jonas Meurer]

Package: ivtv
Severity: normal

hello,

it would be better to create a seperate source package for every major
ivtv release. this way different linux kernel versions could be
supported.

currently only one kernel version (2.6.16) is supported. if we had
ivtv0.6, ivtv0.7 and soon ivtv0.8 in debian, 2.6.16, 2.6.17 (and soon
2.6.18) would be supported.

i don't know the situation of the mythtv maintainer team, but if help is
needed i can help with maintaining ivtv.
i think that ivtvdev (the ivtv X driver) should be packaged for debian
as well.

...
 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.17-3-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#380174: ITP: xserver-xorq-video-ivtv -- X.Org X server -- IVTV display driver

[Jonas Meurer]

On 28/07/2006 Ian Campbell wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ian Campbell <[EMAIL PROTECTED]>
> 
> 
> * Package name: xserver-xorq-video-ivtv

i believe that you meant xserver-xorg-video-ivtv, not xorq ;-)

...
 jonas

>   Version : 0.10.6
>   Upstream Author : John Harvey <[EMAIL PROTECTED]>
> * URL : http://www.ivtvdriver.org/
> * License : To be determined.
>   Programming Lang: C
>   Description : X.Org X server -- IVTV display driver
> 
> This driver for the X.Org X server (see xserver-xorg for a further
> description) provides support for the video overlay on cards support by
> the IVTV driver (see the ivtv-source package). The IVTV driver supports
> card using chipsets frmo the iTVC15 family including the iTVC15 (CX24315)
> and iTVC16 (CX24316). These chips are commonly found on Hauppauge's WinTV
> PVR-250 and PVR-350 TV capture cards.
> 
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers unstable
>   APT policy: (900, 'unstable')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.17-1-686
> Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 
> (charmap=ISO-8859-15)
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379726: [Pkg-cryptsetup-devel] Bug#379726: cryptsetup: luksAddKey asks for unlock-passpharse twice

[Jonas Meurer]

On 27/07/2006 Robert Bihlmeyer wrote:
> reopen 379726
> thanks
> 
> (I find it rude if you close bugs you don't yet understand.)

first, sorry i simply missunderstood you.

now i got what you mean, and i prepared a patch to fix this. next upload
will include it.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#380155: [Pkg-mythtv-maintainers] Bug#380155: ivtv: create seperate source packages for different major releases

[Jonas Meurer]

severity 380155 wishlist
thanks

On 28/07/2006 Ian Campbell wrote:
> My intention has been/is to always have an ivtv which matches the latest
> packaged kernel in unstable and to allow it to propagate to testing at
> the same time as that kernel. The current glitch was because 0.6.x
> propagated to testing before kernel 2.6.16 did (I forgot the RC bug to
> stop it).
> 
> The current plan is to let 0.6.3-2 propagate to testing and then to
> upload 0.7.x. This upload will have an RC bug filed until 2.6.17 moves
> to testing. I'm away most of next week so I'd expect that to happen
> after that, which is roughly when the 10 day wait for 0.6.3-2 finishes
> anyway.
> 
> [...]
> 
> Around about the time of 2.6.19 (was .18, .17...) upstream expects the
> ivtv driver to be merged upstream which is why I didn't upload the
> multi-version packages -- it should soon become unnecessary. I admit I
> (and upstream) thought "soon" would be earlier than it turned out to be
> though ;-)

sorry for the long delay.

i just wanted to say that all this sounds reasonable.

feel free to close the bug or tag it as wontfix (this way it stays
visible to other users who may have the same concerns).

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#390321: zope3-sandbox: ImportError at upgrade

[Jonas Meurer]

Package: zope3-sandbox
Version: 3.3.0-1
Severity: important

hello,

at the upgrade from zope3-sandbox 3.2.1-5 to 3.3.0-1 on my
debian/unstable system, a python ImportError occured, though it didn't
make the upgrade fail.

I've disabled to start zope instances in /etc/default/zope3, if that may
be relevant.

here the exact copy+paste:

[...]
Preconfiguring packages ...
(Reading database ... 213651 files and directories currently installed.)
Preparing to replace zope3 3.2.1-5 (using .../zope3_3.3.0-1_amd64.deb) ...
* Zope3: instances have been disabled, edit /etc/default/zope3 to enable them.
Unpacking replacement zope3 ...
Preparing to replace python-zopeinterface 3.2.1-5 (using 
.../python-zopeinterface_3.3.0-1_amd64.deb) ...
Unpacking replacement python-zopeinterface ...
[ ... some other packages upgrading at the same time ... ]
Preparing to replace zope3-doc 3.2.1-5 (using .../zope3-doc_3.3.0-1_all.deb) ...
Unpacking replacement zope3-doc ...
Preparing to replace zope3-sandbox 3.2.1-5 (using 
.../zope3-sandbox_3.3.0-1_all.deb) ...
Traceback (most recent call last):
  File "/var/lib/zope3/instance/sandbox/bin/zopectl", line 43, in ?
run()
  File "/var/lib/zope3/instance/sandbox/bin/zopectl", line 37, in run
import zope.app.server.controller
ImportError: No module named zope.app.server.controller
Traceback (most recent call last):
  File "/var/lib/zope3/instance/sandbox/bin/zopectl", line 43, in ?
run()
  File "/var/lib/zope3/instance/sandbox/bin/zopectl", line 37, in run
import zope.app.server.controller
ImportError: No module named zope.app.server.controller
Unpacking replacement zope3-sandbox ...
Setting up python-zopeinterface (3.3.0-1) ...

Setting up zope3 (3.3.0-1) ...
* Zope3: instances have been disabled, edit /etc/default/zope3 to enable them.

[ ... again some other packages ... ]

Setting up zope3-doc (3.3.0-1) ...
Setting up zope3-sandbox (3.3.0-1) ...
Zope3 instance 'sandbox' already exists.

please give me advice if you need more information.

...
 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 zope3-sandbox depends on:
ii  debconf [debconf-2.0] 1.5.5  Debian configuration management sy
ii  zope-common   0.5.24 common settings and scripts for zo
ii  zope3 3.3.0-1Open Source Web Application Server

Versions of packages zope3-sandbox recommends:
ii  zope3-doc 3.3.0-1Documentation for Zope3

-- debconf information:
* zope3-sandbox/admin-automatic-password:
  zope3-sandbox/internal:
* zope3-sandbox/admin-user: admin
* zope3-sandbox/instance-http-port: 8031
* zope3-sandbox/keep-data-on-purge: true


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#390590: /etc/cups/cups-pdf.conf is updated for every new release

[Jonas Meurer]

Package: cups-pdf
Version: 2.4.2-1
Severity: normal

hello,

unfortunately, a version information in /etc/cups/cups-pdf.conf is
updated every new upstream release. i consider this as a bug as it
causes dpkg to ask for a configfile update even if no content changed.

if you have local changes in the configuration, this is very annoying.

maybe you can convince upstream to remove the release version from the
configuration file.

...
 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 cups-pdf depends on:
ii  cupsys   1.2.4-2 Common UNIX Printing System(tm) - 
ii  gs-esp   8.15.3.dfsg.1-1 The Ghostscript PostScript interpr
ii  libc62.3.6.ds1-5 GNU C Library: Shared libraries

cups-pdf recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#390590: /etc/cups/cups-pdf.conf is updated for every new release

[Jonas Meurer]

On 02/10/2006 Volker Christian Behr wrote:
> > unfortunately, a version information in /etc/cups/cups-pdf.conf is
> > updated every new upstream release. i consider this as a bug as it
> > causes dpkg to ask for a configfile update even if no content changed.
> > 
> > if you have local changes in the configuration, this is very annoying.
> > 
> > maybe you can convince upstream to remove the release version from the
> > configuration file.
> 
> Is there a way to make dpkg ignore this comment in the configuration
> file?

unfortunately not. the only solution i can think of now, is that the
debian package strips the version line from the config at build time.

> For some other installations/distributions I depend on the version
> number being part of the config file

could you explain in which situations a version number in the config is
required?

...
 jonas


-- 
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

[Jonas Meurer]

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#390590: /etc/cups/cups-pdf.conf is updated for every new release

[Jonas Meurer]

On 03/10/2006 Volker Christian Behr wrote:
> > > For some other installations/distributions I depend on the version
> > > number being part of the config file
> > 
> > could you explain in which situations a version number in the config is
> > required?
> 
> Anytime people do not use the pre-packaged versions (i.e. Debian
> packages, rpms and so on) but compile and install from the sources. They
> tend to forget to update the configuration along with binary. So I have
> to check each config-file they send to me by comparing with my sources
> whether it matches the version they are using and they cannot check it
> by themselves easily. This is - as I had to learn the hard way - a lot
> of extra work when debugging installation issues.

sounds reasonable.

i suggest that the debian maintainer (i guess you are upstrem) strips
the version line from the config file at build time. something like the
following should work in debian/rules:

sed -e '/^# *cups-pdf.conf -- CUPS Backend Configuration/s/ (version 
[0-9a-zA-Z.]*, [0-9-]*)//g' extra/cups-pdf.conf

you could even do the regex without limiting it to the first line:

sed -e 's/ (version [0-9a-zA-Z.]*, [0-9-]*)//g' extra/cups-pdf.conf

but the first one is better because it really only strips the first line
containing '# *cups-pdf.conf -- CUPS Backend Configuration'.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#390321: closed by Fabio Tranchitella <[EMAIL PROTECTED]> (Bug#390321: fixed in zope3 3.3.0-2)

[Jonas Meurer]

On 06/10/2006 Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #390321: zope3-sandbox: ImportError at upgrade,
> which was filed against the zope3-sandbox package.
> 
> It has been closed by Fabio Tranchitella <[EMAIL PROTECTED]>.
> 
> [...]
>
> Closes: 390321
> Changes: 
>  zope3 (3.3.0-2) unstable; urgency=medium
>  .
>* debian/patches/zope.app.twisted-bbb: added a backward compatible
>  package to allow old zope3 instances to be started with zope3 3.3.0.
>  (Closes: #390321)
>* debian/zopeZVER.NEWS.Debian: added a brief description of this
>  problem.
>* Single patch change, urgency to medium to easy the transition
>  to testing.

unfortunately not the full python error went away:

The following packages will be upgraded:
  python-zopeinterface zope3 zope3-doc zope3-sandbox
4 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
3 not fully installed or removed.
[...]
Preparing to replace zope3-sandbox 3.3.0-2 (using 
.../zope3-sandbox_3.3.0-3_all.deb) ...
Traceback (most recent call last):
  File "/var/lib/zope3/instance/sandbox/bin/zopectl", line 43, in ?
run()
  File "/var/lib/zope3/instance/sandbox/bin/zopectl", line 37, in run
import zope.app.server.controller
ImportError: No module named zope.app.server.controller
Unpacking replacement zope3-sandbox ...
[...]
Setting up zope3-sandbox (3.3.0-3) ...
Zope3 instance 'sandbox' already exists.


it seems like the error occurs before unpacking, maybe the preinst
script is the problem.

...
 jonas


signature.asc
Description: Digital signature

Bug#424135: does not resume from uswsusp suspend-to-disk image on encrypted swap partition

[Jonas Meurer]

On 07/06/2007 Marcus Better wrote:
> I have seen the same effect several times. My system has encrypted root and 
> swap, and I use uswsusp (without its encryption).
> 
> I never found a way to reproduce it, and I think the problem went away after 
> some upgrades (I upgraded the kernel many times since then, am now on 
> 2.6.22-rc3).

Hey Zack,

How are your experiences? Did you try a newer kernel yet? If not, could
you do so and report whether this fixes the bug for you?

thanks,
 jonas


signature.asc
Description: Digital signature

Bug#428725: [Pkg-cryptsetup-devel] Bug#428725: initramfs-tools: please provide hook to initialize LVM before mounting crypto-root

[Jonas Meurer]

On 16/06/2007 Marc Haber wrote:
> On Sat, Jun 16, 2007 at 10:22:07AM +0200, maximilian attems wrote:
> > On Sat, 16 Jun 2007, Marc Haber wrote:
> > > > hmmm i certainly know that cryptoroot works with initramfs-tools.
> > > 
> > > It works with the way that d-i uses, with an encrypted PV. My setup
> > > uses an encrypted LV.
> > 
> > afaik you can set up an encrypted partition on top of an lvm2 LV in d-i.
> > 
> > as this has been tested i still assume a bug in your setup.
> 
> What do you want to know about my setup to find out?

David Härdeman mentioned, that you need to use /dev/mapper/vg0-c_root
instead of /dev/vg0/c_root in /etc/crypttab.

I guess that this is the real bug in your configuration.

David wrote further on:

> Then regenerate the initramfs and it should work automagically. The
> /dev/VG/LV nodes are not supported by initramfs-tools and they won't be
> either (this is bug #378332 which is WONTFIX and I agree with Maks on
> that one).

greetings,
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#429928: [Pkg-cryptsetup-devel] Bug#429928: cryptsetup: can't boot with kernel 2.6.21

[Jonas Meurer]

On 21/06/2007 Dmitry Borodaenko wrote:
> Package: cryptsetup
> Version: 2:1.0.4+svn29-1
> Severity: important
> 
> When booting latest Linux kernel 2.6.21 from unstable
> (linux-image-2.6.21-1-686 2.6.21-4), device mapper reports "Error
> allocating crypto tfm" (see screen photo at boot time[0]) and returns to
> the step of asking for password.
> 
> [EMAIL PROTECTED]:~$ cat /etc/crypttab 
> #
> root/dev/sda5   nonecipher=aes-cbc-essiv:sha256
> #swap   /dev/sda6   /dev/urandomswap

This most likely means that the required crypto kernel modules were not
loaded by the initramfs.

For aes-cbc-essiv:sha256, you need the kernel modules dm-mod, dm-crypt,
aes, cbc, sha256 and blkcipher.

If you use initramfs-tools, add all these to /etc/initramfs-tools/modules
and regenerate the initramfs afterwards.

Maybe some of these modules where compiled into the 2.6.18 kernel while
the 2.6.21 kernel has compiled them as modules.

...
 jonas

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#422993: davfs2: fails to install

[Jonas Meurer]

retitle 422993 "fails to install: subprocess post-installation script returned 
error exit status 30"
severity 422993 important
thanks

Package: davfs2
Version: 1.2.1-1
Followup-For: Bug #422993

i raised severity of this bug to important, as this renders the package
uninstallable. i also fixed the subject.

greetings,
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#409814: [Python-modules-team] Bug#409814: python-mysqldb: Adding 2.5 support

[Jonas Meurer]

On 01/05/2007 Bernd Zeimetz wrote:
> > This module compiles fine with 2.5.  I modified
> > /usr/share/python/debian_defaults and added python2.5 to the list of
> > supported versions, and removed it from teh list of unsupported
> > versions, and then re-made python-mysqldb.
> 
> this is not the way to update packages unfortunately. The real solution
> would be to file a bug against python-minimal and ask for support of
> python2.5 (which will result in pycentral installing the modules for
> 2.5, too) or the other way would be to use python-support for this
> package, as python-support is able to handle other versions than the
> default version just fine (except for a few rare cases).

unfortunately even this doesn't work. if you build the package in a
clean environment without python2.5(-dev) installed, the c extensions
are not built for python2.5.

the only clean fix is to wait for python-all-dev to be updated or
build-depend on python2.5-dev.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#421693: [Pkg-cryptsetup-devel] Bug#421693: timeout option does not work with keyscript/key-file

[Jonas Meurer]

On 01/05/2007 Alexander Zangerl wrote:
> Package: cryptsetup
> Version: 2:1.0.4+svn26-2
> Severity: normal
> 
> The timeout option has no effect if keyscript/key-file are used,
> because line 252 in lib/setup.c directly uses read() on the file 
> descriptor. 
> 
> There is a timed_read() function which is used for 
> interactive passphrase entry, and it seems to me that it's feasible
> to use that instead of a direct read.

i'm not sure why this could be needed. upstream cryptsetup knows only
keyfiles and passphrases, keyscripts are a feature of the cryptdisks
wrapper in the debian package.

so from upstream point of view there might be no need to support a
timeout in conjunction with keyfiles.

if you use keyscripts, why don't you simply add timeout support to the
script itself?

greetings
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#405143: what's up with brasero?

[Jonas Meurer]

hey Ondrej,

In the meantime, brasero 0.5.2 has been released, and we still have
0.4.4 in debian. are you busy with other tasks, or do you plan to do
a brasero upload in the next time anyway?

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#429928: cryptsetup: can't boot with kernel 2.6.21

[Jonas Meurer]

severity 429928 minor
thanks

On 22/06/2007 Dmitry Borodaenko wrote:
> >Maybe some of these modules where compiled into the 2.6.18 kernel while
> >the 2.6.21 kernel has compiled them as modules.
> 
> You are right, cbc and blkcipher were missing. After adding these to
> /etc/yaird/Default.cfg, the kernel now boots, although it still
> complains about missing gzip binary (doesn't do any harm, any idea why
> it needs it?).
> 
> Guess this bug can now be upgraded to normal or even minor, but it
> would still be nice to update documentation about this issue,
> README.initramfs seems like the right place. Or should this bug be
> reassigned to yaird to make sure that it automatically detects this
> situation?

Hey Dmitry,

I just downgraded the severity to minor, but I guess that you're right
with the assumption that yaird should automatically add these modules
when they're needed for an encrypted root fs.

I'm not sure how initramfs-tools behaves though, so I'll wait for a
comment from David who knows much more about ramdisk stuff.

David, can we expect that yaird handles this case automatically? Then I
would reassign the bug to yaird. Otherwise we should at least document
it somewhere, as Dmitry suggested.

...
 jonas

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393689: ivtv-source: Please package 0.8.0 for linux-source-2.6.18

[Jonas Meurer]

Package: ivtv-source
Version: 0.7.1-1
Severity: important

hello,

please package ivtv 0.8.0 to support linux-source-2.6.18

...
 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 ivtv-source depends on:
ii  bzip2 1.0.3-6high-quality block-sorting file co
ii  debhelper 5.0.40 helper programs for debian/rules
ii  dpatch2.0.20 patch maintenance system for Debia
ii  module-assistant  0.10.7 tool to make module package creati

ivtv-source recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393473: [Pkg-cryptsetup-devel] Bug#393473: Misses dependency on dosfstools

[Jonas Meurer]

(sorry missed to send it to the bug report the first time)

On 17/10/2006 Loïc Minier wrote:
>  At least luksformat is used by users. :)
> 
> > On the other hand i don't know why the default fstype in luksformat is
> > vfat. Martin, you're the author of luksformat, what was your intension
> > when you set the default fstype to vfat?
> 
>  I think the default makes sense, I found this rationale in the man page:
>The default file system is vfat since that is most commonly used on
>removable devices. However, you can specify any available file system
>with the -t option.

i agree. the next upload of cryptsetup will suggest dosfstools.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393473: [Pkg-cryptsetup-devel] Bug#393473: Misses dependency on dosfstools

[Jonas Meurer]

On 16/10/2006 Loïc Minier wrote:
> Package: cryptsetup
> Version: 2:1.0.4~rc2-1
> Severity: minor
> 
> Hi,
> 
>  luksformat /dev/somedevice barked:
> Error: invalid file system: vfat
> 
>  You might want to add some form of dependency on dosfstools since the
>  default fstype is vfat, even if it's only a Suggests.

Hey Loïc,

I'm not sure about how do deal with this bug.

luksformat is not used by any other software in debian yet, and i don't
know whether it really justifies a Suggests for dosfstools.

On the other hand i don't know why the default fstype in luksformat is
vfat. Martin, you're the author of luksformat, what was your intension
when you set the default fstype to vfat?

I would suggest to either change the default fstype to ext2 or to add
some checks to luksformat which tell the user that the debian package
'dosfstools' is missing.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#394134: [Pkg-cryptsetup-devel] Bug#394134: cryptsetup: does not open luks partitions with filekeys during boot

[Jonas Meurer]

On 19/10/2006 Evgeni Golov wrote:
> Since the last upgrade, the init-scripts do not open a luks crypted
> partition with a key in a file properly.
> cryptsetup ... luksOpen works.
> It seems to me, that 'check_key || continue' does not work as it
> should in do_start of /lic/cryptsetup/cryptdisk.functions. If I comment
> this line out, the partition gets opened. When the line isn't
> commented, I get 'insecure mode' and do_luks isn't run.

hello,

could you elaborate on this? what is the exact line in /etc/crontab, and
what is the exact output by '/etc/init.d/cryptsetup start'?

also, how are permissions of the keyfile?

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#390590: closed by Martin-Éric Racine <[EMAIL PROTECTED]> (Re: #390590)

[Jonas Meurer]

reopen 390590
thanks

On 20/10/2006 Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #390590: cups-pdf: /etc/cups/cups-pdf.conf is updated for every new release,
> which was filed against the cups-pdf package.
> 
> It has been closed by Martin-Éric Racine <[EMAIL PROTECTED]>.

sorry, but i still believe that this is a bug. if you refuse to fix it,
tag it as wontfix, but don't close it silently. this is rude behaviour.

i understand your point of view, but still my one exists too. and i
still believe that the version number in the config file is pointless in
the debian package.

i reopened the bugreport.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#390590: cups-pdf: explanation already given and case closed

[Jonas Meurer]

On 20/10/2006 Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #390590: cups-pdf: /etc/cups/cups-pdf.conf is updated for every new release,
> which was filed against the cups-pdf package.
> 
> It has been closed by Martin-Éric Racine <[EMAIL PROTECTED]>.

On 20/10/2006 Martin-rc Racine wrote:
> Sorry, both upstream and myself clearly explained why the version
> string is needed and also why what you report does not constitute a
> bug. I also iterated our point once more before closing. There's no
> point in leaving this issue open given how it's not a bug. Closing.


Why do you think that a function on the one hand cannot be a bug on the
other hand?

I understand why upstream puts the version number in the config file,
even more i find it quite reasonable.

But still i regard it as a bug that dpkg asks me for manual interaction
everytime i update cups-pdf just because my cups-pdf configuration
differs from the upstream one.
The configfile handling in dpkg is intended to help you if upstream
changed the configuration and you have local modifications.

And i still don't understand why the version number is needed in the
debian package of cups-pdf. Debian bugreports usually include the
package version anyway.

I feel inclined to reopen the bug report, but i don't see why we should
start a open <-> close war here.
If you refuse to accept my fix to strip the version line from the config
at build time, then the tag wontfix is appropriate.
But don't simply close bugs just because you believe they are no bugs.

I look forward to see you reopening the bug.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#394134: [Pkg-cryptsetup-devel] Bug#394134: cryptsetup: does not open luks partitions with filekeys during boot

[Jonas Meurer]

On 20/10/2006 Evgeni Golov wrote:
> > could you elaborate on this? what is the exact line in /etc/crontab,
> crypttab you mean ;-) ^^^

hehe, you're correct ;-)

> # 
> home/dev/sda6   /media/usbstick/keyfile-shinkupaddo.luks luks
> 
> > and what is the exact output by '/etc/init.d/cryptsetup start'?
> 
> # /etc/init.d/cryptdisks start
> Starting remaining crypto disks...STICK!
>  home(starting)
>  - INSECURE MODE FOR /media/usbstick/keyfile-shinkupaddo.luks
> done.

where does this "STICK!" come from?

which version of cryptsetup did you use before? i believe that this was
1.0.4~rc2-1 because 1.0.4-1 introduced 'set -e' for the initscript.

> > also, how are permissions of the keyfile?
> 
> the keyfile is on a vfat usb-stick, permissions are:
> # ls -alh /media/usbstick/keyfile-shinkupaddo.luks
> -rwxr-xr-x 1 root root 256 2006-08-28
> 09:08 /media/usbstick/keyfile-shinkupaddo.luks
> 
> Because of this I get the insecure more message (as I did in prior
> versions too, but there the luks partotion was open after that)
> As I understand, the behavior should be "give warning, but
> continue" (check_key || continue) - am I right?

no, 'check_key || continue' actually says 'continue with the next device
if check_key fails.
i wonder whether this was different in the past.

anyway it's not unusual to keep the key on a vfat usb-stick, so
cryptsetup should be able to cope with this situation.

maybe the permission check should include a check for filesystems
which do not support file permissions, and go on with a warning in these
cases.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#394999: New upstream, please reconfirm bug

[Jonas Meurer]

Hello Ulrich,

Would you mind giving the new python-mysqldb 1.2.2-1 packages a try?

You can find amd64+i386 packages at
http://people.debian.org/~mejo/python-mysqldb/

Please give me a short note whether these packages fix bug #394999 for
you or not.

greetings,
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#418779: Securing-Debian-HOWTO: Removing system users/groups in maintainer scripts

[Jonas Meurer]

Package: harden-doc
Version: 3.11
Severity: normal

Hello Javier,

According to your Securing-Debian-HOWTO, one should add lots of code to
the postrm maintainer script, in case that a system user/group needs to
be removed.

At http://www.debian.org/doc/manuals/securing-debian-howto/ch9#s-bpp-lower-privs
you explain how to check in the postrm, whether the to-be-removed
account is really a system account.

Why don't you simply suggest to use 'deluser/delgroup --system' from the
adduser package? One reason why adduser has been developed, was to help
package maintainers to deal with system accounts.

One problem for sure is, that adduser doesn't have priority essential,
but on the other side passwd, where userdel/groupdel lives, doesn't have
that either.

I suggest to update the HOWTO to use the adduser tools instead of your
code in maintainer scripts. Your code might do the same, but in case
that a bug is found, every single maintainer script that uses this code
needs to be updated. That is a strong argument for tools like adduser.

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.18-12-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#419045: typo in doc-base.prerm

[Jonas Meurer]

Package: doc-base
Version: 0.8.2
Severity: important

Hello,

It seems like you introduced a typo in doc-base.prerm, line 18:

14: remove_docs ( ) {
15:   if which install-docs >/dev/null 2>&1; then
16: install-docs ${VERBOSE} --no-update-menus -r $package || true
17: install-docs ${VERBOSE} -r install-docs-man || true
18:   lse
19: echo "cannot find install-docs on path" 1>&2
20:   fi
21: }

This leads to a warning during the upgrade:

Preparing to replace doc-base 0.8.1 (using .../doc-base_0.8.2_all.deb) ...
/var/lib/dpkg/info/doc-base.prerm: line 18: lse: command not found
dpkg: warning - old pre-removal script returned error exit status 127
dpkg - trying script from the new package instead ...
dpkg: ... it looks like that went OK.
Unpacking replacement doc-base ...


This message by dpkg leads to the assumption that the new postrm script
from 0.8.2 has this bug fixed, but unfortunately this is not the case.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#394999: [Python-modules-team] Bug#394999: python-mysqldb: Str2Set conversion broken

[Jonas Meurer]

On 24/10/2006 Ulrich P. Klein wrote:
> /usr/share/pycentral/python-mysqldb/site-packages/MySQLdb/converters.py,
> line 46:
> return apply(str, tuple(values))
> 
> should be:
> return map(str, tuple(values))

Hello Ulrich,

Could you try the packages at
http://people.debian.org/~mejo/python-mysqldb/?

The debian package patches the Str2Set function:

--- python-mysqldb-1.2.1-p2/MySQLdb/converters.py
+++ python-mysqldb-1.2.1-p2/MySQLdb/converters.py
@@ -42,7 +42,8 @@
 def Bool2Str(s, d): return str(int(s))

 def Str2Set(s):
-return Set([ i for i in s.split(',') if i ])
+values = s.split(',')
+return apply(str, tuple(values))

 def Set2Str(s, d):
 return string_literal(','.join(s), d)

The packages at http://people.debian.org/~mejo/python-mysqldb/ don't
have this patch applied.

I'm happy to use your patch, but i'm just interested whether the
original upstream fails for you too.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#396951: brasero: --data does not work

[Jonas Meurer]

Package: brasero
Version: 0.4.4-4
Severity: normal

Hello,

according to 'brasero --help', brasero offers several command-line
options. -a starts it directly in audio cd mode, -d in data cd mode.

unfortunately -d (or --data) opens brasero in audio cd mode, other 
than documented in 'brasero --help'.

-a (--audio) and -c (--copy) work, only -d (--data) doesn't.

...
 jonas

-- System Information:
Debian Release: 4.0
  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-5-amd64-resivo-vserver
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages brasero depends on:
ii  libart-2.0-2  2.3.17-1   Library of functions for 2D graphi
ii  libatk1.0-0   1.12.3-1   The ATK accessibility toolkit
ii  libaudiofile0 0.2.6-6Open-source version of SGI's audio
ii  libavahi-client3  0.6.14-2   Avahi client library
ii  libavahi-common3  0.6.14-2   Avahi common library
ii  libavahi-glib10.6.14-2   Avahi glib integration library
ii  libbonobo2-0  2.14.0-2   Bonobo CORBA interfaces library
ii  libbonoboui2-02.14.0-5   The Bonobo UI library
ii  libc6 2.3.6.ds1-7GNU C Library: Shared libraries
ii  libcairo2 1.2.4-4The Cairo 2D vector graphics libra
ii  libdbus-1-3   0.94-1 simple interprocess messaging syst
ii  libdbus-glib-1-2  0.71-2 simple interprocess messaging syst
ii  libesd-alsa0 [libesd0]0.2.36-3   Enlightened Sound Daemon (ALSA) - 
ii  libfontconfig12.4.1-2generic font configuration library
ii  libfreetype6  2.2.1-5FreeType 2 font engine, shared lib
ii  libgconf2-4   2.16.0-2   GNOME configuration database syste
ii  libgcrypt11   1.2.3-2LGPL Crypto library - runtime libr
ii  libglib2.0-0  2.12.4-1   The GLib library of C routines
ii  libgnome-keyring0 0.6.0-2GNOME keyring services library
ii  libgnome2-0   2.16.0-2   The GNOME 2 library - runtime file
ii  libgnomecanvas2-0 2.14.0-2   A powerful object-oriented display
ii  libgnomeui-0  2.14.1-2+b1The GNOME 2 libraries (User Interf
ii  libgnomevfs2-02.14.2-2+b1GNOME virtual file-system (runtime
ii  libgnutls13   1.4.4-2the GNU TLS library - runtime libr
ii  libgpg-error0 1.4-1  library for common error values an
ii  libgstreamer-plugins-base 0.10.10-1  GStreamer libraries from the "base
ii  libgstreamer0.10-00.10.10-2  Core GStreamer libraries and eleme
ii  libgtk2.0-0   2.8.20-3   The GTK+ graphical user interface 
ii  libice6   1:1.0.1-2  X11 Inter-Client Exchange library
ii  libjpeg62 6b-13  The Independent JPEG Group's JPEG 
ii  libnautilus-burn3 2.14.3-2   Nautilus Burn Library - runtime ve
ii  libnotify10.4.2-1+b1 sends desktop notifications to a n
ii  liborbit2 1:2.14.3-0.1   libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0 1.14.7-1   Layout and rendering of internatio
ii  libpng12-01.2.8rel-7 PNG library - runtime
ii  libpopt0  1.10-3 lib for parsing cmdline parameters
ii  libsm61:1.0.1-3  X11 Session Management library
ii  libtasn1-30.3.6-2Manage ASN.1 structures (runtime)
ii  libtotem-plparser12.16.2-2   Totem Playlist Parser library - ru
ii  libx11-6  2:1.0.3-2  X11 client-side library
ii  libxcursor1   1.1.7-4X cursor management library
ii  libxext6  1:1.0.1-2  X11 miscellaneous extension librar
ii  libxfixes31:4.0.1-4  X11 miscellaneous 'fixes' extensio
ii  libxi61:1.0.1-3  X11 Input extension library
ii  libxinerama1  1:1.0.1-4.1X11 Xinerama extension library
ii  libxml2   2.6.27.dfsg-1  GNOME XML library
ii  libxrandr22:1.1.0.2-4X11 RandR extension library
ii  libxrender1   1:0.9.1-3  X Rendering Extension client libra
ii  mkisofs   5:1.0~pre4-1.1 Creates ISO-9660 CD-ROM filesystem
ii  wodim 5:1.0~pre4-1.1 command line CD writing tool
ii  zlib1g1:1.2.3-13 compression library - runtime

brasero recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#397012: idesk segfaults

[Jonas Meurer]

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  to continue, or q  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

[Jonas Meurer]

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  to continue, or q  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+, 
std::allocator > ()
#13 0x00430444 in std::operator+, 
std::allocator > ()
#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#411784: cryptsetup: Swap identified as minix filesystem

[Jonas Meurer]

Hello Fredrik,

On 28 Feb 2007, David Härdeman wrote:
> On Tue, February 20, 2007 23:36, Fredrik Olofsson said:
> after a few reboots this partition is identified as a minix
> filesystem, and cryptsetup refuses to start it.
>
> What does "/lib/udev/vol_id /dev/sda6" identify the partition as?

Can you give further information about this bug? please give the output
of "/lib/udev/vol_id /dev/sda6". Are you still able to reproduce the
bug?

...
 jonas

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#430158: uswsusp and cryptoswap

[Jonas Meurer]

Hello Helmut,

Did I get you right, that you're searching for some way to turn of the
limit of three tries at the password prompt for encrypted devices?

If this is all that you're searching for, simply use --tries=0 at
commandline or the option tries=0 in /etc/crypttab.

...
 jonas

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#423102: cryptsetup: sorts crypttab before processing it

[Jonas Meurer]

On 15 May 2007, Joerg Jaspert wrote:
> > Could you add some debugging output to do_start to try to see what is
> > going on?
> 
> I try doing that soon, its a bit of a problem as that needs turning off
> nearly everything on the machine.

Hello Joerg,

You promised to do some more debugging regarding this bug. Did you
already make any efforts?

I still don't understand how to reproduce the bug. My understanding of
cryptdisks initscript code is that it processes /etc/crypttab line for
line, from the head to the tail. There is no code to sort or randomly
mix the lines.

If you're not able to reproduce the bug any more, then I'm pretty sure
that it was a problem at your installation, not in the debian package.

...
 jonas

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#437106: mentions /usr/doc/ncompress/README.Debian in package description

[Jonas Meurer]

Package: ncompress
Version: 4.2.4.0-2
Severity: wishlist

Hello,

ncompress reffers to /usr/doc/ncompress/README.Debian in its package
description. This should be changed to
/usr/share/doc/ncompress/README.Debian, as documentation has been moved
from /usr/doc to /usr/share/doc for ages.

...
 jonas

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#411784: cryptsetup: Swap identified as minix filesystem

[Jonas Meurer]

On 12/08/2007 Fredrik Olofsson wrote:
> On Friday, August 10, 2007 at 16:54:19 +0200, Jonas Meurer wrote:
> > Can you give further information about this bug? please give the output
> > of "/lib/udev/vol_id /dev/sda6". Are you still able to reproduce the
> > bug?
> 
> I won't have access to this system until next week. Then I will try to
> reproduce the bug and get the output. (David's previous bug reply must
> have been caught in a spam filter, sorry)

Hey Fredrik,

Do you have any news for us?

greetings,
 jonas

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438473: [Pkg-cryptsetup-devel] Bug#438473: cryptsetup: Adding support for openct and usplash fixes

[Jonas Meurer]

On 17/08/2007 Daniel Baumann wrote:
> here is a patch to add openct support to cryptsetup 1.0.5-1.
> 
> Additionally, this patch contains a fix for decrypt_opensc to make it
> use with usplash.
> 
> It would be very nice if you can apply it. I did put some comments to
> the scripts, however, if you have questions about it, don't hesitate to ask.

Hello Daniel,

Could you provide a README.openct with some information about how to
setup cryptsetup with openct?

I don't like the idea to add yet another decryption script without
providing documentation. Also I would like to give it a try first.

greetings,
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#441275: ivtv-source: ivtv-fb and the X driver ivtvdev don't work any more

[Jonas Meurer]

Package: ivtv-source
Version: 1.0.2-2
Severity: important

Hey, since I upgraded my kernel to 2.6.22, my Xserver doesn't start on
TVout anymore.

I don't know whether this is a bug in ivtv-fb or in the Xserver driver
ivtvdev (I'm using 0.10.6-1). Loading the module ivtv-fb with modprobe
works without problems, and in dmesg i see:

ivtv0-fb: Framebuffer at 0xc951, mapped to 0xc2000121, size 1665k
ivtv0-fb: === Validated display mode  ===
ivtv0-fb: Display size 640x480 (640x480 Virtual) @ 8bpp
ivtv0-fb: Display position 41,49
ivtv0-fb: Display filter : on
ivtv0-fb: Color space : RGB
ivtv0-fb: === Display mode change ===
ivtv0-fb: Display size 640x480 (640x480 Virtual) @ 8bpp
ivtv0-fb: Display position 41,49
ivtv0-fb: Display filter : on
ivtv0-fb: Color space : RGB
ivtv0-fb: Framebuffer registered on ivtv card id 0

But when starting the Xserver (with exactly the same version and config
as with kernel 2.6.21 - where it worked), Xorg.0.log gives:

[...]
(II) LoadModule: "ivtvdev"
(II) Loading /usr/lib/xorg/modules/drivers//ivtvdev_drv.so
(II) Module ivtv: vendor="X.Org Foundation"
compiled for 7.1.1, module version = 0.10.6
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 1.0
[...]
(--) Chipset PVR-350 found
(EE) NVIDIA(0): ivtvHWProvbe failed to do IVTVFB_IOCTL_GET_STATE for device 
/dev/fb1
(EE) Screen 1 deleted because of no matching config section.
(II) UnloadModule: "ivtvdev"
[...]

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-3-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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#441275: [Pkg-mythtv-maintainers] Bug#441275: ivtv-source: ivtv-fb and the X driver ivtvdev don't work any more

[Jonas Meurer]

reassign 441275 xserver-xorg-video-ivtv 0.10.6-1
thanks

On 08/09/2007 Ian Campbell wrote:
> > Hey, since I upgraded my kernel to 2.6.22, my Xserver doesn't start on
> > TVout anymore.
> > 
> > I don't know whether this is a bug in ivtv-fb or in the Xserver driver
> > ivtvdev (I'm using 0.10.6-1).
> 
> I have a sneaking suspicion you might need a newer Xserver driver. I've
> put some work-in-progress packages of the newer version 1.0.0~svn4027-1
> at  could you give them a go?

You're correct. Thanks a lot. The new packages of ivtvdev fix this
problem.

This email should reassign the bug from ivtv-source to
xserver-xorg-video-ivtv.

> A quick heads-up: if you use mythtv in the PVR-350 hardware decode mode
> (as opposed to just using the fb output and software decode) then you
> will probably find it won't work since the API used for hardware decode
> in the driver which is part of 2.6.22 is different to the one used in
> the old out of tree drivers and myth hasn't yet been updated.

Thanks for the warning, but I don't use mythtv at all. Normally I use only
the TVout to run a second Xserver there (and redirect videos to my 
television).

greetings,
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#441275: [Pkg-mythtv-maintainers] Bug#441275: ivtv-source: ivtv-fb and the X driver ivtvdev don't work any more

[Jonas Meurer]

On 09/09/2007 Ian Campbell wrote:
> > > I have a sneaking suspicion you might need a newer Xserver driver. I've
> > > put some work-in-progress packages of the newer version 1.0.0~svn4027-1
> > > at  could you give them a go?
> > 
> > You're correct. Thanks a lot. The new packages of ivtvdev fix this
> > problem.
> 
> Thanks, looks like I need finalise this new version and get it uploaded
> ASAP.

That would be great. But don't forget to warn about the driver rename
from ivtvdev to ivtv.

greetings,
 jonas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#441428: [Pkg-cryptsetup-devel] Bug#441428: initramfs-tools 0.91 features

[Jonas Meurer]

On 09/09/2007 maximilian attems wrote:
> hello,
> 
> please when applying belows patches bump dep to >= 0.91.

Thanks, will be included in the next upload.

...
 jonas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#411784: [Pkg-cryptsetup-devel] Bug#411784: Bug#411784: ext2 fs identified as mimix fs

[Jonas Meurer]

On 10/09/2007 David Härdeman wrote:
> >> I have the same problem; not on my swap partition, but on my home
> >> partition (ext3).
> >>
> > Is it possible, as crypted partitions are random, that they sometimes look
> > like valid partitions, and therefore /lib/cryptsetup/checks/un_vol_id
> > reports erroneous result ?
> 
> Yes
> 
> > But why do random data look more like minix than any other filesystem ?
> 
> Because Minix has a very short signature located in an unfortunate
> location (one that changes frequently on disk).
> 
> We will perhaps have to filter minix in un_vol_id since it seems more
> likely that someone would have a misdetected fs rather than having a real
> minix fs.

I just added some code to vol_id and un_vol_id which filters out minix
filesystem detection as you suggested, David.

David: Could you take a look at debian/NEWS? Maybe you find better words
to describe the change.

...
 jonas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#406986: New upstream available

[Jonas Meurer]

severity 406986 important
thanks

Hello,

In the meantime, b2evolution 2.0 alpha has been released, and latest
stable release is 1.10.2.

The package in debian still uses upstream 0.9.2, which was released in
May 2005 and is depreciated since a long time.

I raised the severity of this bug to 'important', as the newer upstream
versions fix many many security bugs and add new features.

...
 jonas



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432150: [Pkg-cryptsetup-devel] Bug#432150: /sbin/cryptsetup: repair tools needed

[Jonas Meurer]

On 07/07/2007 [EMAIL PROTECTED] wrote:
> dm-crypt has data corruption issues, and this includes the luks
> header.  a tool to repair the luks header so that you can run fsck on
> the fs would be useful.  it might be that most of the data are ok.
> 
> this could take the form of an fsck-like repair, or a similar
> partition's header to repair the header, or a luksRestore from a
> backed up luksDump.  i'm sure there are issues with each of these, but
> it seems likely that *something* can be done.  there was brief
> discussion on the dm-crypt mailing list about how to repair luks
> headers and that might be a place to start.

Could you point us to more documentation regarding the data corruption
issues? I found your report at the dm-crypt mailing list, but not any
suggestions about how to repair headers.

Maybe you even have some code to start from.

greetings,
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#432781: RM: zope-rdfgrabber -- RoM; old, broken

[Jonas Meurer]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove zope-rdfgrabber from debian, as it is old, broken and
unused. Popcon says it has eleven installations and no votes.

The main reason to remove it is that it's broken though. See bugreport
at http://zope.org/Collectors/Zope/355, which is closed but only because
nobody responsed for ages.

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.21-5-amd64-resivo
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#439590: [Pkg-cryptsetup-devel] Bug#439590: Passphrase not repeated after wrong try

[Jonas Meurer]

On 25/08/2007 Markus Melms wrote:
> Package: cryptsetup
> Version: 1.0.4+svn26-1 0
> 
> When using luksOpen with a wrong passphrase, there are no more chances
> to try again. It does not matter wether --tries is set or not:
> 
> playstation:/mnt# cryptsetup luksOpen /dev/hda1 hda1
> Enter LUKS passphrase: 
> Command failed.
> playstation:/mnt# 
> 
> Im using Debian Etch with kernel 2.6.18.2

Hello Markus,

This bug has been fixed in cryptsetup 1.0.4+svn26-2, which didn't make
it into etch in time.

...
 jonas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#440453: gnome-mount: please add support for keyfiles for encrypted media

[Jonas Meurer]

Package: gnome-mount
Version: 0.6-1+b2
Severity: wishlist

Hello,

It would be great, if you could add the patch from
http://bugs.launchpad.net/baltix/+source/gnome-mount/133520 to support
keyfiles for encrypted media in gnome-mount.

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-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 gnome-mount depends on:
ii  eject  2.1.5-5   ejects CDs and operates CD-Changer
ii  gconf2 2.18.0.1-3GNOME configuration database syste
ii  hal0.5.9.1-4 Hardware Abstraction Layer
ii  libart-2.0-2   2.3.19-3  Library of functions for 2D graphi
ii  libatk1.0-01.18.0-2  The ATK accessibility toolkit
ii  libbonobo2-0   2.18.0-2  Bonobo CORBA interfaces library
ii  libbonoboui2-0 2.18.0-5  The Bonobo UI library
ii  libc6  2.6.1-1   GNU C Library: Shared libraries
ii  libcairo2  1.4.10-1+b2   The Cairo 2D vector graphics libra
ii  libdbus-1-31.1.1-3   simple interprocess messaging syst
ii  libdbus-glib-1-2   0.74-1simple interprocess messaging syst
ii  libeel2-2.18   2.18.3-1  Eazel Extensions Library (for GNOM
ii  libfontconfig1 2.4.2-1.2 generic font configuration library
ii  libgail-common 1.18.0-2  GNOME Accessibility Implementation
ii  libgail18  1.18.0-2  GNOME Accessibility Implementation
ii  libgconf2-42.18.0.1-3GNOME configuration database syste
ii  libglade2-01:2.6.2-1 library to load .glade files at ru
ii  libglib2.0-0   2.14.0-2  The GLib library of C routines
ii  libgnome-keyring0  0.8.1-2   GNOME keyring services library
ii  libgnome2-02.18.0-4  The GNOME 2 library - runtime file
ii  libgnomecanvas2-0  2.14.0-3  A powerful object-oriented display
ii  libgnomeui-0   2.18.1-2  The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0 1:2.18.1-3GNOME Virtual File System (runtime
ii  libgtk2.0-02.10.13-1 The GTK+ graphical user interface 
ii  libhal-storage10.5.9.1-4 Hardware Abstraction Layer - share
ii  libhal10.5.9.1-4 Hardware Abstraction Layer - share
ii  libice62:1.0.4-1 X11 Inter-Client Exchange library
ii  libnautilus-extension1 2.18.3-3  libraries for nautilus components 
ii  libnotify1 [libnotify1-gtk 0.4.4-3   sends desktop notifications to a n
ii  liborbit2  1:2.14.7-0.1  libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0  1.16.5-1  Layout and rendering of internatio
ii  libpopt0   1.10-3lib for parsing cmdline parameters
ii  libsm6 2:1.0.3-1+b1  X11 Session Management library
ii  libx11-6   2:1.0.3-7 X11 client-side library
ii  libxcursor11:1.1.9-1 X cursor management library
ii  libxext6   1:1.0.3-2 X11 miscellaneous extension librar
ii  libxfixes3 1:4.0.3-2 X11 miscellaneous 'fixes' extensio
ii  libxi6 2:1.1.2-1 X11 Input extension library
ii  libxinerama1   1:1.0.2-1 X11 Xinerama extension library
ii  libxml22.6.30.dfsg-2 GNOME XML library
ii  libxrandr2 2:1.2.1-1 X11 RandR extension library
ii  libxrender11:0.9.3-1 X Rendering Extension client libra

gnome-mount recommends no packages.

-- no debconf information

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#440452: gnome-mount: Fails to mount LUKS-encrypted media

[Jonas Meurer]

Package: gnome-mount
Version: 0.6-1+b2
Severity: normal

Hello,

When i insert a LUKS-encrypted DVD into my drive, gnome-mount
automatically asks for the passphrase. But if i give the correct
passphrase, the dvd is not mounted as expected. Instead the passphrase
prompt shows up a second time.

The following error messages are printed to /var/log/syslog only if
the correct passphrase is entered:

Sep  1 17:46:34 resivo kernel: device-mapper: table: 253:16: crypt: Device 
lookup failed
Sep  1 17:46:34 resivo kernel: device-mapper: ioctl: error adding target to 
table
Sep  1 17:46:34 resivo kernel: device-mapper: ioctl: device doesn't appear to 
be in the dev hash table.

...
 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 gnome-mount depends on:
ii  eject  2.1.5-5   ejects CDs and operates CD-Changer
ii  gconf2 2.18.0.1-3GNOME configuration database syste
ii  hal0.5.9.1-4 Hardware Abstraction Layer
ii  libart-2.0-2   2.3.19-3  Library of functions for 2D graphi
ii  libatk1.0-01.18.0-2  The ATK accessibility toolkit
ii  libbonobo2-0   2.18.0-2  Bonobo CORBA interfaces library
ii  libbonoboui2-0 2.18.0-5  The Bonobo UI library
ii  libc6  2.6.1-1   GNU C Library: Shared libraries
ii  libcairo2  1.4.10-1+b2   The Cairo 2D vector graphics libra
ii  libdbus-1-31.1.1-3   simple interprocess messaging syst
ii  libdbus-glib-1-2   0.74-1simple interprocess messaging syst
ii  libeel2-2.18   2.18.3-1  Eazel Extensions Library (for GNOM
ii  libfontconfig1 2.4.2-1.2 generic font configuration library
ii  libgail-common 1.18.0-2  GNOME Accessibility Implementation
ii  libgail18  1.18.0-2  GNOME Accessibility Implementation
ii  libgconf2-42.18.0.1-3GNOME configuration database syste
ii  libglade2-01:2.6.2-1 library to load .glade files at ru
ii  libglib2.0-0   2.14.0-2  The GLib library of C routines
ii  libgnome-keyring0  0.8.1-2   GNOME keyring services library
ii  libgnome2-02.18.0-4  The GNOME 2 library - runtime file
ii  libgnomecanvas2-0  2.14.0-3  A powerful object-oriented display
ii  libgnomeui-0   2.18.1-2  The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0 1:2.18.1-3GNOME Virtual File System (runtime
ii  libgtk2.0-02.10.13-1 The GTK+ graphical user interface 
ii  libhal-storage10.5.9.1-4 Hardware Abstraction Layer - share
ii  libhal10.5.9.1-4 Hardware Abstraction Layer - share
ii  libice62:1.0.4-1 X11 Inter-Client Exchange library
ii  libnautilus-extension1 2.18.3-3  libraries for nautilus components 
ii  libnotify1 [libnotify1-gtk 0.4.4-3   sends desktop notifications to a n
ii  liborbit2  1:2.14.7-0.1  libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0  1.16.5-1  Layout and rendering of internatio
ii  libpopt0   1.10-3lib for parsing cmdline parameters
ii  libsm6 2:1.0.3-1+b1  X11 Session Management library
ii  libx11-6   2:1.0.3-7 X11 client-side library
ii  libxcursor11:1.1.9-1 X cursor management library
ii  libxext6   1:1.0.3-2 X11 miscellaneous extension librar
ii  libxfixes3 1:4.0.3-2 X11 miscellaneous 'fixes' extensio
ii  libxi6 2:1.1.2-1 X11 Input extension library
ii  libxinerama1   1:1.0.2-1 X11 Xinerama extension library
ii  libxml22.6.30.dfsg-2 GNOME XML library
ii  libxrandr2 2:1.2.1-1 X11 RandR extension library
ii  libxrender11:0.9.3-1 X Rendering Extension client libra

gnome-mount recommends no packages.

-- no debconf information

-- 
"In post-historical society, the rulers have ceased to rule,
but the slaves remain slaves." - Perry Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]