Bug#319698: bidwatcher: switch to GTK2

[Miernik]

Package: bidwatcher
Version: 1.3.17-1
Severity: wishlist

Create a GTK2 version of the program.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (50, 'experimental')
Architecture: i386 (i586)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-386
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages bidwatcher depends on:
ii  libc6 2.3.5-1GNU C Library: Shared libraries an
ii  libcurl3  7.14.0-2   Multi-protocol file transfer libra
ii  libgcc1   1:4.0.1-2  GCC support library
ii  libglib1.21.2.10-10  The GLib library of C routines
ii  libgtk1.2 1.2.10-17  The GIMP Toolkit set of widgets fo
ii  libidn11  0.5.18-1   GNU libidn library, implementation
ii  libssl0.9.7   0.9.7g-1   SSL shared libraries
ii  libstdc++51:3.3.6-7  The GNU Standard C++ Library v3
ii  libx11-6  6.8.2.dfsg.1-4 X Window System protocol client li
ii  libxext6  6.8.2.dfsg.1-4 X Window System miscellaneous exte
ii  libxi66.8.2.dfsg.1-4 X Window System Input extension li
ii  xlibs 6.8.2.dfsg.1-4 X Window System client libraries m
ii  zlib1g1:1.2.3-1  compression library - runtime

bidwatcher recommends no packages.

-- no debconf information


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

Bug#319699: RM: pyxine -- RoM, dead upstream, no rdepends

[Joe Wreschnig]

Package: ftp.debian.org
Severity: important

Rather than see Pyxine through the C++ ABI transition it would probably
be better to just remove it. It has no reverse-depends, it's abandoned
upstream, the one program that used it (Lsongs) appears to be equally
dead upstream, and python-gst provides a much better library for the
same task.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Bug#319697: gbase: separate X and non-X versions to different packages

[Miernik]

Package: gbase
Version: 0.5-2
Severity: wishlist

Please separate the package to something like:
gbase-common
gbase-gtk
gbase-nox
so non-X users can install the command line version without installing X
and GTK libraries needlessly.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (50, 'experimental')
Architecture: i386 (i586)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-386
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages gbase depends on:
ii  libc6 2.3.5-1GNU C Library: Shared libraries an
ii  libglib1.21.2.10-10  The GLib library of C routines
ii  libgtk1.2 1.2.10-17  The GIMP Toolkit set of widgets fo
ii  xlibs 6.8.2.dfsg.1-4 X Window System client libraries m

gbase recommends no packages.

-- no debconf information


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

Bug#312003: xscreensaver: Confirmation

[Mike Fedyk]

Package: xscreensaver
Version: 4.21-5
Followup-For: Bug #312003

I have to confirm this issue on my system also.

It is an interesting way to avoid the KDE bug though. ;)

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (7221, 'testing'), (7221, 'stable'), (711, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages xscreensaver depends on:
ii  libatk1.0-01.10.1-2  The ATK accessibility toolkit
ii  libc6  2.3.2.ds1-22  GNU C Library: Shared libraries an
ii  libglade2-01:2.5.1-2 library to load .glade files at ru
ii  libglib2.0-0   2.6.5-1   The GLib library of C routines
ii  libgtk2.0-02.6.8-1   The GTK+ graphical user interface 
ii  libice64.3.0.dfsg.1-14   Inter-Client Exchange library
ii  libjpeg62  6b-10 The Independent JPEG Group's JPEG 
ii  libpam0g   0.76-22   Pluggable Authentication Modules l
ii  libpango1.0-0  1.8.1-1   Layout and rendering of internatio
ii  libsm6 4.3.0.dfsg.1-14   X Window System Session Management
ii  libx11-6   4.3.0.dfsg.1-14   X Window System protocol client li
ii  libxext6   4.3.0.dfsg.1-14   X Window System miscellaneous exte
ii  libxml22.6.16-7  GNOME XML library
ii  libxmu64.3.0.dfsg.1-14   X Window System miscellaneous util
ii  libxpm44.3.0.dfsg.1-14   X pixmap library
ii  libxrandr2 4.3.0.dfsg.1-14   X Window System Resize, Rotate and
ii  libxrender11:0.9.0-2 X Rendering Extension client libra
ii  libxt6 4.3.0.dfsg.1-14   X Toolkit Intrinsics
ii  xlibs  4.3.0.dfsg.1-14   X Keyboard Extension (XKB) configu
ii  zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

Versions of packages xscreensaver recommends:
pn  libjpeg-progs  (no description available)
pn  miscfiles | wordlist   (no description available)
ii  netpbm2:10.0-8   Graphics conversion tools
ii  perl [perl5]  5.8.7-3Larry Wall's Practical Extraction 
pn  xli | xloadimage   (no description available)

-- no debconf information


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

Bug#319695: snac: use GTK2 instead of GTK1.2

[Miernik]

Package: snac
Version: 0.3-4
Severity: wishlist

use GTK2 instead of GTK1.2

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (50, 'experimental')
Architecture: i386 (i586)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-386
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages snac depends on:
ii  gdk-imlib11.9.14-16.2imaging library for use with gtk (
ii  libart2   1.4.2-20   The GNOME canvas widget - runtime 
ii  libaudiofile0 0.2.6-6Open-source version of SGI's audio
ii  libc6 2.3.5-1GNU C Library: Shared libraries an
ii  libdb33.2.9-22   Berkeley v3 Database Libraries [ru
ii  libesd0   0.2.36-1   Enlightened Sound Daemon - Shared 
ii  libglib1.21.2.10-10  The GLib library of C routines
ii  libgnome321.4.2-20   The GNOME libraries
ii  libgnomesupport0  1.4.2-20   The GNOME libraries (Support libra
ii  libgnomeui32  1.4.2-20   The GNOME libraries (User Interfac
ii  libgtk1.2 1.2.10-17  The GIMP Toolkit set of widgets fo
ii  libpopt0  1.7-5  lib for parsing cmdline parameters
ii  xlibs 6.8.2.dfsg.1-4 X Window System client libraries m
ii  zlib1g1:1.2.3-1  compression library - runtime

snac recommends no packages.

-- no debconf information


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

Bug#123611: gnokii: plea to fulfill this wish - separate things which depend on X libs to another package

[Miernik]

Package: gnokii
Version: 0.6.5-1
Followup-For: Bug #123611

It's a pity that over four and a half years after this simple wish has been
filed, it still hasn't been fulfilled. I would also like to use gnokii
without X libs.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (50, 'experimental')
Architecture: i386 (i586)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-386
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages gnokii depends on:
ii  libbluetooth1 2.18-1 Library to use the BlueZ Linux Blu
ii  libc6 2.3.5-1GNU C Library: Shared libraries an
ii  libglib1.21.2.10-10  The GLib library of C routines
ii  libgnokii20.6.5-1Gnokii library
ii  libgtk1.2 1.2.10-17  The GIMP Toolkit set of widgets fo
ii  liblockfile1  1.06   NFS-safe locking library, includes
ii  libx11-6  6.8.2.dfsg.1-4 X Window System protocol client li
ii  libxext6  6.8.2.dfsg.1-4 X Window System miscellaneous exte
ii  libxi66.8.2.dfsg.1-4 X Window System Input extension li
ii  libxpm4   6.8.2.dfsg.1-4 X pixmap library
ii  passwd1:4.0.3-38 change and administer password and
ii  timeout   1.11-6.1   Run a command with a time limit.
ii  xlibs 6.8.2.dfsg.1-4 X Window System client libraries m

gnokii recommends no packages.

-- no debconf information


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

Bug#306290: RFS: ttf-mph-2b-damase -- font with ranges from the latest version of unicode

[Paul Wise]

Hi all,

(I'm not subscribed, please CC me and the ITP - MFT set)

Package name: ttf-mph-2b-damase
Upstream Author : Mark Williamson <[EMAIL PROTECTED]>
Upstream URL: http://fixedsys.org/~node_ue/fonts/
License : Public Domain
ITP : http://bugs.debian.org/306290
Package : deb-src http://mentors.debian.net/debian unstable main
http://mentors.debian.net/debian/pool/main/t/ttf-mph-2b-damase/
Description : font with ranges from the latest version of unicode
 MPH 2B Damase is a SuperUnicode font, including ranges in Plane 1 and
 ranges added in the latest release of the Unicode standard (4.1). Some
 of these ranges include Tifinagh, Kharosthi, hPhags-pa, Old Persian
 Cuneiform and Limbu etc.

 The support for some scripts is not complete because the font lacks
 contextual substition (via OpenType tables) and composite glyphs, which
 are required to support Kharosthi, Limbu and other scripts fully. Please
 read the Debian README for a fuller discussion of the problems this
 may cause.

Upstream has given blessings for this to be in debian. Better short/long
descriptions very welcome. Lintian/Linda clean. I hope to find a
workaround for the fontconfig problem mentioned in README.Debian (and
discussed in the ITP), but my initial quick scan of the docs and wiki
hasn't yielded anything. Any suggestions are welcome :)

-- 
bye,
pabs

http://qa.debian.org/developer.php?login=Paul+Wise&comaint=yes


signature.asc
Description: This is a digitally signed message part

Bug#319694: w3mmee-img: optionally use GTK2 instead of GTK1.2

[Miernik]

Package: w3mmee-img
Version: 0.3.p24.20-2
Severity: wishlist

w3mmee-img depends on libgtk1.2. I would like it to be possible to use
it with GTK2 libs alternatively.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (50, 'experimental')
Architecture: i386 (i586)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-386
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages w3mmee-img depends on:
ii  libc6 2.3.5-1GNU C Library: Shared libraries an
ii  libgdk-pixbuf20.22.0-8   The GdkPixBuf image library, gtk+ 
ii  libglib1.21.2.10-10  The GLib library of C routines
ii  libgtk1.2 1.2.10-17  The GIMP Toolkit set of widgets fo
ii  libx11-6  6.8.2.dfsg.1-4 X Window System protocol client li
ii  libxext6  6.8.2.dfsg.1-4 X Window System miscellaneous exte
ii  libxi66.8.2.dfsg.1-4 X Window System Input extension li
ii  w3mmee0.3.p24.20-2   WWW browsable pager with excellent
ii  xlibs 6.8.2.dfsg.1-4 X Window System client libraries m

w3mmee-img recommends no packages.

-- no debconf information


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

Bug#319696: package pilrcui separately, so pilrc can be installed without X and GTK libs

[Miernik]

Package: pilrc
Version: 3.2-1
Severity: wishlist

Separate the pilrcui GTK frontend to a separate package, so the pilrc
package doesn't depend on libgtk1.2 and xlibs.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (50, 'experimental')
Architecture: i386 (i586)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-386
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages pilrc depends on:
ii  libc6 2.3.5-1GNU C Library: Shared libraries an
ii  libglib1.21.2.10-10  The GLib library of C routines
ii  libgtk1.2 1.2.10-17  The GIMP Toolkit set of widgets fo
ii  libx11-6  6.8.2.dfsg.1-4 X Window System protocol client li
ii  libxext6  6.8.2.dfsg.1-4 X Window System miscellaneous exte
ii  libxi66.8.2.dfsg.1-4 X Window System Input extension li
ii  xlibs 6.8.2.dfsg.1-4 X Window System client libraries m

Versions of packages pilrc recommends:
ii  prc-tools   2.2.90.cvs20030306-6 GCC, GDB, binutils, etc. for PDAs 

-- no debconf information


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

Bug#319693: hypermail: New upstream version

[Robert King]

Package: hypermail
Version: 2.1.8-1
Severity: wishlist

http://sourceforge.net/project/shownotes.php?group_id=18117&release_id=241470
reports release 2.2.0, which removes at least some of the annoying
warnings


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (200, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.7-5-amd64-k8-smp
Locale: LANG=en_AU, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages hypermail depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgdbm31.8.3-2  GNU dbm database routines (runtime
ii  libpcre35.0-1.1  Perl 5 Compatible Regular Expressi

-- no debconf information


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

Bug#225819: man page for blackhole

[Kenshi Muto]

tags 225819 pending
thanks

At Sat, 23 Jul 2005 16:17:53 +0200,
Timo Schneider wrote:
> Package: xjokes
> Tags: patch
> 
> .\" Process this file with
> .\" groff -man -Tascii blackhole.1

Thank you!
I'll upload merged version when ftp-master come back.

Thanks,
-- 
Kenshi Muto
[EMAIL PROTECTED]


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

Bug#317703: xsupplicant: Should not write username/password info to log file

[Eric Evans]

Tags 317703 pending
Thanks

On Sun, Jul 10, 2005 at 10:03:05PM +0200, Frans Pop muttered these words:
> Package: xsupplicant
> Version: 1.0.1-4
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> When xsupplicant is started on boot, my wireless card is not "up".
> In that situation, xsupplicant happily dumps configuration settings,
> including username/password settings, to /var/log/xsupplicant.log.
> 
> For the same reason it is probably not a good idea that the default
> /etc/xsupplicant/xsupplicant.conf is created world-readable.

I've put together a new package that addresses these issues and will
upload it as soon as possible.

Thanks for the report.

-- 
Eric Evans
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#319685: Nevermind...

[Phil Dibowitz]

OK, the package is still there but no longer listed under "recommended"
or "suggested" and at some point had gotten removed from my system (bad
dependency with something?)

Anyway, it installs fine, so nevermind. Though I think it should be a
recommend/suggest package...


-- 
Phil Dibowitz [EMAIL PROTECTED]
Freeware and Technical Pages  Insanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
 - Benjamin Franklin, 1759



signature.asc
Description: OpenPGP digital signature

Bug#319691: Package Web Search

[Tom ...]

Package: packages.debian.org
Version: n/a

If you goto packages.debian.org and do a search for packages in 'any'
distribution and 'any' section and put more than one keyword in, the
search fails with "Error: keyword not valid or missing"

Here's is an example:

http://packages.debian.org/cgi-bin/search_packages.pl?keywords=onscreen+keyboard&searchon=names&subword=1&version=all&release=all

Firefox 1.0.4 Debian Etck Kernel 2.6.8

Bug#319692: metar: decode wind direction

[Peter Samuelson]

Package: metar
Version: 20050706.1-1
Severity: wishlist
Tags: patch

I can convert wind direction from a compass heading to compass points
in my head, but I shouldn't have to.  See patch.

Peter

--- metar-20050706.1.orig/src/main.c
+++ metar-20050706.1/src/main.c
@@ -106,7 +106,12 @@
if (metar.winddir == -1) {
printf("Wind direction: Variable\n");
} else {
-   printf("Wind direction: %i\n", metar.winddir);
+   static const char *winddirs[] = {
+   "N", "NNE", "NE", "ENE", "E", "ESE", "SE", "SSE",
+   "S", "SSW", "SW", "WSW", "W", "WNW", "NW", "NNW", "N"
+   };
+   int i = (metar.winddir * 4 + 45) / 90;
+   printf("Wind direction: %i (%s)\n", metar.winddir, winddirs[i]);
}
printf("Wind speed: %i %s\n", metar.windstr, metar.windunit);
printf("Wind gust : %i %s\n", metar.windgust, metar.windunit);


signature.asc
Description: Digital signature

Bug#319690: mutella(GNU/k*BSD): FTBFS: out of date config.sub/config.guess

[Aurelien Jarno]

Package: mutella
Version: N/A
Severity: important

Hello,


The current version of mutella fails to build on GNU/kFreeBSD, 
because of outdated config.guess and config.sub.

The versions of config.guess and config.sub in mutella are too
old to correctly support Debian GNU/k*BSD.  A version is needed
from this year, which is available in the autotools-dev packages
that are in current sarge, and sid.

You can simply copy them manually, but it can also be done 
automatically using the method described in
/usr/share/doc/autotools-dev/README.Debian.gz 

It would also be nice if you cans ask upstream to update 
config.guess and config.sub in their next release.


Thanks for your cooperation.

-- System Information:
Debian Release: testing/unstable
Architecture: kfreebsd-i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: GNU/kFreeBSD 5.3-16
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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

Bug#319688: gsmlib(GNU/k*BSD): FTBFS: out of date libtool scripts

[Aurelien Jarno]

Package: gsmlib
Version: N/A
Severity: important

Hello,


The current version of gsmlib fails to build on
GNU/kFreeBSD, because of outdated libtool.

The version of libtool in gsmlib is too old to correctly 
support Debian GNU/k*BSD.  libtool 1.5.2-1 or later is need.

Here is how to update the libtool in your package (Make sure you
are using libtool 1.5.2-1 or later):
  libtoolize -c -f
  aclocal (-Im4 might be needed if there's an "m4" template dir)
  autoconf

It would also be nice if you can ask upstream to update libtool 
in their next release.


Thanks for your cooperation.

-- System Information:
Debian Release: testing/unstable
Architecture: kfreebsd-i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: GNU/kFreeBSD 5.3-16
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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

Bug#319687: devscripts: dch --distribution always set the distribution to UNRELEASED

[Aurelien Jarno]

Package: devscripts
Version: 2.9.2
Severity: normal

The --distribution option is broken, as the distribution is set to
UNRELEASED whatever distribution is given as an argument.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)

Versions of packages devscripts depends on:
ii  debianutils 2.14.1   Miscellaneous utilities specific t
ii  dpkg-dev1.13.10  Package building tools for Debian
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  perl5.8.7-4  Larry Wall's Practical Extraction 
ii  sed 4.1.4-2  The GNU sed stream editor

Versions of packages devscripts recommends:
ii  fakeroot  1.4.2  Gives a fake root environment

-- no debconf information


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

Bug#319686: segfaults on bad ~/.xgalscores, potentially exploitable

[Joey Hess]

Package: xgalaga
Version: 2.0.34-30
Severity: important
Tags: security

xgalaga is sgid and reads/writes from ~/.xgalscores. This is a
potentially dangerous combination and I've found one potential 
security hole in it.

The code tries to be fairly safe, and it does not seem vulnerable to
symlink attacks with ~/.xgalscores since it does a setgid(getegid)
before writing to the file and then setgids back afterwards.

However, the code to read the ~/.xgalscores runs as gid games and
contains bugs that allow xgalaga to segfault on certian files. I've
attached one such file, which makes xgalaga crash so bad it corrupts its
stack and I can't see in gdb what the actual issue is. At a guess,
buffer overrun. So there is the possibility of running shellcode as gid
games here.

-- 
see shy jo
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
No name ,  0, 0,No date 
joey,  37101,15,Fri Jan 31 10:21:35 2003


signature.asc
Description: Digital signature

Bug#309389: ipmasq: enumerate-if does not report eth0:1 etc. correctly

[Osamu Aoki]

Hi, (Sorry for slow response.  I just moved from Europe to Japan.)

On Mon, May 16, 2005 at 05:51:31PM -0400, Paul Miller wrote:
> Package: ipmasq
> Version: 4.0.2
> Severity: normal
> 
> When using multiple subnets on the same interface, enumerate-if does
> not correctly list sub interfaces, ethX:Y.  This causes problems with
> determining the internal/external interfaces...  For some reason,
> ifconfig doesn't even list these sub interfaces even though they
> exist.
> 
> /etc/network/interfaces
> auto eth0 eth0:1
> 
> iface eth0 inet dhcp
> 
> iface eth0:1 inet static
> address 192.168.8.97
> netmask 255.255.255.0
> network 192.168.8.0

Strange. I have set up similar situation (ifconfig)

eth0  Link encap:Ethernet  HWaddr 08:00:46:7A:02:B0  
  inet addr:192.168.0.4  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: fe80::a00:46ff:fe7a:2b0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:1250 errors:0 dropped:0 overruns:0 frame:0
  TX packets:554 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:428980 (418.9 KiB)  TX bytes:50722 (49.5 KiB)

eth0:1Link encap:Ethernet  HWaddr 08:00:46:7A:02:B0  
  inet addr:192.168.0.66  Bcast:192.168.0.255  Mask:255.255.255.0
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:14116 errors:0 dropped:0 overruns:0 frame:0
  TX packets:14116 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:4218551 (4.0 MiB)  TX bytes:4218551 (4.0 MiB)

and enumerate-if returns:

eth0
eth0:1
lo

I think bug ios elsewhere if it existed.  It may be other program's
problem.  Are you sure you have interfaces set up properly?  Send me
ifconfig result. 


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

Bug#319554: ncurses-base: xterm-color terminfo should have kdch1=\E[3~

[Thomas Dickey]

On Sat, 23 Jul 2005, Daniel Jacobowitz wrote:


Since the terminfo shipped with xterm is primarily of interest for the
"real" and current xterm, and the terminfo shipped with ncurses is
supposed to cover a wide variety of all kinds of oddball terminals, I
am inclined to take only the entries describing our xterm from
debian/xterm.ti (i.e. from the xterm source); let ncurses's
misc/terminfo.src supply things like xterm-r6.  As a side effect, that
would fix this problem for Vincent.  Does that sound reasonable?


perhaps - I'll be checking over the two (and comparing against the X11R6.1 
source) just to see that nothing got lost.  Checking terminfo seems to be 
very time-consuming (I've been doing some of that today). But in 
principle, ncurses should be the source for the various terminals, and 
xterm to reflect _its_ special stuff.


However, ncurses' xterm-color has kbs=^H (which I don't see a point in
changing, since there _are_ no terminals that match it in Debian).


Hmm, I just checked - Red Hat's xterm-r6 terminfo uses \177 so they
must be getting it from xterm.  My Solaris box is down.  HPUX uses
kbs=\177 but has no kdch1 at all (that's for "xterm").  Darwin uses
kdch1=\E[3~ for xterm and xterm-r6.


Redhat - yes, that's something on one of the bugzillas.  They had been 
patching things, decided not to, found that people used the changes, want 
to be like Debian, but upstream ncurses and xterm don't match what they 
were using. Etc.


Solaris uses kbs=^H, as do the *BSD's.  Solaris has no kdch1 in its
xterm terminfo (though X11R6.1 does).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


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

Bug#319685: multisync: Pilot plugin gone!

[Phil Dibowitz]

Package: multisync
Version: 0.82-5.1
Severity: important


The pilot plugin for multisync seems to have disappeared. Since I use
multisync to sync my phone to my palm pilot, this makes the package
completely unusable for me, and I suspect many others.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2rider-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages multisync depends on:
ii  libart-2.0-2 2.3.17-1Library of functions for 2D graphi
ii  libatk1.0-0  1.10.1-2The ATK accessibility toolkit
ii  libbonobo2-0 2.10.0-1Bonobo CORBA interfaces library
ii  libbonoboui2-0   2.10.0-1The Bonobo UI library
ii  libc62.3.2.ds1-22GNU C Library: Shared libraries an
ii  libgconf2-4  2.10.1-1GNOME configuration database syste
ii  libglib2.0-0 2.6.5-1 The GLib library of C routines
ii  libgnome2-0  2.10.1-1The GNOME 2 library - runtime file
ii  libgnomecanvas2-02.10.2-2A powerful object-oriented display
ii  libgnomeui-0 2.10.1-1The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0   2.10.1-5The GNOME virtual file-system libr
ii  libgtk2.0-0  2.6.8-1 The GTK+ graphical user interface 
ii  libice6  6.8.2.dfsg.1-3  Inter-Client Exchange library
ii  liborbit21:2.12.2-2  libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-01.8.1-1 Layout and rendering of internatio
ii  libpopt0 1.7-5   lib for parsing cmdline parameters
ii  libsm6   6.8.2.dfsg.1-3  X Window System Session Management
ii  libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li
ii  libxml2  2.6.20-1GNOME XML library
ii  xlibs6.8.2.dfsg.1-3  X Window System client libraries m
ii  zlib1g   1:1.2.3-1   compression library - runtime

Versions of packages multisync recommends:
ii  libmultisync-plugin-backup0.82-5.1   Backup plug for MultiSync
pn  libmultisync-plugin-evolution  (no description available)
ii  libmultisync-plugin-irmc  0.82-5.1   IrMc Mobile plugin for MultiSync

-- no debconf information


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

Bug#319554: ncurses-base: xterm-color terminfo should have kdch1=\E[3~

[Daniel Jacobowitz]

On Sat, Jul 23, 2005 at 10:44:49AM -0400, Thomas E. Dickey wrote:
> >I'm a bit confused really; the xterm-r6 definition in misc/terminfo.src
> >has kdch1=\E[3~.  The xterm-r6 definition in debian/xterm.ti has
> >kdch1=\177, and I'm pretty sure we get that from the xterm source
> >distribution... I wonder why they diverged?
> 
> I'm not 100% sure, since some of the changes are old.  I see looking at 
> xterm's terminfo history that kdch1 was originally \E[3~. In August 1996, 
> there's a change to make it \177.  I don't see that in any of my patches 
> (though I did make other changes to the terminfo around then - added the 
> ech string).
> 
> The XFree86 CVS only shows "updates" for the change comment on that file. 
> So who and why the change was made - I doubt that the answer is 
> forthcoming.  I don't see any xterm-fixes for that period in XFree86's
> changelog other than mine, and doubt that David Dawes recalls who 
> submitted the change.
> 
> ncurses's terminfo is maintained separately, and I probably ignored this 
> since when I compare the two, I'm focused on the XFree86 flavor - 
> xterm-r6 and xterm-r5 are in xterm's file just for convenience.

Right, I understand.

Since the terminfo shipped with xterm is primarily of interest for the
"real" and current xterm, and the terminfo shipped with ncurses is
supposed to cover a wide variety of all kinds of oddball terminals, I
am inclined to take only the entries describing our xterm from
debian/xterm.ti (i.e. from the xterm source); let ncurses's
misc/terminfo.src supply things like xterm-r6.  As a side effect, that
would fix this problem for Vincent.  Does that sound reasonable?

Hmm, I just checked - Red Hat's xterm-r6 terminfo uses \177 so they
must be getting it from xterm.  My Solaris box is down.  HPUX uses
kbs=\177 but has no kdch1 at all (that's for "xterm").  Darwin uses
kdch1=\E[3~ for xterm and xterm-r6.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Bug#319454: drscheme: Selecting text in a text entry field crashes on AMD64

[Ari Pollak]

I can't reproduce this on amd64 with drscheme 209-6 and xserver-xorg.

Simon Guest wrote:
> Package: drscheme
> Version: 1:209-5
> Severity: normal
> 
> This problem occurs for me on AMD64, but not on i386.
> 
> Selecting text in a text entry field, for example the filename in the
> Open File dialog, crashes DrScheme, with the following error message:
> 
> X Error of failed request:  BadValue (integer parameter out of range for 
> operation)
>   Major opcode of failed request:  18 (X_ChangeProperty)
>   Value in failed request:  0x40
>   Serial number of failed request:  9481
>   Current serial number in output stream:  9483
> 
> This occurs whether the selection is done with the mouse or the
> keyboard.  I have noticed it in both the Open File dialog, and the Add
> Teachpack dialog.
> 
> cheers,
> Simon
> 


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

Bug#319684: xfce4-diskperf-plugin: X4DP runs but never sees any traffic on busy disk

[A Costa]

Package: xfce4-diskperf-plugin
Version: 1.5-3
Severity: normal


I have 'Disk Performance' running, (it shows up on the panel), and configured
for my default drive '/dev/hda3':

% { mount ; df ; } | grep hda3
/dev/hda3 on / type ext3 (rw,errors=remount-ro)
/dev/hda3  7901858   6386003   1106198  86% /

...but it never shows any action.  When I move the mouse above it, an 
informative
looking tooltip pops up, but it always says 0 for I/O, and -1 for busy time.

Other 'xfce4' applets like 'System Load' work fine.

If it's useful, attached is the output of 'cat /proc/diskstats'.


Hope this helps...


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.11-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Versions of packages xfce4-diskperf-plugin depends on:
ii  libatk1.0-0 1.10.1-2 The ATK accessibility toolkit
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libglib2.0-02.6.5-1  The GLib library of C routines
ii  libgtk2.0-0 2.6.8-1  The GTK+ graphical user interface 
ii  libpango1.0-0   1.8.1-1  Layout and rendering of internatio
ii  libxfce4util-1  4.2.2-1  Utility functions library for Xfce
ii  libxfcegui4-3   4.2.2-1  Basic GUI C functions for Xfce4
ii  libxml2 2.6.20-1 GNOME XML library
ii  xfce4-panel 4.2.2-1  The Xfce4 desktop environment pane
ii  zlib1g  1:1.2.2-8compression library - runtime

xfce4-diskperf-plugin recommends no packages.

-- no debconf information
   10 ram0 0 0 0 0 0 0 0 0 0 0 0
   11 ram1 0 0 0 0 0 0 0 0 0 0 0
   12 ram2 0 0 0 0 0 0 0 0 0 0 0
   13 ram3 0 0 0 0 0 0 0 0 0 0 0
   14 ram4 0 0 0 0 0 0 0 0 0 0 0
   15 ram5 0 0 0 0 0 0 0 0 0 0 0
   16 ram6 0 0 0 0 0 0 0 0 0 0 0
   17 ram7 0 0 0 0 0 0 0 0 0 0 0
   18 ram8 0 0 0 0 0 0 0 0 0 0 0
   19 ram9 0 0 0 0 0 0 0 0 0 0 0
   1   10 ram10 0 0 0 0 0 0 0 0 0 0 0
   1   11 ram11 0 0 0 0 0 0 0 0 0 0 0
   1   12 ram12 0 0 0 0 0 0 0 0 0 0 0
   1   13 ram13 0 0 0 0 0 0 0 0 0 0 0
   1   14 ram14 0 0 0 0 0 0 0 0 0 0 0
   1   15 ram15 0 0 0 0 0 0 0 0 0 0 0
   70 loop0 0 0 0 0 0 0 0 0 0 0 0
   71 loop1 0 0 0 0 0 0 0 0 0 0 0
   72 loop2 0 0 0 0 0 0 0 0 0 0 0
   73 loop3 0 0 0 0 0 0 0 0 0 0 0
   74 loop4 0 0 0 0 0 0 0 0 0 0 0
   75 loop5 0 0 0 0 0 0 0 0 0 0 0
   76 loop6 0 0 0 0 0 0 0 0 0 0 0
   77 loop7 0 0 0 0 0 0 0 0 0 0 0
   30 hda 121836 90559 795233 918195 19875 102765 245288 5886423 0 463711 
6804621
   31 hda1 64511 64511 0 0
   32 hda2 0 0 0 0
   33 hda3 113050 686080 122636 245272
   34 hda4 17456 17456 16 16
   35 hda5 17355 27098 0 0
   36 hda6 0 0 0 0
   3   64 hdb 44668 38273 121944 11758 0 0 0 0 0 10157 11758
   3   65 hdb1 82939 121928 0 0
   3   66 hdb2 0 0 0 0
   3   69 hdb5 0 0 0 0
  220 hdc 0 0 0 0 0 0 0 0 0 0 0
  22   64 hdd 17 49 264 6445 0 0 0 0 0 6445 6445
 2520 pktcdvd0 0 0 0 0 0 0 0 0 0 0 0

Bug#319683: wmaker: New upstream version available

[Nelson A. de Oliveira]

Package: wmaker
Version: 0.91.0-7.2
Severity: wishlist


Hi!

There is a new upstream version of Window Maker (version 0.92), that fix
some bugs and also have some new features.

Thank you!
Nelson

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-rc6-mm1
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) (ignored: LC_ALL set to 
pt_BR)

Versions of packages wmaker depends on:
ii  cpp  4:4.0.0-2   The GNU C preprocessor (cpp)
ii  debianutils  2.14.1  Miscellaneous utilities specific t
ii  libc62.3.2.ds1-22GNU C Library: Shared libraries an
ii  libfontconfig1   2.3.2-1 generic font configuration library
ii  libfreetype6 2.1.10-1FreeType 2 font engine, shared lib
ii  libwraster3  0.91.0-7.2  Shared libraries of Window Maker r
ii  libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li
ii  libxext6 6.8.2.dfsg.1-4  X Window System miscellaneous exte
ii  libxft2  2.1.7-1 FreeType-based font drawing librar
ii  libxrender1  1:0.9.0-2   X Rendering Extension client libra
ii  xlibs6.8.2.dfsg.1-4  X Window System client libraries m
ii  zlib1g   1:1.2.3-1   compression library - runtime

wmaker recommends no packages.

-- no debconf information


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

Bug#319554: ncurses-base: xterm-color terminfo should have kdch1=\E[3~

[Thomas Dickey]

On Sun, 24 Jul 2005, Vincent Lefevre wrote:


On 2005-07-23 09:38:31 -0400, Thomas Dickey wrote:

hmm - a quick glance at the code shows this is another of the ones that
claim it's xterm-compatible (I see some "xterm" and "vt100" literals).
I'd suggest testing that theory with vttest.  The only mention of vttest
in the changelog is two years old "largely works".


I tried with tack (I don't have vttest), and IIRC, I found only one
problem. There are also problems with the numeric keypad, and also
the numeric keypad gives unknown escape sequences.


tack doesn't check the vt100-compatibility; it just makes generic checks
on the terminfo contents.  vttest would provide a check for the keyboard
(as well as other things).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


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

Bug#319682: unionfs-source: pathconf does not work with _PC_NAME_MAX option

[Vincent Bernat]

Package: unionfs-source
Version: 1.0.11-1
Severity: important


On an unionfs mount point, pathconf(".", _PC_NAME_MAX) returns 0
(instead of 255). This undermines the usability of patch in certain
cases.

Here is a related message :
 http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2005-February/000181.html

This thread ended to this bug :
 https://bugzilla.filesystems.org/show_bug.cgi?id=204

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10-1-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages unionfs-source depends on:
ii  bzip2 1.0.2-7high-quality block-sorting file co
ii  debhelper 4.9.5  helper programs for debian/rules
ii  module-assistant  0.9.5  tool to make module package creati

unionfs-source recommends no packages.

-- no debconf information


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

Bug#319678: aspell-fr: Please autobuild dictionary hash at install time

[Brian Nelson]

Package: aspell-fr
Severity: wishlist

As of aspell >= 0.60.3-3 in conjunction with dictionaries-common >=
0.49.2, aspell now fully supports building dictionary hashes at install
time.  This provides two huge advantages over packaging the hashes in
the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging autobuilt dictionaries for aspell >= 0.60.3-3
-

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319674: aspell-de-alt: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-de-alt
Severity: grave
Version: 2.1-1-1
Tags: sid


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319677: aspell-pl: Please autobuild dictionary hash at install time

[Brian Nelson]

Package: aspell-pl
Severity: wishlist

As of aspell >= 0.60.3-3 in conjunction with dictionaries-common >=
0.49.2, aspell now fully supports building dictionary hashes at install
time.  This provides two huge advantages over packaging the hashes in
the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging autobuilt dictionaries for aspell >= 0.60.3-3
-

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319659: nautilus-cd-burner: Fails to rewrite DVD-RW

[Brett Smith]

On Sat, Jul 23, 2005 at 10:10:10PM +0200, Lo?c Minier wrote:
>  Looks like a kernel bug to me.  Are you able to achieve the same task
>  via command line tools?  Could you please send the commands which are
>  failing/succeeding?

I've never used the command-line tools before, and I can't say I'm very
well-versed in them.  I ran a few that looked like obvious candidates;
their output is below.  While I did get output similar to what Nautilus is
reporting, I couldn't get an exact match, and none of these commands caused
the dmesg error to show up again.  Here's what I tried:

[EMAIL PROTECTED] % dvd+rw-mediainfo /dev/scd0
INQUIRY:[PLEXTOR ][DVDR   PX-712A  ][1.05]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 14h, DVD-RW Sequential
 Current Write Speed:   1.0x1385=1385KB/s
 Write Speed #0:2.0x1385=2770KB/s
 Write Speed #1:1.0x1385=1385KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 2.0x1385=2770KB/[EMAIL PROTECTED] -> 2294911]
 Speed Descriptor#0:03/2142287 [EMAIL PROTECTED]/s
 [EMAIL PROTECTED]/s
 Speed Descriptor#1:03/2142287 [EMAIL PROTECTED]/s
 [EMAIL PROTECTED]/s
READ DVD STRUCTURE[#10h]:
 Media Book Type:   32h, DVD-RW book [revision 2]
 Legacy lead-out at:2298496*2KB=4707319808
READ DVD STRUCTURE[#0h]:
 Media Book Type:   32h, DVD-RW book [revision 2]
 Last border-out at:2142288*2KB=4387405824
READ DISC INFORMATION:
 Disc status:   complete
 Number of Sessions:1
 State of Last Session: complete
 Number of Tracks:  1
READ TRACK INFORMATION[#1]:
 Track State:   complete incremental
 Track Start Address:   0*2KB
 Free Blocks:   0*2KB
 Track Size:2142288*2KB
 Last Recorded Address: 2142287*2KB
FABRICATED TOC:
 Track#1  : [EMAIL PROTECTED]
 Track#AA : [EMAIL PROTECTED]
 Multi-session Info:[EMAIL PROTECTED]
READ CAPACITY:  2142288*2048=4387405824

[EMAIL PROTECTED] % dvd+rw-format -blank=full /dev/scd0
* DVD RW/-RAM format utility by <[EMAIL PROTECTED]>, version 4.10.
* 4.7GB DVD-RW media in Sequential mode detected.
* blanking .:-[ PERFORM OPC failed with SK=5h/ASC=27h/ACQ=00h]:
Input/output error

[EMAIL PROTECTED] % dvd+rw-format -force=full -blank=full /dev/scd0
* DVD RW/-RAM format utility by <[EMAIL PROTECTED]>, version 4.10.
* 4.7GB DVD-RW media in Sequential mode detected.
* blanking /:-[ PERFORM OPC failed with SK=5h/ASC=27h/ACQ=00h]:
Input/output error

[EMAIL PROTECTED] % growisofs -M /dev/scd0 -R -J /tmp/testfile
:-( media is not appendable

[EMAIL PROTECTED] % growisofs -dvd-compat -Z /dev/scd0=/tmp/testfile
WARNING: /dev/scd0 already carries isofs!
About to execute 'builtin_dd if=/tmp/testfile of=/dev/scd0 obs=32k seek=0'
:-( write failed: Input/output error

[EMAIL PROTECTED] % growisofs -speed=1 -dvd-compat -use-the-force-luke=tty
-Z /dev/scd0=/tmp/testfile
WARNING: /dev/scd0 already carries isofs!
About to execute 'builtin_dd if=/tmp/testfile of=/dev/scd0 obs=32k seek=0'
:-( write failed: Input/output error

Of course, even though I couldn't reproduce the kernel message, the fact
that none of these succeeded does suggest, at least, that the problem isn't
just with Nautilus.  The last is what I thought Nautilus was running, given
what's in nautilus_burn_recorder_write_growisofs, but it doesn't look like
it.  If you can suggest other commands to try, especially if you know what
Nautilus might be running or how I might get some more detailed
diagnostics, I'd be happy to try them out and pass them along.

Thanks.


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

Bug#318815: Needs repackaging for latest aspell

[Brian Nelson]

retitle 318815 Needs repackaging for latest aspell
severity 318815 grave
tag 318815 sid
thanks

Here's some additional information regarding the aspell changes:


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


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

Bug#319671: tla(GNU/k*BSD): FTBFS: out of date config.sub/config.guess

[Aurelien Jarno]

Package: tla
Version: N/A
Severity: important

Hello,


The current version of tla fails to build on GNU/kFreeBSD, 
because of outdated config.guess and config.sub.

The versions of config.guess and config.sub in tla are too
old to correctly support Debian GNU/k*BSD.  A version is needed
from this year, which is available in the autotools-dev packages
that are in current sarge, and sid.

You can simply copy them manually, but it can also be done 
automatically using the method described in
/usr/share/doc/autotools-dev/README.Debian.gz 

It would also be nice if you cans ask upstream to update 
config.guess and config.sub in their next release.


Thanks for your cooperation.

-- System Information:
Debian Release: testing/unstable
Architecture: kfreebsd-i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: GNU/kFreeBSD 5.3-16
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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

Bug#319669: aspell-pt-br: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-pt-br
Severity: grave
Version: 2.4.really.3.0.beta4-9
Tags: sid


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319673: aspell-fo: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-fo
Severity: grave
Version: 0.2.16-1.1
Tags: sid


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319672: aspell-it: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-it
Severity: grave
Version: 0.60-2
Tags: sid


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319680: aspell-ca: Please autobuild dictionary hash at install time

[Brian Nelson]

Package: aspell-ca
Severity: wishlist

As of aspell >= 0.60.3-3 in conjunction with dictionaries-common >=
0.49.2, aspell now fully supports building dictionary hashes at install
time.  This provides two huge advantages over packaging the hashes in
the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging autobuilt dictionaries for aspell >= 0.60.3-3
-

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319679: kdelibs4 broken dependency

[Beto]

Package: kdelibs4
Version: 4:3.3.2-7

It's impossible to install KDE. I have installed Debian Sid (Sarge
netinstall and then upgraded to Sid) today and if I try to install
KDE, it cannot, so I finally got the problem:
'apt-get install kdelibs4' says it depends on libaspell15, but it's
not installable, so I tried  'apt-get install libaspell15' and it says
that this package is replaced by libaspell15c2 (this one CAN be
installed), but not libaspell15, soy kdelibs4 won't install and I
can't use KDE.

Sorry if you find mistakes on my text, I'm spanish.

-- 
Betorr

Bug#319681: aspell-bn: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-bn
Severity: grave
Version: 0.60.0.01.1.1-2
Tags: sid

As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319554: ncurses-base: xterm-color terminfo should have kdch1=\E[3~

[Vincent Lefevre]

On 2005-07-23 09:38:31 -0400, Thomas Dickey wrote:
> hmm - a quick glance at the code shows this is another of the ones that 
> claim it's xterm-compatible (I see some "xterm" and "vt100" literals). 
> I'd suggest testing that theory with vttest.  The only mention of vttest 
> in the changelog is two years old "largely works".

I tried with tack (I don't have vttest), and IIRC, I found only one
problem. There are also problems with the numeric keypad, and also
the numeric keypad gives unknown escape sequences.

> The source code doesn't contain a terminfo or termcap.  Nor does it 
> contain any real documentation.  Perhaps you can file a bug report against
> iTerm, suggesting that this be provided.

Done.

> "xterm-color" might work for you, but I see no reason to change 
> "xterm-color" to match this - it would then be different from what other 
> people have come to think of as "xterm-color".

Well, http://www.ibb.net/~anne/keyboard.html says that kbs=\177 and
kdch1=\E[3~ are the correct values. And currently xterm-color is
inconsistent with xterm (that has the above values as expected).
And both xterm-xfree86 and xterm-vt220 have kbs=^H, which is
incorrect too.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA


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

Bug#319667: aspell-sv: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-sv
Severity: grave
Version: 0.50-2-4
Tags: sid


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319666: aspell-tl: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-tl
Severity: grave
Version: 0.02-5
Tags: sid

As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.



-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319660: katoob depends on libaspell15 which doesn't exists anymore

[Brian Nelson]

Mohammed Sameer <[EMAIL PROTECTED]> writes:

> On Sat, Jul 23, 2005 at 01:00:31PM -0700, Brian Nelson wrote:
>> tag 319660 pending
>> thanks
>> 
>> On Sat, Jul 23, 2005 at 08:28:59PM +0100, Baruch Even wrote:
>> > katoob depends on libaspell15 which has been replaced with
>> > libaspell15c2. The package needs to be rebuilt to correct this.
>> 
>> Please don't.
>> 
>> I (aspell maintainer) am undoing the libaspell15 transition, so this
>> problem will go away as soon as ftp-master comes back up and I can
>> upload a new package.
>> 
> Allow me to ask a stupid question since I'm still new to all this:
> Is this the gcc 4.0 transition ?

Yes, but libaspell15 doesn't need to undergo the transition since it
only publicly exports a C interface.  Hence, I'm undoing the transition.

See the discussion in this thread for more info:

  http://lists.debian.org/debian-devel/2005/07/msg01019.html

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Bug#319668: aspell-sl: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-sl
Severity: grave
Version: 0.60-2
Tags: sid


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319670: aspell-pt: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-pt
Severity: grave
Version: 0.50-2-4
Tags: sid


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319675: aspell-de: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-de
Version: 0.60-20030222-1-3
Severity: grave
Tags: sid


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages aspell-de depends on:
ii  dictionaries-common   0.49.2 Common utilities for spelling dict
ii  libaspell15   0.60.3-4   GNU Aspell spell-checker runtime l

aspell-de recommends no packages.


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

Bug#319676: aspell-bg: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-bg
Severity: grave
Version: 3.0-4
Tags: sid


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#319156: Needs repackaging for latest aspell

[Brian Nelson]

retitle 319156 Needs repackaging for latest aspell
severity 319156 grave
tag 319156 sid
thanks

Here's some additional information regarding the aspell changes:


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


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

Bug#319273: popularity-contest: should be able to send copies to From address

[Ulf Harnhammar]

On Sat, Jul 23, 2005 at 10:02:39PM +0200, Petter Reinholdtsen wrote:
> Why do you make it so complex?  I would believe it was sufficient to
> add this line to /etc/popularity-contest.conf if you wanted to send
> email both to the normal MAILTO address and the MAILFROM address.
>   MAILTO="$MAILTO,$MAILFROM"

Using that method, both addresses will be included in the "To:" header 
of the e-mails that are sent. I was afraid that the receiving script on
the other side would not like that. Perhaps I was wrong.

> I am not convinced that your need should be a separate configuration
> option.  This is partly influenced by the fact that we are moving
> towards HTTP submissions to make sure more machines can participate.

Fair enough.

> >   popularity-contest/use-http: true
> >  ^^  (huh? a bug??)
> 
> Why do you believe it is a bug?  We just added support for HTTP post
> submissions.

Here is my /usr/share/popularity-contest/default.conf:


# Default config file for Debian's popularity-contest package.
#
# Local overrides are in /etc/popularity-contest.conf

# PARTICIPATE can be one of "yes" or "no".
# If you don't want to participate in the contest, say "no"
# and we won't send messages.
#
# If this option is missing, the default is "no".
#
PARTICIPATE="no"

# MAILTO specifies the address to e-mail statistics to each week.
#
MAILTO="[EMAIL PROTECTED]"

# MAILFROM is the forged sender email address you want to use in
# email submitted to the popularity-contest.  If this is commented
# out, no From: or Sender: lines will be added to the outgoing mail,
# and it will be your MTA's job to add them.  This is usually what
# you want.
#
# If your MTA is misconfigured or impossible to configure correctly,
# and it always generates invalid From: and/or Sender: lines, you
# can force different results by setting MAILFROM here.  This can
# cause problems with spam bouncers, so most people should leave it
# commented out.
#
#MAILFROM="[EMAIL PROTECTED]"

# SUBMITURLS is a space separated list of where to submit
# popularity-contest reports using http.
SUBMITURLS="http://popcon.debian.org/cgi-bin/popcon.cgi";

# USEHTTP enables http reporting.   Set this to 'yes' to enable it.
USEHTTP="no"

# MY_HOSTID is a secret number that the popularity-contest receiver
# uses to keep track of your submissions.  Whenever you send in a
# new entry, it overwrites the last one that had the same HOSTID.
#
# This key was generated automatically so you should normally just
# leave it alone.
#
#MY_HOSTID="_ID_"


And here is my /etc/popularity-contest.conf:


# Config file for Debian's popularity-contest package.
#
# To change this file, use:
#dpkg-reconfigure popularity-contest
#
# You can also edit it by hand, if you so choose.
#
# See /usr/share/popularity-contest/default.conf for more info
# on the options.

MY_HOSTID=[[censorship]]
PARTICIPATE="yes"
MAILFROM="[EMAIL PROTECTED]"
USEHTTP="no"
COPYTOFROMADDRESS="yes"


As you can see, both files say USEHTTP="no", so the "use-http: true" 
data in reportbug looks a bit weird.

// Ulf



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

Bug#319554: ncurses-base: xterm-color terminfo should have kdch1=\E[3~

[Thomas Dickey]

On Sun, 24 Jul 2005, Vincent Lefevre wrote:


On 2005-07-23 09:38:31 -0400, Thomas Dickey wrote:

hmm - a quick glance at the code shows this is another of the ones that
claim it's xterm-compatible (I see some "xterm" and "vt100" literals).
I'd suggest testing that theory with vttest.  The only mention of vttest
in the changelog is two years old "largely works".


I tried with tack (I don't have vttest), and IIRC, I found only one
problem. There are also problems with the numeric keypad, and also
the numeric keypad gives unknown escape sequences.


The source code doesn't contain a terminfo or termcap.  Nor does it
contain any real documentation.  Perhaps you can file a bug report against
iTerm, suggesting that this be provided.


Done.


;-)


"xterm-color" might work for you, but I see no reason to change
"xterm-color" to match this - it would then be different from what other
people have come to think of as "xterm-color".


Well, http://www.ibb.net/~anne/keyboard.html says that kbs=\177 and


Sure enough - on the internet you can find text to support any argument.
(I don't regard that one as authoritative - just a nuisance).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


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

Bug#319619: Needs repackaging for latest aspell

[Brian Nelson]

retitle 319619 Needs repackaging for latest aspell
severity 319619 grave
tag 319619 sid
thanks

Here's some additional information regarding the aspell changes:


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


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

Bug#319660: katoob depends on libaspell15 which doesn't exists anymore

[Mohammed Sameer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jul 23, 2005 at 01:00:31PM -0700, Brian Nelson wrote:
> tag 319660 pending
> thanks
> 
> On Sat, Jul 23, 2005 at 08:28:59PM +0100, Baruch Even wrote:
> > katoob depends on libaspell15 which has been replaced with
> > libaspell15c2. The package needs to be rebuilt to correct this.
> 
> Please don't.
> 
> I (aspell maintainer) am undoing the libaspell15 transition, so this
> problem will go away as soon as ftp-master comes back up and I can
> upload a new package.
> 
Allow me to ask a stupid question since I'm still new to all this:
Is this the gcc 4.0 transition ?


- -- 
- 
- -- Katoob Main Developer, Arabbix Maintainer.
GNU/Linux registered user #224950
Proud Egyptian GNU/Linux User Group  Admin.
Life powered by Debian, Homepage: www.foolab.org
- --
Don't send me any attachment in Micro$oft (.DOC, .PPT) format please
Read http://www.gnu.org/philosophy/no-word-attachments.html
Preferable attachments: .PDF, .HTML, .TXT
Thanx for adding this text to Your signature
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC4rcgy2aOKaP9DfcRAuslAJ9e1oqK4rkFFgZhiUNuIqmqhBpoGACZAcvs
5/dc9dFzyy8eD1Yd/fOjT1I=
=+XQ9
-END PGP SIGNATURE-


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

Bug#319638: [l10n] Initial Czech translation of trn4 debconf messagesd

[Colin Watson]

tags 319638 pending
thanks

On Sat, Jul 23, 2005 at 06:29:14PM +0200, Miroslav Kure wrote:
> Package: trn4
> Severity: wishlist
> Tags: l10n, patch
> 
> Hi, in attachement there is initial Czech translation (cs.po) of
> trn4 debconf messages, please include it.

Thanks, committed to my repository.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Bug#319567: taking over 2 packages

[Carlo Segre]

Dirk:

I must have missed the message, I will spend some time on it this weekend.

Carlo

On Sat, 23 Jul 2005, Dirk Eddelbuettel wrote:



Perlers,

Following up on this post by Carlo

On 20 June 2005 at 23:39, Carlo Segre wrote:
|
| I have been asked by Dirk Eddelbuetel to have the group adopt two of his
| perl packages.  I have uploaded them to the svn server and they are ready
| for upload.  They both check out lintian clean.
|
| libtk-png-perl
| http://www.cpan.org/modules/by-module/Tk/Tk-PNG-2.005.tar.gz
[...]
| libdbd-odbc-perl
| http://www.cpan.org/modules/by-module/DBD/DBD-ODBC-1.13.tar.gz
|
| Description: Perl5 module for an ODBC driver for DBI
|   This Perl5 module provides DBI (Database independent interface for Perl)
|   connectivity using ODBC (Open DataBase Connectivity).
|
|
| As soon as someone modifies the debian/control file and uploads them, I
| will tag the release.

DBD::ODBC has a FTBFS reported by Matt in #319567 (and also see Steve's
follow-up).  I had emailed across town to Carlo but haven't heard -- he may
be at a conference, or on vacation.  So could someone please make the simple
change, rebuild and upload (once ftp-master is back, of course) ?

Many thanks to all,  Dirk


|
| Thanks,
|
| Carlo
|
|
| --
| Carlo U. Segre -- Professor of Physics
| Associate Dean for Special Projects, Graduate College
| Illinois Institute of Technology
| Voice: 312.567.3498Fax: 312.567.3494
| [EMAIL PROTECTED]http://www.iit.edu/~segre




--
Carlo U. Segre -- Professor of Physics
Associate Dean for Special Projects, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
[EMAIL PROTECTED]http://www.iit.edu/~segre


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

Bug#318816: Needs repackaging for latest aspell

[Brian Nelson]

retitle 318816 Needs repackaging for latest aspell
severity 318816 grave
tag 318816 sid
thanks

Here's some additional information regarding the aspell changes:


As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


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

Bug#319661: note

[Joey Hess]

Note that this is fixed in the new upsteam release by Nico at


-- 
see shy jo


signature.asc
Description: Digital signature

Bug#319665: aspell-no: Needs repackaging for latest aspell

[Brian Nelson]

Package: aspell-no
Severity: grave
Version: 2.0-20
Tags: sid

As of the aspell 0.60.3-2 package, I changed the location in which
aspell looks for dictionaries from /usr/lib/aspell-0.60 to
/usr/lib/aspell (for support for autobuilding dictionary hashes).
Obviously, this broke all existing dictionaries so I made it conflict
with dictionaries providing aspell6-dictionary.

Additionally, as of version 0.60.3-3 in conjunction with
dictionaries-common >= 0.49.2, aspell now fully supports building
dictionary hashes at install time.  This provides two huge advantages
over packaging the hashes in the .deb:

1. The dictionary packages may be Arch: all, which for some dictionaries
   provides a significant relief to the mirrors.

2. The hashes will be automatically rebuilt for new aspell versions if
   the dictionary format changes, eliminating the need to transition all
   dictionary packages.

Consequently, this is now the preferred method for packaging aspell
dictionaries.


Packaging dictionaries for aspell >= 0.60.3-3
-

[Old-style hashes (.rws files) in .deb]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell6a-dictionary"

2. Ensure dictionary files are installed to /usr/lib/aspell

3. Remove any dependency on libaspell15 (see #310590) or aspell-bin
   (which no longer exists).  Instead depend on aspell (>= 0.60.3-2).


[New-style autobuilt hashes]

1. Change "Provides: aspell6-dictionary" to "Provides:
   aspell-dictionary" (no version in name).

2. Remove build-dependency on aspell(-bin)

3. Change Architecture to "all"

4. Add binary package dependency on "aspell (>= 0.60.3-3)"

5. Remove any relationship on libaspell15 or aspell-bin

6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where
   $DICT_LANG is the iso code for the dictionary, e.g. "en")

7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to
   /usr/share/aspell.

8. For each of the above wordlists:

   a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where
  $WORDLIST is the wordlist filename minus the .*wl.gz extension)

   b. Add a symlink /usr/lib/aspell/$WORDLIST.rws ->
  /var/lib/aspell/$WORDLIST.rws

   c. Append the $WORDLIST to the file
  "/usr/share/aspell/$DICT_LANG/.contents".  The .contents file
  should contain one $WORDLIST per line.

9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the
   easiest way to do this is to build-depend on dictionaries-common-dev
   (>= 0.9.1) and run installdeb-aspell from debian/rules.

For some examples, see aspell-en (for dictionaries based on
ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for
dictionaries based on plain wordlists).

If the dictionary is packaged correctly, you should see something like:

Setting up aspell-en (6.0-0-5) ...
aspell-autobuildhash: processing: en [en-common]
aspell-autobuildhash: processing: en [en-variant_0]
aspell-autobuildhash: processing: en [en-variant_1]
aspell-autobuildhash: processing: en [en-variant_2]
aspell-autobuildhash: processing: en [en_CA-w_accents-only]
aspell-autobuildhash: processing: en [en_CA-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only]
aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only]
aspell-autobuildhash: processing: en [en_US-w_accents-only]
aspell-autobuildhash: processing: en [en_US-wo_accents-only]

when installing.  The dictionary should then work the same as before.


Please send any questions to the [EMAIL PROTECTED]
mailing list.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Bug#317388: logwatch: Unmatched entries in Postfix section

[Willi Mann]

Dustin Huptas schrieb:

Hi Willi,

sorry for the late feedback, here are the corresponding log lines:

Jul  4 13:04:04 saturn postfix/smtpd[22767]: NOQUEUE: reject_warning:RCPT from host[x.x.x.x]: 450 
<[EMAIL PROTECTED]>: Sender address rejected: Domain not found; from=<[EMAIL PROTECTED]> 
to=<[EMAIL PROTECTED]> proto=ESMTP helo=
Jul  4 13:04:37 saturn postfix/smtpd[22767]: NOQUEUE: reject: RCPT from host[x.x.x.x]: 450 <[EMAIL 
PROTECTED]>: Sender address rejected: Domain not found; from=<[EMAIL PROTECTED]> to=<[EMAIL 
PROTECTED]> proto=ESMTP helo=

You are absolutely right, the reject_warning log line is always written
together with the reject log line.


Hi Dustin!

The manpage of says:


postconf.5

   warn_if_reject
   Change  the meaning of the next restriction, so that it logs a 
warning instead of rejecting a request (look for logfile records that
   contain "reject_warning"). This is useful for testing new restrictions in a "live" environment without risking unnecessary loss of mail. 


This description suggests that you get the reject_warning and reject because 
you have two rules, one with warn_if_reject and one without. Can you confirm 
 that?


What confused me was that you said "...is always written together...", which 
would mean we should ignore reject_warning lines. However, it looks like we 
need to parse them all, to be fully reliable.


Willi


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

Bug#319657: Cloning, reassigning to kernel-package, tagging pending

[Jurij Smakov]

clone 319657 -1
reassign -1 kernel-package
tags -1 pending
tags 319657 pending
thanks

Hi,

This is bug in kernel-package, maintainer is aware of the problem and will 
upload a fixed version (9.004) as soon as the ftp-master is functional 
again (Monday, at the latest). We'll have to re-upload the kernel images 
once it's done, so I am cloning the bug and leaving it open against 
linux-image as well.


Best regards,

Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/   KeyID: C99E03CC


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

Bug#319567: taking over 2 packages

[Dirk Eddelbuettel]

(reposting, this time with valid recipients. Sorry for the dupes --edd)

Perlers,

Following up on this post by Carlo 

On 20 June 2005 at 23:39, Carlo Segre wrote:
| 
| I have been asked by Dirk Eddelbuetel to have the group adopt two of his 
| perl packages.  I have uploaded them to the svn server and they are ready 
| for upload.  They both check out lintian clean.
| 
| libtk-png-perl
| http://www.cpan.org/modules/by-module/Tk/Tk-PNG-2.005.tar.gz
[...]
| libdbd-odbc-perl
| http://www.cpan.org/modules/by-module/DBD/DBD-ODBC-1.13.tar.gz
| 
| Description: Perl5 module for an ODBC driver for DBI
|   This Perl5 module provides DBI (Database independent interface for Perl)
|   connectivity using ODBC (Open DataBase Connectivity).
| 
| 
| As soon as someone modifies the debian/control file and uploads them, I 
| will tag the release.

DBD::ODBC has a FTBFS reported by Matt in #319567 (and also see Steve's
follow-up).  I had emailed across town to Carlo but haven't heard -- he may
be at a conference, or on vacation.  So could someone please make the simple
change, rebuild and upload (once ftp-master is back, of course) ?

Many thanks to all,  Dirk


| 
| Thanks,
| 
| Carlo
| 
| 
| -- 
| Carlo U. Segre -- Professor of Physics
| Associate Dean for Special Projects, Graduate College
| Illinois Institute of Technology
| Voice: 312.567.3498Fax: 312.567.3494
| [EMAIL PROTECTED]http://www.iit.edu/~segre


-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
 -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'


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

Bug#319663: mirror: creates a dir instead of a symlink

[Baurzhan Ismagulov]

Package: mirror
Version: 2.9-52
Severity: normal


Hello Ian,

given the following mirror file:

package=denx
site=ftp.denx.de
remote_dir=/pub
local_dir=denx
passive_ftp=true
recursive=true

, mirror creates the directory denx/LinuxPPC/usr/src/RTAI, mirrors it,
and complains afterwards:

package=denx ftp.denx.de:/pub -> denx
No files to transfer
rmdir( LinuxPPC/usr/src/RTAI ) before symlink failed: Directory not empty

I'm running mirror on a sarge system with patch 2.5.9-2 and perl 5.8.4-8.

With kind regards,
Baurzhan.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-1-k7
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages mirror depends on:
ii  netbase   4.21   Basic TCP/IP networking system
ii  patch 2.5.4-11   Apply a diff file to an original
ii  perl  5.8.4-8Larry Wall's Practical Extraction 

-- no debconf information


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

Bug#319482: Acknowledgement (mozilla-firefox: Hebrew support doesn't work properly)

[Antony Gelberg]

I have spoken to the author of the patch.  It is not scheduled to enter 
upstream.  He and I are going to undertake this and I shall update this 
bug report with our progress.


Antony


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

Bug#317954: bluefish 1.0-1 depends on the absent in unstable libaspell15

[Brian Nelson]

tag 317954 pending
thanks

On Tue, Jul 12, 2005 at 10:01:10AM -0500, Erick Ivaan Lopez Carreon wrote:
> The following packages have unmet dependencies:
>   bluefish: Depends: libaspell15 (>= 0.60) but it is not installable
> E: Broken packages
> 
> 
> And in accordance with the list of packages:
> Package libaspell15
>   * stable (libs): The GNU Aspell spell-checker runtime toolkits 
> 0.60.2+20050121-2: alpha amd64 arm hppa i386 ia64 m68k mips
> mipsel powerpc s390 sparc
>   * testing (libs): The GNU Aspell spell-checker runtime toolkits 
> 0.60.2+20050121-3: alpha amd64 arm hppa i386 ia64 m68k mips
> mipsel powerpc s390 sparc
> Package libaspell15c2
>   * unstable (libs): The GNU Aspell spell-checker runtime toolkits 
> 0.60.3-3: arm hppa i386 m68k mips mipsel powerpc s390 sparc

I (aspell maintainer) am undoing the libaspell15 transition, so this
problem will go away as soon as ftp-master comes back up and I can
upload a new package.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Bug#317388: [Logwatch-Devel] fwd: Re: Bug#317388: logwatch: Unmatched entries in Postfix section

[Who Knows]

Willi Mann wrote:

But you didn't find out out whether the reject_warning line is 
redundant and what's the difference between the two. Before anyone can 
seriously apply the patch, we need to know that. Of course, from the 
original report, it's very likely that it's another line which would 
be what you intended in your patch, because of the "big" difference in 
the two reporting dates (33 secs), but I don't know that for sure.


Okay, I accept my chastisement graciously. From the latest postfix 
manpage for postconf.5


   warn_if_reject
   Change  the meaning of the next restriction, so that it 
logs a warning instead of rejecting a request (look for logfile records that
   contain "reject_warning"). This is useful for testing 
new restrictions in a "live" environment without risking unnecessary 
loss of mail.


Which basically means the person who configured postfix, didn't want to 
REALLY reject a message for some  specific reason, however they did want 
to be warned that a message would have matched the rejection criteria. 
Therefore as far as logwatch is concerned there seems to be 3 options:


1. ignore reject_warning
2. add additional logic in every instance a reject_warning might appear 
and differentiate between rejects and warnings
3. leave it as is to print in the unmatched section, leaving it up to 
the configurator to remove the warn_if_reject qualifier if they don't 
want to see the warnings.


And my vote is for # 3 simply due to the amount of effort required to 
implement #2 which would be in my opinion the best choice.



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

Bug#319661: sgid games program can write to any file writable by games group

[Joey Hess]

Package: xemeraldia
Version: 0.3-29
Severity: grave
Tags: security

In the progress of removing the sgid bit from xemeraldia as a routing
preventative measure, I noticed that Xemeraldia's score file is
controlled by an X resource. Therefore, it can trivially be used to
overwrite any file on the system that can be written to by group games.

[EMAIL PROTECTED]:~>xrdb -merge
XEmeraldia*ScoreFile: /var/games/xjewel.scores

Now just run xemeraldia, lose a game, and the xjewel score file is
replaced by an xemaraldia score file. 

It's also possible that since this can be used to feed xemeraldia
arbitrary data files, that this could be used to crash it, which would
obtain a shell owned by group games. I have not attempted this exploit.

Note that xemeraldia's own Imakefile does not install it sgid or suid to
anything, so this bug can only be exploited on systems which override
its default permissions. However, its Imakefile certianly did encourage
making it sgid/suid by setting the score file location to /usr/local/lib,
and I expect most system install it sgid. The best fix is to make it
write to a per-user score file in a user's home directory and lose the
sgid bit.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#300860: more complete patch for klic

[LaMont Jones]

implicit deps cause problems on 64-bit machines.  The attached patch
makes for far fewer warnings from gcc-4.0, although there are still
several:

  klicdb.c:126: warning: pointer targets in passing argument 1 of 'atoi' differ 
in signedness
  klicdb.c:252: warning: pointer targets in passing argument 1 of 
'enter_functor' differ in signedness
  klicdb.c:254: warning: pointer targets in passing argument 1 of 
'enter_predicate' differ in signedness
  bb.c:231: warning: assignment makes pointer from integer without a cast
  generic.c:243: warning: function definition has qualified void return type
  generic.c:243: warning: function return types not compatible due to 'volatile'
  generic.c:243: warning: function return types not compatible due to 'volatile'
  generic.c:243: warning: function return types not compatible due to 'volatile'
  ggoal.c:81: warning: pointer targets in passing argument 1 of 'strlen' differ 
in signedness
  ggoal.c:91: warning: pointer targets in passing argument 1 of 'strlen' differ 
in signedness
  ggoal.c:228: warning: passing argument 1 of 'find_pred_ent' discards 
qualifiers from pointer target type
  gunix.c:1813: warning: pointer targets in passing argument 3 of 'accept' 
differ in signedness
  gunix.c:1871: warning: pointer targets in passing argument 3 of 'getsockname' 
differ in signedness
  io.c:25: warning: pointer targets in passing argument 2 of 
'__builtin_strncpy' differ in signedness
  faisus.c:173: warning: passing argument 2 of 'do_fail' from incompatible 
pointer type
  debug.c:314:25: warning: trigraph ??/ ignored, use -trigraphs to enable
  faisus-t.c:173: warning: passing argument 2 of 'do_fail' from incompatible 
pointer type
  recsusp.c:66: warning: passing argument 1 of 'hash_pred' discards qualifiers 
from pointer target type
  debug-t.c:314:25: warning: trigraph ??/ ignored, use -trigraphs to enable
  trace.c:292: warning: passing argument 1 of 'enter_pred_hash' discards 
qualifiers from pointer target type
  /build/lamont/klic-3.003/runtime/gunix.c:2543: warning: the use of `mktemp' 
is dangerous, better use `mkstemp'

lamont
diff -ur t/klic-3.003/debian/changelog klic-3.003/debian/changelog
--- t/klic-3.003/debian/changelog   2005-07-23 14:23:00.0 -0600
+++ klic-3.003/debian/changelog 2005-07-23 13:59:07.0 -0600
@@ -1,3 +1,9 @@
+klic (3.003-2ubuntu1) breezy; urgency=low
+
+  * fix compile errors.  Closes: Debian #300860
+
+ -- LaMont Jones <[EMAIL PROTECTED]>  Sat, 23 Jul 2005 13:58:54 -0600
+
 klic (3.003-2) unstable; urgency=low
 
   * Change maintainer address.
diff -ur t/klic-3.003/compiler/klic.c klic-3.003/compiler/klic.c
--- t/klic-3.003/compiler/klic.c1999-03-25 00:33:16.0 -0700
+++ klic-3.003/compiler/klic.c  2005-07-23 14:04:38.0 -0600
@@ -18,6 +18,7 @@
 #ifdef USELOCKF
 #include 
 #endif
+#include 
 
 #define KL1_TO_C_COMPILER   KLIC_COMPILER
 
diff -ur t/klic-3.003/compiler/klicdb.c klic-3.003/compiler/klicdb.c
--- t/klic-3.003/compiler/klicdb.c  1999-03-25 00:33:16.0 -0700
+++ klic-3.003/compiler/klicdb.c2005-07-23 14:04:45.0 -0600
@@ -16,8 +16,7 @@
 #ifdef USELOCKF
 #include 
 #endif
-
-extern void *malloc();
+#include 
 
 char *dbdir = 0;
 char *initdbdir = 0;
diff -ur t/klic-3.003/include/klic/options.h klic-3.003/include/klic/options.h
--- t/klic-3.003/include/klic/options.h 1999-03-25 00:33:22.0 -0700
+++ klic-3.003/include/klic/options.h   2005-07-23 13:58:51.0 -0600
@@ -20,8 +20,6 @@
 ARG_NOT_USED
 };
 
-extern Const struct opttable opttable[];
-
 char *parse_opts();
 
 /* not copied when spawned */
diff -ur t/klic-3.003/runtime/alloc.c klic-3.003/runtime/alloc.c
--- t/klic-3.003/runtime/alloc.c1999-03-25 00:33:32.0 -0700
+++ klic-3.003/runtime/alloc.c  2005-07-23 14:06:08.0 -0600
@@ -7,8 +7,7 @@
 #include 
 #include 
 #include 
-
-extern char *malloc(), *realloc();
+#include 
 
 char *malloc_check(size)
  unsigned long size;
diff -ur t/klic-3.003/runtime/asyncio.c klic-3.003/runtime/asyncio.c
--- t/klic-3.003/runtime/asyncio.c  1999-03-25 00:33:32.0 -0700
+++ klic-3.003/runtime/asyncio.c2005-07-23 14:12:25.0 -0600
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
   void sigio_handler(allocp, sig)
@@ -169,7 +170,6 @@
 init_sigio_handler()
 {
   static sigio_initiated = 0;
-  extern char *malloc();
   int k;
   if (sigio_initiated)
 return;
@@ -246,7 +246,6 @@
 #ifdef USESIG
   static asyncio_initiated = 0;
   if (!asyncio_initiated) {
-extern char *malloc();
 int k;
 
 init_sigio_handler();
diff -ur t/klic-3.003/runtime/debug.c klic-3.003/runtime/debug.c
--- t/klic-3.003/runtime/debug.c1999-03-25 00:33:32.0 -0700
+++ klic-3.003/runtime/debug.c  2005-07-23 14:15:48.0 -0600
@@ -4,6 +4,7 @@
 %   (C)1996, 1997, 1998, 1999 Japan Information Processing Development Center
 %   (Read COPYRIGHT-JIPDEC for detailed information.)
 

Bug#317814: libenchant1 depends on removed libaspell15 package and cannot be installed.

[Brian Nelson]

tag 317814 pending
thanks

On Mon, Jul 11, 2005 at 10:28:44PM +0100, David Ramsden wrote:
> libenchant1 depends on libapsell15 which appears to have been removed
> and replaced with libapsell15c2.
> 
> As a result libenchant1 cannot be installed.
> 
> This stops programs such as abiword from being installed.
> 
> Please update the depends on this package.

I (aspell maintainer) am undoing the libaspell15 transition, so this
problem will go away as soon as ftp-master comes back up and I can
upload a new package.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Bug#318053: python2.3-gnome2-extras: package is uninstallable because it depends on libaspell15

[Brian Nelson]

tag 318053 pending
thanks

On Wed, Jul 13, 2005 at 02:04:24AM -0400, John McCutchan wrote:
> Package depends on libaspell15, which has been replaced by libaspell15c2

I (aspell maintainer) am undoing the libaspell15 transition, so this
problem will go away as soon as ftp-master comes back up and I can
upload a new package.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Bug#319660: katoob depends on libaspell15 which doesn't exists anymore

[Baruch Even]

Brian Nelson wrote:
> On Sat, Jul 23, 2005 at 08:28:59PM +0100, Baruch Even wrote:
> 
>>katoob depends on libaspell15 which has been replaced with
>>libaspell15c2. The package needs to be rebuilt to correct this.
> 
> 
> Please don't.
> 
> I (aspell maintainer) am undoing the libaspell15 transition, so this
> problem will go away as soon as ftp-master comes back up and I can
> upload a new package.

OK. Thanks for the heads up.

Baruch


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

Bug#319657: linux-image-2.6.12-1-686: /vmlinuz and /initrd symlinks were botched after installing 2.6.12

[Frans Pop]

On Saturday 23 July 2005 20:47, Andrew Moise wrote:
>   After installing linux-image, the automatic run of lilo failed.  I
> found that that had been because my /vmlinuz symlink pointed to
> '/boot/-2.6' and my /initrd.img to '/boot/-2.6'.

That should probably be '/boot-2.6' in both cases. At least that what it 
looks like on my system (from linux-image-2.6.12-1-686; 2.6.12-1).

Cheers,
FJP


pgpdFW2PfSR9f.pgp
Description: PGP signature

Bug#318889: sylpheed-claws-gtk2: libaspell15 was changed to libaspell15c2 so it doesn't install

[Brian Nelson]

tag 318889 pending
thanks

On Mon, Jul 18, 2005 at 03:51:51PM +0300, Micha Feigin wrote:
> Debain switch from libaspell15 to libaspell15c2 which requires a rebuild
> of the package. After that it works fine. Without it, it won't install
 
I (aspell maintainer) am undoing the libaspell15 transition, so this
problem will go away as soon as ftp-master comes back up and I can
upload a new package.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Bug#319486: Installation on Sony Vaio VGN-A417M

[Iain Georgeson]

"Frans Pop" <[EMAIL PROTECTED]> writes:
> What you need to do is manually install the 2.6.11 kernel and make sure a 
> new initrd is created for that and your bootloader is configured for it.
> To install the new kernel you can use the rescue mode of the installer 
> (boot 'rescue').

OK, thanks for that. The machine's at work ATM, so I'll get onto it on
Monday.

Iain.



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

Bug#319657: linux-image-2.6.12-1-686: /vmlinuz and /initrd symlinks were botched after installing 2.6.12

[Andrew Moise]

  Just to be clear, regardless of what it _should_ be, it's definitely
not correct on my system:

[EMAIL PROTECTED] ~]$ ls -l /vmlinuz
lrwxrwxrwx  1 root root 10 2005-07-23 09:56 /vmlinuz -> /boot/-2.6
[EMAIL PROTECTED] ~]$ ls -l /initrd.img
lrwxrwxrwx  1 root root 10 2005-07-23 09:56 /initrd.img -> /boot/-2.6
[EMAIL PROTECTED] ~]$ ls -l /boot-2.6
ls: /boot-2.6: No such file or directory

  ... and, of course:

[EMAIL PROTECTED] ~]$ ls -l /boot/-2.6
ls: /boot/-2.6: No such file or directory

-- 
Andrew Moise <[EMAIL PROTECTED]>



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

Bug#319660: katoob depends on libaspell15 which doesn't exists anymore

[Brian Nelson]

tag 319660 pending
thanks

On Sat, Jul 23, 2005 at 08:28:59PM +0100, Baruch Even wrote:
> katoob depends on libaspell15 which has been replaced with
> libaspell15c2. The package needs to be rebuilt to correct this.

Please don't.

I (aspell maintainer) am undoing the libaspell15 transition, so this
problem will go away as soon as ftp-master comes back up and I can
upload a new package.

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Bug#319659: nautilus-cd-burner: Fails to rewrite DVD-RW

[Brett Smith]

Package: nautilus-cd-burner
Version: 2.10.2-1
Severity: normal

I have an AMD64 system with a Plextor PX-712A CD-RW and DVD-/+RW SATA
optical drive.  I've engaged in a bit of kernel trickery to get this drive
working; I've written more about that if it helps:

  http://www.brettcsmith.org/wiki/wiki.cgi?OzyComputer/SATAOpticalDrive

I'm using Samsung DVD-RW 4.7GB Rerecordable single-sided discs.

I have been able to use nautilus-cd-burner to write to these DVDs once,
when they're blank.  After I've written to them, however, I can't rewrite
them.

After I choose "Write to disc" I select all the same options I did when I
originally wrote the discs: using the same drive, at a 1x write speed.
nautilus-cd-burner creates an .iso image for the new disc without incident.
There are no prompts, and no errors show up in dmesg.  After it finishes
that, it asks me: "The inserted disc was already written to.  Do you want
to insert another disc, or erase this one?"  I click the "Erase this disc"
button.

The progress dialog says "Preparing to write DVD" for a moment.  Then it
brings up an error dialog: "There was an error when writing to the CD."
When I ask it for the detailed error message, it displays:

   WARNING: /dev/scd0 already carries isofs!
   /dev/scd0: FEATURE 21h is not on, engaging DAO...
   :-[ PERFORM OPC failed with SK=5h/ASC=2Ch/ACQ=00h]: Input/output error

An error message has shown up in dmesg as well:

   Assertion failed! qc->flags &
   ATA_QCFLAG_ACTIVE,drivers/scsi/libata-core.c,atapi_packet_task,line=3584

This error is repeated a second time.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.3-1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages nautilus-cd-burner depends on:
ii  cdrecord  4:2.01+01a01-4 command line CD writing tool
ii  libart-2.0-2  2.3.17-1   Library of functions for 2D graphi
ii  libatk1.0-0   1.10.1-2   The ATK accessibility toolkit
ii  libbonobo2-0  2.10.0-1   Bonobo CORBA interfaces library
ii  libbonoboui2-02.10.0-1   The Bonobo UI library
ii  libc6 2.3.2.ds1-22   GNU C Library: Shared libraries an
ii  libeel2-2 2.10.1-2   Eazel Extensions Library (for GNOM
ii  libgail-common1.8.4-1GNOME Accessibility Implementation
ii  libgail17 1.8.4-1GNOME Accessibility Implementation
ii  libgconf2-4   2.10.1-1   GNOME configuration database syste
ii  libglade2-0   1:2.5.1-2  library to load .glade files at ru
ii  libglib2.0-0  2.6.5-1The GLib library of C routines
ii  libgnome2-0   2.10.1-1   The GNOME 2 library - runtime file
ii  libgnomecanvas2-0 2.10.2-2   A powerful object-oriented display
ii  libgnomeui-0  2.10.1-1   The GNOME 2 libraries (User Interf
ii  libgnomevfs2-02.10.1-5   The GNOME virtual file-system libr
ii  libgtk2.0-0   2.6.8-1The GTK+ graphical user interface 
ii  libice6   6.8.2.dfsg.1-4 Inter-Client Exchange library
ii  libnautilus-burn1 2.10.2-1   Nautilus Burn Library - runtime ve
ii  libnautilus-extension12.10.1-3   libraries for nautilus components 
ii  liborbit2 1:2.12.2-1 libraries for ORBit2 - a CORBA ORB
ii  libpango1.0-0 1.8.1-1Layout and rendering of internatio
ii  libpopt0  1.7-5  lib for parsing cmdline parameters
ii  libsm66.8.2.dfsg.1-4 X Window System Session Management
ii  libxml2   2.6.20-1   GNOME XML library
ii  mkisofs   4:2.01+01a01-4 Creates ISO-9660 CD-ROM filesystem
ii  xlibs 6.8.2.dfsg.1-4 X Window System client libraries m
ii  zlib1g1:1.2.3-1  compression library - runtime

Versions of packages nautilus-cd-burner recommends:
ii  dvd+rw-tools   5.21.4.10.8-1 DVD+-RW/R tools

-- no debconf information


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

Bug#318261: nedit: does not start up after installing xserver-xorg (x opcode failure)

[Lars Lindner]

I have exactly the same problem.

Best regards,
Lars



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

Bug#318261: nedit: does not start up after installing xserver-xorg (x opcode failure)

[Lars Lindner]

I also tried nedit-nc which show the same problem.

The 5.5 binary from nedit.org does not have the problem.

Lars



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

Bug#319529: tpctl: starting tpctl produces dma errors

[Sanjoy Mahajan]

The laptop is a TP 600X (2645-9FU).

> Is tpctl still useful to you?

I haven't used it in many months.  I last used it to set
power-management features such as what happens when the lid is opened
or closed.  But that was back when I used APM for power management (in
my TP 560{,X} days and when I first got the 600X).  I've now fixed the
600X's DSDT enough to make ACPI usable, and the ACPI kernel support
has improved greatly.  Suspending and hibernating don't work as well
as with APM, but they are 75% of the way there, and the fan behaves
sensibly with ACPI.  I'm very happy about the (lack of) fan noise.  

Since the power-management controls are now (or will be) handled by
ACPI, I hardly use tpctl.  But don't get me wrong, it has been a very
useful tool.

I'm still not sure whether the dma issue is caused by tpctl, or
whether tpctl just happens to trigger an underlying issue in the dma
code.

-Sanjoy


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

Bug#319660: katoob depends on libaspell15 which doesn't exists anymore

[Baruch Even]

Package: katoob
Version: 0.3.8-1
Severity: grave

katoob depends on libaspell15 which has been replaced with
libaspell15c2. The package needs to be rebuilt to correct this.



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

Bug#186739: SSL-POP3 closes connection when feeding to local SMTP takes too long -> fetchmail dies with signal 13

[Matthias Andree]

Ralf,

Please retry with fetchmail-6.2.5 and state whether 6.2.5
still shows this problem or fixes it.


Thank you.

-- 
Matthias Andree


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

Bug#312902: Missing UTF-8 locales

[GOTO Masanori]

tags 312902 fixed-upstream
thanks

At Sat, 11 Jun 2005 00:36:58 +0200,
Denis Barbier wrote:
> > It would be great if all our locales support UTF-8 for etch.  I'm
> > not familiar with glibc locale data, but if there's any grunt
> > work I can do to help with this, I'm very willing to assist.
> 
> Hi,
> 
> FWIW all locales except uz_UZ have been fixed upstream in CVS, but I
> did not check whether some of these locales are added by Debian.

I've checked and all localedata is available in SUPPORTED with the
current 2.3.5-3 development in svn - it'll be OK when 2.3.5 is into
unstable.

Regards,
-- gotom



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

Bug#319489: Buffer overflow in Description parsing

[Kevin Dwyer]

On Sat, Jul 23, 2005 at 01:56:00PM -0400, Anthony DeRobertis wrote:
> Kevin Dwyer wrote:
> 
> > - while (*scratch != '\n') {
> > + while (*scratch != '\n' && idx < sizeof Description) {
> 
> I strongly suspect that should be sizeof(Description)-1 because you're
> going to NULL-terminate... (didn't go back and look at the code to check
> closely)

Correct.  I just glanced at it and didn't test/commit that change.

-kpd


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

Bug#318934: GNU/kFreeBSD summary

[Robert Millan]

Aurelien has updated some of the patches for -4, so the patchset that we need
to get applied is a bit different.

Ok, this bug log has gone a bit crazy.  Let's summarise to make it clear.

This one is now up-to-date (for -4), thanks to Aurelien:

  http://glibc-bsd.alioth.debian.org/patches/xorg/add_manifest_and_friends.diff

Same as before, just make sure you're using the latest version, always available
from:

  http://glibc-bsd.alioth.debian.org/patches/xorg/misc_fixes_in_debian_dir.diff
  
http://glibc-bsd.alioth.debian.org/patches/xorg/remove_old_gnu-kfreebsd_support.diff
  http://glibc-bsd.alioth.debian.org/patches/xorg/xwrapper_major_number.diff

That's all for now, thank you!

-- 
Robert Millan


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

Bug#237907: xemacs segfaults when replying to messages in Gnus

[Shyamal Prasad]

Hi,

I tried contact the bug submitter in Nov 2004 to see if it was still
occuring and have not received a reply yet.

I use Gnus as my primary (only) MUA and have never had this problem,
and certainly not with the version in sarge.

I think you should close this bug or reduce severity and mark as
irreproducible. 

Best regards,
Shyamal


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

Bug#319524: please allow DHCP server to specify default archive mirror

[Joey Hess]

Phil Blundell wrote:
> You're right that a preseed file would also allow me to set the mirror
> location during install, but that would be slightly more cumbersome from
> my point of view.  I don't really want to get into building customised
> CD images, so in order to make it "just work" without manual
> intervention there would need to be a way for clients to automatically
> locate the preseed file on the server, which I think would again come
> down to a DHCP option.

I've wanted for a while a way to let dhcp servers broadcast a preseed
file (either content or url). If you can point me at a way to make a
dhcp server do that and show me what it looks like to a dhcp client,
then the rest of the peices should be very easy to put together.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#319657: linux-image-2.6.12-1-686: /vmlinuz and /initrd symlinks were botched after installing 2.6.12

[Andrew Moise]

Package: linux-image-2.6.12-1-686
Version: 2.6.12-1
Severity: normal

  After installing linux-image, the automatic run of lilo failed.  I
found that that had been because my /vmlinuz symlink pointed to
'/boot/-2.6' and my /initrd.img to '/boot/-2.6'.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-- no debconf information


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

Bug#319136: [Pkg-shadow-devel] Bug#319136: passwd: config script silently fails if invalid group file is present

[Alexander Gattin]

> On Fri, Jul 22, 2005 at 07:48:08AM +0200, Marc Haber wrote:
> > if ! shadowconfig bla; then
> >   echo >&2 "ERR: shadowconfig failed"
> >   exit 1
> > fi
> >
> > Having the -e trip is something to be avoided.
> 
> In order for the above code to work, you mean?

Oops, now I see -- you mean "-e trip" should be avoided
with a code like the above. AFAIU, you meant "silent
-e trip", didn't you?

Usually "-e trip" itself is recommended by Debian
policy (6.1, 10.4), that's why I was confused about
your sentence. And, also, english is not my native
language.
-- 
WBR,
xrgtn


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

Bug#312415: fetchmail: does not implement IMAP correctly

[Matthias Andree]

Please provide more details, for instance, the fetchmail -vv output and
the message that was received with the extra parenthesis.

-- 
Matthias Andree


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

Bug#314408: libc6: Fix pthread_rwlock_wrlock hang with nptl

[GOTO Masanori]

tags 314408 fixed-upstream
thanks

At Fri, 24 Jun 2005 03:58:02 -0700,
Steve Langasek wrote:
> Given that this bug is specific to amd64, it is not actually a
> release-critical bug for Debian (yet); there's no sense in letting this bug
> block glibc updates from reaching testing when amd64 isn't even in the
> archive...
> 
> Does http://sources.redhat.com/ml/libc-hacker/2004-02/msg00022.html suggest
> that the fix is already included in glibc 2.3.5?

Thanks for your checks - looking through the bug report, it's already
fixed in the recent glibc.  I marked as fixed-upstream and I expect
it'll be fixed in the next glibc 2.3.5.

Regards,
-- gotom



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

Bug#317082: libc6-s390x: missing depends on lib64gcc1

[GOTO Masanori]

reassign 317082 dpkg-dev
thanks

Summary:

  The bug submitted in #317082 that requests adding "Depends:
  lib64gcc1" to libc6-s390x on s390.  However the bug submitted in
  #258647 that requests removing "Depends: lib64gcc1" to libc6-sparc64
  on sparc.  Both bugs are conflicted because both libc6-s390x and
  libc6-sparc64 packages are equivalent as 64bit libc6 biarch package.

  I decided to remove "Depends: lib64gcc1" from libc6 which explains
  below.  This bug should be fixed as dpkg-dev's dpkg-shlibdeps
  handles 64 bit libraries like dpkg-cross' dpkg-shlibdeps does.

  Debian sparc and s390 people, from glibc 2.3.5-2 and until
  dpkg-shlibdeps supports 64bit libraries correctly, when you install
  biarch 64 bit binary packages, you may have some problems: installed
  binaries can't resolve 64bit libraries.  In that case, please
  install such libraries packages manually.


At Thu, 14 Jul 2005 15:26:58 +0900,
GOTO Masanori wrote:
> At Tue, 12 Jul 2005 19:44:11 +0200,
> Matthias Klose wrote:
> > GOTO Masanori writes:
> > > At Tue, 05 Jul 2005 20:09:59 -0700,
> > > Ryan Murray wrote:
> > > > libc6-s390x is missing a depends on lib64gcc1 that causes gcc to fail 
> > > > to link
> > > > when -m64 is used on an s390 system.
> > > >
> > > > I'm filling the bug here rather than on the gcc-VERSION packages 
> > > > because the
> > > > sparc64 packages have the dependency in libc6-sparc64, and not the gcc
> > > > packages.
> > > 
> > > According to #258647, the latest glibc.deb in svn already removed the
> > > "Depends: lib64gcc1" entry.  So I think it should be fixed in gcc
> > > packages instead of libc6-s390x.  How about this idea?
> > 
> > I don't know of a good way to handle the 64bit dependencies. We do not
> > want to unconditionally depend on the non-default biarch packages.
> > dh_shlibdeps doesn't work for 64bit packages, so you have to hand-code
> > all the dependencies ...
> >
> > maybe dpkg-shlibdeps could use objdump -x instead of ldd to determine
> > the needed library dependencies?
> 
> I tested this problem on sparc64, dpkg-shlibdeps detects lib64gcc1 -
> even if libc6 does not depend on it.

The actual concern suggested by Matthias was: dpkg-shlibdeps can't
resolve 64 bit libraries when the built environment uses 32 bit
kernel.

The current dpkg-shlibdeps detects dependent libraries using "ldd" and
"objdump".  However "/bin/ldd 64bit-binaries" can't work on 32bit
kernel (it's the correct behavior).  "objdump -p" can't show the
actual path because elf binary has library names, but not library
pathnames.  And dpkg-shlibdeps can't work for 64bit binaries on 32bit
environment.

The current libc6-sparc64 in sarge has "Depends: lib64gcc1".  However
this kind of manual assignment for debian/control file is a bad way.
Why is it "bad"?  Because in future we probably have more biarch
applications (ex: imagine multimedia gnome application that handles
over 4GB video data, and it has a lot of library dependencies), so
manual handling should be dropped.  I removed this dependency from
glibc 2.3.5-2 in experimental.

The correct fix discussed and suggested by Ryan, Daniel and Matthias
was: dpkg-shlibdeps should handle 64bit library dependencies even on
32 bit kernels correctly.  Actually dpkg-shlibsdeps in dpkg-cross
package should have worked nicely because it considers about 64bit
libraries.

BTW, Nikita, dpkg-shlibdeps in dpkg-cross should have additional elf64
entries for ppc64 and amd64 like:

@crosslib64formats = ("elf64-sparc", "elf64-s390", "elf64-x86-64", 
"elf64-powerpc");

Regards,
-- gotom


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

Bug#58992: viper-mode and gnus cause frequent error messages

[Shyamal Prasad]

Hi,

I am not a regular user of viper mode (but actually an avid vi fan
even though I use emacs, so I just use vi when I want those key
bindings ;-).

I have tried using viper mode and gnus together (and I am writing this
email in such a mode) and do not see any problems in sarge.

This bug is over 5 years old, I would strongly suggesting closing it
since the original fault (in post-command-hook) clearly does not exist
anymore.

Best regards,
Shyamal



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

Bug#69594: viper-mode and gnus cause frequent error messages

[Shyamal Prasad]

Hi,

The bug report describes an interaction between tm and gnus. This
fault does not appear in the standard version of gnus shipped in
xemacs21-support in sarge (in fact tm is not loaded by gnus at all). 

I would recommend closing this bug because it was fixed a long time
ago (the bug is nearly 5 years old, if you want me to find more
evidence I can but I can assure you it no longer exists).

Best regards,
Shyamal


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

Bug#319655: debtags: Generates exception when run for first time

[Mark Brown]

Package: debtags
Version: 1.1
Severity: normal

Naively attempting to add tags to one of my packages I invoked debtags
but got an error message as follows:

| ~$ debtags tag add lspowertweak system role::sw-utility
| Warning: Impossible to restore previous backup copy: No such file or 
directory Can't write to /home/broonie/.debtags/patch (SystemException)
| debtags: SystemException: No such file or directory Can't write to 
/home/broonie/.debtags/patch

This is the first time I've invoked the debtags command line program.
There appear to be two problems here: one is that the error message is
a bit obscure, the other is that I would expect debtags to create the
~/.debtags directory if it does not already exist.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.11-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages debtags depends on:
ii  apt [libapt-pkg-libc6.3-5-3 0.6.38   Advanced front-end for dpkg
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1 1:4.0.1-2GCC support library
ii  libstdc++5  1:3.3.6-7The GNU Standard C++ Library v3
ii  libtdb1 1.0.6-13 Trivial Database - shared library
ii  zlib1g  1:1.2.3-1compression library - runtime

debtags recommends no packages.

-- no debconf information


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

Bug#319654: mutt: No way to match on folded header lines.

[Andreas Metzler]

Package: mutt
Version: 1.5.9-2
Severity: wishlist

Hello,
I am currently using this in my muttrc:
-
save-hook '~h ^List-Id:\ .*' 
+exim
-
This worked perfectly well, when the header used was:
List-Id: Reach the exim4 maintainers 


However recently, probably due to a mailman upgrade *folding* is used,
i.e. these lines are inserted:
List-Id: Reach the exim4 maintainers

and my pattern specified above does not match. 

Which leads to my question:

Which pattern will match header X-foo contains bar, even if X-foo is
folded?[1]


 thanks, cu andreas
[1] This
~h ^List-Id: ~h ^\t*
is not good enough, as it will match any mail that contains a List-Id
header and contains 
in *any* folded header line.
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
   http://downhill.aus.cc/


signature.asc
Description: Digital signature

Bug#319656: debtags: Silently fails to add system tag

[Mark Brown]

Package: debtags
Version: 1.1
Severity: normal

Attempting to add the system tag to the package lspowertweak produces
the following results:

| [EMAIL PROTECTED]:~$ debtags tag ls lspowertweak
| hardware::detection
| role::sw-utility
| special::not-yet-tagged
| special::not-yet-tagged::l
| [EMAIL PROTECTED]:~$ debtags tag add lspowertweak system
| [EMAIL PROTECTED]:~$ echo $?
| 0
| [EMAIL PROTECTED]:~$ debtags tag ls lspowertweak
| hardware::detection
| role::sw-utility
| special::not-yet-tagged
| special::not-yet-tagged::l

In other words, I am unable to add the 'system' tag but there is no
indication from the add command that this has happened.  The
hardware::detection and role::sw-utility tags were previously added by
me.

An error should be generated if it is not possible to add a tag for some
reason.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.11-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages debtags depends on:
ii  apt [libapt-pkg-libc6.3-5-3 0.6.38   Advanced front-end for dpkg
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1 1:4.0.1-2GCC support library
ii  libstdc++5  1:3.3.6-7The GNU Standard C++ Library v3
ii  libtdb1 1.0.6-13 Trivial Database - shared library
ii  zlib1g  1:1.2.3-1compression library - runtime

debtags recommends no packages.

-- no debconf information


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

Bug#319653: compilation mode doesn't handle UTF-8 output from subprocesses (by default)

[Daniel Burrows]

Package: emacs21
Version: 21.4a-1
Severity: minor

  Emacs seems to mostly work fine in a UTF-8 environment.  However, there is 
one annoyance.  It appears that g++, in a UTF-8 locale, will output extended 
characters in its error messages.  For instance,

matchers.cc:227: error: request for member ‘c_str’ in ‘s’, which is of 
non-class type ‘const char*’

  In Emacs, though, the high characters are displayed as non-printable ASCII 
characters:

matchers.cc:227: error: request for member \200\230c_str\200\231 in 
\200\230s\200\231, which is of non-class type \200\230const char*\200\231

  Each of the \NNN values is a single character according to Emacs, and when I 
pasted this text directly, those values showed up as individual characters:

matchers.cc:227: error: request for member ‘c_str’ in ‘s’, which is of 
non-class type ‘const char*’

  It looks like maybe I can work around this by fiddling with some options, 
but I don't think that running a compile job from emacs should be broken by 
default.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|   Apostrophes are not a warning that a|
|   word is about to end in an "s". |
\ The Turtle Moves! -- http://www.lspace.org ---/


pgpO6BQdBgcsN.pgp
Description: PGP signature

Bug#319652: failed assertion

[Wichert Akkerman]

Package: slapd
Version: 2.2.23-8

I just get a bunch of these from cron running on haydn:

/home/devel/openldap/build-area/openldap2-2.1.30/libraries/liblber/io.c:702: 
ber_get_next: Assertion `0' failed.

Wichert.

-- 
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.


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

Bug#319376: close bug 319376

[Qingning Huo]

package autoconf-archive
found 319376 20050418-1
close 319376 20050502-1
thanks

This bug has been fixed by upstream version 20050502.

qingning


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

Bug#319154: kdelibs' ftbfs: simple fix

[David Schmitt]

Hello *!


Including  in kdeui/kactioncollection.h fixes this ftbfs, 
though I have not yet tried whether the new packages work and the build 
sports quite a few warnings.


Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15