Bug#292323: jack: Dislikes CD titles with exclamation marks?

[era eriksson]

Package: jack
Version: 3.0.0-9
Severity: normal
Tags: upstream

I'm not overtly certain of this diagnostic, but I happened to have two
Pretenders CD:s with exclamation marks in the title, and both of them
failed with the following error message:

 bash$ jack -Q
 This is  jack 3.0.0 (C) 2003  Arne Zellentin <[EMAIL PROTECTED]>
  *warning* charset has no effect without a char_filter
  *info* querying...
 /home/era/jack/jack-880a980c
 Info: cwd now /home/era/jack/Pretenders/¡Viva el Amor!
 Traceback (most recent call last):
   File "/usr/bin/jack", line 222, in ?
 global_error = jack_main_loop.main_loop(mp3s_todo, wavs_todo, space, 
dae_queue, enc_queue, track1_offset)
   File "/usr/lib/python2.3/site-packages/jack_main_loop.py", line 317, in 
main_loop
 jack_status.enc_stat_upd(num, 'waiting for encoder.')
   File "/usr/lib/python2.3/site-packages/jack_status.py", line 44, in 
enc_stat_upd
 jack_term.tmod.enc_stat_upd(num, string)
   File "/usr/lib/python2.3/site-packages/jack_t_curses.py", line 233, in 
enc_stat_upd
 status_pad.addstr(map_track_num[num], jack_ripstuff.max_name_len + 40, " " 
+ jack_status.enc_status[num])
 curses.error: addstr() returned ERR
  *warning* abnormal exit

 bash$ echo $?
 1

 bash$

(The other one is DISCID=8909170b, DTITLE=Pretenders / Packed!)

Ripping appears to proceed normally, just about up to the point where
you would expect files to be renamed with the freedb info, then it
fails.

Ripping without -q or -Q works fine, then jack -q with the CD still in
the drive also works okay, so there is a workaround (if even my hunch
about what this is happening is correct in the first place. I tested
this with the two CD:s I have, and the tests seemed to bear this out).

/* era */

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-1-686-smp
Locale: LANG=C, LC_CTYPE=C

Versions of packages jack depends on:
ii  cdda2wav 4:2.0+a34-2 Creates WAV files from audio CDs
ii  cdparanoia   3a9.8-11An audio extraction tool for sampl
ii  python   2.3.4-4 An interactive high-level object-o
ii  python-cddb  1.4-3   Python interface to CD-IDs and Fre
ii  python-id3   1.2-6.1 Python module for id3-tags manipul
ii  python-id3lib0.5.1-3 id3lib wrapper for Python - dummy 
ii  python-pyvorbis  1.3-1   A Python interface to the Ogg Vorb
ii  vorbis-tools 1.0.1-1 Several Ogg Vorbis Tools

Bug#292612: jack: Cannot cope with empty title

[era eriksson]

Package: jack
Version: 3.1.1-1
Severity: normal
Tags: upstream

I stumbled over a record which has what appears to be an anonymous
track -- not sure if this is non-audio CD content or what.

DISCID=700fe60a
DTITLE=John Paul Jones / Zooma

 bash$ jack -q
 This is jack 3.1.1 (C)2004 Arne Zellentin <[EMAIL PROTECTED]>
  *warning* config file /etc/jackrc is of unknown version None.
  *info* Track 10 not found by cdparanoia. Treated as non-audio.
  *info* querying...
  *warning* no freedb info for track 10 ("TTITLE9")
  *error* could not read freedb file

(The listing for  calls
this "Data Track". That's an alternate version of this record but the
track lengths are similar enough to make sense.)

FWIW the actual freedb file appears to have transferred correctly into
jack-700fe60a/jack.freedb so I guess the error message actually means
just "parse error" (and reading the file did not actually fail).

/* era */

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-1-686-smp
Locale: LANG=C, LC_CTYPE=C

Versions of packages jack depends on:
ii  cdda2wav 4:2.0+a34-2 Creates WAV files from audio CDs
ii  cdparanoia   3a9.8-11An audio extraction tool for sampl
ii  python   2.3.4-4 An interactive high-level object-o
ii  python-cddb  1.4-3   Python interface to CD-IDs and Fre
ii  python-id3   1.2-6.1 Python module for id3-tags manipul
ii  python-id3lib0.5.1-3 id3lib wrapper for Python - dummy 
ii  python-pyvorbis  1.3-1   A Python interface to the Ogg Vorb
ii  vorbis-tools 1.0.1-1 Several Ogg Vorbis Tools

-- no debconf information



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

Bug#341353: uniq: -t option stopped working

[era eriksson]

Package: coreutils
Version: 5.93-5

Upgrading coreutils yesterday appears to have broken the -t 
option in uniq.

There is no mention of this change in /usr/share/doc/coreutils/NEWS.gz
so I assume (and hope) that this was a mistake and not a conscious
decision. There's a cryptic mention of "--separator" in README.Debian
and a corresponding (but misspelled) note for version 5.93-1 in the
changelog.Debian.gz though.

I'm afraid I don't know exactly which version the previous coreutils
package was (this is not my own system; things like this is one of the
reasons I don't run unstable on production systems).

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#152977: Old bug, suggest closing / wontfixing

[era eriksson]

retitle 152977 w3m-el: Cannot cope with URL #fragments
notfound 152977  1.4.4-1
thanks

Now that Woody is no longer the hot topic of the day, perhaps it would
be appropriate to mark this bug as WONTFIX?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#344015: w3m-el: https auth not supported (?)

[era eriksson]

Package: w3m-el
Version: 1.4.4-1

I'm having trouble logging in to a twiki server which runs over https. I
can access the site fine with just w3m. I can access the same site fine
over plain http with both w3m and w3m-el (albeit the latter with some
difficulty). But with https, w3m-el just seems to try to connect
forever.

I'm not cool enough to give exact steps to repro this, but here's what
the server produces when I connect with openssl s_client -crlf -quiet
-connect localhost:443

HTTP/1.1 401 Authorization Required
Date: Fri, 02 Dec 2005 20:54:47 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) mod_ssl/2.8.22 OpenSSL/0.9.7d
mod_perl/1.29
WWW-Authenticate: Basic realm="Enter your WikiName. Cancel to register
 if you do not have one."
Connection: close
Content-Type: text/html; charset=iso-8859-1



401 Authorization Required

Authorization Required
This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.
Additionally, a 401 Authorization Required
error was encountered while trying to use an ErrorDocument to handle the
request.


Over plain http, the authentication message is printed in the echo area.
I don't get a lot of feedback from what I type, so it's a bit cumbersome
to use, but it works. No such luck with https. I've tried typing in my
user name in the blind, too, but w3m just acts as if I was trying to
type in commands while it's working ("Cannot run two w3m processes
simultaneously" etc).

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#321417: Known issue; patch exists

[era eriksson]

tags 321417 +patch
thanks

This is a known problem in Sawfish. The mail thread
http://thread.gmane.org/gmane.comp.window-managers.sawfish/2737 from the
Sawfish mailing list contains a patch which supposedly fixes the
problem.

See also https://launchpad.net/distros/ubuntu/+source/sawfish/+bug/551

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#304743: bugs.debian.org: pts subscribers get all notices

[era eriksson]

Package: bugs.debian.org
Severity: normal

I can see how this could be considered a feature, at least
occasionally, but since the boilerplate notices contain so little
per-message information, it's usually mostly just annoying that as a
subscriber to [EMAIL PROTECTED] I get the following
three messages:

8k  15 Apr 2:33   Debian Bug Tracking ...  Bug#302468: marked as d...
8k  15 Apr 2:33   Debian Bug Tracking ...  Bug#302442: marked as d...
3k  15 Apr 2:17   Javier Fernandez-San...  Accepted harden-doc 3.2...

 when merely the small one from the package maintainer would be
quite sufficient in any but the most convoluted circumstances (and of
course is included wholesale in the other two in any event).

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#305528: xscreensaver: Stop "thermometer" from sinking when you're typing

[era eriksson]

Package: xscreensaver
Version: 4.16-1
Severity: wishlist
Tags: upstream

I'm sure you must have seen Matthew Thomas "First 48 hours enduring
Ubuntu" and his suggestion to not make the password dialog expire in
the middle of your typing (this is a posting in his blog; the URL is
 but the site is having
some sort of PHP hiccups at the moment so you may be better off
getting it from Google's cache; this is item 31 on his list) but I'd
like to echo his wish here in the form of an actual bug report.

Could the thermometer / fuel gauge start over from the top, and/or
pause when you type or move the mouse?

When you get a phone call in the middle of entering your password, you
might pause for just long enough to be this close -> <- to a timeout,
and rush to type in the last letter, and hit the wrong key, and spill
your coffee all over your keyboard and scare your house animals and
possibly other sentient life forms in your vicinity. It's a drag.
Could it be changed?

Thanks for considering this,

/* era */


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-1-686-smp
Locale: LANG=C, LC_CTYPE=C

Versions of packages xscreensaver depends on:
ii  libatk1.0-0   1.8.0-4The ATK accessibility toolkit
ii  libc6 2.3.2.ds1-18   GNU C Library: Shared libraries an
ii  libglade2-0   1:2.4.0-1  Library to load .glade files at ru
ii  libglib2.0-0  2.6.1-3The GLib library of C routines
ii  libgtk2.0-0   2.4.13-1   The GTK+ graphical user interface 
ii  libice6   4.3.0.dfsg.1-8 Inter-Client Exchange library
ii  libjpeg62 6b-9   The Independent JPEG Group's JPEG 
ii  libpam0g  0.76-22Pluggable Authentication Modules l
ii  libpango1.0-0 1.8.0-3Layout and rendering of internatio
ii  libsm64.3.0.dfsg.1-8 X Window System Session Management
ii  libx11-6  4.3.0.dfsg.1-8 X Window System protocol client li
ii  libxext6  4.3.0.dfsg.1-8 X Window System miscellaneous exte
ii  libxml2   2.6.11-5   GNOME XML library
ii  libxmu6   4.3.0.dfsg.1-8 X Window System miscellaneous util
ii  libxrandr24.3.0.dfsg.1-8 X Window System Resize, Rotate and
ii  libxrender1   0.8.3-7X Rendering Extension client libra
ii  libxt64.3.0.dfsg.1-8 X Toolkit Intrinsics
ii  xlibs 4.3.0.dfsg.1-8 X Window System client libraries m
ii  zlib1g1:1.2.2-1  compression library - runtime

-- no debconf information



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

Bug#305528: xscreensaver: Stop "thermometer" from sinking when you're typing

[era eriksson]

On Wed, 20 Apr 2005 18:09:05 +0300 (EEST), "era eriksson" <[EMAIL PROTECTED]>
said:
> Could the thermometer / fuel gauge start over from the top, and/or
> pause when you type or move the mouse?

Sorry, I realize when reading what I posted that I wasn't very explicit
about the context of this wish. Just in case this wasn't already
completely obvious to everyone who is reading this bug report, this is
for the password dialog you get when attempting to access a screen which
is currently locked by xscreensaver.

Pardon my over-eagerness,

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#305528: xscreensaver: Stop "thermometer" from sinking when you're typing

[era eriksson]

On Sat, 30 Apr 2005 13:59:22 -0700, "Jamie Zawinski" <[EMAIL PROTECTED]> said:
> That's not a bad idea; I've made it add 10% to the time remaining every
> time you type a key.

Thanks. I'm not convinced that's how it should work, though. How about
make it stop sinking for 3 seconds? Or start over from the top? But if
you've already considered these, and think adding 10% (I assume 1/10 of
the full height, not of the remaining height) is the best solution, I'm
not complaining or anything. :-)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#320102: jack: Erratic error messages for fuzzy freedb match

[era eriksson]

On Tue, 26 Jul 2005 23:30:44 +0100, "Martin Michlmayr" <[EMAIL PROTECTED]>
said:
> > > Warning: calculated id (870a660a) and id from freedb file
> > >   : ['870a680a']
> > >   : do not match, hopefully due to inexact match.
> > 
> > Also, if these warnings are really useful in some context, I guess it
> > would be useful to get the id from the actual CD somewhere in the
> > output as well.
> 
> What's listed as "calculated id" is the ID of the CD.  Can you suggest
> better wording to make this clearer?

Sorry, my comment doesn't make any sense to myself anymore ... I guess I
might have missed the difference between the two id:s in the message,
since they are so similar. If they were listed directly on top of each
other, they would be easier to compare at a glance, though -- something
like this perhaps:

Warning: CD signature ID and ID from FreeDB file do not match.
   CD signature: 870a660a
   FreeDB ID:870a680a

Pardon my ignorance if this is hard to do from Python 

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


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

Bug#316482: Lowering priority and retitling -- not really actually broken?

[era eriksson]

severity 316482 normal
retitle 316482 apt-file: jarring 404 warnings from back end should be
hidden from view
thanks

As far as I can tell, the 404 is not actually an error from apt-file's
perspective. It faithfully reports that the file is not available but
it's not a fatal condition at all. To verify, add more servers to the
end of your /etc/apt/sources.list, or reorder the entries you have
there; on my installation, it proceeds past the 404 and tries to fetch
files for the remaining servers just fine.

HOWEVER, I agree that these 404 errors scared me too at first; probably
the back end's output should be hidden from view or filtered somehow
under normal conditions -- the output is only useful for debugging, and
(at least with wget) even then it's painfully verbose.

In any event, it's hardly a problem that apt-file will not be able to
search for matches in security updates; they're bound to contain exactly
the same files as the corresponding packages in the regular archive
except under very special conditions.

Feel free to lower this further down to wishlist priority as far as I'm
concerned.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#320313: apt-file: a way to update without being root

[era eriksson]

Package: apt-file
Version: 2.0.3-7
Severity: wishlist
Tags: patch

I can see how this might be tricky to fix, but it really sucks to have
to be root to do `apt-file update' (or some cheesy workaround, such as
adding a new system group with permission to write to the APT cache).

At a minimum, I think this should be mentioned in the manual (although
anybody moderately Unix-literate can probably figure it out from the
error message you get).

Here's an almost-patch:

 Some actions are required to run the search:
 .TP
 \fBupdate\fR
 Resynchronize the package contents from their sources. The
 contents packages are fetched from the location(s)
 specified in
 \fI/etc/apt/sources.list\fR. This command
 attempt to fetch the
 \fIContents-.gz\fR file from
 remote source.
+\fBNote:\fR You need to have write access
+to the cache directory in order to 
+execute this command.
 .TP
---
 .SH "OPTIONS"
 .TP
 \fB   --cache | -c cache-directory \fR
 Sets the cache directory to
 cache-directory instead of its default
-value (\fI/var/cache/apt\fR) thus you can
-use \fBapt-file\fR even if you do not have
-administrator privileges.
+value (\fI/var/cache/apt\fR).
---
 .SH "BUGS"
 .PP
 cdrom backend haddn't been tested.
 .PP
 Non-release line in sources.list is not handled by apt-file.
 .PP
+It would be nice if normal users could update the
+default cache directory as needed
+without having to become root or some such.
+.PP

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#320318: apt-file: obsolete pointers in README and man page

[era eriksson]

Package: apt-file
Version: 2.0.3-7
Severity: minor

The pointers to sjgross.org are stale and should probably be replaced or
removed.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#320322: apt-file: Errors in manual page

[era eriksson]

Package: apt-file
Version: 2.0.3-7
Severity: minor
Tags: patch

The manual page contains some unintelligible passages. I have tried to
fix the obvious errors, but there a few issues remain:

  * The use of  for parameters. I'm not knowledgeable enough
with DocBook to tell what element should be used instead, but
certainly the items tagged with this element are not literals,
and the formatting in the manual page is not what you want (they
end up as completely innocent words, resulting in gems like "the
pattern pattern" where obviously you'd want one occurrence of
"pattern" to get +some+ sort of markup).

  * The section "String expansion" fails to define some parts of the
parameters listed at the beginning of the section, and on the
other hand explains some parameters which are not referenced
anywhere. For example, where are you supposed to plug in "dest"?
Anyway, perhaps the user should just be directed to the apt
documentation instead?

Please also find below a patch which contains some trivial typo fixes
etc.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

--- apt-file-2.0.3/apt-file.1.sgml.orig	2004-03-15 01:40:39.0 +0200
+++ apt-file-2.0.3/apt-file.1.sgml	2005-07-28 14:38:17.540812320 +0300
@@ -45,12 +45,12 @@
 	
 	  
 	Resynchronize the package contents from their sources. The
-	contents packages are fetched from the location(s)
+	lists of the contents of packages are fetched from the location(s)
 	specified in
 	/etc/apt/sources.list. This command
-	attempt to fetch the
-	Contents-.gz file from
-	remote source.
+	attempts to fetch the
+	Contents-.gz files from
+	remote sources.
 	  
 	
   
@@ -59,8 +59,8 @@
 	search
 	
 	  
-	Search in which package file is included. A list of all
-	package containing the pattern pattern
+	Search in which package a file is included. A list of all
+	packages containing the pattern pattern
 	is returned.
 	  
 	
@@ -169,7 +169,7 @@
 	  
 	  Sets architecture to architecture. This
 	  option is useful if you search a package for a different
-	  architecture the one installed on your system.
+	  architecture from the one installed on your system.
 	  
 	
   
@@ -182,7 +182,7 @@
 	
 	  
 	Sets the sources.list file to a
-	different value its default
+	different value from its default
 	/etc/apt/sources.list.
 	  
 	
@@ -240,8 +240,8 @@
   proxies.
 
 
-  A string expension is done on severa value. See string
-	expension section.
+  A string expension is done on several values. See the string
+	expansion section.
 
 
   
@@ -256,19 +256,19 @@
 	http | ftp | ssh | rsh | file | cdrom
 	
 	  
-	Here are the commands used to fetch files.
+	Define are the commands used to fetch files.
 	  
 	
   
 
 
-  String expension
+  String expansion
   
 	A sources.list entry is defined as:
 	
-	  deb uri dist componant1 componant2 ...
+	  deb uri dist component1 component2 ...
 	
-	an uri, is defined as:
+	A uri is defined as:
 	
 	  proto:/[/][user[:[EMAIL PROTECTED]:port][/path]
 	
@@ -328,7 +328,7 @@
 	  
 	  
 	
-	  replace with destination expended
+	  replace with destination expanded
 	  value.
 	
 	  
@@ -354,14 +354,14 @@
   
 	/etc/apt/sources.list
 	
-	  Locations to fetch packages contents from.
+	  Locations to fetch package contents from.
 	
   
   
 	/etc/apt/apt-file.conf
 	
 	  
-	Configuration file for apt-file.
+	Configuration file for apt-file.
 	  
 	
   
@@ -384,7 +384,7 @@
   
   
 BUGS
-cdrom backend haddn't been tested.
+cdrom backend hadn't been tested.
 
   Non-release line in sources.list is not handled by apt-file.
 

Bug#303346: gdm: Suppresses X logging with "Too much output"

[era eriksson]

Package: gdm
Version: 2.6.0.4-1
Severity: grave
Justification: Discards error output rather than logging as requested

When an X session has been running for a while, I get the message
"...Too much output, ignoring rest..." and then all logging to my
~/.xsession-errors stops.

I googled for this message, and the only relevant hit I got
 suggests
that GDM is responsible for this message.

 defines
MAX_XSESSION_ERROR_BYTES to be 80*2500 -- I guess that's supposed to
be 2500 lines at full width. (My current .xsession-errors which just
got this message is actually 4422 lines, for comparison, but about
half of those are empty, because many programs seem to include a
spurious newline with each message.)

This limitation seems a bit ill-conceived. I can imagine that it might
be useful to limit the output produced by a runaway process in rapid
succession, but it should still be possible to get log messages from a
process which runs for as long as the computer is up; eventually, if
there are no crashes or power failures, it will produce enough log
messages to exceed whatever limit you come up with.

Still, as a workaround, perhaps the Debian package could make the
limit really large.

In the meantime, feel free to tag this as "upstream" and forwarding it
to the Gnome folks.

Ultimately, the limit should probably be configurable at startup time,
with an option to disable it (perhaps by setting the limit to 0 in the
configuration), and documented.

Thanks in advance for your attention to this,

/* era */


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-1-686-smp
Locale: LANG=C, LC_CTYPE=C

Versions of packages gdm depends on:
ii  adduser  3.59Add and remove users and groups
ii  debconf  1.4.30.10   Debian configuration management sy
ii  dpkg 1.10.23 Package maintenance system for Deb
ii  gksu 1.2.2-1 graphical frontend to su
ii  gnome-session2.6.2-6 The GNOME 2 Session Manager
ii  gnome-terminal [x-te 2.6.1-6 The GNOME 2 terminal emulator appl
ii  libart-2.0-2 2.3.16-6Library of functions for 2D graphi
ii  libatk1.0-0  1.8.0-4 The ATK accessibility toolkit
ii  libattr1 2.4.16-1Extended attribute shared library
ii  libaudiofile00.2.6-4 Open-source version of SGI's audio
ii  libbonobo2-0 2.6.2-7 Bonobo CORBA interfaces library
ii  libbonoboui2-0   2.6.1-1 The Bonobo UI library
ii  libbz2-1.0   1.0.2-1 A high-quality block-sorting file 
ii  libc62.3.2.ds1-18GNU C Library: Shared libraries an
ii  libcroco30.6.0-2 a generic Cascading Style Sheet (C
ii  libesd0  0.2.35-2Enlightened Sound Daemon - Shared 
ii  libgconf2-4  2.6.4-2 GNOME configuration database syste
ii  libgcrypt11  1.2.0-4 LGPL Crypto library - runtime libr
ii  libglade2-0  1:2.4.0-1   Library to load .glade files at ru
ii  libglib2.0-0 2.6.1-3 The GLib library of C routines
ii  libgnome-keyring00.2.1-3 GNOME keyring services library
ii  libgnome2-0  2.6.1.2-2   The GNOME 2 library - runtime file
ii  libgnomecanvas2-02.6.1.1-2   A powerful object-oriented display
ii  libgnomeui-0 2.6.1.1cvs-1The GNOME 2 libraries (User Interf
ii  libgnomevfs2-0   2.6.2-2 The GNOME virtual file-system libr
ii  libgnutls11  1.0.16-9GNU TLS library - runtime library
ii  libgpg-error01.0-1   library for common error values an
ii  libgsf-1 1.10.1-1Structured File Library - runtime 
ii  libgtk2.0-0  2.4.13-1The GTK+ graphical user interface 
ii  libice6  4.3.0.dfsg.1-8  Inter-Client Exchange library
ii  libjpeg626b-9The Independent JPEG Group's JPEG 
ii  liborbit21:2.10.2-1.1libraries for ORBit2 - a CORBA ORB
ii  libpam-modules   0.76-22 Pluggable Authentication Modules f
ii  libpam-runtime   0.76-22 Runtime support for the PAM librar
ii  libpam0g 0.76-22 Pluggable Authentication Modules l
ii  libpango1.0-01.8.0-3 Layout and rendering of internatio
ii  libpopt0 1.7-5   lib for parsing cmdline parameters
ii  librsvg2-2   2.8.1-1 SAX-based renderer library for SVG
ii  libselinux1  1.16-2  SELinux shared libraries
ii  libsm6   4.3.0.dfsg.1-8  X Window System Session Management
ii  libt

Bug#295300: Un-localizing error message and subject

[era eriksson]

retitle 295300 gdm: gdm_slave_xioerror_handler|: Fatal X error - Restarting :0
thanks

As per 
the error message is a translation of "Fatal X error - Restarting %s"
(where in this case apparently %s expands to ":0").

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#257010: submitter address changed (Reopen 257010)

[era eriksson]

 > Submitter changed because the original submitter didn't
 > appear to care (didn't reopen the bug)

I haven't had the time to check out the new skin. But be my guest.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#233214: found, tags upstream patch, retitle 233214 perlcall(1) incorrectly refers to "X windows"

[era eriksson]

found 233214 5.8.7-4
tags 233214 upstream patch
retitle 233214 perlcall(1) incorrectly refers to "X windows"
thanks

The simple patch would be to simply talk about "X" or "X11" pro "X
windows", as the meaning of the abbreviated term should be obvious from
the context.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#179019: Fixed (sort of) in 5.4.7-4

[era eriksson]

notfound 179019 5.8.7-4
thanks

On a Sarge system, I get this:

perl /tmp/179019.pl 
Illegal declaration of anonymous subroutine at /tmp/179019.pl line 5.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#324800: perl: backslash not working as expected in m(\() and m[\[]

[era eriksson]

Package: perl
Version: 5.8.7-4
Tags: upstream

When square or round brackets are used as regular expression delimiters,
the expression apparently cannot contain a backslash-escaped literal
opening delimiter bracket.

I see nothing in the documentation to suggest that this is intentional
or expected behavior.

 vnix$ $ perl -ne 'print if m(\()' ' 

Bug#322351: libtest-warn-perl: Language errors in messages

[era eriksson]

Package: libtest-warn-perl
Version: 0.08-2
Severity: minor
Tags: patch

The messages printed by this package are not fully idiomatic English.
Please find attached a patch for the current stable version.
(The latest upstream version on CPAN is still 0.08, from 2003.)


/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

--- Warn.pm.orig	2005-08-10 13:18:54.057617480 +0300
+++ Warn.pm	2005-08-10 13:41:46.980901416 +0300
@@ -9,13 +9,13 @@
   warning_is{foo(-dri => "/")} "Unknown Parameter 'dri'", "dri != dir gives warning";
   warnings_are  {bar(1,1)} ["Width very small", "Height very small"];
   
-  warning_is{add(2,2)} undef, "No warning to calc 2+2"; # or
-  warnings_are  {add(2,2)} [],"No warning to calc 2+2"; # what reads better :-)
+  warning_is{add(2,2)} undef, "No warning for calc 2+2"; # or
+  warnings_are  {add(2,2)} [],"No warning for calc 2+2"; # reads better :-)
   
   warning_like  {foo(-dri => "/"} qr/unknown param/i, "an unknown parameter test";
   warnings_like {bar(1,1)} [qr/width.*small/i, qr/height.*small/i];
   
-  warning_is{foo()} {carped => 'didn't found the right parameters'};
+  warning_is{foo()} {carped => 'didn't find the right parameters'};
   warnings_like {foo()} [qr/undefined/,qr/undefined/,{carped => qr/no result/i}];
   
   warning_like {foo(undef)} 'uninitialized';
@@ -27,9 +27,9 @@
 
 =head1 DESCRIPTION
 
-This module provides a few convenience methods for testing warning based code.
+This module provides a few convenience methods for testing warning-based code.
 
-If you are not already familiar with the Test::More manpage 
+If you are not already familiar with the Test::More manpage,
 now would be the time to go take a look.
 
 =head2 FUNCTIONS
@@ -38,29 +38,29 @@
 
 =item warning_is BLOCK STRING, TEST_NAME
 
-Tests that BLOCK gives exactly the one specificated warning.
-The test fails if the BLOCK warns more then one times or doesn't warn.
+Tests that BLOCK gives exactly the one specified warning.
+The test fails if the BLOCK warns more than once, or doesn't warn.
 If the string is undef, 
 then the tests succeeds iff the BLOCK doesn't give any warning.
-Another way to say that there aren't ary warnings in the block,
-is C.
+Another way to say that there aren't ary warnings in the block
+is C.
 
 If you want to test for a warning given by carp,
-You have to write something like:
+you have to write something like:
 C 'msg'}, "Test for a carped warning">.
-The test will fail,
+The test will fail
 if a "normal" warning is found instead of a "carped" one.
 
 Note: C would print something like C. 
 This method ignores everything after the at. That means, to match this warning
 you would have to call C.
-If you need to test for a warning at an exactly line,
-try better something like C.
+If you need to test for a warning at a particular line number,
+try something like C.
 
-warning_is and warning_are are only aliases to the same method.
+warning_is and warnings_are are only aliases to the same method,
+simply in order to make for more readable method names.
 So you also could write
 C or something similar.
-I decided me to give two methods to have some better readable method names.
 
 A true value is returned if the test succeeds, false otherwise.
 
@@ -70,32 +70,33 @@
 =item warnings_are BLOCK ARRAYREF, TEST_NAME
 
 Tests to see that BLOCK gives exactly the specificated warnings.
-The test fails if the BLOCK warns a different number than the size of the ARRAYREf
-would have expected.
+The test fails if the warnings from BLOCK are not exactly the ones in ARRAYREF.
 If the ARRAYREF is equal to [], 
 then the test succeeds iff the BLOCK doesn't give any warning.
 
 Please read also the notes to warning_is as these methods are only aliases.
 
-If you want more than one tests for carped warnings look that way:
+If you want more than one test for carped warnings, try this:
 C ['c1','c2'];> or
 C ["Carp 1", "Carp 2"]}, "Warning 2"]>.
-Note that C<{carped => ...}> has always to be a hash ref.
+Note that C<{carped => ...}> always has to be a hash ref.
 
 =item warning_like BLOCK REGEXP, TEST_NAME
 
-Tests that BLOCK gives exactly one warning and it can be matched to the given regexp.
+Tests that BLOCK gives exactly one warning and it can be matched by
+the given regexp.
 If the string is undef, 
 then the tests succeeds iff the BLOCK doesn't give any warning.
 
-The REGEXP is matched after the whole warn line,
-which consists in general of "WARNING at __FILE__ line __LINE__".
-So you can check for a warning in at File Foo.pm line 5 with
+The REGEXP is matched against the whole warning message,
+which in general has the form "WARNING at __FILE__ line __LINE__".
+So you can check for a warning in the file Foo.pm on line 5 with
 C.
-I don't know whether it's sensful to do such a test :-(
-However, you should be prepared as a matching with 'at', 'file', '\d'
+Perhaps it isn't sensible to perform such a test;
+h

Bug#321375: cvs: cvs tag -B option not documented in manual page

[era eriksson]

Package: cvs
Version: 1:1.12.9-14

The manual page does not document the -B option to cvs tag.

This is something which broke some of my scripts when I upgraded from
woody to sarge.

I had to take the detour via Google to find out what was wrong.
http://lists.gnu.org/archive/html/info-cvs/2003-03/msg00100.html

If the manual page can't be kept in sync with the info documentation,
perhaps it would be safer to scrap the manual page entirely (or rather,
replace it with a stub pointing to info). While there is a caveat at the
top of the manual page, you often just search for the option or error
message you need help with, and probably don't actually read warnings in
headers or footers.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#400233: Use pidof instead

[era eriksson]

Actually, there is a utility "pidof" which is included in sysv-init and
which is already used by the patch for #396277 (security, NMU) so that
should be preferred to these other approaches.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#400212: (no subject)

[era eriksson]

Just a quick note: Amaya closed this bug, but Sven's changelog portion
also has an entry which sounds like it was related to this bug, with
"closes: 40212" which is an unrelated old mysql- 

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#400233: Problem with the shipping script

[era eriksson]

On Sat, 16 Dec 2006 14:12:13 +0100, "Jesus Climent"
<[EMAIL PROTECTED]> said:
> The only problem with the script that thttpd ships right now is a missing
> space between "^" and "$PID":
> 
> if ps ax | grep -q "^ $PID"; then
> 
> since "ps ax" puts a space in the begining.

Actually, seems it pads the PID to five digits, so you may or may not
get one or more spaces, depending on the width of the PID.

Is this version dependent? That would explain why people are trying
different things and not getting it right. But IIRC it has been this way
in my version of ps for quite some time.

Also, if you happen to get PID 123, then the grep will match 1234, 12345
as well, so you should bound it on both sides.

Personally, on a Debian-based system, I would perhaps try to use a more
specific option to ps(1) to look for the PID in question. "ps --pid
$PID" would appear to do that, and seems to return useful error status.
You'll also need to redirect to /dev/null if you don't want artefacts to
be displayed on the screen (grep -q handled that in the original code).

Hope this helps,

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#184333: mguesser: upstream contact address changed

[era eriksson]

As per  I believe
[EMAIL PROTECTED] might be a working address for the upstream
maintainer.

The address is in cleartext on that page, so I'm not spamproofing it
here ...

Hope this helps,

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#400462: mguesser: wishlist: specify directories for language files

[era eriksson]

Package: mguesser
Version: 0.2-5
Severity: wishlist
Tags: patch
X-Debbugs-Cc: [EMAIL PROTECTED]

The -p option is somewhat hard to use without root access, since you
need to add your generated language models to /usr/share/mguesser/ for
them to be of any use.

Attached please find a patch to implement a -d option which allows you
to specify multiple lm directories on the command line.

I'm afraid my m4d C 5|<1llz show through here -- please feel invited to
fix any unidiomatic or unobvious code.

As you can see I'm on Ubuntu, but the substance of the Ubuntu package
should be the same as the Debian version, apart from the fix for #353309
which I had to reinvent independently in order to get this to compile
:-)

-- System Information:
Debian Release: testing/unstable
  APT prefers dapper-updates
  APT policy: (500, 'dapper-updates'), (500, 'dapper-security'), (500,
  'dapper-$Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-27-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Versions of packages mguesser depends on:
ii  libc62.3.6-0ubuntu20 GNU C Library: Shared
libraries an

mguesser recommends no packages.

-- no debconf information

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

  * Implement -d option to specify language map directories at run time
  * Add a FILES section to the manual page

diff -rN -u old-mguesser/debian/mguesser.1 new-mguesser/debian/mguesser.1
--- old-mguesser/debian/mguesser.1	2006-11-26 14:30:48.0 +0200
+++ new-mguesser/debian/mguesser.1	2006-11-26 14:30:48.0 +0200
@@ -3,7 +3,7 @@
 mguesser \- guess language
 .SH SYNOPSIS
 .B mguesser
-.RI "[-n maxhits] < FILENAME"
+.RI "[-n maxhits] [-d directory:directory...] < FILENAME"
 .br
 .B mguesser
 .RI "-p -c charset -l language < FILENAME"
@@ -15,7 +15,7 @@
 because the original program does not have a manual page.
 .PP
 .\" TeX users may be more comfortable with the \fB\fP and
-.\" \fI\fP escape sequences to invode bold face and italics, 
+.\" \fI\fP escape sequences to invoke bold face and italics, 
 .\" respectively.
 \fBmguesser\fP is for guessing languages.
 .SH OPTIONS
@@ -30,6 +30,13 @@
 .B \-v
 Be verbose.
 .TP
+.B \-d directory[:directory...]
+Specify director(ies) to search for language maps in.
+This overrides the default directory
+.IR /usr/share/mguesser ;
+if you want to include that directory,
+you have to specify it.
+.TP
 .B \-p
 Print (for creating a new language map).
 .TP
@@ -39,6 +46,15 @@
 .B \-l language
 Define language (for creating a new language map).
 .br
+.SH BUGS
+The
+.B \-d
+option is a Debian-specific addition
+and is not present in the upstream sources.
+.SH FILES
+.TP
+.I /usr/share/mguesser/*.lm
+Language definition files
 .SH AUTHOR
 This manual page was written by Gürkan Sengün <[EMAIL PROTECTED]>,
 for the Debian GNU/Linux system (but may be used by others).
diff -rN -u old-mguesser/guesser.c new-mguesser/guesser.c
--- old-mguesser/guesser.c	2006-11-26 14:30:48.0 +0200
+++ new-mguesser/guesser.c	2006-11-26 14:30:48.0 +0200
@@ -121,7 +121,7 @@
 	char name[1024]="";
 	int res=0;
 
-	Env->LangMapList.nmaps=0;
+	/* Env->LangMapList.nmaps=0; */
 	dir=opendir(mapdir);
 	if(!dir)return 0;
 
@@ -382,10 +382,27 @@
 void usage(){
 	printf("mguesser %s\n\n",MGUESSER_VERSION);
 	printf("To guess use:\n");
-	printf("\tmguesser [-n maxhits] < FILENAME\n\n");
+	printf("\tmguesser [-n maxhits] [-d directory:directory:...] < FILENAME\n\n");
 	printf("To create new language map use:\n");
 	printf("\tmguesser -p -c charset -l language < FILENAME\n");
-} 
+}
+
+char ** get_directories(char * optarg){
+	int i;
+	char * p;
+	char ** directories;
+
+	/* XXX TODO: fix ugliness */
+	directories=malloc(strlen(optarg)*sizeof(char **)/sizeof(char));
+	directories[0]=optarg;
+	for(i=1;(p=strchr(optarg,(int)':'));++i,optarg=p+1){
+		*p='\0';
+		directories[i]=p+1;
+	}
+	realloc(directories,(i+2)*sizeof(char **));
+	directories[i+1]=(char *)NULL;
+	return directories;
+}
 
 int main(int argc,char ** argv){
 	int ch;
@@ -393,12 +410,14 @@
 	int print=0;
 	int n=1000;
 	char buf[1024]="";
+	char ** directories = (char **) NULL;
+	int d=0;
 	UDM_ENV env;
 	UDM_LANGMAP mchar;
 	char * charset=NULL;
 	char * lang=NULL;
 
-	while((ch=getopt(argc,argv,"pv?c:l:n:"))!=-1){
+	while((ch=getopt(argc,argv,"pv?c:l:n:d:"))!=-1){
 		switch(ch){
 			case 'n':
 n=atoi(optarg);
@@ -415,6 +434,9 @@
 			case 'v':
 verbose++;
 break;
+			case 'd':
+directories = get_directories(optarg);
+break;
 			case '?':
 			default:
 usage();
@@ -428,15 +450,24 @@
 	memset(&env,0,sizeof(env));
 	memset(&mchar,0,sizeof(mchar));
 
+	if (!directories){
+		directories=malloc(2*sizeof(char **));
+		directories[0]=LMDIR;
+		directories[1]=(char *) NULL;
+	}
+
 	if(!print){
-		/* Load all available lang ngram maps */
-		if(verbose){
-			fprintf(stderr,"Loading language maps from '%s'\n",LMDIR);
-		}
-		UdmL

Bug#294214: rootstrap: Configuration file handling undocumented / incomplete

[era eriksson]

Package: rootstrap
Version: 0.3.21-1
Severity: minor

I'm afraid this bug report contains multiple minor bug reports and
enhancement requests. If you'd like me to split it up into a number of
minor and wishlist bug reports, feel free to write back and I'll take
care of it.

I have been trying to wrap my head around rootstrap from time to time
but always failing. There's a bunch of things one needs to understand
about UML and about how Debian is installed in order to succeed, and I
was having trouble with the UML stuff in particular. I'm just trying
to get pbuilder-uml to work here, and didn't want to spend a lot of
time on understanding rootstrap. Well, now I delved into it anyway.
Here are my impressions -- hopefully other newcomers will find it
easier to get started if even some of these problems I stumbled into
could be straightened out or at least made a little bit less puzzling.

Again, sorry if this is not formatted in a way which makes sense to
you. I'd be tempted to split this into a dozen tiny bug reports, but
then some developers would be upset about that approach, too. Please
let me know how you prefer this feedback and I'll try to massage it
into a format which is convenient for you.

Attached is a documentation patch which attempts to fix some of these
issues. I have marked those sub-bugs with "Tags: patch".

/* era */


Subject: Requires /etc/rootstrap/rootstrap.conf, even if empty  [#1]

I experimentally removed /etc/rootstrap/rootstrap.conf. This results
in the following error:

 bash$ rootstrap root_fs
 Traceback (most recent call last):
   File "/usr/bin/rootstrap", line 34, in ?
 config.readfp(open('/etc/rootstrap/rootstrap.conf'))
 IOError: [Errno 2] No such file or directory: '/etc/rootstrap/rootstrap.conf'

Does it really make sense to require this file to exist? I wanted to
experiment with a minimal rootstrap.conf and I didn't want to be root,
so I figured I'd just rename the site-wide config file and let my
../rootstrap.conf contain my entire experimental config. Alas, this is
not possible, although the workaround is simple; create an empty
/etc/rootstrap/rootstrap.conf.

An alternative to making this file completely optional would be to
ship a really minimal rootstrap.conf which only specifies the absolute
minimum required options. This would make it much easier to create an
experimental per-user config.

Sub-cases:
  [global] section required   [#1.1]
  [global]::initialsize required  [#1.2]
  [global]::modules required  [#1.3]
  No warning if PATH is not set   [#1.4]
  fstype directive required   [#1.5]


Subject: [global] section required  [#1.1]

If the file /etc/rootstrap/rootstrap.conf exists but is empty, I get
an error about not having a [global] section. Maybe this requirement
should be relaxed, too -- require the [global] section heading only if
the file is non-empty, perhaps. Otherwise, assume some reasonable
defaults (and document them ...)


Subject: [global]::initialsize required  [#1.2]

If I have an empty [global] section, I get an error about not having
any initialsize directive:

 bash$ rootstrap root_fs
 Traceback (most recent call last):
   File "/usr/bin/rootstrap", line 50, in ?
 imagesize = config.getint('global', 'initialsize')
   File "/usr/lib/python2.3/ConfigParser.py", line 315, in getint
 return self._get(section, int, option)
   File "/usr/lib/python2.3/ConfigParser.py", line 312, in _get
 return conv(self.get(section, option))
   File "/usr/lib/python2.3/ConfigParser.py", line 513, in get
 raise NoOptionError(option, section)
 ConfigParser.NoOptionError: No option 'initialsize' in section: 'global'

Perhaps some default could be assumed (say, 2048, which is allegedly
large enough for even the largest pbuilder-uml package builds).


Subject: [global]::modules required  [#1.3]

If I have an empty [global] section, I get an error about not having
any modules directive, way into the creation of a file system.

 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
 VFS: Mounted root (hostfs filesystem) readonly.
 Mounted devfs on /dev
 builder running...
 Traceback (most recent call last):
   File "/usr/lib/rootstrap/builder", line 60, in ?
 for module in config.get('global', 'modules').split():
   File "/usr/lib/python2.3/ConfigParser.py", line 513, in get
 raise NoOptionError(option, section)
 ConfigParser.NoOptionError: No option 'modules' in section: 'global'
 Kernel panic: Attempted to kill init!

Adding an empty modules= fixes this. Perhaps this should be assumed to
be the default if no modules are specified.


Subject:  No warning if PATH is not set  [#1.4]

The documentation does not really document PATH, but mentions that it
is mandatory. However, if it is omitted, no warning is issued until
very late into the debian module, after you've spent on the order of
fifteen minutes downloading all packages (lots longer if you don't
have a fast local mirror!)

 I: Extracting textutils...
 I: Extracting util-linux...

Bug#296461: UpgradeTwiki upgrade script not present/working : fix setlib.cfg

[era eriksson]

In , you write:
 > In order to upgrade from a previous twiki installation, the
 > upstream script UpgradeTwiki is quite [useful].

If you are using a Debian package, you should not be updating things
in place. dpkg will be rightfully upset if you change an installed
package behind its back. Upgrade to a new version of the Debian
package (perhaps a locally created backport?), or install directly
from upstream sources, and don't use the Debian package in the first
place.

Granted, it would be interesting to see how well the upgrade script
would be at upgrading the source of a Debian package ... Perhaps
that's actually what you are suggesting?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#297468: equivs: provide a equics manpage

[era eriksson]

On Mon, 28 Feb 2005 22:57:40 +0100, "Vincent Fourmond"
<[EMAIL PROTECTED]> said:
>   I would just like that you provide a equivs man page, stating the name
>   and the basic usage of teh main executables of the package.

As far as I can tell, this is already present. The main executables of
the package are called equivs-build and equivs-control, and there is a
manual page for both of them.

> My first try, when I install a package, is to type
>   man package 
>   I'm always disappointed when it actually doesn't give anything...

I'm sure your request for an "equivs" man page could be considered, but
there are lots of other packages which don't contain a man page (or an
executable) with the same name as the package. You just need to consider
various library packages, and in particular the (somewhat silly) Perl
package naming convention -- librcs-perl, libtext-csv-perl -- but even
among packages which provide userland binaries, what you want and expect
is by no means the only norm. Do you expect coreutils to have a
coreutils(1) manual page, too? abiword-common? altgcc? apt?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#409557: equivs: Please don't override Source: if present

[era eriksson]

On Sat, 3 Feb 2007 21:29:00 -0600, "Peter Samuelson" <[EMAIL PROTECTED]>
said:
> > As a small step towards [#323648], please consider this patch. It at least
> > allows one to supply a Source: different from Package:
> 
> Why did you create a new bug rather than just attach this patch to the
> old one?

Because it doesn't even pretend to solve that problem, but solves a
related but different problem. I think it is indeed a bug in its own
right that a user-specified Source: is arbitrarily overridden with
essentially a nonsense value.

However, with this, I am also able to run a small external preprocessor
to generate equivs files from a central file, and run equivs-build on
each in turn, like you would expect for a multi-package debian/control
file.

I didn't even want to try to hack that into equivs-build but now after
your cleanup it looks a lot better already. Maybe it could be done
without completely overhauling it.

This change in and of itself is really minimal, so I hope you will
consider it, regardless of its implications for the other bug.

Attached please find an updated patch for 2.0.7.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

--- equivs-2.0.7/usr/bin/equivs-build	2006-02-28 10:33:25.0 +0200
+++ usr/bin/equivs-build	2007-02-10 21:53:38.0 +0200
@@ -154,6 +154,10 @@
 
   $control->{'Architecture'} = $specific_arch ? 'any' : 'all';
 
+  # Fix Source: entry, part I: remove any silly predefied "equivs-dummy"
+
+  undef $control->{'Source'} if ($control->{'Source'} eq 'equivs-dummy');
+
   open($in, $file) or
 die "Cannot open control file $file: $!\n";
 
@@ -161,8 +165,8 @@
 die "error: empty control file\n";
   close $in;
 
-  # Fix Source: entry
-  $control->{'Source'} = $control->{'Package'};
+  # If no Source entry was specified, copy Package:
+  $control->{'Source'} ||= $control->{'Package'};
 
   # remove trailing whitespace
 #  foreach my $key (keys %$control) {
@@ -251,7 +255,7 @@
   open OUT, '>', "$builddir/debian/changelog" or
 die "Couldn't write changelog: $!\n";
   print OUT <{Package} ($version) unstable; urgency=low
+$control->{Source} ($version) unstable; urgency=low
 
   * First version
 

Bug#354959: tags ! +upstream?

[era eriksson]

This is upstream bug #160654,
http://bugzilla.gnome.org/show_bug.cgi?id=160654

Should it be tagged as such?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#410938: Pach was against description!

[era eriksson]

reopen 410938
thanks

It's very nice if similar bugs were fixed in the manual, but my patch
was against the package's description (the text in debian/control). If
you need a proper diff, I'll be happy to provide one.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#413415: ITA?

[era eriksson]

Do I understand correctly that you intend to adopt this package and do
an upload to fix these problems? (Ref. recent activity on bug #245101)

Good to finally see some activity here! (-:

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#412033: PTS: extremely noisy when new package closes many bugs

[era eriksson]

Package: qa.debian.org
X-Debbugs-Cc: [EMAIL PROTECTED]

I am subscribed to some packages via the PTS. For example, I receive
copies of all messages related to the twiki package.

Now, recently, twiki has gone through a number of update cycles where a
lot of bugs have been closed.

Version 1:4.0.5-9.1 which was uploaded Tuesday this week closed 12 open
bugs.

Guess twice how many copies of the following message I have received?

From: Debian Bug Tracking System <[EMAIL PROTECTED]>
To: Christian Perrier <[EMAIL PROTECTED]>
Subject: Bug#xx: marked as done (bug title)

I can understand the motivation for detailed reporting to the package
owner and the bug submitter, but I think for the majority of PTS
subscribers just the upload notice would suffice.

(Tangentially, see also #340863)

If

tries to explain how to fix this if you don't like the defaults, then I
don't understand it, and in any event, does the current default really
make sense?

(Opting out from bts-control sounds like it might work, but then do you
lose other less predictable messages, too?)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#412033: PTS: extremely noisy when new package closes many bugs

[era eriksson]

On Fri, 23 Feb 2007 12:33:59 +0100, "Raphael Hertzog"
<[EMAIL PROTECTED]> said:
> On Fri, 23 Feb 2007, Christoph Berg wrote:
> > > keyword you won't receive discussions concerning bug reports.
> > 
> > I agree that the "done" mails from the BTS are quite boring as they
> > only repeat the initial mail.
> 
> That's because most of the -done mails are generated by dak. But there
> are also manual -done mails which have valuable information in that case.
> We could special case based on some dak headers but I don't think it's
> worth the pain.

Any chance then you could call that category "bts-dak" or something, and
at least make it something one could opt out from separately from the
other stuff? Perhaps the dak maintainer could cooperate to make this
less painful to code? I don't want to unsubscribe from the current
"bts", I just want to avoid getting large amounts of completely
predictable messages.

I know how to filter my mail, but I'm troubled by the approach to defer
the issue to the users instead of adapting an existing mechanism (the
pts keywords) to make it go away entirely.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#407412: #407412: dlocate: '-s' option ignores virtual packages.

[era eriksson]

On Tue, 20 Feb 2007 17:19:19 -0500, "A. Costa" <[EMAIL PROTECTED]> said:
> > How about then just proceed to display the status of
> > exim4-daemon-light instead?
> 
> It depends if the 'dlocate' programmer (or patcher) likes long or
> short output.  The longer version you suggested (with status switch) has
> the advantage that the 'dlocate' output would be more standard.  The
> shorter one would be harder for scripting, because if we wanted the
> package size of the current 'mail-transport-agent', it'd require
> parsing 'dlocate' twice -- first to check if its virtual, and again to
> run 'dlocate -s exim4-daemon-light'.  For that purpose the long version
> seems much better!

Yes, that's a good scenario to keep in mind, too. I was thinking mainly
from the perspective of the user. "That's what I asked for, dammit, do I
have to tell you again that that's what I want!?"

> > Packages which provide 'mail-transport-agent':
> > exim4-daemon-heavy - exim MTA (v4) daemon with extended features, ...
> 
> Your lead in is better.  The listing with one-line descriptions should be
> a '-v (--verbose)' option.

Ah, but dlocate's handling of options is rather non-standard. Currently
every command is an "option" and there are no real "options". I don't
like that design much, but I don't think we should break it, either.

> Howbout a different approach, new (conditional or pseudo) field names:
> 
>   % dlocate -s mail-transport-agent
>   Virtual package providers:  { ... }
>   Current provider: exim4-daemon-light
>   Package: exim4-daemon-light
>   Status: install ok installed
>   Priority: standard
>   { ... }
> 
> ...and if there was no MTA it would say:
> 
>   % dlocate -s mail-transport-agent
>   Virtual package providers:  { ... }
>   Current provider: none
> 
> Hope that's better...

Yes, I like that approach.

Actually, I'd add an empty line in there, just to keep this visually
distinct. Otherwise it's too easy to miss. Consider this:

 vnix$ command -option
 Xxxx: xxx x xx xx xx
 X-Xxx-X: xxx, xxx (>= xxx.x:x)
 Xxx-X: xx, ?
 Attention: here is the information you want
 X: xxx xxx 

With an empty line, it's at least a little bit more likely that you will
notice that the first line contains stuff which affects the
interpretation of the information that you are actually looking for.

(On the next day, he learned to pipe the command to "| grep ^Attention:"
...)

For some weird reason, my subconscious tells me to use single-word or
hyphenated field names for consistency. I'm also wondering whether the
fields should be reordered a litte bit. Maybe like this:

 vnix$ dlocate -s mail-transport-agent
 Package: mail-transport-agent (virtual)
 Providers: exim4-daemon-heavy, exim4-daemon-light, postfix, courier-mta
 ...

 Package: postfix
 Status: install ok installed
 Priority: extra
 Section: mail
  :

Not sure if Providers: should be comma-separated (cf. Depends:) or
space-separated or even pipe-separated (again, cf. how equally valid
alternatives are shown in Depends:) or what.

(I had "Virtual-Providers:" there at first but I think maybe just
"Providers:" is better.)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#407412: #407412: dlocate: '-s' option ignores virtual packages.

[era eriksson]

On Sun, 25 Feb 2007 02:26:20 -0500, "A. Costa" <[EMAIL PROTECTED]> said:
> On Sat, 24 Feb 2007 16:41:11 +0200
> "era eriksson" <[EMAIL PROTECTED]> wrote:
> 
> 0>  vnix$ dlocate -s mail-transport-agent
> 1>  Package: mail-transport-agent (virtual)
> 2>  Providers: exim4-daemon-heavy, exim4-daemon-light, postfix,
> courier-mta ...
> 3> 
> 4>  Package: postfix
> 5>  Status: install ok installed
> 6>  Priority: extra
> 7>  Section: mail
> 
> Many good ideas.  Adding the blank line looks better.  "Providers:" is
> also better, as is your reordering.
> 
> Duplicate fields:  both line #1 and #4 begin with "Package:".
> The trailing "(virtual)" makes searching and parsing harder; for
> instance, 'sed'ing or 'grep'ing for anything in parenthesis means 
> extra quoting.

Well, my reasoning was exactly that somebody might do "| grep ^Package:"
and miss the fact that a package is virtual. But I guess we can accept
that, in favor of having unique field names (and anyway, most lusers are
too lazy or ignorant to include the ^ anchor anyway :^)

> > Not sure if Providers: should be comma-separated (cf. Depends:) or
> > space-separated or even pipe-separated (again, cf. how equally valid
> > alternatives are shown in Depends:) or what.
> 
> Pipes seem ideal, since for '.deb's they mean XOR.

Well, they clutter the output, and don't really add anything. Just a
whitespace separator makes the data easier to cut and paste. I'm not at
all really sure how to prioritize this.

> Interesting point about 'dlocate' having its own conventions for
> switch syntax.  Instead of '-v' then, any mnemonic suggesting 
> 'Virtual' would do

I humbly suggest '-virtual' to go with the other full-length options
(-conf, -lsconf, -md5sum, -md5check, -man -- these have a single hyphen,
too)

... Or simply replacing the current option processing with something a
little less insane, but that would entail breaking backwards
compatibility. Privately, I've been toying with the idea to create a
competing package which straightens out some of dlocate's quirks.
Unfortunately, I'm afraid I can't commit to being a more active
maintainer than the current (non-)maintainer of dlocate.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#415362: Security fix included in GNU file 4.20

[era eriksson]

Package: file
Version: 4.19-1
Severity: grave
Tags: security
X-Debbugs-Cc: [EMAIL PROTECTED]

According to the changelog included in the GNU file 4.20 tarball at
, this version includes a
security fix:

2007-02-08 17:30 Christos Zoulas <[EMAIL PROTECTED]>

* fix integer underflow in file_printf which can lead to
  to exploitable heap overflow (Jean-Sebastien Guay-Lero)

I have not seen this receive any publicity. A quick Google seems to
confirm this.

The release announcement with pertinent ChangeLog is also at
 if you don't want to
grab the full tarball.

Sorry if I have assigned an inflated severity; I suppose it's better at
this point to exaggerate than to downplay. The instructions at
 suggest "grave" for a
bug which "introduces a security hole allowing access to the accounts of
users who use the package". I'm not sure about "introduces" (it likely
existed before?) and without an isolated patch, it's hard to assess the
exact scope of the vulnerability, even for someone more skilled than
myself.



/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#267803: Documentation is in magic(5)

[era eriksson]

tags 267803 +patch
thanks

As indicated in the file(1) manual page, the format of the magic
database is described in the magic(5) manual page.

However, be warned that file(1) is not very good at handling various
heuristics. You really do need something like a "magic marker" somewhere
in the file for the detection to be accurate and reliable.

Having said that, some Info files do contain something resembling a
magic marker, namely a mode indicator for Emacs. Thus, the attached
magic snippet should be able to detect at least some fraction of Info
files, at least enough to offer a workaround for those who need one.

(None of the Info files on my system contain this marker, though, save
for the "dir" entries which I believe are automatically generated. All
the Debian info pages are gzipped anyway.)

This could be generalized to handle any text file with a -*- mode -*-
indicator, but that would mess up things, because you'd like the
detection strings to be consistent In other words, C code should not
display as "ASCII C text" but as "ASCII C program text" because that's
what file(1) currently displays for other C files; but a generalized
solution would have to know for each detected mode whether it's
"program" text or some other kind. So it would not be very general after
all.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



info.magic
Description: Binary data

Bug#267803: Oops, small informal fix for patch

[era eriksson]

Actually, it seems that the snippet I created has a bug, but works
anyway because of a bug in file itself.  Still investigating, but the
first + in the regular expression should be a * (allow the -*- mode -*-
stuff to be at beginning of line, like it is e.g. in my
/usr/share/info/dir on this Ubuntu Edgy box; file 4.17-2ubuntu1).

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#38542: file: This bug is fixed upstream in the next release; please close

[era eriksson]

> I sent my report and patch upstream and it will be fixed in the next
> release.

The Debian bug should be closed only when a fixed version is available
in Debian.

The ChangeLog for 4.20 doesn't mention any patch from you; do you know
if it was included there?  If not, do you know which "next release" it
will be in?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#362977: Cycling thru external screen a workaround?

[era eriksson]

I am typing this from a Libretto U105 running the Ubuntu Edgy i386 Live
CD. I am only just familiarizing myself with this machine, but I already
accidentally found that at least once, the Fn+F5 screen cycling key
would seem to fix the problem. (Cycle through external and external+LCD
and back to LCD only: doesn't matter if you actually have an external
screen).

Just a quick note lest I forget (have nowhere else to save this
information :-) but I'll try to follow up with more details if this
seems to work out in the long term.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#382336: dh-make: a copyright file is not bsd with -c bsd and -n

[era eriksson]

 > I'll see if it makes sense to be able to specify copyright, I cannot
 > see any rules that say Debian native packages need to be GPL.

Indeed. any DFSG-license should be acceptable. But if you want to be
conservative, and not go all the way, then at least a warning that the
requested copyright is not available with the -n option would be most
welcome.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#409557: equivs: Please don't override Source: if present

[era eriksson]

Package: equivs
Version: 2.0.6
Severity: wishlist
Tags: patch

As a small step towards #247974, please consider this patch. It at least
allows one to supply a Source: different from Package:



/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

  * equivs-build: Don't override Source: if it is present

--- equivs-2.0.6/usr/bin/equivs-build	2004-05-29 04:29:30.0 +0300
+++ equivs-2.0.6-0.1era1/usr/bin/equivs-build	2007-02-04 00:55:42.0 +0200
@@ -206,14 +206,18 @@
 
   $control{"Maintainer"} = "$fullname <[EMAIL PROTECTED]>";
 
+  # Fix Source: entry, part I: remove any silly predefied "equivs-dummy"
+
+  undef $control{"Source"} if ($control{"Source"} eq "equivs-dummy");
+
   open(IN, $file) or 
 die "$file: cannot open control file for reading: $!";
 
   read_control_file_section(\%control) or die "error: empty control file";
 
-  # Fix Source: entry
+  # If no Source entry was specified, copy Package:
 
-  $control{"Source"} = $control{"Package"};
+  $control{"Source"} ||= $control{"Package"};
 
   # remove trailing whitespace
   
@@ -331,7 +335,7 @@
   my $version = $control{"Version"} || "1.0";
   
   print OUT <

Bug#409557: Sorry, not 247974

[era eriksson]

The bug I was wanting to write about was #323648 -- sorry for the
confusion.

Gaah, it's too late for me to do things right.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#372151: dlocate: please rename atomically

[era eriksson]

On Thu, 8 Jun 2006 10:45:14 -0400, Justin Pryzby
<[EMAIL PROTECTED]> wrote:
 > +unlink("$dbfile.old") if ( -e "$dbfile.old" ) ;
 > +link("$dbfile", "$dbfile.old") if ( -e $dbfile ) ;

Erm, shouldn't you take care to leave .old if no new $dbfile exists?

+if (-e $dbfile) {
+  unlink("$dbfile.old") if (-e "$dbfile.old");
+  link("$dbfile", "$dbfile.old");
+}

Something like that?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#361196: Contents and formatting of die message

[era eriksson]

Shouldn't the last die say

  die "can't open file $pkg.list";

instead?

Also, as a matter of style, it would be nice if the die messages
contained the prefix "$0: " throughout, i.e.

  die "$0: can't open file $pkg.list";

and similarly for other dies, globally.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#389933: tailor: obsolete link to upstream repo in README.Debian

[era eriksson]

Package: tailor
Version: 0.9.19-2
Tags: patch
Severity: minor
X-Debbugs-Cc: [EMAIL PROTECTED]

As per http://www.darcs.net/DarcsWiki/Tailor, the current URL for the
master repo is
http://darcs.arstecnica.it/tailor

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#389937: tailor: manual page should point to README file

[era eriksson]

Package: tailor
Version: 0.9.19-2
Tags: patch
Severity: minor
X-Debbugs-Cc: [EMAIL PROTECTED]

The manual page is apparently Debian's. It describes the program's
options, but as the real meat is in the configuration file, that doesn't
help too much. The README file contains extensive documentation, but it
would be nice if the manual page could mention so much, since many
README files are deceptively content-free, and this one too starts off
rather unpromisingly.

Off the top of my head:

.sh SEE ALSO
The syntax for tailor's configuration file format
and a good number of examples
are in tailor's
.I README
file,
which on Debian systems is installed in
.IR /usr/share/doc/tailor .

(Sorry if my -man syntax is a bit rusty.)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#369231:

[era eriksson]

On Thu, 20 Jul 2006 20:39:12 -0700, Daniel Burrows <[EMAIL PROTECTED]>
wrote:
 >   There are things that could be done to adjust the storage of the
 > descriptions list, of course.  For instance, I wonder if a suffix tree
 > or some similar data structure would be helpful.  I don't really want
 > to rewrite the whole apt caching layer, though.
 >
 >   Probably the reason aptitude pulls everything into RAM is that it
 > walks over the whole cache to build some of its structures on startup.
 > I suppose we could get some speedup by using a binary cache of those
 > too.  For instance, the debtags stuff doesn't change unless the lists
 > change, so there's no need to build it every time.  Also, currently
 > std::sets are used; probably we could just use those to build it the
 > first time, but actually store it as a sorted list.  Other optimizations
 > are also possible (e.g., indexing into a common list of tag strings),
 > depending on how much time you want to waste on them.

For simple command-line use, the whole debtags component is irrelevant,
anyway -- factoring it out so it's not done at all for a simple "sudo
aptitude install -y deborphan" would perhaps already be enough to make
it palatable again.

FWIW, I've been trying to use aptitude as a straight replacement for
apt-get, but on my 64Mb P133 this is no longer feasible.
I'm afraid to run aptitude at all on this machine because oom-killer
might zap some essential system daemon. This is on Ubuntu Dapper with
main+universe+backports, BTW. When I was running Woody on the same
hardware but only 32Mb RAM, Xfree was mostly usable even while apt-get
was installing something. Now I basically have to choose between Emacs
or aptitude, and forget about X altogether ... But I am about to switch
back to apt-get + deborphan if I can get used to the idea. Maybe then I
could try running X again.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#237830: Merge 143532 237830?

[era eriksson]

I perceive #143532 and #237830 to be fundamentally about the same
problem, although I'm not sure you agree. Do you think they could be
merged? Do you think one or both is identical to Ubuntu
? For the time
being, I marked it as upstream #143532, but I'm really not at all sure.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#394987: thttpd-util: makeweb: useless as shipped, needs setgid

[era eriksson]

Package: thttpd-util
Version: 2.23beta1-4
X-Debbugs-Cc: [EMAIL PROTECTED]

The "makeweb" utility is supposed to let users create their own
directory structure in /var/www/users, but in order to be able to do
this, the utility needs to be setgid to the group owner of that
directory (this is mentioned in the source code). At present, that
directory is group "root" on my installation, and makeweb is not setgid.

Perhaps it would be simpler in the short term to simply replace this
command with a no-op warning unless you relly want to go through the
hassle to introduce a new group and a new setgid program.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#394988: thttpd-util: Please compile cgi-bin/* statically

[era eriksson]

Package: thttpd-util
Version: 2.23beta1-4
X-Debbugs-Cc: [EMAIL PROTECTED]

The shipped cgi-bin utilities will no longer work after you made the
chroot option the default. One either has to disable the chroot option
(which is of course a bit of a security risk) or compile these binaries
statically (I think this should be a one-line fix against
cgi-bin/Makefile.in). I think the latter would make more sense for the
distribution package, but at the very least, this needs to be documented
someplace, such as in README.Debian

Thanks in advance

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#394991: thttpd: libthttpd.c.rej failed patch included in diff.gz

[era eriksson]

Package: thttpd
Version: 2.23beta1-4
X-Debbugs-Cc: [EMAIL PROTECTED]
Severity: minor

thttpd_2.23beta1-4.diff.gz includes a diff for creating the file
thttpd-2.23beta1/libhttpd.c.rej which is a failed patch. The equivalent
code is present via the regular libhttpd.c patch in the same diff.
Probably the previous maintainer applied this hunk by hand and then
forgot to remove this .rej file from his source tree.

I'm also wondering about the motivations for the patch for removing the
link to http://www.acme.com/software/thttpd/notes.html#sizes from README
but not enough to submit a separate bug report about that ...

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#394988: thttpd-util: Please compile cgi-bin/* statically

[era eriksson]

On Tue, 24 Oct 2006 11:33:42 +0300, "era eriksson" <[EMAIL PROTECTED]> said:
> The shipped cgi-bin utilities will no longer work after you made the
> chroot option the default. One either has to disable the chroot option
> (which is of course a bit of a security risk) or compile these binaries
> statically (I think this should be a one-line fix against
> cgi-bin/Makefile.in). I think the latter would make more sense

Actually it seems that the previous maintainer disbled this by removing
all occurrences of $(STATIC) in the main Makefile.in. Reverting that
IMHO slightly radical patch would make it a snap; if users want to
compile non-static, then it's just a matter of overriding the STATIC
flag.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#394987: thttpd-util: makeweb: useless as shipped, needs setgid

[era eriksson]

On Tue, 24 Oct 2006 11:30:13 +0300, "era eriksson" <[EMAIL PROTECTED]> said:
> Package: thttpd-util
> Version: 2.23beta1-4
> X-Debbugs-Cc: [EMAIL PROTECTED]
> 
> The "makeweb" utility is supposed to let users create their own
> directory structure in /var/www/users, but in order to be able to do
> this, the utility needs to be setgid to the group owner of that
> directory (this is mentioned in the source code). At present, that
> directory is group "root" on my installation, and makeweb is not setgid.
> 
> Perhaps it would be simpler in the short term to simply replace this
> command with a no-op warning unless you relly want to go through the
> hassle to introduce a new group and a new setgid program.

I meant to add that yes, you are mentioning this in README.Debian, but
IMHO it's still not very useful or intuitive. Maybe that turns this into
a "minor" / "wishlist" bug though. Sorry for not making this clear from
the start.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#394988: thttpd-util: Please compile cgi-bin/* statically

[era eriksson]

tags 394988 +patch
thanks

On Tue, 24 Oct 2006 16:59:28 +0300, "era eriksson" <[EMAIL PROTECTED]> said:
> On Tue, 24 Oct 2006 11:33:42 +0300, "era eriksson" <[EMAIL PROTECTED]> said:
> > The shipped cgi-bin utilities will no longer work after you made the
> > chroot option the default. One either has to disable the chroot option
> > (which is of course a bit of a security risk) or compile these binaries
> > statically (I think this should be a one-line fix against
> > cgi-bin/Makefile.in). I think the latter would make more sense
> 
> Actually it seems that the previous maintainer disbled this by removing
> all occurrences of $(STATIC) in the main Makefile.in. Reverting that
> IMHO slightly radical patch would make it a snap; if users want to
> compile non-static, then it's just a matter of overriding the STATIC
> flag.

Sorry, that's STATICFLAG actually.

Attached is a patch which reverts the change against upstream
cgi-src/Makefile.in

This would still require some changes to debian/rules to make it
convenient to control from there whether the cgi-src stuff should be
compiled statically or not. I think with the chroot option it's sensible
to ship statically compiled cgi binaries by default, but it would be
nice if there was a simple way to override that.

(Sorry for this monologue ... humor me. I was like -><- this close to
forgetting to attach the actual patch.)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

--- thttpd-2.23beta1/cgi-src/Makefile.in
+++ thttpd-2.23beta1.orig/cgi-src/Makefile.in
@@ -35,7 +35,7 @@
 DEFS =		@DEFS@
 INCLS =		-I..
 CFLAGS =	$(CCOPT) $(DEFS) $(INCLS)
-LDFLAGS =	@LDFLAGS@
+LDFLAGS =	@LDFLAGS@ @V_STATICFLAG@
 LIBS =		@LIBS@
 NETLIBS =	@V_NETLIBS@
 INSTALL =	@INSTALL@
@@ -51,15 +51,15 @@
 all:		redirect ssi phf
 
 redirect:	redirect.o
-	$(CC) $(LDFLAGS) redirect.o $(LIBS) -o redirect
+	$(CC) $(LDFLAGS) $(STATICFLAG) redirect.o $(LIBS) -o redirect
 
 ssi:		ssi.o ../match.o
-	$(CC) $(LDFLAGS) ssi.o ../match.o $(LIBS) -o ssi
+	$(CC) $(LDFLAGS) $(STATICFLAG) ssi.o ../match.o $(LIBS) -o ssi
 
 ssi.o:		../match.h
 
 phf:		phf.o
-	$(CC) $(LDFLAGS) phf.o $(LIBS) -o phf
+	$(CC) $(LDFLAGS) $(STATICFLAG) phf.o $(LIBS) -o phf
 
 strerror.o:
 	@rm -f strerror.o

Bug#270586: Error messages in syslog?

[era eriksson]

Could you check whether there are any error messages in syslog? Do you
have the chroot option enabled? Or was that your complete thttpd.conf?

Samma på finska (-:

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#734712: jack3rc configuration file format undocumented

[era eriksson]

Package: jack
Version: 3.1.1+cvs20050801-26
X-Debbugs-Cc: era+deb...@iki.fi

Forwarding my own Ubuntu bug report to the Debian upstream maintainer.

https://bugs.launchpad.net/ubuntu/+source/jack/+bug/960970

The manual page says that the "--save" option will write out your
selected options to the file ~/.jack3rc but not all options are written
there, and some configuration directives are not available as options.
For example, when I ran jack, it complained that the "base_dir" variable
was not set, and I noticed that the value of the -Q option does not get
written to the generated .jack3rc.

For what it's worth, here is what I ended up with. The file
/usr/share/pyshared/jack_config.py shows what options are available and
their internal names.

# jackrc-version:31
encoder:flac
# Undocumented, gleaned from error message
base_dir:flac
# Undocumented, will not be written here by --save; gleaned from source
query_on_start:1

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#734718: jack -x option not understandable

[era eriksson]

Package: jack
Version:
X-Debbugs-Cc: era+deb...@iki.fi

Forwarding my Ubuntu bug report to the Debian upstream maintainer.

https://bugs.launchpad.net/ubuntu/+source/jack/+bug/961019

The manual states that the -x option causes jack to run a "predefined
command" when it finishes, but it is not stated how this command is
defined or where and how it can be set.

Running "jack -x eject" causes an error message to be displayed. Running
"jack -x=exec_rip_done" does nothing after finishing. From reading the
sources, it appears in /usr/share/pyshared/jack_main_loop.py that the
value of the configuration variable exec_rip_done is passed to
os.system() when -x is present.

Thus, in my case, simply "jack -x" did do what I want, and what it does
can be changed by setting exec_rip_done in your ~/.jack3rc.

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#520947: Repro instructions

[era eriksson]

I have had SpamAssassin eating a lot of memory.  In order to limit the
damage, I set it up with fairly aggressive ulimits.  Unfortunately, that
means I am now also getting this error message.  I don't see crashes,
though.

Here is a pared-down version of the script I use to start up spamd:

#!/bin/sh

ulimit -v 204800
ulimit -m 204800
ulimit -n 256
# This is the beef.  Try even lower numbers.
# I could not start it at all with ulimit -u 110
ulimit -u 150

perl -T -I lib -w spamd \
--configpath myrules \
--siteconfigpath mapsd.cf \
--helper-home-dir . \
--nouser-config \
--syslog stderr \
--min-children 2 \
--max-spare 5 \
--max-children 40 \
"$@"

The ulmit values are otherwise out of contrib/run-masses but I could not
run spamd at all with the ulimit -u 30 they have.

@Christian: If you signed up for Debian bug reports, only you can
unsubscribe.  You should see in the headers with what ID you have
subscribed; I believe you should also see an unsubscribe link there.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#685933: No, don't close

[era eriksson]

I don't think these bugs should be closed until there is a useful
diagnostic instead of an error message most users won't know how to
interpret.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#691345: emacs24: org-export fails without emacs24-el

[era eriksson]

Package: emacs24
Version: 24.1+1-2
X-Debbugs-Cc: era+deb...@iki.fi

Forwarding an emacs24 bug report from an Ubuntu user;
https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1064024
submitted by Fredrik Nyqvist on 2012-10-08:

When I am trying to export my .org document to another format by using
the command C-c C-e I get the response "Can't find library org".

 1) Ubuntu 12.10 Beta 2

 2) emacs24 24.1+1-2ubuntu3

 3) I want to export my .org file to pdf or other format using Emacs.

 4) I get the response "Can't find library org".

Here is the resulting Lisp backtrace:

Debugger entered--Lisp error: (error "Can't find library org")
  signal(error ("Can't find library org"))
  error("Can't find library %s" "org")
  find-library-name("org")
  (file-name-directory (find-library-name "org"))
  (expand-file-name "../contrib" (file-name-directory (find-library-name
  "org")))
  (file-name-as-directory (expand-file-name "../contrib"
  (file-name-directory (find-library-name "org"
  (expand-file-name "scripts" (file-name-as-directory (expand-file-name
  "../contrib" (file-name-directory (find-library-name "org")
  (file-name-as-directory (expand-file-name "scripts"
  (file-name-as-directory (expand-file-name "../contrib"
  (file-name-directory (find-library-name "org"))
  (expand-file-name "ditaa.jar" (file-name-as-directory
  (expand-file-name "scripts" (file-name-as-directory (expand-file-name
  "../contrib" (file-name-directory (find-library-name "org")))
  eval((expand-file-name "ditaa.jar" (file-name-as-directory
  (expand-file-name "scripts" (file-name-as-directory (expand-file-name
  "../contrib" (file-name-directory (find-library-name "org"
  custom-initialize-reset(org-ditaa-jar-path (expand-file-name
  "ditaa.jar" (file-name-as-directory (expand-file-name "scripts"
  (file-name-as-directory (expand-file-name "../contrib"
  (file-name-directory (find-library-name "org"
  custom-declare-variable(org-ditaa-jar-path (expand-file-name
  "ditaa.jar" (file-name-as-directory (expand-file-name "scripts"
  (file-name-as-directory (expand-file-name "../contrib"
  (file-name-directory (find-library-name "org")))
  ("/usr/share/emacs/24.1/lisp/org/org-exp-blocks.elc" . 6155) :group
  org-babel :type string)
  require(org-exp-blocks)
  
byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\207"
  [require org org-macs org-agenda org-exp-blocks ob-exp org-src] 2)

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#663424: (no subject)

[era eriksson]

> Severity normal?  Really?  Anyway, I'm not really interested.

Color me dismayed.  This would be for the benefit of your users, not
primarily for you.
In fact, I'm certain that you already have access to your VCS.

For the record, I too would like to see this happen.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#679101: equivs: equivs-build: no quoting of $builddir

[era eriksson]

Package: equivs
Version: 2.0.9
X-Debbugs-Cc: era+deb...@iki.fi

I am hereby forwarding Ubuntu bug #1016402 to the upstream maintainer of
equivs from the Ubuntu bug tracking system.

https://bugs.launchpad.net/ubuntu/+source/equivs/+bug/1016402

--- cut --- 8< ---
Steps to reproduce:

1. mkdir -p '/tmp/a/a&&b&&c'
2. put some code and debian packaging into this dir
3. run mk-build-deps/equivs-build

Result:
mmrazik@fry:/tmp/a/a&&b&&c/autopilot$ equivs-build debian/control
sh: 1: b: not found
Error on copy of the template files: exit status 127

Expected result:
it works.

Patch attached.
--- >8 --- tuc ---

For your convenience, I am inlining the patch, since it is completely
trivial.  Perhaps there are other spots in the code which should be
audited for proper quoting, though.

--- equivs-build2012-06-22 09:27:18.0 +0200
+++ equivs-build.new2012-06-22 09:27:06.0 +0200
@@ -46,7 +46,7 @@
   usage();
 }
 
-system("cp -R /usr/share/equivs/template/* $builddir") == 0 or
+system("cp -R /usr/share/equivs/template/* \"$builddir\"") == 0 or
   die "Error on copy of the template files: exit status " . ($?>>8) .
   "\n";
 
 # Parse the equivs control file

If you accept the patch, please note that the original author is Martin
Mrazik, not me.  Thanks.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#677191: Add watch: LP#789706

[era eriksson]

Just a quick note that Ubuntu Launchpad has a largish number of recent
duplicates for this bug. 
https://bugs.launchpad.net/ubuntu/+source/xemacs21/+bug/789706

xemacs21 has been stable (as in basically unmaintained in Ubuntu) for a
long time, across several Ubuntu releases.  This points to
emacsen-common as the likely source for whatever exposes this, although
it may well be that the root cause for the bug is in the xemacs21
packaging.

#313511 looks similar, maybe the changes discussed there are actually
relevant for this case?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#594514: Belatedly tagging

[era eriksson]

tags 594514 + wontfix
thanks

As per Rob's latest comment (only from 2010 ...) I am tagging this as
wontfix.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#409058: Fixed?

[era eriksson]

package readpst
notfound 409058  0.6.54-0ubuntu1
thanks

This is not reproducible on Ubuntu Precise.  Because the Ubuntu diffs
show no indication that there is any Ubuntu-specific fix for this, I
speculate that it is fixed (or for all I know wfm),

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#312829: reassign to anthy-el?

[era eriksson]

Shouldn't you instead reassign this to anthy-el?  anthy-el Requires:
emacsen but should probably also Conflicts: xemacs21-nomule if the
analysis earlier in this bug report is correct.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#686113: Coordinate with similar Ubuntu bugs

[era eriksson]

The following two Ubuntu bugs have similar symptoms:

* https://bugs.launchpad.net/ubuntu/+source/maildir-utils/+bug/1150593
* https://bugs.launchpad.net/ubuntu/+source/maildir-utils/+bug/1199553

The former reports that replacing an elpa install of org-mode with the
Ubuntu-packaged org mode fixed things for him.  (If the elisp sources
are required, I would sort of expect it to be the other way around? Or
does elpa also only install elc files?)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#686113: Workaround: Temporarily uninstall mu4e

[era eriksson]

We now have a report that uninstalling mu4e allows the emacs24 install
to finish, whereby mu4e can be installed successfully as well.

To follow up on my earlier note, I'm beginning to think that the elpa
diagnostic was wrong, and that the real issue is the sequence in which
you install emacs24 and mu4e.  Maybe emacs24-el just happened to set
things up to happen in the proper order as well, and is not a true
requirement?

Sorry for talking to myself here ...

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#714131: bugs.debian.org: inline attachment view; "full text" isn't

[era eriksson]

Package: bugs.debian.org
Severity: minor
X-Debbugs-Cc: era+debb...@iki.fi

When looking at a bug via the web interface, it would be useful to be
able to browse patches without downloading them.  Frequently, this is
not possible, because the patches are served with a
"content-disposition: attachment" which cause most browsers to display a
download dialog.

If I'm just browsing, and just want to take an informal look at the
proposed patch, it would be much more useful to have it served as
"Content-type: text/plain; Content-disposition: inline" and thus
rendered in the browser just like any other textual content.

(Granted, some patches are base64 encoded and/or compressed.)

The BTS web interface offers "full text" and "mbox" links for each
message on a web page.  I don't know what problems they are intended to
solve and for whom, but it would be a nice first approximation if the
"full text" link would actually display the full MIME source, rather
than just render the (full) headers.

Alternatively, perhaps each attachment could be made available via a
separate "inline" link as well -- by the looks of the href, the back end
already has the file as a separate object.  If the browser cannot render
it, too bad.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#653279: (no subject)

[era eriksson]

As you can tell by the diagnostic output, you cannot use a regex anchor
to signal beginning of file in this context.  Did you get the impression
from the documentation that this ought to be possible?  An easy patch
would be to convert any initial '^' anchor in the search expression to
the separator used in /var/lib/dlocate/dlocatedb before running the grep
command (that is, convert it to ': ') but then the -S regex template has
to be tweaked slightly to accommodate this change.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#655971: tags 655971 +patch

[era eriksson]

tags 655971 +patch
thanks

The linked CVE report has a forward link to a git repo with patches for
Debian et al.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#543564: lintian check against info/dir(.gz)?

[era eriksson]

On Tue, 14 Feb 2012 10:42:47 +, Richard Kettlewell
 wrote:
> Perhaps there should be some systematic approach to preventing
> packages shipping such toxic files?

There is; bug #535566.

(Omitting cc: 659...@bugs.debian.org as it's already fixed in cvs.)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#667451: haskell-mode: fails to support emacs-snapshot et al.

[era eriksson]

Package: haskell-mode
Version: 2.7.0-2.1
Severity: wishlist
X-Debbugs-Cc: era+deb...@iki.fi
Tags: patch

The patch for #568579 would appear to also drop support for e.g.
emacs-snapshot.  I use neither emacs-snapshot nor haskell-mode, so I'm
not going to push this any further, but if you publish another update at
some point, you might want to change the logic to explicitly ignore
xemacs21 and support everything else, instead of the other way around.

The patch also changes the behavior for the case when ${FLAVOR} is just 'emacs' 
-- I'm not intimately familiar with this part of the Debian emacsen 
infrastructure, but you might want to reinstate the quiet behavior that existed 
before the NMU.

For context, here is the patch from that bug report:

-if [ ${FLAVOR} = emacs ]; then exit 0; fi
+case ${FLAVOR} in
+emacs2[2-9]*)
+   echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
+   ;;
+*)
+   echo install/${PACKAGE}: Ignoring emacsen flavor ${FLAVOR}
 
-echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
+   exit 0
+   ;;
+esac

Here is my proposal for a revised patch:

-if [ ${FLAVOR} = emacs ]; then exit 0; fi
+case ${FLAVOR} in
+emacs)
+   exit 0
+   ;;
+xemacs21)
+   echo install/${PACKAGE}: Ignoring emacsen flavor ${FLAVOR}
+   exit 0
+   ;;
+*)
+   echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
+   ;;
+esac

Finally, shouldn't "Depends: whatever | xemacs21" be dropped from 
debian/control?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#588961: Close as unreproducible

[era eriksson]

tag 588961 +unreproducible +wontfix
close 588961
thanks

Submitter: This bug report does not contain sufficient information to
diagnose the problem.  It looks like a communications error with gksu. 
If you are able to diagnose the problem, please feel free to reopen and
perhaps reassign to gksu, or whichever component originally
misconfigured things on your system.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#775974: lists.debian.org: Disable AHBL in SpamAssassin

[era eriksson]

Package: lists.debian.org
X-Debbugs-Cc: era+deb...@iki.fi

Apparently, all messages now get the AHBL hit, which increases the
likelyhood of spam false positives. Spot checks reveal this problem at
least on debian-user-spanish, debian-russian, and debian-l10n-french,
but apparently, all lists are affected.

For example, a recent message to debian.user-spanish [1] has the
following SpamAssassin headers:

X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
bendel.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-9.4 required=4.0 tests=DNS_FROM_AHBL_RHSBL,
LDOSUBSCRIBER,LDO_WHITELIST,RDNS_NONE autolearn=unavailable
version=3.3.2

While the total score is fine, the AHBL hit is spurious, and the rule
should be disabled.  The service was decommissioned on Jan 1, 2015, and
is now returning a blocked status for all queries; here is the DNSBL
maintainer's announcement:

http://www.ahbl.org/content/changes-ahbl

Tangentially, see also http://article.gmane.org/gmane.discuss/16570

[1] https://lists.debian.org/debian-user-spanish/2015/01/msg00195.html
but this view does not include full headers.  You could also access it
over NNTP from Gmane.org for full headers -- I think a useful URL could
be news://news.gmane.org/gmane.linux.debian.user.spanish:197903 but I
don't have a tool I can check this with (maybe change news: to nntp:
IIRC?)

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#566943: Repro attempt

[era eriksson]

I tried to send email to 566943-h...@bugs.debian.org as suggested in the
feedback from the (then?) list maintainer, and got nothing back.

I sent another bug report in the meantime and that registered properly,
and I got the expected reply, so my mail does seem to be going through,
both ways.

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#774768: See also #775974

[era eriksson]

Tangentially, see also #775974

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#663424: sources.debian.net to the rescue

[era eriksson]

As a partial remedy, sources.debian.net now exposes the sources for
browsing, though it's not quite the same as having them on Github.

https://sources.debian.net/src/equivs/

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#798320: aptitude: returns 0 (success) exit code when no packages found

[era eriksson]

Package: aptitude
Version: 0.6.11-1+b1
X-Debbugs-Cc: era+deb...@iki.fi

I bumped into another case where a zero (success) exit code was produced
when the requested action could not be taken.  I'm submitting this as a
separate bug report even though it has similarities with e.g. #590686
and #592818 and should hopefully be possible to fix with similar means.

The scenario has to do with installing i386 packages on an x86_64
system. I can successfully "dpkg --add-architecture i386" but the
partial mirror in the test network we have at work doesn't carry any
i386 packages, so they cannot be installed.

dpkg --add-architecture i386 && aptitude update && aptitude install -y
libc6:i386 || echo failed

appears to succeed in this scenario; whereas with apt-get instead of
aptitude, I get the desired and expected behavior.

The output from aptitude is:

jessie$ sudo aptitude install -y libc6:i386
Couldn't find any package whose name or description matched "libc6:i386"
Couldn't find any package whose name or description matched "libc6:i386"
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

jessie$ echo $?
0

Note that this also masks the error when you did dpkg --add-architecture
but forgot to do apt-get update to download new package indices for the
architecture you added. (Also notice the unattractive but harmless
duplicated message.)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#803767: debian-changelog-mode: don't rely on external date (LP#1197870)

[era eriksson]

Package: dpkg-dev-el
Version: 35.12
Tags: patch
X-Debbugs-Cc: era+deb...@iki.fi

The current debian-changelog-mode shells out to coreutils' date.

To increase  portability (some  developers work  on packages  from other
architectures), it would be nice to see this clean up get integrated:

https://github.com/pcarrier/debian-changelog-mode/commits/master

---
Belatedly forwarding upstream this bug from the Ubuntu Launchpad.

https://bugs.launchpad.net/ubuntu/+source/emacs-goodies-el/+bug/1197870

The original  submitter was Pierre  Carrier; please make sure  to credit
him properly if/when you merge this.

--
If this were my real .signature, it would suck much less.  Well, maybe.

Bug#761621: bash: cannot echo $'\x00'

[era eriksson]

Package: bash
Version: 4.1-3
Severity: wishlist
X-Debbugs-Cc: era+debb...@iki.fi

I was somewhat surprised and miffed to find that this does not work.

I found old correspondence about this issue on the bash-bugs mailing
list [1] but it was hardly an exhaustive discussion.

[1]: http://lists.gnu.org/archive/html/bug-bash/2006-03/msg00063.html

To my mind, in particular the non-POSIX $'\x00' syntax could impossibly
be used in scripts which do not run Bash. It's not entirely clear to me
what the logic should be here; if the builtin echo really cannot support
this, then perhaps a warning message would be appropriate.

As noted in the 2006 discussion, a (portable!) workaround is to use
printf instead.

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#758192: unzip: prints to terminal, even with -qq

[era eriksson]

Package: unzip
Version: 6.0-4
Severity: minor
X-Debbugs-Cc: era+debb...@iki.fi

The unzip utility has odd, non-Unixy output handling.  There are
messages which are almost impossible to (guess how to) redirect or
squelch.  This includes (but may not be limited to) error output from
the unzip -t command.

squeeze$ unzip -t -qq LATAM43.zip >/dev/null
... produces a lot of output ...

squeeze$ unzip -t -qq LATAM43.zip 2>/dev/null
... still produces a lot of output ...

squeeze$ unzip -t -qq LATAM43.zip >file 2>&1

squeeze$ # oddly, only one copy of the output in file!

squeeze$ unzip -t -qq LATAM43.zip | less
... still messes up my screen ...

squeeze$ unqip -t -qq LATAM43.zip 2>&1 | less

squeeze$ # again, works, but not what you would expect

Unfortunately, the file in question contains material I cannot share,
but it should not be hard to come by broken ZIP archives. As a rough
approximation, you can observe the same behavior (but very different
error output) with just

squeeze$ echo moo>moo.zip

squeeze$ unzip -t -qq moo.zip 2>/dev/null

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772952: 7z: Error messages go to stdout

[era eriksson]

Package: p7zip-full
Version: 9.04~dfsg.1-1
Severity: minor
X-Debbugs-Cc: era+deb...@iki.fi

7z prints error messages to standard output.  This makes it impossible
to keep apart regular output and error messages, and violates user
expectations, if not applicable standards.

When you are running 7z as a subprocess, the intuition is to display
standard error (but not necessarily standard output) in case of an
error.  But this displays nothing at all, and loses the error message
for the user.

(The following demo case depends on what I believe is undocumented
behavior: passwords with newlines in them are rejected with -tzip.)

debian$ 7z a -p'4$$w0rD
' -tzip /tmp/archive.zip /etc/motd >/dev/null

debian$ echo $?
2

debian$ ls -l /tmp/archive.zip
ls: cannot access /tmp/archive.zip: No such file or directory

debian$ 7z a -p'4$$w0rD
' -tzip /tmp/archive.zip /etc/motd 2>/dev/null

7-Zip 9.04 beta  Copyright (c) 1999-2009 Igor Pavlov  2009-05-30
p7zip Version 9.04 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,1 CPU)
Scanning

Creating archive /tmp/archive.zip



System error:
E_INVALIDARG

This is tangentially related to #528200 -- whoever tackles one should
probably tackle the other at the same time.

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#346463: Bug#772952: 7z: Error messages go to stdout

[era eriksson]

package p7zip p7zip-full
forcemerge 346463 772952
thanks

Sorry, I foolishly only consulted the p7zip-full bug listing, and thus
missed the duplicate.

On Fri, Dec 12, 2014, at 14:46, era eriksson wrote:
> Package: p7zip-full
> Version: 9.04~dfsg.1-1
> Severity: minor
> X-Debbugs-Cc: era+deb...@iki.fi
> 
> 7z prints error messages to standard output.  This makes it impossible
> to keep apart regular output and error messages, and violates user
> expectations, if not applicable standards.
>
> When you are running 7z as a subprocess, the intuition is to display
> standard error (but not necessarily standard output) in case of an
> error.  But this displays nothing at all, and loses the error message
> for the user.

...

-- 
If this were a real .signature, it would suck less.  Well, maybe not.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#865401: base-passwd: erratic punctuation spacing in English debconf questions

[era eriksson]

Package: base-passwd
Version: 3.5.39
Severity: minor
X-Debbugs-Cc: era+deb...@iki.fi

I was playing around with debconf-get-selections, and noticed this:

root# debconf-get-selections | grep -A 1 ' ?' |
> sed -n $'/^[^-#]/s/\t.*//p' | uniq -c
 12 base-passwd

In English (unlike e.g. in French) orthography, question marks (and
exclamation marks) are typed adjacent to the preceding word, with no
space between.

root# debconf-get-selections | grep ' ?'
# Do you want to add the group ?
# Do you want to move the user ?
# Do you want to change the GID of user ?
# Do you want to remove the group ?
# Do you want to change the UID of user ?
# Do you want to remove the user ?
# Do you want to change the GID of group ?
# Do you want to change the shell of user ?
# Do you want to change the GECOS of user ?
# Do you want to move the group ?
# Do you want to change the home directory of user ?
# Do you want to add the user ?

On a fairly spare system (Docker image with just debconf-utils installed
in addition to the base system), this is the only package with this
problem. There are strings with question marks which are correctly
formatted in libc6, dash, adduser, and libpam-runtime. (This was
actually an Ubuntu image, for what it's worth; but the package version
indicates that base-passwd package was copied verbatim from Debian.)

For consistency, please adjust these strings to fix the formatting.  sed
's/ ?/?/g'

I realize this will trigger a pesky review of the translations of these
strings.  Maybe somehow the translator teams need to be included for
coordination.

Incidentally, I notice the same problem in ucf, but I don't have the
time to go through every package, nor to coordinate mass bug filing at
this point.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#841038: Odd formatting in PHP license position statement

[era eriksson]

Package: ftp.debian.org
Version: 20161017
Severity: minor
X-Debbugs-Cc: era+deb...@iki.fi

There is a Debian position statement regarding the PHP license at

https://ftp-master.debian.org/php-license.html

This was recently highligthed on DDA [1] and thus brought to my
attention.

The blockquote formatting on this page seems wrong.  I guess the
following pseudo-diff against the page HTML should be applied (which
also includes a simple typo fix near the beginning):


  Debian packages include PHP and PHP add-ons but we don't
- attempt to, nor can we, resolve the impossible quandry
+attempt to, nor can we, resolve the impossible quandary
  that the language of the PHP 3.01 license creates. It is
  a free software license and we modify the software and
  correctly designate the source of its origin by calling
  it PHP or X for PHP. The license requires us to make a
  statement:


  "This product includes PHP software, freely available
  from
- http://www.php.net/software/";, the veracity of which
cannot be
+http://www.php.net/software/";
+the veracity of which cannot be
  verified by us, nor can we be held responsible for the
maintenance of the link.
-   

Even with these changes, it is not clear (at least to me) which part(s)
of the position statement needs to be included in PHP packages.  Perhaps
the page could be reorganized to contain a specific copy/pastable
snippet for easy reuse?

I hope reporting the problems via a bug report against ftp.debian.org is
acceptable procedure.  If not, please help me understand how to bring
this up properly.

Thanks in advance,

/* era */

[1] https://lists.debian.org/debian-devel-announce/2016/10/msg4.html

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#426166: Perhaps be more explicit about creating a separate file

[era eriksson]

I like this suggestion, but I had to read it three times to see that you
actually mentioned putting these commands in a file.  Perhaps this could
be a little bit more explicit?  For newbies, it might also be useful to
say a word or two about how to create a useful name for the file (I
personally add ".local" to all my own files in /etc/modprobe.d, for
example).

Also, I'm afraid /usr/share/doc/module-init-tools/FAQ is not a visible
enough location for this information.  Perhaps even a patch against the
modprobe.conf manual proper could be considered?

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.



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

Bug#468806: mguesser: upstream mail address changed

[era eriksson]

Package: mguesser
Version: 0.2-5.1
Severity: minor
X-Debbugs-Cc: [EMAIL PROTECTED]

As incidentally reported in #184333, the upstream contact address in
debian/copyright etc is no longer current.  You might want to update it.
 [EMAIL PROTECTED] still appears to work.  (See further also
 and
also bug #400462 which has a link to the upstream bug tracker.)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.




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

Bug#456292: dlocate: ionice in cronjob does not work in VServer

[era eriksson]

On Sun, 2 Mar 2008 09:51:39 +1100, "Craig Sanders" <[EMAIL PROTECTED]>
said:
> there's a few other things i want to fix in the next release
> (especially #42 - that's a serious bug rather than just an
> annoyance)i'll upload 0.95 when i've finished them.

It occurred to me that it might be useful to add a comment to explain
the reason you redirect stderr from iostat to /dev/null -- this is one
of those things a possible future maintainer might be hesitant to touch
unless it's documented somehow.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.




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

Bug#451750: dlocate: Does not work with split-off locate package

[era eriksson]

On Sun, 18 Nov 2007 09:26:09 +0100, "Andreas Metzler"
<[EMAIL PROTECTED]> said:
> It would be nice if this fix should be uploaded *before* locate is
> going to sid.

Could somebody who is a Debian Developer please do a MIA check on Craig
Sanders, still the owner of dlocate?  He might simply be ignoring his
dlocate mail, or something, but in any event, judging from several of
the open bugs against dlocate, it has been a challenge in the past to
get through to him.  In fact, the last non-NMU upload of this package
was in 1999, although Craig has commented on some bugs as recently as in
2005 IIRC.

I'd be happy to act as a co-maintainer or something if that helps at
all.  I'm not a DD though.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.




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

Bug#451750: dlocate: Does not work with split-off locate package

[era eriksson]

On Sun, 18 Nov 2007 09:26:09 +0100, "Andreas Metzler"
<[EMAIL PROTECTED]> said:
> following a brief discussion o debian-devel locate is going to be
> split off from the findutils package. 
> []
> This has already happened in experimental and will soon be done in
> sid, too. A fix to make dlocate work both with the curent setup and a
> separate locate package is attached.
<...>
> +if [ -x /usr/bin/locate.findutils ] ; then
> + # locate package is installed
> + LOCATE="/usr/bin/locate.findutils" 
> +else
> + # slocate diverts locate
> + LOCATE=`/usr/sbin/dpkg-divert --truename /usr/bin/locate`
> +fi

If I understood the discussion on the mailing list correctly, the new
slocate would use the alternatives mechanism, too, and you are now
requiring a suitable version of locate to be installed, so isn't the
slocate case dead code under these circumstances?  Sure, it's required
for the transition phase (if somebody has findutils << 4.2.31-2 and
slocate), but wouldn't it be simpler to say Conflicts: slocate <= older
than this transition?

... Hmm, or add a comment that this could be changed in lenny+1 to
conflict with slocate <= old and remove this case from the code?

Just thinking out loud here; sorry for the interruption.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.




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

Bug#451940: bugs.debian.org: uninformative bounce for mzil to archived bugs

[era eriksson]

Package: bugs.debian.org
Severity: minor
X-Debbugs-cc: [EMAIL PROTECTED]

On Sun, 18 Nov 2007 17:47:07 -0500 (EST), the olde mailer daemon said:
> <[EMAIL PROTECTED]>: host bugs.debian.org[140.211.166.43] said:
> 550 unknown user (in reply to RCPT TO command)

Turns out that this bug was archived, and for that reason, I could not
add a comment.  Would it perhaps be possible to provide a more
informative error message than "unknown user" in this case?

Attempting to manipulate the bug via [EMAIL PROTECTED] gave a much
more useful error message.

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.




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

Bug#408309: Updated patch proposed

[era eriksson]

See also https://bugs.launchpad.net/ubuntu/+source/apt-file/+bug/176757

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.




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

Bug#448598: Raising severity -- causes data loss

[era eriksson]

severity 448598 grave
thanks

Justification: data loss

> sudo tar --ignore-failed-read  -C /media/data_big -cv -f - . |
>  sudo tar -C /mnt -x -f -
>
> Unfortunately, after the reading tar encountered about three
> unreadable files, the two processes got desynchronized somehow, and
> stracing the receiver tar revealed that it did nothing but read lots
> of data from standard input.  As a result, nothing got to the
> destination disk after the read errors were encountered.

This must be what bit me as well.  I backed up my old laptop and
decommissioned it, only to find to my surprise only weeks later that
only half of /home and nothing after that had been copied.  Good thing I
noticed before the hard drive died completely; the partition table had
already gone AWOL but I was able to reconstruct it and start copying
stuff in smaller batches.

The --ignore-failed-read option is by no means necessary.  What I had
was "file changed size", for whatever reason (I'll see if I can repro;
actual file size different from what the directory says it should be?).

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.




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

Bug#443930: auctex: Help links to elisp source don't work

[era eriksson]

> LaTeX-mode-hook is a variable defined in `/usr/share/emacs22/site-
> lisp/auctex/latex.elc'.
> 
> and if I try to follow the link it doesn't work. Not a surprise, since
> you need to drop the "22" to get it to work. What I don't understand
> is why the link is wrong in the first place.

Notice the ".elc".  The byte-compiled files are in a different directory
than the source ".el" files.  I'm guessing you don't have the source
directory in you `load-path' (but this is a shot from the hip; haven't
tested whether this would in fact cause this, or solve it).

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org