bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-mailutils] Debian patches


From: Jordi Mallach
Subject: Re: [bug-mailutils] Debian patches
Date: Wed, 15 Sep 2010 13:09:36 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Hola de nou, Sergey!

The 2.2 seems to have gone through the autobuilders for most architectures
without problems (sparc, which is a traditional annoying arch for MU is
still uncompiled, we'll see).

It's time to revisit a pair of old issues. Sorry for not being on top of
it before for so long.

On Fri, May 07, 2010 at 12:18:26AM +0300, Sergey Poznyakoff wrote:
> > In order to be able to generate manpages with a somewhat useful whatis
> > entry, I modified a few descriptions to make help2man happy.
> >
> > Would you consider applying these two patches:
> > 
> > http://patch-tracker.debian.org/patch/series/view/mailutils/1:2.1+dfsg1-6/sieve.scm_help_output.diff
> 
> Sure I will. Thank you.

This patch, along with the GNU Radius check discussed later, is the only
one I need to apply in the migration from 2.1 to 2.2. New URL:

http://patch-tracker.debian.org/patch/series/view/mailutils/1:2.2+dfsg1-1/sieve.scm_help_output.diff

I think the patch is trivial enough that it can be applied without
problems. It just adjusts the program help output to match the rest of MU
programs, with the added bonus of having help2man able to parse its
output.

On Fri, May 14, 2010 at 04:55:52PM +0300, Sergey Poznyakoff wrote:
> > The problem is, GNU radius is not packaged in Debian, so the m4 is not
> > available. I had forgotten to ask if this m4 can't be added to the
> > release tarballs, to ease regeneration of configure.
> 
> This is asked from time to time, but the problem is that keeping the
> same .am file in two repositories induces unnecessary strain on both
> maintainers (well, in this particular case, `both' means me:]) I shall
> see if this can be done on `make dist' stage.

Is there anything we can do about this? I've given it a bit of thought,
and still think requiring Radius' m4 file from GNU radius source is a
significant burden. It means people need to download both Mailutils *and*
Radius to bootstrap MU even if they intend *not* to compile in Radius
support. I'm not sure how difficult having a duplicate in MU would be from
the maintainer's POV (but can see it can bit a bit painful too); I'm just
expressing the distributor's POV. ;)

I see gnulib contains a good amount of m4 files. Wouldn't that be a good
place to keep it, so MU can import updated versions more easily?

Gràcies!
Jordi
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
address@hidden     address@hidden     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]