Bug#838905: libssl1.0.2: openssl 1.0.2i has segfault in CRL processing

Package: libssl1.0.2 Version: 1.0.2i-1 Severity: normal Dear Maintainer, If I edit test/pkits-test.pl (making $ossl_path = "/usr/bin/openssl"), add a pkits with the PKITS tests and run it, openssl segfaults. #0 0x7fb0b1b8fd20 in get_crl_sk (ctx=ctx@entry=0x7ffea36f3890, pcrl=pcrl@entry=0x7

Bug#723090: tcl8.5: [:cntrl:] character class does not include 0x00-0x1f

Package: tcl8.5 Version: 8.5.14-5 Followup-For: Bug #723090 Dear Maintainer, Judging by the changes in core-8.5.0, it's bug a876646, , and has been fixed, but subsequent to 8.5.14. Line 7765 of

Bug#723090: tcl8.5: [:cntrl:] character class does not include 0x00-0x1f

Package: tcl8.5 Version: 8.5.14-5 Severity: normal Dear Maintainer, I have an expect script that tries to match ([^[:cntrl:]]*), and it also matches the CRs at the end of a line. On inspection, that's because controlRangeTable[] and controlCharTable[] do not contain the normal ASCII control char

Bug#711516: zsh-doc: texinfo dir information has leading whitespace

Package: zsh-doc Version: 5.0.2-3local1 Severity: normal Dear Maintainer, In emacs, I couldn't view the ZSH info. That seems to be the leading whitespace (different to other dir lines). Removing it seemed to resolve the problem: --- zsh-5.0.2.orig/Doc/ztexi.yo +++ zsh-5.0.2/Doc/ztexi.yo @@ -71,7

Bug#681799: hardening-wrapper: README.Debian should mention -4.7

Package: hardening-wrapper Version: 2.2 Severity: minor The README mentions The hardening-wrapper package works by diverting g{cc,++}-4.[23456] and but by the looks of it also changes 4.7. -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'st

Bug#674921: xstow: Seems not to permit the same directory in two packages, making it not very useful

Package: xstow Version: 1.0.0-1 Severity: normal If I'm in /auto/tmpfs/stow and the following paths exist: one/bin/one two/bin/two So 2 packages, one and two, with just an executable each (and a common directory). When I try to stow both, I get an error: brs% xstow one brs% xst

Bug#628783: Fails to start: assert gtk.pygtk_version >= pygtkver

Package: meld Version: 1.4.0-2 Followup-For: Bug #628783 May be something wrong with python-support. An strace shows that one of the last files being read by the broken version is /usr/lib/pymodules/python2.6/gtk-2.0/gtk/__init__.py, which is empty. I can run "sudo pbuilder --login", then instal

Bug#628783: meld: Fails to start: assert gtk.pygtk_version >= pygtkver

Package: meld Version: 1.4.0-2 Severity: normal meld fails to start. Presumably this is some local problem, but I've no idea what it might be. Running meld under strace -f doesn't suggest (to me) anything obvious (/usr/local/lib/python2.6/{dist,site}-packages are empty). Traceback (most recent

Bug#582233: emacs23: Emacs23.3-1 doesn't crash nearly so often

Package: emacs23 Followup-For: Bug #582233 I didn't really follow up and debug this with 23.1/23.2. Fortunately, it seems to be resolved in 23.3-1, so I think it can be closed as fixed. -- System Information: Debian Release: wheezy/sid APT prefers oldstable APT policy: (500, 'oldstable'), (

Bug#619701: calibre: Rebuild doesn't work for me

Package: calibre Version: 0.7.50+dfsg-1local1 Followup-For: Bug #619701 I had the SIP API mismatch error, so installed from unstable, and got a segfault. I rebuilt (with no local changes), but calibre still segfaults on startup. -- System Information: Debian Release: wheezy/sid APT prefers ol

Bug#600571: perl: Installed fine for me

Package: perl Severity: normal I saw no issues during the upgrade. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYP

Bug#582233: Crash in long-running (well, over a day) emacs23.2

Package: emacs23 Version: 23.2+1-2local21 Severity: normal -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB

Bug#575749: exactimage-perl: "use ExactImage;" fails

Package: exactimage-perl Version: 0.7.5-3 Severity: normal It fails: Can't locate ExactImage.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) I imagi

Bug#561623: MP3 files end up with incorrect lengths (1000 times too long) when transferred to MTP device

Package: amarok Severity: normal I agree that this bug's been resolved. (My apologies for not replying sooner; I overlooked the email.) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd6

Bug#561623: amarok: MP3 files end up with incorrect lengths (1000 times too long) when transferred to MTP device

Package: amarok Version: 2.2.1-2 Severity: normal I started noticing this a few days ago, so I guess it's a bug in the new version of amarok. I understand there were other issues with durations so I rescanned the tracks as suggested, but that had no effect. Amarok itself displays the expected d

Bug#548704: libgtk2.0-0: This also seems to affect emacs23 -daemon menus

Package: libgtk2.0-0 Version: 2.18.2-1 Severity: normal -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UT

Bug#520961: Fix found for the issue with Creative Zen 0x041e:0x4157

I reported this upstream. It's bug 2745107 on project libmtp at sourceforge. As I noted, I found the first change that caused problems and (correctly, as it happens) guessed that removing the DEVICE_FLAG_BROKEN_MTPGETOBJPROPLIST_ALL flag for my device would work, and it does. Presumably the flag

Bug#542792: zlib1g: Upstream release appears to be 1.2.3

Package: zlib1g Version: 1:1.2.3.3.dfsg-15 Severity: normal -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_G

Bug#540397: possibly this gtk toolbar bug, fixed on the trunk

The problem sounds like which is fixed on the trunk. Unfortunately I don't know how easy it would be to take across the fix. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Tr

Bug#350639: gnome-volume-manager: Automounting does not work

Package: gnome-volume-manager Version: 2.24.1-3 Severity: normal I understand that automount is deliberately disabled (presumably for good reason, however inconvenient the decision is for some of us). In that case the package description probably needs trimming (at present it still claims that g

Bug#532330: alien: postinstall scripts may end up starting with #/bin/bash, which Deb.pm will complain about

Package: alien Version: 8.74 Severity: normal -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh

Bug#520961: libmtp8-0.3.7-1 fails to find all tracks on Creative Zen

Package: libmtp8 Version: 0.3.7-1 Severity: normal This is presumably somewhat related to #519980, but is with a different device for which that bug patch does not apply. I find that with 0.2.6-3 mtp-tracks gives 707 tracks, but with 0.3.7-1 and 0.3.6-2 I get only 144 tracks. (I haven't counted

Bug#519980: 0.3.7-1 fixing Bug#519980 is in experimental

Rafael Laboissiere writes: > Hi, > > I just uploaded libmtp_0.3.7-1 to experimental. This should fixes > Bug#519980. Please, test it with your device. It doesn't work for me (a Creative Zen, 041e:4157). With mtp-tools 0.2.6.1-3 "mtp-tracks | grep 'Track ID'|wc -l" gives 707. With 0.3.7-1 the

Bug#519980: libmtp8: Same (broken) behaviour for a Creative Zen (041e:4157)

Rafael Laboissiere writes: > * Bruce Stephens [2009-03-16 22:00]: > >> Package: libmtp8 >> Version: 0.3.6-2 >> Followup-For: Bug #519980 >> >> >> I also get only partial retrieval of tracks. By the looks of the >> patch linked to in the bug re

Bug#519980: libmtp8: Same (broken) behaviour for a Creative Zen (041e:4157)

Package: libmtp8 Version: 0.3.6-2 Followup-For: Bug #519980 I also get only partial retrieval of tracks. By the looks of the patch linked to in the bug report the flags aren't changed for this device, so I imagine the patch wouldn't fix things for me. libmtp7 0.2.6.1-3 doesn't seem to show this

Bug#481828: tig: Correct. Works after a rebuild, FWIW

Package: tig Followup-For: Bug #481828 The code is indeed doing popen("git config --list", ...). Code looks OK to me, and after a rebuild of the package, works fine. So I've no idea what happened to the official package. -- System Information: Debian Release: lenny/sid APT prefers testing AP

Bug#392644: jadetex 3.13-9 failing in fmtutil-sys

Frank Küster <[EMAIL PROTECTED]> writes: > Bruce Stephens <[EMAIL PROTECTED]> wrote: > >> Package: jadetex >> Version: 3.13-9 >> Followup-For: Bug #392644 > > No, this is a different issue. OK. Looked similar, though! [...] > apt-get --reinstall

Bug#392644: jadetex 3.13-9 failing in fmtutil-sys

Package: jadetex Version: 3.13-9 Followup-For: Bug #392644 I get the error Setting up jadetex (3.13-9) ... Running mktexlsr. This may take some time... done. Building format(s) --all --cnffile /etc/texmf/fmt.d/40jadetex.cnf. This may take some time... fmtutil-sys failed. Output has been

Bug#428324: kaffeine: drag & drop in playlist window seems not to work reliably

Package: kaffeine Version: 0.8.4-4 Severity: normal It always used to work that I'd choose a directory containing some .avi (or other) files, then select the ones I wanted, dragging them across to the playlist bit of the screen. But now (much of the time), the cursor remains as a no-entry type cu

Bug#427428: xserver-xorg-input-wacom: Package includes wacom_drv.o, but xorg looks for wacom_drv.so

Package: xserver-xorg-input-wacom Version: 0.7.7.10-1 Severity: grave Justification: renders package unusable I guess the wrong file got packaged (renaming it doesn't fix it). If I rename it, I get (II) LoadModule: "wacom" (II) Loading /usr/lib/xorg/modules/input//wacom_drv.so dlopen: /usr/lib/x

Bug#361412: libsqlite3-tcl: Version still seems wrong; patch attached

Package: libsqlite3-tcl Version: 3.3.7-1 Followup-For: Bug #361412 The version mentioned in pkgIndex.tcl must match exactly what's used in src/tclsqlite.c. That appears to resolve to what's called RELEASE in Makefile, so I suggest the following patch to Makefile.in (to call tclinstaller.tcl with

Bug#382279: soundconverter: Produces an error, and doesn't do anything

Lars Wirzenius <[EMAIL PROTECTED]> writes: > ke, 2006-08-09 kello 23:01 +0100, Bruce Stephens kirjoitti: >> Trying to convert some flac files, I get: >> >> Writing to: '/vob/Anamar/Transfado/04-Ovelha negra (Black sheep)-Anamar.ogg' >> Traceback (

Bug#382279: soundconverter: Produces an error, and doesn't do anything

Package: soundconverter Version: 0.8.7-1 Severity: important Trying to convert some flac files, I get: Writing to: '/vob/Anamar/Transfado/04-Ovelha negra (Black sheep)-Anamar.ogg' Traceback (most recent call last): File "/usr/bin/soundconverter", line 802, in new_decoded_pad sink.set_proper

Bug#372152: g++-4.1: PR27935 appears to be unresolved (operator delete(void*, size_t) issue)

Package: g++-4.1 Version: 4.1.1-2 Severity: normal describes what appears to be simply a size_t issue: struct a { void operator delete (void*, unsigned int); ~a(); }; void g(a *b) { delete b; } fails to compile. But of course size_t isn't necessarily unsigned

Bug#361412: libsqlite3-tcl: version in pkgIndex.tcl is different, but still wrong

Package: libsqlite3-tcl Version: 3.3.5-0.2 Followup-For: Bug #361412 Now the error is: attempt to provide package sqlite3 3.3 failed: package sqlite3 3.3.5 provided instead -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'tes

Bug#361412: libsqlite3-tcl: version in pkgIndex.tcl is wrong

Package: libsqlite3-tcl Version: 3.3.5-0.1 Severity: minor package require sqlite3 produces the warning: attempt to provide package sqlite3 3.0 failed: package sqlite3 3.3.5 provided instead I think that's because the pkgIndex.tcl file says: package ifneeded sqlite3 3.0 [list load [file join

Bug#317132: libmail-sender-perl: attachments with encoding 7BIT are sent without terminating newline

Package: libmail-sender-perl Version: 0.8.10-1 Severity: minor This script, when /tmp/blah is a text file with a newline at the end (as most files have) use Mail::Sender; $sender = new Mail::Sender {smtp => 'mail.your.domain', from => 'from-addr'}; $sender->MailFile({to => 'to-addr', subject => '

Bug#299498: Only grave on unstable

Philipp Frauenfelder <[EMAIL PROTECTED]> writes: [...] > And as I can tell from earlier occurences of the same problem, a > recompile against the newest valgrind should suffice. However, my > first try did not succeed as valgrind has changed some paths in the > packaging or is missing some includ

Bug#299498: Only grave on unstable

My apologies. I hadn't noticed that this same version is used in testing, too. Probably the package works fine with the valgrind in testing, and is only broken in unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#299498: valgrind-callgrind: undefined symbol: vgPlain_register_compact_helper

Package: valgrind-callgrind Version: 0.9.10-1 Severity: grave Justification: renders package unusable Something in the API to valgrind has changed, causing callgrind to fail: brs% valgrind --tool=callgrind ls Can't open tool "callgrind": /usr/lib/valgrind/vgskin_callgrind.so: undefined symbol: v

Bug#298704: libyaml-perl: Strings with commas in aren't quoted when being dumped, and can't be read in

Package: libyaml-perl Version: 0.36-1 Severity: normal In ysh: ysh > {'a,v' => 'c'} --- a,v: c ysh > --- a,v: c yaml> yaml> ... YAML Load Failed: --- !perl/YAML::Error code: YAML_LOAD_ERR_BAD_MAP_ELEMENT msg: Invalid element in map line: 2 document: 1 ... This didn't happen in 0.35-1

Bug#296349: wacom-kernel-source: Module relationship with usbhid incorrectly registered

Ron <[EMAIL PROTECTED]> writes: [...] > anyway, it is (otherwise harmless) cruft now and /etc/modprobe-before- > can be safely removed. OK. >> When I added "rmmod wacom; rmmod usbhid" to >> /etc/init.d/gdm, I got X back again (before that X failed to start, >> since the wacom mouse is my primar

Bug#296349: wacom-kernel-source: Module relationship with usbhid incorrectly registered

Package: wacom-kernel-source Version: 0.6.6-7 Severity: normal The generated package seems to contain an empty directory /etc/modprobe-before-usbhid.d/wacom I can't seem to find documentation for what it ought to be (presumably a file in /etc/modprobe.d), but this doesn't seem to cause wacom to

Bug#296168: wacom-kernel-source: With 2.6.10, fails to configure, and then fails to build (i386)

Ron <[EMAIL PROTECTED]> writes: [...] > This however is a small mystery to me. It would appear the kernel > headers you have included are different in some important aspect > from what I (and others I presume) have been using. I can't > reproduce it myself, nor do I see anything like a likely c

Bug#296168: wacom-kernel-source: With 2.6.10, fails to configure, and then fails to build (i386)

Package: wacom-kernel-source Version: 0.6.6-7 Severity: normal With make-kpkg modules_config: make[1]: Entering directory `/usr/src/modules/wacom' make[1]: *** No rule to make target `kdist_configure'. Stop. make[1]: Leaving directory `/usr/src/modules/wacom' Module /usr/src/modules/wacom failed