Bug#1040237: New project leader of Masqmail: Oswald Buddenhagen

[markus schnalke]

Hoi,

it has been several years without any work by me on masqmail.
Recently, Debian decided to kick the masqmail package out of its
repos, which is understandable as it has been RC-buggy for years
without a maintainer. This motivated Oswald Buddenhagen to revive
the project. :-)

We exchanged emails and now I officially want to hand over the
project to him.

The new home of masqmail is:

https://github.com/ossilator/masqmail

My masqmail website will remain as an archive. If there's a wish or
need to change the mailinglist, it'll be announced here.


It's nice to see masqmail come back to life again, in a way similar
to when I took it over from Oliver Kurth. Oswald, however, is not
new to the project; he used it long before I even heard of it. ;-)


meillo

Bug#1040237: RM: masqmail -- RoQA; dead upstream, RC-buggy

[markus schnalke]

Hoi.

[2023-07-03 20:21] Moritz Muehlenhoff 
>
> Please remove masqmail. It's dead upstream, orphaned without an adopter
> since 2015 and RC-buggy (dropped from testing since 2017).

I agree. It does no longer make sense to keep the masqmail package.
I haven't worked on neither upstream nor the package for years and
don't see that change. Thanks for cleaning up.


meillo

Bug#951045: Omit space after ``VERSION:'' in Vcard creation

[markus schnalke]

Package: readpst
Version: 0.6.74-1

Hoi.

The Vcard files readpst creates include a line:

VERSION: 3.0

The whitespace after the colon is invalid for Vcards. Thunderbird
can not import it. Correct is:

VERSION:3.0

The attached patch should fix this.


Thanks goes to debianoli at debianforum.de for discovering this bug
and finding the solution to the problem. I only created the patch
and report it.


meillo
diff -r c6b10ac09bb6 src/readpst.c
--- a/src/readpst.c	Sun Jan 12 15:31:30 2020 -0800
+++ b/src/readpst.c	Mon Feb 10 11:56:52 2020 +0100
@@ -2015,7 +2015,7 @@
 
 write_extra_categories(f_output, item);
 
-fprintf(f_output, "VERSION: 3.0\n");
+fprintf(f_output, "VERSION:3.0\n");
 fprintf(f_output, "END:VCARD\n\n");
 if (result) free(result);
 DEBUG_RET();

Bug#882316: masqmail fails to install on amd64 architecture

[markus schnalke]

Hoi.

[2017-11-21 12:32] Tomasz Ciborski 
>
> Dear Maintainer,
> 
> I tried to install masqmail on my system via aptitude but it fails every time.
> The error message I get from aptitude is:
> E: Internal Error, No file name for masqmail:amd64▒
> I can't use the package at all.

Thanks for your interest in masqmail.

Unfortunately, masqmail is no longer maintained in Debian. Please
have a look at bug #797301.

If you want to use masqmail, install it from upstream source. (Plus
an MTA equivs package to satisfy dependencies.)

If you are a Debian maintainer, you're welcome to fix the masqmail
package. :-)


Greetings,


meillo

Bug#812616: O: masqmail

[markus schnalke]

Package: wnpp
Severity: normal

Hoi,

this is the follow-up to the RFA in bug #797301.

Since no one wanted to adopt the package, I orphan it now. If
someone though is interested in adopting the package, I'd glad
to be as helpful as possible.


meillo

Bug#797301: RFA: masqmail

[markus schnalke]

Package: wnpp
Severity: normal

Hoi,

some years ago, my work in Debian started by adopting the
non-maintained masqmail package, because I were afraid that it
would drop out of Debian otherwise. Shortly afterwards I also
became masqmail's upstream developer. While I still care for
upstream and use it myself, I don't find the time and interest
to care for the Debian package any longer. A joint effort with
Steffen Rumberger and jhr to modernize the package and switch
to the 0.3 branch of masqmail got stuck halfway through.

Our common decision is to search for a new package maintainer
now.

We would be happy to find someone who modernizes the package.
There's a bunch of work by Steffen, which misses only some
further cleanups, we think. Someone with knowledge of modern
Debian packaging should be well able to do this. Because
masqmail is an MTA and a config migration to 0.3 is needed,
its package is not trivial, but on the other hand, one is
able to learn a lot with this package.

As the upstream author, I offer full support to the package
maintainer.

Upstream development is low, thus few regular packaging work
will be necessary, after the package is modernized once. (It
would be already of great help, if a one-time modernization
would be done.)


meillo


P.S.
If no new maintainer is found until 2015-12-01, I'll change
the RFA to O.

Bug#728622: initramfs-tools: post-update.d/runlilo fails if RAID is degraded

[markus schnalke]

Package: initramfs-tools
Version: 0.109.1
Severity: important

Dear Maintainer,

the root filesystem of my system resides on a degraded mdadm RAID1. This leads
to the situation that I cannot install some packages. Here the apt-get output:

Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-3.2.0-4-686-pae
Warning: LBA32 addressing assumed
Fatal: Not all RAID-1 disks are active; use '-H' to install to active 
disks only
run-parts: /etc/initramfs/post-update.d//runlilo exited with return 
code 1
dpkg: error processing initramfs-tools (--configure):
 subprocess installed post-installation script returned error exit 
status 1
Processing triggers for python-support ...
Processing triggers for menu ...
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

I had the same problem with D-I as well, wenn I wanted to install lilo, it 
failed.
I managed to work around the problem by switching to the shell and running 
`lilo -H'
manually.

It might be a solution to use the `-H' flag of lilo in
/etc/initramfs/post-update.d//runlilo

IMO the system should be fully usable if the RAID it resides on is degraded.
(In my current case, I'll add the second disk when the system is fully running
and I've copied the data from the second disk to the new system.)


meillo


-- Package-specific info:
-- initramfs sizes
-- /proc/cmdline
auto BOOT_IMAGE=Linux ro root=900

-- /proc/filesystems
ext4

-- lsmod
Module  Size  Used by
dm_mod 57362  0 
ppdev  12651  0 
lp 12797  0 
loop   17810  0 
usblp  17115  0 
snd_wavefront  26625  0 
snd_cs4236 26487  0 
snd_opl3_lib   13141  2 snd_cs4236,snd_wavefront
nouveau   526808  2 
snd_hwdep  12943  2 snd_opl3_lib,snd_wavefront
mxm_wmi12467  1 nouveau
wmi13051  2 mxm_wmi,nouveau
snd_wss_lib22493  2 snd_cs4236,snd_wavefront
snd_mpu401 12633  0 
snd_mpu401_uart13299  3 snd_mpu401,snd_cs4236,snd_wavefront
video  17459  1 nouveau
snd_seq_midi   12744  0 
snd_intel8x0   22372  0 
ttm47786  1 nouveau
snd_seq_midi_event 13124  1 snd_seq_midi
snd_ac97_codec 84236  1 snd_intel8x0
snd_rawmidi22472  3 snd_seq_midi,snd_mpu401_uart,snd_wavefront
drm_kms_helper 22738  1 nouveau
snd_pcm53461  4 
snd_ac97_codec,snd_intel8x0,snd_wss_lib,snd_cs4236
snd_page_alloc 12867  3 snd_pcm,snd_intel8x0,snd_wss_lib
i2c_sis96x 12485  0 
drm   146387  4 drm_kms_helper,ttm,nouveau
power_supply   13283  1 nouveau
i2c_algo_bit   12713  1 nouveau
snd_seq39512  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device 13016  4 snd_seq,snd_rawmidi,snd_seq_midi,snd_opl3_lib
snd_timer  22356  4 snd_seq,snd_pcm,snd_wss_lib,snd_opl3_lib
ns558  12431  0 
snd42722  14 
snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_rawmidi,snd_ac97_codec,snd_intel8x0,snd_mpu401_uart,snd_mpu401,snd_wss_lib,snd_hwdep,snd_opl3_lib,snd_cs4236,snd_wavefront
parport_pc 22036  1 
evdev  17225  9 
gameport   13375  2 ns558
pcspkr 12515  0 
soundcore  12921  1 snd
ac97_bus   12462  1 snd_ac97_codec
parport31254  3 parport_pc,lp,ppdev
i2c_core   19116  5 
i2c_algo_bit,drm,i2c_sis96x,drm_kms_helper,nouveau
shpchp 26717  0 
button 12817  1 nouveau
processor  27565  0 
ext4  306996  2 
crc16  12327  1 ext4
jbd2   52330  1 ext4
mbcache12938  1 ext4
raid1  26218  2 
md_mod 85719  3 raid1
usbhid 31554  0 
hid60152  1 usbhid
usb_storage35142  0 
sg 21476  0 
sd_mod 35425  3 
sr_mod 17468  0 
crc_t10dif 12332  1 sd_mod
cdrom  34813  1 sr_mod
ata_generic12439  0 
pata_sis   13123  2 
libata125014  2 pata_sis,ata_generic
ohci_hcd   22059  0 
ehci_hcd   35509  0 
floppy 48087  0 
scsi_mod  135037  5 libata,sr_mod,sd_mod,sg,usb_storage
fan12594  0 
thermal13103  0 
thermal_sys17752  4 thermal,fan,processor,video
firewire_ohci  26784  0 
usbcore   104555  6 ehci_hcd,ohci_hcd,usb_storage,usbhid,usblp
sis900 21945  0 
mii12595  1 sis900
usb_common 12338  1 usbcore
firewire_core   

Bug#678493: masqmail: prompting due to modified conffiles which were not modified by the user

[markus schnalke]

[2012-06-23 11:39] Andreas Beckmann deb...@abeckmann.de
 On 2012-06-23 11:24, markus schnalke wrote:
  Surprisingly, the piuparts website reports the package to be successful:
  http://piuparts.debian.org/sid/source/m/masqmail.html
 That's not an upgrade test.
 
 Look here (some time in the future, package is not yet tested,
 dependencies are still queued):
 http://piuparts.debian.org/testing2sid/source/m/masqmail.html

Thanks a lot for the clarification.


meillo



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

Bug#678361: stopped expanding aliases

[markus schnalke]

[2012-06-21 07:40] Raf Czlonka rafal.czlo...@gmail.com
 
 After upgrading to the new version masqmail stopped expanding aliases.

Thanks for the bug report. I apologize for the inconveniece.

 Mail which usually landed in my mailbox ended up in root's.

I agree that masqmail should do aliasing by default as the old package
had done. We'll fix this with the next package version.

 Upgrade should not break the current setup without any warning.

We do warn using the debian NEWS file, conforming to the policy.

The NEWS entry contains a warning that the transition from 0.2.x
versions to 0.3.x versions is not possible without human actions. The
administrator must check the configuration manually.


meillo



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

Bug#673551: Processed: Bug#673551: ifupdown: error during boot: grep: unrecognized option '--all'

[markus schnalke]

[2012-06-09 14:07] Andrew Shadura bugzi...@tut.by
 On Sat, 09 Jun 2012 12:55:47 +0200
 markus schnalke mei...@marmaro.de wrote:

 IFACE can be used only when you're sure it holds what you expect it
 to hold. If you expect a name of iface ... inet stanza, you should
 also check ADDRFAM for inet. If you probably expect inet6 things
 too, you should check ADDRFAM for it as well.

 Can we conclude that there is an issue that should be solved, but it
 is not related to masqmail anymore? (Well, at least as soon as the new
 package is uploaded.)

 No, it's masqmail's issue. It's not using IFACE properly.

As masqmail-0.3.4-1 neither uses IFACE nor any other ifupdown stuff
anymore, I believe it's not masqmail's issue anymore.

Andrew, do you agree this bug is solved for masqmail now?


Nonetheless, thanks for your suggestings to improve our script.


meillo



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

Bug#661591: Bug #661591: packages providing ifupdown scripts must have those scripts fixed if needed

[markus schnalke]

Andrew,

why do you think bug #661591 is not fixed?

Was it this missleading changelog message:

Ifupdown hooks are not installed by default anymore.

Or do you have other reasons?

Masqmail-0.3.4-1 doesn't install ifupdown hooks at all. Actually, it
does not at all interface ifupdown anymore.

Is there any reason why this bug should not be considered fixed?


meillo



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

Bug#678361: stopped expanding aliases

[markus schnalke]

[2012-06-23 12:22] Raf Czlonka rafal.czlo...@gmail.com
 
 /etc/aliases being the default on many unices I simply assumed that
 you can point to a different alias file but the default one would be
 read when the alias_file= is commented out, especially when
 the config file doesn't contain expand_aliases=true/false it
 seemed strange to me that alias_file would both point to an alias
 file AND enable alias expansion.

Thanks for sharing your thoughts.

Upstream masqmail does not assume there is such a default as
/etc/aliases. Thus your expectations didn't match. But by defaulting
to /etc/aliases in further package versions we solve this problem for
Debian.


 On Sat, Jun 23, 2012 at 11:08:29AM BST, markus schnalke wrote:
  
  We do warn using the debian NEWS file, conforming to the policy.
  
  The NEWS entry contains a warning that the transition from 0.2.x
  versions to 0.3.x versions is not possible without human actions. The
  administrator must check the configuration manually.
 
 Debian Policy seems to be aimed at maintainers and developers...
 ...not end users ;^)

IMO, the problem is rather that the NEWS entries are not displayed by
default.


meillo



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

Bug#661591: Bug #661591: packages providing ifupdown scripts must have those scripts fixed if needed

[markus schnalke]

affects 661591 - masqmail
thanks

[2012-06-23 20:44] Andrew Shadura bugzi...@tut.by
 On Sat, 23 Jun 2012 12:30:09 +0200
 markus schnalke mei...@marmaro.de wrote:
 
  Or do you have other reasons?
 
 Obviously, because it wasn't filed against masqmail.

Oh, now I see. Seems as if I am not enough used to the Debian BTS.

I'll only remove masqmail from being affected by the bug.

Sorry for the inconvenience.


meillo



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

Bug#678493: masqmail: prompting due to modified conffiles which were not modified by the user

[markus schnalke]

[2012-06-22 09:37] Andreas Beckmann deb...@abeckmann.de
 Package: masqmail
 Version: 0.3.4-1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: piuparts
 
 Hi,

Thanks for your report.

 during a test with piuparts I noticed your package failed the piuparts
 upgrade test

Surprisingly, the piuparts website reports the package to be successful:
http://piuparts.debian.org/sid/source/m/masqmail.html


Nevertheless, we're investigating and working on it. We appreciate
the useful and details information you've provided. Thanks.


meillo



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

Bug#673551: Processed: Bug#673551: ifupdown: error during boot: grep: unrecognized option '--all'

[markus schnalke]

tags 673551 pending
thanks

Hello,

thanks for reporting this bug and thanks for the discussion already
done.

We are currently working on the transition from masqmail-0.2.x to
masqmail-0.3.x. The new package is 98% finished and will be uploaded
very soon. It does not interface with ifupdown anymore. Hence, the bug
report becomes irrelevant for new package version of masqmail.


Nonetheless, I like to know and remove the cause of the problem. Let's
dig down!

In masqmail's ifupdown script, there's the following snippet:

if [ ! x$IFUP_IFACES = xall ] ; then
echo $IFUP_IFACES | grep $IFACE  /dev/null || exit 0
fi

(If IFUP_IFACES contains the magic value ``all'', then we go on in all
cases, otherwise we go on only if the current interface is one of the
inferfaces we care for.)

The grep in this snippet is the grep that breaks. (It's the only one
in the script.)

The IFUP_IFACES variable is set in /etc/default/masqmail, which is
created during debconf (in postinst):

db_get masqmail/ifup_ifaces || true
echo IFUP_IFACES=\$RET\  $DEBDEFTMP

The relevant debconf question is:

Template: masqmail/ifup_ifaces
Type: string
Default: all
_Description: List of interfaces used for Masqmail online detection:
 Please choose a list of network interfaces which will trigger queue
 runs and/or fetching mails when going up. The list will be used in
 the /etc/ppp/ip-up and /etc/network/if-up.d/ scripts, when the
 interface goes up.
 .
 A reasonable choice is for instance ppp0 for a home computer
 connected by PPP or ppp0 eth0 for a notebook.
 .
 Other possible choices are all to listen on all network interfaces,
 or none for not listening on any interface.

Now, I'd like to have a look at the bug reporter's
/etc/default/masqmail file. What value has it assigned to IFUP_IFACES?
I guess that it's ``--all'', instead of ``all''.

@Thilo: Can you confirm?


If I've not missed anything, I'd declare this bug as misconfiguration
by user and thus no bug in the package.

Anyway, the soon uploaded new package won't include this ifupdown
script.


meillo



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

Bug#673551: Processed: Bug#673551: ifupdown: error during boot: grep: unrecognized option '--all'

[markus schnalke]

[2012-06-09 11:13] Raf Czlonka rafal.czlo...@gmail.com
 
 It seems like you've missed what I've written in my previous email,
 it is IFACE variable which holds --all, not IFUP_IFACES.

True. You're right.

 Also, since IFACE is not declared anywhere in the script and by
 testing I found out that is being passed from if{up,down} as no
 matter which /etc/network/ip-up.d/ script I put echo $IFACE
 I get --all after running ifup -a.

Am I right that doing another check would be a hack to solve the
issue?

if [ ! x$IFUP_IFACES = xall ] ; then
if [ ! x$IFACE = x--all ] ; then
echo $IFUP_IFACES | grep $IFACE  /dev/null || exit 0
fi
fi


  Anyway, the soon uploaded new package won't include this ifupdown
  script.

That's the reason why I don't care too much about the issue.


meillo



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

Bug#673551: Processed: Bug#673551: ifupdown: error during boot: grep: unrecognized option '--all'

[markus schnalke]

[2012-06-09 13:27] Andrew Shadura bugzi...@tut.by
 On Sat, 9 Jun 2012 11:13:09 +0100
 Raf Czlonka rafal.czlo...@gmail.com wrote:
 
  Also, since IFACE is not declared anywhere in the script and by
  testing I found out that is being passed from if{up,down} as no
  matter which /etc/network/ip-up.d/ script I put echo $IFACE
  I get --all after running ifup -a.
 
 Of course, because it should be there.

  I guess IFACE shouldn't hold --all in the first place since a lot of
  scripts in the above location rely on it holding only an interface's
  name or all the scripts should be corrected not to use $IFACE.
 
 No, it should. Scripts should not rely on IFACE without also checking
 ADDRFAM or METHOD, as it may have nothing in common with a real
 interface name.
 
  I'm getting more and more confused to be honest and am not sure which
  behaviour is correct, --all being passed in IFACE by ifupdown
  (can someone more knowledgeable correct me if I'm wrong here) or
  scripts assuming the usage of $IFACE to be only a single interface
  name.
 
 IFACE can be used only when you're sure it holds what you expect it to
 hold. If you expect a name of iface ... inet stanza, you should also
 check ADDRFAM for inet. If you probably expect inet6 things too, you
 should check ADDRFAM for it as well.

Can we conclude that there is an issue that should be solved, but it
is not related to masqmail anymore? (Well, at least as soon as the new
package is uploaded.)


meillo



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

Bug#676352: unrtf: raquot misses terminating semicolon.

[markus schnalke]

Package: unrtf
Version: 0.19.3-1.1+b1
Severity: minor

The RTF code
\'bb
is translated to
raquot
for HTML output. However, it should be translated to
raquot;

Piping the output through
sed 's/raquot/;/g'
is a hack to solve the problem.


meillo


-- System Information:
Debian Release: 6.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages unrtf depends on:
ii  libc6 2.11.3-3   Embedded GNU C Library: Shared lib

unrtf recommends no packages.

unrtf suggests no packages.

-- no debconf information



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

Bug#674666: masqmail: make use of lsb fancy boot messages

[markus schnalke]

[2012-05-26 16:59] Thilo Six t@gmx.de
 Package: masqmail
 Version: 0.2.30-1
 Severity: wishlist
 
 Dear Maintainer,
 
 please consider using lsb fancy boot messages in '/etc/init.d/masqmail'
 instead of plain echo. Thanks.

Thanks for the bug report.

We're currently preparing a new package which includes this feature.


meillo



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

Bug#654643: (no subject)

[markus schnalke]

severity 654643 important
thanks

There's still no confimation of the bug and no way to reproduce it.
Also, it is uncertain whether the bug is actually related to masqmail.


meillo



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

Bug#615895: New upstream of grap

[markus schnalke]

retitle 615895 O: grap -- program for typesetting graphs
thanks


First of all: Sorry for the long delay.

[2012-02-29 14:54] Tobias Quathamer to...@debian.org
 
 there's now a new upstream version of grap available (1.44). You might
 want to prepare that package for Debian and close this ITA bug at the
 same time.

Thanks for the reminder. I still do use troff and thus would like the
package to remain in Debian. But I've moved to Crux Linux with my
workstations. This has technical reasons, also related to Debian
packaging.

I did try to prepare a new package in January already, but after some
hours I gave up because I was frustrated by the need to learn to use
so many packaging technologies for such a small package. I do
understand Debians reasons and have discussed the topic a lot. Only,
my personal preference is different.


In concequence, I now withdraw my ITA and orphan the package again.


meillo



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

Bug#654643: *** SPAM ***

[markus schnalke]

tag 654643 moreinfo unreproducible
thanks

Olaf had told me in personal communication, that he would provide more
information to the bug in order to enable me to reproduce it and to
investigate. He wanted to do this one month ago. Unfortunately, he
didn't yet. The bug is still as before: vague and unreproducible.

Please, Olaf, provide more information!

I really like to get rid of this RC bug. Especially, I like to be able
to decide how serious it is for the users. I can't yet, unless I put
lots of time into this (possibly not masqmail-concerning) issue.


meillo


FYI:
We are currently preparing a new (and final) version of the 0.2
branch. Thereafter we are going to migrate the package to the 0.3
branch.



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

Bug#586765: Fixed upstream in version 1.6.0

[markus schnalke]

tag 586765 fixed-upstream
thanks


Just to let you know: This bug is fixed in the upstream version 1.6.0,
which had been released in June 2011.

Please package this new version, if you find the time. Thanks a lot.


meillo



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

Bug#654643: masqmail: Silently discards mails when mbox exceeds 2 GiB

[markus schnalke]

[2012-01-04 20:58] olafbuddenha...@gmx.net
 
 Dear Maintainer,

Hello Olaf,

I'm sorry to hear, you lost mail. I hope we can fix the bug soon.

Could you please provide additional information to speed the fixing up:

 I'm using masqmail -g to fetch email with pop3, and store them in a
 traditional mbox file. New mails silently ceased to arrive. (Luckly I
 discoverd this after irretrievably loosing only a bit more than 100
 mails...) It turns out my mbox reached a size of 2 GiB.

Which mbox is 2 GiB large: The remote one from which you fetch
(because you keep retrieved mails there) or the local one, to which
masqmail puts retrieved mails?

If it is the local mail box, is then the problem the same if you send
some message from the local system to this account? E.g.:
date | masqmail olaf

The point is: Does the problem sit in the POP retrieval code (get) or
in the local delivery code? It would be great if you can help to
identify the location.


 Not only does masqmail fail to store the mails: it doesn't even realize
 anything is wrong -- so there is no warning whatsoever, and the
 undelivered mails are purged from the queue.

The problem looks as if the size (in bytes) would be stored in some
signed 32bit data type. That would range until: 2,147,483,647.
Problems of this kind often fail silently.


meillo


P.S.
To explain my general point of view on masqmail:

The 0.2 branch of masqmail is dying out. It is only in a bug fixing
state. Development happens in the 0.3 branch, which, however is
changing to much to be suited to replace the 0.2-branch package in
Debian.

Newer versions of masqmail don't have the POP client anymore. If the
problem lies there, then my advice is clear: Use some other MRA
instead. Futur packages of masqmail in Debian will surely miss the POP
client. (Nontheless, I like to provide a quick fix in masqmail, too.)

If the problem lies in the local delivery, then the advice is similar.
I consider masqmail's local delivery code as a fall-back if you don't
have any better MDA available. If you have another one, than use it:
mda=/usr/bin/procmail -Y -d ${rcpt_local}
(in masqmail.conf)

The other parts of masqmail are unlikely the cause of this bug.

Masqmail is a Mail Transfer Agent, which *transfers* mail. I believe,
that retrieval and local delivery are different tasks, that should be
covered by different, specialized programs. Such ones are readily
available. The classics are fetchmail and procmail.



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

Bug#349211: Wontfix in 0.2 branch

[markus schnalke]

tag 349211 wontfix
thanks

The bug is fixed in the 0.3 branch of masqmail, but won't be fixed in
the 0.2 branch. The latter branch is a dead end in development and
thus receives only fixes concerning security or grave other problems.

It is intended that 0.3.x versions of masqmail will enter Debian
eventually, but currently the branch is still under non-compatible
development. This makes it unsuited to be included. When things will
settle, 0.3.x will enter Debian. Then this bug will be fixed.


meillo



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

Bug#638002: Fixed upstream in 0.2.30

[markus schnalke]

tags 638002 fixed-upstream
thanks

The bug had been fixed in version 0.2.30.

The relevant changeset is:
http://hg.marmaro.de/masqmail/rev/e507c854a63e


meillo



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

Bug#532123: recommends vs depends

[markus schnalke]

Hoi,

as I ran in the same issue today, I like to comment.


[2011-03-28 16:52] Bdale Garbee bd...@gag.com
 On Mon, 28 Mar 2011 23:59:54 +0200, Julien Viard de Galbert 
 jul...@vdg.blogsite.org wrote:
  I see your point, so a direct recommends on geoip-database will give
  less steps to fixing the issue, however, a depends would install
  geoip-database even for users not enabling the geoip feature... and I
  still think thats just wrong.

I agree.

  Do you think it's OK if I just add the recommends ?
 
 Probably.  Is the geoip feature disabled by default on new installs?

IMO that's the point. In current stable (squeeze), whe have webalizer
V2.01-10, which has geoip enabled by default. Hence I get the
mentioned error message when I run:

webalizer -c /dev/null ...

I think the cleanest solution is to disable geoip by default.


meillo



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

Bug#586765: tree: symlinks are printed with `argetm' at the beginning

[markus schnalke]

See also: #479576


meillo



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

Bug#586765: tree: symlinks are printed with `argetm' at the beginning

[markus schnalke]

This mail goes to upstream as well.


[2011-03-14 18:17] Florian Ernst florian_er...@gmx.net
 On Tue, Jun 22, 2010 at 01:21:20PM +0200, markus schnalke wrote:
 
  Tree prints `argetm' in front of symlink names. See:
  [...]
  This bug was reported from lenny/stable, but it exists in sid/unstable
  too.
 
 Hmm, unfortunately I cannot reproduce this misbehavior at all, neither
 in Etch, Lenny, Squeeze nor in Wheezy/Sid, using different set of
 installed and used locales. As such I now mark this bugreport
 correspondingly.
 
 Do you still experience this error? Anything you could possibly add to
 the bugreport?

Now I dug deeper in the bug and found the reasons.

The problem shows up only if you colorize the output. Then tree takes
the colors defined by $LS_COLORS. This looks like that:

no=00:fi=00:di=01;34:ln=target:pi=40;33:so=01;35:...

Each key has a color value, which may be used directly in a terminal
escape sequence, except `ln' which may also have the value ``target''.
See:

Symbolic link. If you set this to `target' instead of a numerical
value, the color is as for the file pointed to.

http://www.bigsoft.co.uk/blog/index.php/2008/04/11/configuring-ls_colors

This special case leads to the bug, reported here.

With the above $LS_COLORS, the escape sequence for a directory would
be `^[[01;34m'. For a link we get `^[[targetm', resulting in the escape
sequence `^[[t' and the text `argetm'.


In the sources start reading at tree.c:1391 parse_dir_colors(), the
``Hacked in DIR_COLORS support for linux.'' There $LS_COLORS is split
and link_flgs gets set (It could be to `target').

1433 case COL_LINK:
1434   if (c[1]) link_flgs = scopy(c[1]);
1435   break;

If link_flgs is set to `target' stat(2), instead of lstat(2), should
be used for symlinks. Or maybe we should do a further stat(2) in this
case. Maybe this function can be handled in a similar way as orphan
and missing links. Or tree would simply ignore `ln=target' and use
some default link color instead. This should be left open to upstream.


meillo


P.S.
I took tree-1.5.2 for reference.



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

Bug#615895: (no subject)

[markus schnalke]

retitle 615895 ITA: grap -- program for typesetting graphs
thanks

I'd much like to adopt the package. Thanks for the perfect shape in
which it had been orphaned. :-)


I'll need a sponsor then. Tobias, would you still like to sponsor? Or
Hauke, as you do sponsor my masqmail package, would you like to upload
this one too?

As the package is in perfect shape, there is few need for an upload
currently. Should we stay with the ITA until it's worth a new version?


meillo



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

Bug#551704: Correction

[markus schnalke]

I have to beg your pardon and correct what I said before. It is not at
all so impossible as I thought.

I like to explain what install-mh(1) does:

It creates an nmh profile file which contains the Path to the nmh mail
directory. This nmh mail directory gets created also, if it does not
exist already. Within the mail directory an nmh context file gets
created. These three files are everything.

The location of the profile file is either the value of $MH (if set)
or ~/.mh_profile . The location of the mail directory is stored in the
profile and can be extracted with `mhparam path'. (This path may be
absolute or relative to the home directory.) The context file is named
``context'' and located within the mail directory.

By removing these three files the operation of install-mh(1) is undone.


Please see also the discussion in the thread ``[patch] undo of
install-mh (Debian bug #551704)'' on the nmh-workers mailing list:
http://www.mail-archive.com/nmh-work...@nongnu.org/msg02061.html


meillo



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

Bug#551704: remove-mh is impossible to create

[markus schnalke]

Hoi,

writing such a remove-mh command is impossible, even tailored only to
Debian. With some ugly techniques and by ignoring corner-cases it
could be done though, but the effort is probably not worth the result.

I proposed a man page improvement to upstream. It might be included in
future versions.


Now to answer the concrete question of how to do it manually:

There is no general answer as it depends on how you answered the
queries of install-mh and if the chosen mail directory had existed
before. If you took the defaults, $HOME/Mail hadn't existed before and
$MH is not set, you may undo with these commands:

cd
rm .mh_profile Mail/context
rmdir Mail

Be sure you know what these commands do before you run them.


meillo



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

Bug#349211: Fixed upstream

[markus schnalke]

tags 349211 fixed-upstream
thanks

This bug had been correct as masqmail's behavior had been against the
RFCs (2821, 5321; section 3.2).

By today it is fixed upstream. The upcoming release of version 0.3.1
will include the fix.


meillo



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

Bug#584864: Announce of the upcoming NMU for the masqmail package

[markus schnalke]

[2010-10-12 18:35] Christian PERRIER bubu...@debian.org
 Quoting Jan Hauke Rahm (j...@debian.org):
 
  He's on a long-term vacation. As his sponsor I subscribed to his package
  and just found your mails in my INBOX. :) I'm not aware of anything he
  wanted to do on masqmail before squeeze, i.e. there is nothing to hold
  you back from uploading your NMU. Please proceed and thank you very
  much!
 
 Actually, Markus notified me about this and already gave permission to
 NMU. Thanks anyway for your answe and your care to send it.

Thanks for caring so much about masqmail, Debian, and the community.
:-)


   The package is currently translated to:
   cs de es fr it ja pt ru sv vi
  
   Among these, the following translations are incomplete: none
 
  There just came in another translation for da IIRC. But I guess, you'll
  check all open bugs anyways before you upload, right? :)
 
 
 I even subscribe to the package's PTS as soon as the intent to NMU is
 sent...so that translation is already sitting in my work directory.

Let me clarify the situation a bit. There were four bugs which had
not been automatically marked as done at the upload of 0.2.24-1,
namely:

#389731  Missing rmail link
#409912  uucp should be set/considered as 'trusted'
#536060  Logging breaks after rotation
#584864  [INTL:es] Spanish debconf template translation for masqmail

The changlog entry of 0.2.24-1 read:

 masqmail  (0.2.24-1) unstable; urgency=low

   * New upstream release (Closes: #536060, #389731)
   * New Debconf translation: Spanish by Francisco Javier Cuadrado
 (Closes: #584864)
   * Activated a hack to make group `uucp' trusted (Closes: #409912)
   * Using doc-base now

 -- markus schnalke mei...@marmaro.de  Thu, 24 Jun 2010 13:04:02 +0200 

Hence these bugs should have been closed. However, I closed them today
manually.

The Spanish translation (bug #584864) is already present in the
current package -- I checked it.

Thus, open are the bugs:

#591258  [l10n:cs] Updated Czech translation of PO debconf template for package 
masqmail 0.2.21-8
#599822  [INTL:da] Danish translation of the debconf templates masqmail

I'd appreciate if you could upload them as NMU, like you intended
already.


To clarify my comment on bug #591258: The translation had been for
0.2.21-8 but it can be used for 0.2.27-1 as well as the templates have
not been altered since then. (AFAIR)


Hope this helps.


meillo



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

Bug#591258: [l10n:cs] Updated Czech translation of PO debconf template for package masqmail 0.2.21-8

[markus schnalke]

[2010-08-01 17:38] Michal Simunek michal.simu...@gmail.com
 
 Package: masqmail
 Version: 0.2.21-8
 Severity: wishlist
 Tags: l10n, patch
 
 In attachment there is updated Czech translation of PO debconf template
 (cs.po) for package masqmail, please include it.

Thanks for the updated translation.

I'll include it in the next package version. (You'll probably have to
wait a few month for it.)


In the meanwhile version 0.2.27-1 is out, but AFAIK the debconf
templates didn't change.


meillo



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

Bug#459935: abook: export all email addresses to mutt aliases file

[markus schnalke]

[2010-07-22 16:25] Gerfried Fuchs rho...@deb.at
   Hi!
Hoi


  First of all, sorry for the late response.

A response, a response,  great! :-)

 I just recently got adopted
 into the upstream team and am looking through patches now that make
 sense to incorporate there directly instead of having them potential rot
 within Debian alone. ;)

Thanks for working on abook.

I don't use abook's export function anymore because I switched from
mutt to nmh and don't use an alias database there. But anyway the
issue surely needs a fix.


 * markus schnalke mei...@marmaro.de [2008-01-09 17:37:11 CET]:
  Package: abook
  Version: 0.5.6-3
  Severity: wishlist
  
  The following command
  
  abook --convert --infile ~/.abook/addressbook --informat abook
  --outfile mutt.aliases_test --outformat mutt
  
  does only export the first (primary) email address of each contact.
  All further (secondary) email addresses are simply ignored.
  If you want to generate mutt.aliases from abook, you have to create
  multiple entries for one person in abook - for every email address
  one.
  
  Also, contacts without email addresses at all, are exported. This
  leads to entries in the aliases file that are useless.
 
  I agree that these are both an annoyance and am taking a look at your
 patch now and trying to bring it up to the 0.6.0 pre2 codebase, quite
 some things have changed, so it isn't a straight forward patch.
 
  I got a working version so far, though somehow I got for the rotated
 email as realname all the email addresses, have to check again wether I
 have adjusted something wrongly here, or wether there is some logic
 error involved.
 
  Also, the exit you did for no email did make the function quit on the
 first addressbook entry that didn't had an email address attached to it
 - I somehow guess this wasn't your attention. ;)

Surely not. Two and a half year ago, my C knowledge wasn't as good as
it is now. ;-)

 Fixed that in my local
 copy already (moved the if (*email) { level to the outermost part of
 the loop).
 
  Again, thanks for your suggestion, sorry for the delay, and a fix for
 it will be soon get applied upstream.

Thank you very much for this information mail; that's a great service.

I hope fixing it completely won't be too difficult. Unfortunately, I
can't offer my help, because I'm very busy at the moment. I would have
loved to help, but it's not possible currently.


Have good times.


meillo



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

Bug#584459: unbalanced font changes ... again

[markus schnalke]

Hoi,

the current fix was still buggy. Actually it didn't work.

Attached is a fix that does work. (I checked it against severeal man
pages.)


meillo

diff --git a/roffit b/roffit
index 3d924f9..b7d643f 100755
--- a/roffit
+++ b/roffit
@@ -178,27 +178,30 @@ sub linkfile {
 
 sub handle_italic_bold ($) {
 local $_ = shift;
+my $inspan = 0;
 
-while ( m,^(.*?)(\\f[IB].*?\\fR)(.*), ) {
-	my ($before, $match, $after) = ($1, $2, $3);
+while ( m,^(.*?)\\f(.)(.*), ) {
+	my ($before, $font, $after) = ($1, $2, $3);
+	my $match = '';
 
-	my $counter = 0;
-
-	while ( $match =~ s/\\fI/span class=\emphasis\/ ) {
-	$counter++;
+	if ($inspan) {
+		$match = '/span';
+		$inspan = 0;
 	}
 
-	while ( $match =~ s/\\fB/span class=\bold\/ ) {
-	$counter++;
+	if ($font eq 'I') {
+		$match .= 'span class=emphasis';
+		$inspan = 1;
+	} elsif ($font eq 'B') {
+		$match .= 'span class=bold';
+		$inspan = 1;
 	}
 
-	my $tag = '/span';
-	my $end = $tag x $counter;
-
-	$match =~ s/\\f[PR]/$end/;
-
 	$_ = $before . $match . $after;
 }
+if ($inspan) {
+	$_ .= '/span';
+}
 
 $_;
 }
@@ -470,7 +473,7 @@ sub parsefile {
 $txt =~ s/\\\'/acute\;/g;
 $txt =~ s/\\\(co/copy\;/g;
 
-	$_ = handle_italic_bold $_;
+	$txt = handle_italic_bold $txt;
 
 # replace backslash [something] with just [something]
 $txt =~ s/\\(.)/$1/g;

Bug#586765: tree: symlinks are printed with `argetm' at the beginning

[markus schnalke]

Package: tree
Version: 1.5.2-1
Severity: normal

Tree prints `argetm' in front of symlink names. See:

$ touch a

$ ln -s a b

$ ls -l
total 0
-rw-r--r-- 1 meillo meillo 0 2010-06-22 13:14 a
lrwxrwxrwx 1 meillo meillo 1 2010-06-22 13:14 b - a

$ tree
.
|-- a
`-- argetmb - a

0 directories, 2 files

$ 

I took a quick look in tree's code but couldn't locate the string
`argetm'. Thus unfortunately I cannot provide further help.

The problem is probably easy to fix after you found out where to look
for it. ;-)


meillo


P.S.
This bug was reported from lenny/stable, but it exists in sid/unstable
too.



-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages tree depends on:
ii  libc6   2.7-18lenny2 GNU C Library: Shared libraries

tree recommends no packages.

tree suggests no packages.

-- no debconf information



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

Bug#409912: Will be fixed soon

[markus schnalke]

tags 409912 pending
thanks

Thanks for the bug report.

Although I do not completely agree that uucp should be trusted, I'll
change this for the Debian package.

Changing masqmail in a way that multiple groups can be trusted is not
what I want to do. But I added a few lines of code to the permission
check which is commented by default. I uncommented this code in the
Debian package and made the group `uucp' (not the user `uucp', but
that shouldn't matter) trusted.

It's available from version 0.2.24 on.


Hope that helps.


meillo



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

Bug#584864: thanks

[markus schnalke]

tags 584864 pending
thanks

Thanks for the translation. :-)


meillo



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

Bug#427900: Can't reproduce, please provide more information

[markus schnalke]

tag 427900 unreproducible moreinfo
thanks

[2007-06-07 12:40:28]  Reuben Thomas r...@sc3d.org

 When I'm not online, every connection to the localhost SMTP server
 results in another masqmail -bd -q10m process

No matter if you're online or not, masqmail always forks for incoming
SMTP connections. The command line parameters are irrelevant, they
just originate from the fork.

 which doesn't go away
 and the mail never completes sending (from the MUA's point of view).

Unfortunately (or fortunately ;-) ) I can't reproduce this behavior. I
told masqmail that it is offline and submitted a message with telnet
on localhost:25. After sending QUIT the connection was terminated by
the server at once.

I also tried to tell masqmail that we're online when I was not online.
The behavior was the same: the connection was terminated by the server
at once after sending QUIT.

 stracing shows the process waiting on a futex; gdbing doesn't give any
 symbols in the backtrace.

Hmm. Masqmail itself doesn't use futex anywhere. Could be that glib
uses them, don't know.


 Allowing the MUA (alpine, in my case) to break the connection (it
 prompts me for this after waiting for a while) results in the mail
 being apparently sent, although the masqmail process still remains.

I haven't seen a masqmail process remaining when it should not.

It would be good to have an SMTP log of such a situation.

Trying to manually submit a message with telnet could provide useful
information too.

Also describing the situation more closely (is the computer online,
does masqmail think it's online, which version of masqmail, etc) would
be good. Maybe some cases could be excluded then.


 If I instead use /usr/lib/sendmail, I don't get this problem.

The bug seems to be SMTP related then.


meillo



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

Bug#389731: Fixed in upstream devel version

[markus schnalke]

tags 389731 fixed-upstream pending
thanks

This bug is now fixed upstream, although not released yet.

The fix does not add this link, which would be possible, but includes
a small shell script which was taken from postfix. The shell script
cares about the first line of the message which can include the from
address of the sender. This is not done by calling masqmail as rmail.


meillo



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

Bug#536060: masqmail: Logging breaks after rotation

[markus schnalke]

tags 536060 patch pending upstream
thanks

[2010-06-12 09:53:31] markus schnalke mei...@marmaro.de
 
 Currently I can't tell why the daemon does not restart logging. (On
 SIGHUP it closes all open fds and exec()s itself again.) I'll dig
 deeper in this.

I found the bug now and it is fixed in the upstream source code repo.

The situation was such:

When running in daemon mode, first the log files are opened. They get
assigned to the file descriptors 3 and 4 usually. Then std{in,out,err}
are closed. When SIGHUP comes in, all open files are closes and
masqmail reexecutes itself. The new masqmail instance opens the log
files at fd 0 and 1 now, but std{in,out,err} are closed afterwards,
thus the log files are closed.

The fix is to close the log files before std{in,out,err} are closed,
in case the log files have higher fds. After std{in,out,err} were
closed, the log files get opened again, now.


A new upstream release will probably appear soon. I'll create a new
package then.


meillo
diff -r 98cda87105a7 src/masqmail.c
--- a/src/masqmail.c	Wed Jun 16 10:14:50 2010 +0200
+++ b/src/masqmail.c	Wed Jun 16 10:17:17 2010 +0200
@@ -161,9 +161,15 @@
 
 	conf.do_verbose = FALSE;
 
+	/* closing and reopening the log ensures that it is open afterwards
+	   because it is possible that the log is assigned to fd 1 and gets
+	   thus closes by fclose(stdout). Similar for the debugfile.
+	*/
+	logclose();
 	fclose(stdin);
 	fclose(stdout);
 	fclose(stderr);
+	logopen();
 
 	listen_port(do_listen ? conf.listen_addresses : NULL, queue_interval, argv);
 }
@@ -194,9 +200,15 @@
 
 	conf.do_verbose = FALSE;
 
+	/* closing and reopening the log ensures that it is open afterwards
+	   because it is possible that the log is assigned to fd 1 and gets
+	   thus closes by fclose(stdout). Similar for the debugfile.
+	*/
+	logclose();
 	fclose(stdin);
 	fclose(stdout);
 	fclose(stderr);
+	logopen();
 
 	get_daemon(get_interval, argv);
 }

Bug#349211: What masqmail actually does

[markus schnalke]

tags 349211 moreinfo
thanks

Hoi,

I'm currently tackling all those old bugs in masqmail. This one is one
of them.


First I want to explain how masqmail actually acts, based on my code
research (smtp_out.c):

If the server says ``ESMTP'' in the initial message, then masqmail
says ``EHLO'' otherwise ``HELO''. If the following response of the
server matches the regexp /^AUTH[ =\t]/ then authentication
will be done.

It seems that servers only respond with multi-line answers which
include stuff like AUTH if the greeting was ``EHLO''. This bases on a
quick test with a handful of servers I know.

I don't know one of these picky servers, PLEASE TELL ME if you know
one, so I can test.


I don't want to simply apply Eric's patch because it introduces a new
option which I would like to avoid. My aim is to find out more about
the existing implementations out there and decide then.

Please also tell me if this bug affects you.


meillo



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

Bug#536060: masqmail: Logging breaks after rotation

[markus schnalke]

[2009-07-07 11:28] Ove Kaaven o...@arcticnet.no
 
 After logrotate has rotated /var/log/masqmail/masqmail.log, it appears that
 at most one more event is logged (i.e., 3 lines in the case of an e-mail
 transmission). After that, further activity is logged to /dev/null.
 As far as I can tell, e-mail delivery still works, it's just not logged.

I can confirm that this bug exists.

Actually it is not directly related to logrotate. The SIGHUP handler
in masqmail is broken and logrotate sends (indirectly via masqmail's
init script) a SIGHUP to masqmail. Thus logging stops also if you
simply send SIGHUP.

The reason why still some messages are logged is such: If you submit
mail into the system by calling `sendmail', then a new instance gets
started and this one does log. This instance is independent to the
daemon which stopped logging.

Currently I can't tell why the daemon does not restart logging. (On
SIGHUP it closes all open fds and exec()s itself again.) I'll dig
deeper in this.


meillo



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

Bug#584437: roffit: better man page header detection

[markus schnalke]

[2010-06-04 11:02] Jari Aalto jari.aa...@cante.net
 markus schnalke mei...@marmaro.de writes:
 
  .TH curl 1 22 Oct 2003 Curl 7.10.8 Curl Manual
  .TH curl 1 22\ Oct\ 2003 Curl\ 7.10.8 Curl\ Manual
 
 From unscientific test:
 
 $ ls /usr/share/man/man1/*.gz | xargs zgrep '^\.TH.*\\' | egrep -v '\'
 
 usr/share/man/man1/ci.1.gz:.TH CI 1 \*(Dt GNU
 /usr/share/man/man1/co.1.gz:.TH CO 1 \*(Dt GNU
 /usr/share/man/man1/evince-thumbnailer.1.gz:.TH evince\-thumbnailer 1 
 2007\-01\-15  
 /usr/share/man/man1/formail.1.gz:.TH FORMAIL 1 \*(Dt BuGless
 /usr/share/man/man1/gnome-panel.1.gz:.TH gnome-panel 1 2006\-03\-07
 /usr/share/man/man1/html2text.1.gz:.TH html2text 1 2008\-09\-20
 /usr/share/man/man1/ident.1.gz:.TH IDENT 1 \*(Dt GNU
 /usr/share/man/man1/join-dctrl.1.gz:.TH join\-dctrl 1
 /usr/share/man/man1/lockfile.1.gz:.TH LOCKFILE 1 \*(Dt BuGless
 /usr/share/man/man1/merge.1.gz:.TH MERGE 1 \*(Dt GNU
 /usr/share/man/man1/patch.1.gz:.TH PATCH 1 \*(Dt GNU
 /usr/share/man/man1/procmail.1.gz:.TH PROCMAIL 1 \*(Dt BuGless
 /usr/share/man/man1/rcs.1.gz:.TH RCS 1 \*(Dt GNU
 /usr/share/man/man1/rcsclean.1.gz:.TH RCSCLEAN 1 \*(Dt GNU
 /usr/share/man/man1/rcsdiff.1.gz:.TH RCSDIFF 1 \*(Dt GNU
 /usr/share/man/man1/rcsfreeze.1.gz:.TH RCSFREEZE 1 \*(Dt GNU
 /usr/share/man/man1/rcsintro.1.gz:.TH RCSINTRO 1 \*(Dt GNU
 /usr/share/man/man1/rcsmerge.1.gz:.TH RCSMERGE 1 \*(Dt GNU
 /usr/share/man/man1/rlog.1.gz:.TH RLOG 1 \*(Dt GNU
 /usr/share/man/man1/rpcgen.1.gz:.TH \*(x}
 /usr/share/man/man1/saidar.1.gz:.TH saidar 1 $Date:\ 2006/11/30\ 
 23:42:42\ $ i\-scream 
 
 There doesn't seem to be cases where \  is used.

The last line is such a case.

 I'm inclined to conclude that bug reports should be sent to packages
 that have pages using backslashes in .TH line. These pages should be
 converted to use the double quote notation.

I could agree for TH lines with escaped spaces, but not for using any
backslashes in TH lines.

Especially \- must be possible as it means something different to -.

 The main problem is with
 those pages:
 
 - No information can be parsed reliably; there is no delimiters
   (start, stop) to specify which text is within which.

If you parse it char for char, then you can parse it reliable. Nroff
can do it. But I don't think we want this overhead here.


The most important thing is detecting the first two parameters (name
and section). These will almost always be detectable without problems.
If we can detect them, we should display them in the page title. The
``secret man page'' should then appear almost never.

For all the other parameters we should try to detect them as good as
possible. If we can detect values then we should use them, otherwise
we should just ignore them. IMO we can ignore escaped spaces here.


 In any case, here is patch to improve the TH detection in cases like the
 above.
 
 Daniel, would you apply this to CVS.

I think we can still improve that one. Let's do it in two steps:

First detect the first two arguments, which will succeed almost
always. And as a separate step we could try to detect the rest.

In general: Did you notice that nothing but the first argument of TH
is ever used by roffit? Thus we should think about how much code we
put into roffit to detect the other arguments.

It might be enough to detect the first two arguments which will be
successful in most cases, and we don't have to mess around with the
rest.


Unsolved still is \*(Dt. Your patch deletes it. This might be the best
solution for now.


meillo



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

Bug#584463: roffit: generate semantically better HTML and CSS

[markus schnalke]

[2010-06-04 09:40] Daniel Stenberg dan...@haxx.se
 On Fri, 4 Jun 2010, Jari Aalto wrote:
 
  Instead of span class=bold use b or strong.
  Instead of span class=emphasis use i or emph.
 
  This may make HTML simpler, but the change would actually degrade the 
  versality. The SPAN elements can be freely manipulated via CSS, whereas the 
  B and I tags have a distinct meaning.
 
 Yes. That is the exact reasoning I had when I did it that way from the start 

In what way would you want to manipulate the tags? \fB means ``bold
face'' and nothing more, hence it should be represented with b which
means ``bold face'' too.

I don't see how this flexibility would be needed.

Specifiying different colors and thelike is possible with b too.


  Likewise. It is good that the headings have distinct identifiers from
  the start. This allows the ability to embed the HTML somewhere else
  and not the interfere with the exixting H definitions. Like:
 
 h1
 {
 /* regular */
 }
 
 h2.nroffsh
 {
 /* from roffit */
 }
 
  In this regard I'm inclined to not recommend these changes. Daniel, the
  author, can comment more.
 
 Being able to include the roffit HTML code embedded in another existing HTML 
 page without too much trouble (and of course then subsequently being able to 
 modify the look of the roffit HTML parts only from the CSS) has been one of 
 my 
 goals since day 1 so this isn't anything I want to hamper in any way.

You convinced me on this second point.


meillo



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

Bug#584437: roffit: better man page header detection

[markus schnalke]

Package: roffit
Version: 0.6+cvs20090507-1
Severity: wishlist
Tags: upstream patch

Roffit is very strict in detecting man page headers (TH lines).

It should recognize fields correctly if unneccesary double quotes are
omitted. Also, arbitrary white space between fields should not matter.
The attached patch probably fixes these problems.


One issue is still unsolved: Escaped spaces. For nroff the following
lines are equivalent:

.TH curl 1 22 Oct 2003 Curl 7.10.8 Curl Manual

.TH curl 1 22\ Oct\ 2003 Curl\ 7.10.8 Curl\ Manual

This corner-case will probably seldom show up, however. Fixing it
might require more than the single regexp that is used currently.


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages roffit depends on:
ii  perl  5.10.1-12  Larry Wall's Practical Extraction 

roffit recommends no packages.

roffit suggests no packages.

-- no debconf information
--- roffit.orig 2010-06-03 16:30:34.0 +0200
+++ roffit  2010-06-03 16:56:57.0 +0200
@@ -212,13 +212,19 @@
 # man page header:
 # curl 1 22 Oct 2003 Curl 7.10.8 Curl Manual
 # NAME SECTION DATE VERSION MANUAL
-if($rest =~ /([^ ]*) (\d+) \([^\]*)\ 
\([^\]*)\(\([^\]*)\)?/) {
+if($rest =~ /
+([^ ]+)[ \t]+
+(\d+)[ \t]+
+(\[^\]+\|[^ \t]+)[ \t]+
+(\[^\]+\|[^ \t]+)[ \t]+
+(\[^\]+\|[^ \t]+)?
+/x) {
 # strict matching only so far
 $manpage{'name'} = $1;
 $manpage{'section'} = $2;
 $manpage{'date'} = $3;
 $manpage{'version'} = $4;
-$manpage{'manual'} = $6;
+$manpage{'manual'} = $5;
 }
 }
 elsif($keyword =~ /^S[HS]$/) {

Bug#584439: roffit: p at unneccesary places and without /p

[markus schnalke]

Package: roffit
Version: 0.6+cvs20090507-1
Severity: normal
Tags: upstream

Roffit appears to insert

p class=level0

at the beginning of each line in the HTML body but there are no
closing /p tags. XHTML requires closing all tags:

For non-empty elements, end tags are required

( http://www.w3.org/TR/xhtml1/ )

Although XHTML validity may not be of need, it can only count as a
quick hack to insert p tags at the beginning of each line.


Paragraphs are not allowed to contain block elements (e.g. other
paragraphs or headings). Quoting the HTML4 specification:

The P element represents a paragraph. It cannot contain
block-level elements (including P itself).

( http://www.w3.org/TR/REC-html40/struct/text.html )


meillo


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages roffit depends on:
ii  perl  5.10.1-12  Larry Wall's Practical Extraction 

roffit recommends no packages.

roffit suggests no packages.

-- no debconf information



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

Bug#584459: roffit: unbalanced font changes

[markus schnalke]

Package: roffit
Version: 0.6+cvs20090507-1
Severity: normal
Tags: upstream

Roffit represents \f font changes with

span class=...text/span

This leads to unbalanced span tags for valid nroff input like:

normal\fBbold\fIitalic\fRnormal

This is commonly used in the synopsis section of man pages to specify
options and arguments to them. E.g. from Heirloom tar:

\fB\-C\fI dir\fR

The result is:

span class=bold-Cspan Class=emphasis dir/span


Additionally:

Font changes (as escape sequence \f) can appear at any point in nroff
input an change the font for all following text, i.e. over line and
page breaks. Hence font changes can not be represented with span,
as inline elements must not contain block elements.

Seems as if the current font should be stored in a variable and at
the beginning of each block element, an appropriate font change must
be made, while at each end of a block element the appropriate end
element to the font change must be inserted. Like this:

\fBfoo
.PP
bar

would get converted to

span class=boldfoo/span
p
span class=boldbar/span
/p

or better

span class=boldfoo/span
p class=bold
bar
/p


The main problem here is that nroff's language design is generally
different to the one of HTML, at least to newer (X)HTML versions.


meillo


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages roffit depends on:
ii  perl  5.10.1-12  Larry Wall's Practical Extraction 

roffit recommends no packages.

roffit suggests no packages.

-- no debconf information



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

Bug#584463: roffit: generate semantically better HTML and CSS

[markus schnalke]

Package: roffit
Version: 0.6+cvs20090507-1
Severity: wishlist
Tags: upstream

This bug is mainly about cosmetics but it is also about using those
HTML elements that express exactly what you mean.

Instead of span class=bold use b or strong.

Instead of span class=emphasis use i or emph.


About the headings:

h2.nroffsh {
 background-color: #e0e0e0;
}

h2 class=nroffshfoo/h2

Can get simplified to:

h2 {
 background-color: #e0e0e0;
}

h2foo/h2


We could also define the most commonly used style as default style
for p. This will save us many class attributes, thus making the
HTML code simpler.


meillo


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages roffit depends on:
ii  perl  5.10.1-12  Larry Wall's Practical Extraction 

roffit recommends no packages.

roffit suggests no packages.

-- no debconf information



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

Bug#563698: At least inform

[markus schnalke]

At least, john should print that he found a number of password hashes
that he does not recognize. That would make clear why john loads no
hashes when there are some existing.


meillo



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

Bug#527146: Interested to adopt

[markus schnalke]

I am interested to adopt the `deroff' package.

I use troff myself and very much like it, thus deroff is a useful tool
in my toolchest.

Before I run the ITA, I'd like to hear from you.

There are several implementations of deroff available. I found at
least these:
- http://swtch.com/plan9port/man/man1/deroff.html
- http://www.moria.de/~michael/deroff/
- http://heirloom.sourceforge.net/tools.html

Yet, I have only had a look at the heirloom implementation, which is
2300 SLOC of C. I much like your's to be 300 SLOC of lex, instead. But
I haven't compared the functions in detail.

I'd appreciate if you could comment on this.


meillo



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

Bug#541297: masqmail: diff for NMU version 0.2.21-7.1

[markus schnalke]

[2009-11-28 11:38] gregor herrmann gre...@debian.org 
 
 Dear maintainer,
 
 I've uploaded an NMU for masqmail (versioned as 0.2.21-7.1). The diff
 is attached to this message.

Thanks.


meillo



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

Bug#533563: gawk: fails to configure (update-alternatives has problems with nawk)

[markus schnalke]

Package: gawk
Version: 1:3.1.6.dfsg-3
Severity: important
Tags: patch

I receive following output during gawk installation:


Setting up gawk (1:3.1.6.dfsg-3) ...
update-alternatives: error: alternative nawk can't be slave of awk: it is a 
master alternative.
dpkg: error processing gawk (--configure):
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of geda-gnetlist:
 geda-gnetlist depends on gawk; however:
  Package gawk is not configured yet.
dpkg: error processing geda-gnetlist (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of geda:
 geda depends on geda-gnetlist; however:
  Package geda-gnetlist is not configured yet.
dpkg: error processing geda (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 gawk
 geda-gnetlist
 geda
E: Sub-process /usr/bin/dpkg returned an error code (1)


This probably comes from some restructuring in the alternatives system.

Removing the nawk references in debian/postinst let me install without errors.
However, I am not sure if this is the correct solution.


meillo

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gawk depends on:
ii  libc6 2.9-14 GNU C Library: Shared libraries

gawk recommends no packages.

gawk suggests no packages.

-- no debconf information
--- debian/postinst 2009-06-18 22:07:56.0 +0200
+++ ../../gawk-3.1.6.dfsg/debian/postinst   2009-06-18 21:53:31.0 
+0200
@@ -1,10 +1,8 @@
 #!/bin/sh -e
 
 update-alternatives --quiet --install /usr/bin/awk awk /usr/bin/gawk 10 \
-  --slave /usr/share/man/man1/awk.1.gz awk.1.gz /usr/share/man/man1/gawk.1.gz \
-  --slave /usr/bin/nawk nawk /usr/bin/gawk \
-  --slave /usr/share/man/man1/nawk.1.gz nawk.1.gz /usr/share/man/man1/gawk.1.gz
-for badlink in /usr/man/man1/awk.1 /usr/man/man1/nawk.1; do
+  --slave /usr/share/man/man1/awk.1.gz awk.1.gz /usr/share/man/man1/gawk.1.gz
+for badlink in /usr/man/man1/awk.1; do
   if [ -L $badlink ]; then
 if ! ls -l $(ls -l $badlink | cut -d -f2) /dev/null 21; then
   rm -f $badlink; fi; fi; done

Bug#533006: masqmail: segfaults with connection method pipe

[markus schnalke]

tag 533006 pending
thanks

[2009-06-13 19:56] Andreas Hoenen andr...@hoenen-terstappen.de
 Package: masqmail
 Version: 0.2.21-6
 Severity: important

 After upgrading masqmail 0.2.21-5 to 0.2.21-6, masqmail segfaults when trying 
 to
 deliver queued mails:
 
 Jun 13 19:33:05 manetheren masqmail[16167]: Starting queue run.
 Jun 13 19:33:05 manetheren kernel: [ 1983.224568] masqmail[16167]: segfault 
 at 0 ip 805706d sp ff965910 error 4 in masqmail[8048000+1c000]
 Jun 13 19:33:05 manetheren masqmail[16166]: process with pid 16167 got 
 signal: 11
 
 Reverting to 0.2.21-5 resolves the problem, as well as rebuilding 0.2.21-6 
 with
 the 0.2.21-5 version of file online.c.  When looking at the changes between -5
 and -6 for this file, it seems that masqmail tries to determine the length of 
 an
 uninitialized string (l.39):
 
 25  static
 26  gchar *detect_online_pipe(const gchar *pipe)
 27  {
 28pid_t pid;
 29void (*old_signal)(int);
 30int status;
 31FILE *in;
 32gchar *name = NULL;
 
 33old_signal = signal(SIGCHLD, SIG_DFL);
 
 34in = peopen(pipe, r, environ, pid);
 35if(in != NULL){
 36  gchar output[256];
 37  if(fgets(output, 255, in)){
 38g_strchomp(g_strchug(output));
 39if (strlen(name) == 0) {  /* - !!! SUSPICIOUS !!! */
 40  logwrite(LOG_ALERT, only whitespace connection name\n);
 41  name = NULL;
 42} else {
 43  name = g_strdup(output);
 44}
 45  } else {
 46logwrite(LOG_ALERT, nothing read from pipe %s\n, pipe);
 47name = NULL;
 48  }

Thanks for this excellent bug report!


I'm deeply ashamed for this bug. The length must get determined from
`output' instead of `name'. Unfortunately, the bug appeared during a
by-hand code transfer, sorry. Next time I better create a patch and
apply it, even for few lines.


meillo


signature.asc
Description: Digital signature

Bug#513566: dir2ogg: WAV files are not preserved for WMA input

[markus schnalke]

[2009-02-13 15:21] Julian Andres Klode j...@debian.org
 On Fri, Jan 30, 2009 at 10:19:55AM +0100, markus schnalke wrote:
  Package: dir2ogg
  Version: 0.11.6-1
  Severity: normal
  
  The option `-p' (`--preserve-wav') does not work for WMA input files. It 
  does
  not matter if single files or whole directories are used as input.
  
 It generally won't work for anything using mplayer. dir2ogg uses temp.wav as 
 the
 temporary filename here, whereas for other decoders, the name of the input 
 file,
 the suffix replaced with .wav, is used.
 
 The reason is that for mplayer, you have to give the option like -ao 
 pcm:file=temp.wav,
 and using the real filename here leads to problems if there are spaces in the 
 filename,
 or something else. And encoding the filenames is no option.
 
 I could still patch it to rename the temp.wav to the correct filename 
 afterwards.

When I read about the `-p' option, I thought it would work as follows:

I run `dir2ogg' with whatever configuration and have in the end each
input file in the target format _and_ each input file as WAV, too.

For example:

$ ls
aa.mp3  bb.wav  cc.wma

$ dir2ogg -p *

$ ls
aa.mp3  bb.wav  cc.wma
aa.ogg  bb.ogg  cc.ogg
aa.wav  cc.wav


I don't know about the internals ... that simply how I thought the
programm would behave. And IMO this is the right way.


meillo


signature.asc
Description: Digital signature

Bug#513566: dir2ogg: WAV files are not preserved for WMA input

[markus schnalke]

Package: dir2ogg
Version: 0.11.6-1
Severity: normal

The option `-p' (`--preserve-wav') does not work for WMA input files. It does
not matter if single files or whole directories are used as input.

However it does work for MP3 input (tested).


meillo



-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dir2ogg depends on:
ii  mpg321 [mpg123]   0.2.10.6   mpg123 clone that doesn't use floa
ii  python2.5.2-3An interactive high-level object-o
ii  python-mutagen1.14-1 audio metadata editing library
ii  vorbis-tools  1.2.0-5several Ogg Vorbis tools

Versions of packages dir2ogg recommends:
ii  faad2.6.1-3.1freeware Advanced Audio Decoder pl
ii  icedax  9:1.1.9-1Creates WAV files from audio CDs
ii  mplayer 1:1.0.rc2svn20080706-0.1 The Ultimate Movie Player For Linu
ii  python-cddb 1.4-5.1+b1   Python interface to CD-IDs and Fre
ii  python-musicbra 0.6.0-2  An interface to the MusicBrainz XM

dir2ogg suggests no packages.

-- no debconf information



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

Bug#513332: masqmail: [INTL:vi] Vietnamese debconf templates translation update

[markus schnalke]

[2009-01-28 19:25] Clytie Siddall cly...@riverland.net.au
 Package: masqmail
 Version: 0.2.21-6
 Tags:  l10n patch
 Severity: wishlist
 
 The updated Vietnamese translation for the debconf file: masqmail
 
 completely reviewed, translated and submitted by:

Thanks for your help.

I try to upload the new package in February.


meillo


signature.asc
Description: Digital signature

Bug#512388: fbi: order of j/k keys should be reversed (and the should be documented in man page)

[markus schnalke]

Package: fbi
Version: 2.07-1
Severity: minor


I discovered by accident that the `j' and `k' keys can be used as alternatives
to `PgUp' and `PgDn'. But their function should be switched.

Currently `j' (means `down' in vi) decreases the number of the displayed image,
but this means going backward. However `j' should go foreward. `PgDn' in
constrast does it right as it increases the number of displayed picture, thus
goes foreward.

I recommend to exchange the function of `j' and `k', to receive a more
natural/expected control.


Additionally the keys should be documented in the man page.


meillo


P.S.
Excuse me that I do not provide a patch. Unfortunately I'm pretty busy ATM.

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages fbi depends on:
ii  ghostscript8.63.dfsg.1-2 The GPL Ghostscript PostScript/PDF
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libcurl3-gnutls7.18.2-8  Multi-protocol file transfer libra
ii  libexif12  0.6.16-2.1library to parse EXIF files
ii  libfontconfig1 2.6.0-3   generic font configuration library
ii  libfreetype6   2.3.7-2   FreeType 2 font engine, shared lib
ii  libgif44.1.6-6   library for GIF images (library)
ii  libjpeg62  6b-14 The Independent JPEG Group's JPEG 
ii  libpcd21.0.1-1   A library for reading PhotoCD imag
ii  libpng12-0 1.2.27-2  PNG library - runtime
ii  libtiff4   3.8.2-11  Tag Image File Format (TIFF) libra
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

fbi recommends no packages.

Versions of packages fbi suggests:
ii  imagemagick7:6.3.7.9.dfsg1-3 image manipulation programs

-- no debconf information



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

Bug#512387: fbi: fbgs -a: switch to next page while zoomed

[markus schnalke]

Package: fbi
Version: 2.07-1
Severity: normal


When `fbgs -a file.ps' is started and one page is zoomed then (using `+') it is
not possible to go to the next page (`PgUp'/`PgDn') anymore. (Except I'm at the
very bottom of the page and want to go forward, or I'm at the very top of the
page and want to go backward.)

The problem does not exist if `fbgs' was called without the `-a' option.

What IMO should be possible:
- call with `-a'
- zoom that page in
- switch to next page (using PgDn)
- zoom that page in too
- switch back and forth using PgUp/PgDn

This is extremely useful for working in a text section that spans two pages.


meillo



-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages fbi depends on:
ii  ghostscript8.63.dfsg.1-2 The GPL Ghostscript PostScript/PDF
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libcurl3-gnutls7.18.2-8  Multi-protocol file transfer libra
ii  libexif12  0.6.16-2.1library to parse EXIF files
ii  libfontconfig1 2.6.0-3   generic font configuration library
ii  libfreetype6   2.3.7-2   FreeType 2 font engine, shared lib
ii  libgif44.1.6-6   library for GIF images (library)
ii  libjpeg62  6b-14 The Independent JPEG Group's JPEG 
ii  libpcd21.0.1-1   A library for reading PhotoCD imag
ii  libpng12-0 1.2.27-2  PNG library - runtime
ii  libtiff4   3.8.2-11  Tag Image File Format (TIFF) libra
ii  zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

fbi recommends no packages.

Versions of packages fbi suggests:
ii  imagemagick7:6.3.7.9.dfsg1-3 image manipulation programs

-- no debconf information



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

Bug#505794: thanks

[markus schnalke]

tags 505794 pending
thanks


[2008-11-15 14:08] Martin Bagge [EMAIL PROTECTED]
 
 Please consider to add this file to translation of debconf.

done.

Thanks for your help!


meillo


signature.asc
Description: Digital signature

Bug#505730: thanks

[markus schnalke]

tags 505730 pending
thanks

Thanks for your work Yuri!


meillo


signature.asc
Description: Digital signature

Bug#504794: thanks

[markus schnalke]

tags 504794 pending
thanks

Thanks for your work!


meillo


signature.asc
Description: Digital signature

Bug#504615: masqmail: [INTL:fr] French debconf templates translation update

[markus schnalke]

Hoi,

I sent my mail before I saw your bug report follow-up.


[2008-11-06 08:05] Christian Perrier [EMAIL PROTECTED]
 Apparently, Ivan Buresi also sent an update. Please feel free to use
 whatever update we both sent as the only change in both cases is
 removing the fuzzy markers introduced by the recent rewording of
 templates (which indeed were anticipated in the French translation).

So I'll take Ivan's one, simply because he also did the last
translation.

Nevertheless, I thank you for your effort!


meillo


signature.asc
Description: Digital signature

Bug#174975: This bug is solved

[markus schnalke]

tags 174975 fixed
tags 174975 pending
thanks

This bug is not in the current version 0.2.21-1.2 which is in etch,
nor in version 0.2.21-4 which is in lenny.

The next upload will close the bug.


meillo


signature.asc
Description: Digital signature

Bug#416237: more information needed

[markus schnalke]

tags 416237 pending
tags 174975 -moreinfo
thanks

The problem seems to comes from bad contents in /etc/hosts.
See: http://ubuntuforums.org/showthread.php?t=313576

The next upload will fix it by ignoring `hostname -f' when it makes
problems.


meillo


signature.asc
Description: Digital signature

Bug#427096: fixed

[markus schnalke]

tags 427096 pending
thanks


Fixed it. Wait for the next version.

Thanks for your work!


meillo


signature.asc
Description: Digital signature

Bug#480477: fixed man page

[markus schnalke]

tags 480477 pending
thanks

I removed the wrong line in masqmail(8). Talking about /dev/null seems
to be missleading too.
The information in masqmail.conf(5) seems to be enough, as you said.


meillo


signature.asc
Description: Digital signature

Bug#417842: explanations

[markus schnalke]

tags 417842 fixed
tags 417842 pending
thanks


Alexis,

thanks for the bug report.

I added appropriate log messages for non-existing and empty alias
files.

In case of empty alias files, mail is delivered as expected now. And a
log message (notice) is written.

In case of being unable to open the alias file, no delivery was made,
in the former versions. Now delivery is made, but without aliasing. A
log message (alert) is written.
It should be no problem to deliver without aliasing in that case.

(btw: If no alias file is specified in masqmail.conf, no aliasing is
done at all.)


About Marcos patch:
Thanks for it---it helped much to start right off working on the bug.
The problem with your patch is, that -1 is not of type GList*. So it
is no valid return value.
Therefor I chose the solution decribed above.


About /etc/aliases:
This file is not needed by masqmail---one may use any file as alias
file. Thus I don't care for it to be available or not.
Nevertheless /etc/aliases the place where one wants to put the data
most likely.
However, I think there is no need to treat this location special. So I
will not file a bug against something, here.


wait for the next version to fix the problem.


meillo


signature.asc
Description: Digital signature

Bug#427095: fixed

[markus schnalke]

tags 427095 pending
thanks

Empty online files and non existent ones will cause appropriate log
messages and lead to not being online.

Wait for the next version to fix it.


meillo


signature.asc
Description: Digital signature

Bug#503910: latexmk: please add support for multiple bibliographies

[markus schnalke]

Package: latexmk
Version: 307a-2
Severity: wishlist

Multiple bibliographies are provided by the package `multibib'. The usage is
described on http://airminded.org/2006/02/25/multiple-bibliographies-in-latex/
and on http://www.tex.ac.uk/cgi-bin/texfaq2html?label=multibib

It seems not so difficult to add the support.
To do is:
  run bibtex on every *.bbl file existing (not only $document_root.bbl)
  clean the generated files on clean

I'm not unfortunately not familiar with Perl and can therefor not provide a
patch.

Currently I run latexmk and receive some ``undefined reference'' errors. Then
I run bibtex on the second bbl file. And finally latexmk again.
It workes this way, but included support would be nice :-)


meillo

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages latexmk depends on:
ii  perl   5.10.0-16 Larry Wall's Practical Extraction 
ii  tetex-bin  2007.dfsg.1-4 TeX Live: teTeX transitional packa
ii  texlive-latex-base 2007.dfsg.1-4 TeX Live: Basic LaTeX packages

Versions of packages latexmk recommends:
ii  ghostscript [postscript- 8.62.dfsg.1-3.1 The GPL Ghostscript PostScript/PDF
ii  gv [postscript-viewer]   1:3.6.5-2   PostScript and PDF viewer for X
ii  xpdf-reader [pdf-viewer] 3.02-1.4Portable Document Format (PDF) sui
ii  xpdf-utils [pdf-viewer]  3.02-1.4Portable Document Format (PDF) sui

Versions of packages latexmk suggests:
ii  ghostscript [gs-common]  8.62.dfsg.1-3.1 The GPL Ghostscript PostScript/PDF
ii  gs-common8.62.dfsg.1-3.1 Transitional package

-- no debconf information



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

Bug#500661: lintian: allow literally '?' in extended description

[markus schnalke]

Package: lintian
Version: 2.0.0
Severity: wishlist


Lintian reports a warning when there is a question mark ('?') in the
extended desription of a debconf template.
The reason is that there should be no questions in it.
But it's a problem if you want to insert a literally '?'.

An example text is:
You can use wildcard expressions like '*' or '?'.

In this case, no warning should be thrown.


It would be good to not simply search for question marks but for
question marks at the end of sentences.

Here is a patch from Stephen Gran (given on debian-mentors):

--- a/checks/debconf
+++ b/checks/debconf
@@ -312,7 +312,7 @@ foreach my $template (@templates) {
tag malformed-question-in-templates, $template-{template};
}   

  
}   

  
- if (defined ($extended)  $extended =~ /\?/) {
+ if (defined ($extended)  $extended =~ /\?(\s+|$)/) {
tag using-question-in-extended-description-in-templates, 
$template-{template};
}   

  
if ($type eq 'note') {


(note: the '+' in the regexp seems not to be needed)

See http://lists.debian.org/debian-mentors/2008/09/msg00414.html and
follow-ups for further information.



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



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

Bug#452188: adopting masqmail

[markus schnalke]

Hello,

this is a short statement about my ITA.

I use masqmail on my machines and like it. I want to have it stay in
Debian and be in a good shape. Now it'll be on me to assure that.

Currently I'm writing my diploma thesis _about masqmail_ and I will
work on it in the next months. So maintaining it is somehow the
logical result. (Not only for that time, but for the future!)

Because the upstream author (and former maintainer) Oliver Kurth is
not active anymore, I'll also take over upstream and want to start
developing it again. (I have his okay.)


I hope my skills are adequate.


meillo

P.S.
Of course help and advice is appreciated!


signature.asc
Description: Digital signature

Bug#488481: debian-installer: timezone is not freely choosable, it depends on country/language selected

[markus schnalke]

Package: debian-installer
Severity: normal


I just installed from a Debian testing netinstall with the lenny beta2
release of the installer:
http://cdimage.debian.org/cdimage/lenny_di_beta2/i386/iso-cd/debian-LennyBeta2-i386-netinstall.iso

I chose English as language and the United States as country
(thought that effects the kind of English I'm gonna get).

Acutually I'm from Germany, but want a en_US system.

When I came to configuring the timezone, I could only choose among the
US timezones (Eastern, Mountain, Pacific, Alaska, ...).
There was no way to take Central Europe/Berlin, which I wanted.

Imaging the case, that someone installes a computer, while beeing on
holiday in a different location. He probably wants to have the system
for the US, but at the moment, he wants the time like at the place he's
currently.

In any case ... the user should have the ability to choose any timezone
he wants. Please add an entry other timezone at the end of the list.


meillo

(btw: I filed this bug from an other system.)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



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

Bug#487975: ITP: resize-gd -- resizes images using the gd-library

[markus schnalke]

Package: wnpp
Severity: wishlist
Owner: markus schnalke [EMAIL PROTECTED]


* Package name: resize-gd
  Version : 0.2
  Upstream Author : markus schnalke [EMAIL PROTECTED]
* URL : http://prog.marmaro.de/resize-gd
* License : MIT/X
  Programming Lang: C
  Description : resizes images using the gd-library


About the program:
--

The program has two modes:
* aspect ratio of the images is preserved and only shrinking is done. Smaller
  images remain unmodified.
* the images are resized to match a specific size. The images probably get
  stretched and enlarged.

Only JPEG and PNG files are supported. The filetype is detected by the
filename suffix which has to be `.jpg', `.jpeg' or `.png'. Unsupported files
get skipped.

All resizing is done in-place.



The idea behind:
--

This program is meant to be a small(er) alternative to the `mogrify -resize'
command of ImageMagick. Mainly because ImageMagick has lots of dependencies,
while the GD-Library has less.

`resize-gd' is only for resizing images, not for doing all the other fancy
stuff, that ImageMagick (or GraphicsMagick) can do.

I wrote this program, because I had to install over 80MB on a fresh Debian
installation, just to get a simple web gallery generator (`genwebgallery') to
run. This came from its dependency on ImageMagick. (GraphicsMagick wouldn't
have been better.)

That is way to much, for the simple task that needs to be done: image resizing.

I haven't found a small program that simply does image resizing. So I wrote
that one.
It uses the GD library, which is only about 1/10 in size, compared to
ImageMagick.

The quality seems to be slightly worse, but still good enough for most tasks
(especially thumbnail generation).






-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



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

Bug#484597: ITP: genwebgallery -- generates minimalistic web galleries

[markus schnalke]

Package: wnpp
Severity: wishlist
Owner: markus schnalke [EMAIL PROTECTED]


* Package name: genwebgallery
  Version : 0.5
  Upstream Author : markus schnalke [EMAIL PROTECTED]
* URL : http://prog.marmaro.de/genwebgallery
* License : MIT/X
  Programming Lang: sh
  Description : generates minimalistic web galleries

Very simple tool to generate static HTML pages to view pictures on the
web. The generated pages are not very beautiful, but simple. They
contain just what is really needed - no fancy stuff. Also the generation
process is only one program call. You can specify some configuration
options like the dimension of the created thumbnails, the name of the
index page and some more.
All image processing is done via ImageMagick.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)



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

Bug#446001: mlmmj: man page differs from program: -a option

[markus schnalke]

Daniel Walrond [EMAIL PROTECTED] wrote:
 
 Hello,

hi, nice to hear from you.


 On Tue, Oct 09, 2007 at 05:54:43PM +0200, markus schnalke wrote:
  Package: mlmmj
  Version: 1.2.11-7.1
  Severity: normal
  
  The man page of ??mlmmj-make-ml.sh?? script has an error:
  
  The man page tells:
  -a: Create the needed entries in /etc/aliases
  
  but `mlmmj-make-ml.sh -a' tells:
  /usr/bin/mlmmj-make-ml: invalid option
  Try /usr/bin/mlmmj-make-ml -h for more information.
  
  and `mlmmj-make-ml.sh -h' says nothing about a '-a' option at all
  
  
  so I think the man page is obsolete.
 
 Actually the man page is correct if you're using the upstream version of
 the script. But the -a option has been removed and to make the
 mlmmj-make-ml script clever and add the alias for you.

Did you missunderstood, or did I?
To make it clear: Does the upstream version have the '-a' option?
The version in etch does not.
(Just the manpage tells about that option.)


 I see there's 3 options:
 
 1) fix the manpage
 2) use the upstream script ditching any Debian changes
 3) rework the script to include -a
 
 Personally I do not like option 1, since on my exim/mlmmj installation I don't
 add entries for mailing lists into /etc/aliases.

Haven't you meant option 3?
Cause fixing the manpage means removing the documented (but not
available) option '-a'.



This bugreport is against the version in stable (etch), and I don't
know how the situation is in unstable. Maybe everything is fine there.
(I do not have an unstable system, sorry.)

Actually, this was my first bugreport and I was so happy having found
a bug :-)

Get simple bugs like that one fixed in stable?
Since I think program versions do not get upgraded in stable (if it is
nothing serious), fixing the manpage would be the way to go.
Also it is the most logical solution (in my eyes).


meillo



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

Bug#459935: abook: export all email addresses to mutt aliases file

[markus schnalke]

Package: abook
Version: 0.5.6-3
Severity: wishlist


The following command

abook --convert --infile ~/.abook/addressbook --informat abook
--outfile mutt.aliases_test --outformat mutt

does only export the first (primary) email address of each contact.
All further (secondary) email addresses are simply ignored.
If you want to generate mutt.aliases from abook, you have to create
multiple entries for one person in abook - for every email address
one.


Also, contacts without email addresses at all, are exported. This
leads to entries in the aliases file that are useless.


The attached patch is an example solution for both problems.


meillo



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages abook depends on:
ii  debconf [debconf-2.0]  1.5.11Debian configuration management sy
ii  libc6  2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii  libncursesw5   5.5-5 Shared libraries for terminal hand
ii  libreadline5   5.2-2 GNU readline and history libraries

abook recommends no packages.

-- debconf information:
  abook/muttrc.d: true
diff -u abook-0.5.6/edit.c abook_meillo/edit.c
--- abook-0.5.6/edit.c	2005-10-20 15:59:30.0 +0200
+++ abook_meillo/edit.c	2008-01-09 16:36:06.0 +0100
@@ -96,7 +96,7 @@
 		str[MAX_EMAIL_LEN-1] = 0;
 }
 
-static void
+void
 roll_emails(int item)
 {
 	char tmp[MAX_EMAILSTR_LEN];
diff -u abook-0.5.6/edit.h abook_meillo/edit.h
--- abook-0.5.6/edit.h	2005-09-17 12:10:26.0 +0200
+++ abook_meillo/edit.h	2008-01-09 16:35:56.0 +0100
@@ -3,6 +3,7 @@
 
 void		edit_item(int item);
 void		get_first_email(char *str, int item);
+void		roll_emails(int item);
 void		add_item();
 
 #define EDITW_COLS	(COLS - 6)
diff -u abook-0.5.6/filter.c abook_meillo/filter.c
--- abook-0.5.6/filter.c	2006-04-10 18:02:10.0 +0200
+++ abook_meillo/filter.c	2008-01-09 17:15:42.0 +0100
@@ -1600,15 +1600,47 @@
 {
 	char email[MAX_EMAIL_LEN];
 	char *alias = NULL;
+	int	 email_addresses;
+	char *ptr;
 
 	db_enumerate_items(e) {
 		alias = mutt_alias_genalias(e.item);
 
 		get_first_email(email, e.item);
-		fprintf(out, *email ? alias %s %s %s\n: alias %s %s%s\n,
+
+		/* do not output contacts without email address */
+		/* cause this does not make sense in mutt aliases */
+		if (! *email) {
+			return 0;
+		}
+
+		/* output first email address */
+		fprintf(out, alias %s %s %s\n,
 alias,
 database[e.item][NAME],
 email);
+
+		/* number of email addresses */
+		email_addresses = 1;
+		ptr = database[e.item][EMAIL];
+		while (*ptr != '\0') {
+			if (*ptr == ',') {
+email_addresses++;
+			}
+			ptr++;
+		}
+
+		/* output other email addresses */
+		while (email_addresses--  1) {
+			roll_emails(e.item);
+			get_first_email(email, e.item);
+			fprintf(out, alias %s__%s %s %s\n,
+	alias,
+	email,
+	database[e.item][NAME],
+	email);
+		}
+		roll_emails(e.item);
 		xfree(alias);
 	}

Bug#457370: boxes: Alleged system-wide config file '/etc/boxes' is a directory

[markus schnalke]

Package: boxes
Version: 1.0.1a-2.1
Severity: normal


If you start a fresh installed `boxes', it crashes with the message:
  boxes: Alleged system-wide config file '/etc/boxes' is a directory

This is because debian/dirs creates /etc/boxes and debian/rules copies
the boxes-config _into_ /etc/boxes.

You get the program working, simply put /etc/boxes/boxes-config to
/etc/boxes.


I appended a patch, that probably fixes a part of the problem, but I
think, a closer look is needed.

This problem was mentioned in bug #374490 as well.



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages boxes depends on:
ii  libc6  2.3.6.ds1-13etch2 GNU C Library: Shared libraries

boxes recommends no packages.

-- no debconf information



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

Bug#446001: mlmmj: man page differs from program: -a option

[markus schnalke]

Package: mlmmj
Version: 1.2.11-7.1
Severity: normal

The man page of »mlmmj-make-ml.sh« script has an error:

The man page tells:
-a: Create the needed entries in /etc/aliases

but `mlmmj-make-ml.sh -a' tells:
/usr/bin/mlmmj-make-ml: invalid option
Try /usr/bin/mlmmj-make-ml -h for more information.

and `mlmmj-make-ml.sh -h' says nothing about a '-a' option at all


so I think the man page is obsolete.



-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages mlmmj depends on:
ii  debconf [debconf-2.0]  1.5.11Debian configuration management sy
ii  grep-dctrl 2.9.3 Grep Debian package information - 
ii  libc6  2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii  masqmail [mail-transpo 0.2.21-1.2A mailer for hosts without permane

mlmmj recommends no packages.

-- debconf information:
* mlmmj/text-format-changed:
  mlmmj/remove-on-purge: false



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