Bug#1061971: doxygen: does not honor PROJECT_NUMBER in LaTeX output (regression in 1.9.4)

[Ian Abbott]

Package: doxygen
Version: 1.9.4-4
Severity: normal

Dear Maintainer,

If the PROJECT_NUMBER tag is set to a non-empty value in the Doxygen
configuration file (Doxyfile), it is supposed to be rendered below the
PROJECT_NAME tag value on the title page of the LaTeX output (and on pdf files
generated from the LaTeX output).  However, a regression was introduced in
Doxygen 1.9.4 which resulted in the PROJECT_NUMBER tag value being omitted from
the LaTeX output.  See upstream bug report:


This was fixed in Doxygen 1.9.4 by upstream commit
b293309a4cacf4e6385a9a992165f6c30a0575ce. See:


The patch appears to apply cleanly to the 1.9.4-4 source, so I request it be
included in a future revision of the package.  (It is already fixed in the
"unstable" 1.9.8 package.)

To test:

1. Run `doxygen -u` in an empty directory.
2. Edit the Doxyfile and set a non-empty value for PROJECT_NUMBER.
3. Run `doxygen` to generate html and latex output in subdirectories of the
same names.
4. Examine the latex/refman.tex file and look for the `\begin{titlepage}`
environment and the `\begin{center}` environment therein. The value of the
PROJECT_NUMBER tag value (if non-empty) should appear somewhere between the
PROJECT_NAME tag value (which defaults to "My Project") and the "Generated by
Doxygen 1.9.4" text.
5. Optionally, if pdflatex and make are available, PDF output can be generated
as refman.pdf by running `make` in the latex subdirectory. On viewing the PDF
file, the PROJECT_NUMBER tag value (if non-empty) should appear between the
PROJECT NAME tag value line and the "Generated by Doxygen 1.9.4" line on the
title page.

If the bug is present, the non-empty PROJECT_NUMBER tag value is missing from
the refman.tex (step 4 above) and refman.pdf (step 5 above) files.

If the bug is fixed, the non-empty PROJECT_NUMBER tag value should appear as
described in refman.tex (step 4 above) and refman.pdf (step 5 above).


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (920, 'testing'), (910, 'unstable'), (820, 'testing'), (810, 
'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 6.5.0-5-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages doxygen depends on:
ii  libc6   2.37-14
ii  libclang-cpp14  1:14.0.6-16
ii  libclang1-141:14.0.6-16
ii  libgcc-s1   13.2.0-10
ii  libllvm14   1:14.0.6-16
ii  libstdc++6  13.2.0-10
ii  libxapian30 1.4.22-1

doxygen recommends no packages.

Versions of packages doxygen suggests:
pn  doxygen-doc
pn  doxygen-gui
pn  doxygen-latex  
ii  graphviz   2.42.2-8

-- no debconf information

Bug#1050290: glibc: Harmless bug in tcsetattr() handling of CREAD, CSIZE, PARENB bits

[Ian Abbott]

Source: glibc
Severity: minor

Dear Maintainer,

I believe that the "any/local-tcsetaddr.diff" (sic) patch applied to the glibc
sources contains a probably unmanifestible bug in the checking of c_cflag
changes other than the PARENB, CREAD, and CSIZE bits here:

+  else if ((k_termios_old.c_cflag | (PARENB & CREAD & CSIZE)) !=
+  (k_termios.c_cflag | (PARENB & CREAD & CSIZE)))
+   {
+ /* Some other c_cflag setting was successfully changed, which
+means we should not return an error. */
+ __set_errno (save);
+ retval = 0;
+   }

I believe the (PARENB & CREAD & CSIZE) subexpressions (which evaluate to 0)
should be (PARENB | CREAD | CSIZE).

This bug should be harmless as long as the TTY device either handles changes to
the PARENB, CREAD, and CSIZE settings, or always sets them to consistently
fixed values.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (920, 'testing'), (910, 'unstable'), (820, 'testing'), (810, 
'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 6.4.0-2-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1042892: fixed in nvidia-graphics-drivers-legacy-390xx 390.157-4

[Ian Abbott]

Has the build server had problems building the updated packages for all 
the relevant architectures?  So far, they have only been built for armhf.


--
-=( Ian Abbott  || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

Bug#894250: dkms: reinstalling custom kernel package may cause dkms to lose list of modules

[Ian Abbott]

Package: dkms
Version: 2.3-3
Severity: normal

Dear Maintainer,

For a custom-built linux-image package, the package's "prerm" script (that was
output by "scripts/package/builddeb" in the Linux kernel sources) runs the
/etc/kernel/prerm.d/* scripts regardless of the package operation type, which
may result in dkms losing its list of added modules prematurely.  This is
unlike the "prerm" script in Debian's own linux-image packages, which checks
that the package operation type is "remove" before running the
/etc/kernel/prerm.d/* scripts.

In particular, the /etc/kernel/prerm.d/dkms script will remove dkms modules
completely if they are not needed by any other kernels, causing dkms to forget
its list of modules to be built when a kernel is installed.  This is a problem
when reinstalling a custom linux-image package (or upgrading to a custom linux-
image package whose version differs only in the Debian package revision number)
when that is the only Linux kernel installed, because the system is left in a
state with none of the previous dkms modules installed.

I filed a bug upstream at https://github.com/dell/dkms/issues/37 but I was
unsure at the time whether it should be classed as an upstream bug.  I
presently do not consider it to be an upstream bug, or rather it is an issue
that has already been fixed upstream in dkms 2.4 (see yuzaipiaofei's comment
https://github.com/dell/dkms/issues/37#issuecomment-348067214 on 30 Nov 2017).
That fix involved a change to the dkms "uninstall" functionality and a change
to the upstream "kernel_prerm.d_dkms" script upon which Debian's
"/etc/kernel/prerm.d/dmks" script is based.

This may be related to bug #621846, but that one is about 7 years old.

[Note: System Information is from an embedded ARM Debian GNU/Linux
system that has the custom linux-image package installed.]



-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.14.3-ipec+ (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dkms depends on:
ii  build-essential  12.3
ii  coreutils8.26-3
ii  dpkg-dev 1.18.24
ii  gcc  4:6.3.0-4
ii  kmod 23-2
ii  make 4.1-9.1
ii  patch2.7.5-1+b2

Versions of packages dkms recommends:
ii  fakeroot   1.21-3.1
pn  linux-headers-686-pae | linux-headers-amd64 | linux-headers-g  
ii  lsb-release9.20161125
ii  sudo   1.8.19p1-2.1

Versions of packages dkms suggests:
pn  menu
pn  python3-apport  

-- no debconf information

Bug#815924: yacas: Does not find yacasinit.ys file, so nothing much works

[Ian Abbott]

Package: yacas
Version: 1.3.6-1
Severity: important

Dear Maintainer,

After installing the yacas package, I ran it in order to try out some simple
examples from the tutorial.  However, nothing worked as expected.  The main
reason for this seems to be due to the program not finding its initialization
file, 'yacasinit.ys'.

Here is a sample session showing the incorrect behavior:

$ yacas
yacasinit.ys(1) : File not found

yacasinit.ys(1) : File not found

yacasinit.ys(1) : File not found

This is Yacas version '1.3.6'.
Yacas is Free Software--Free as in Freedom--so you can redistribute Yacas or
modify it under certain conditions. Yacas comes with ABSOLUTELY NO WARRANTY.
See the GNU General Public License (GPL) for the full conditions.
Type ?license or ?licence to see the GPL; type ?warranty for warranty info.
See http://yacas.sf.net for more information and documentation on Yacas.
Type ?? for help. Or type ?function for help on a function.

To exit Yacas, enter  Exit(); or quit or Ctrl-c.
Type 'restart' to restart Yacas.
To see example commands, keep typing Example();
In> 1+1
CommandLine(1) : Error parsing expression, near token +

In> N(Sin(1),20)
Out> N(Sin(1),20);
In> Exit()
Out> True;
Quitting...
$

To diagnose the problem, I ran the program under strace and discovered it was
trying to open the file "/usr/share/yacas/scripts/yacasinit.ys". However, that
file is actually installed as "/usr/share/yacas/yacasinit.ys".

As a workaround, I added a symlink:

$ sudo ln -s . /usr/share/yacas/scripts

After that, the program worked as normal.  Here are those example inputs and
outputs with the workaround in place:

In> 1+1
Out> 2
In> N(Sin(1),20)
Out> 0.84147098480789650665
In> Exit()
Out> True
Quitting...



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages yacas depends on:
ii  gnuplot 4.6.6-3
ii  google-chrome-stable [www-browser]  48.0.2564.116-1
ii  iceweasel [www-browser] 44.0.2-1
ii  libc6   2.21-9
ii  libgcc1 1:5.3.1-8
ii  libstdc++6  5.3.1-8
ii  w3m [www-browser]   0.5.3-26
ii  yacas-doc   1.3.6-1

yacas recommends no packages.

Versions of packages yacas suggests:
pn  texmacs  

-- no debconf information

Bug#787104: regression: 3.14.2 is 1 row × 1 column smaller than requested

[Ian Abbott]

If I build vte2.91_0.40.2.orig.tar.xz from source, I don't see the bug 
with the row and column sizes.  The bug only seems to appear after 
applying 
debian/patches/0001-Add-the-style-context-provider-with-FALLBACK-priorit.patch 
from vte2.91_0.40.2-1.debian.tar.xz.  See 
https://bugzilla.gnome.org/show_bug.cgi?id=750559#c8


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-


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

Bug#769575: vim-common: vim.desktop sets name to GVim instead of Vim

[Ian Abbott]

Package: vim-common
Version: 2:7.4.488-1
Severity: normal

Dear Maintainer,

The /usr/share/applications/vim.desktop installed by vim-common sets the "Name"
field to "GVim" even though the desktop entry opens vim in a terminal.  It also
makes file managers' "open with" handlers difficult to use if vim-gui-common is
installed, since that installs gvim.desktop with the same value for the "Name"
field and identical values for the "Icon" fields.

Please consider changing the "Name" field to "Vim".

Cheers,
Ian Abbott



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages vim-common depends on:
ii  libc6  2.19-13

Versions of packages vim-common recommends:
ii  vim2:7.4.488-1
ii  vim-gtk [vim]  2:7.4.488-1
ii  vim-tiny   2:7.4.488-1

vim-common 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#765069: huge SVG icons

[Ian Abbott]

On Sun, 9 Nov 2014 22:22:30 + Emmanuele Bassi  wrote:

this is a change in GTK+ 3.14: the SVG icons are loaded as specified
by the icon theme data, and not constrained by the widget's
allocation.

the release notes for GTK+ 3.14 say:

* The icon theme code has become a little pickier about sizes and is not
  automatically scaling icons beyond the limits defined in the icon theme
  unless explicitly asked to do so with GTK_ICON_LOOKUP_FORCE_SIZE.
-- https://git.gnome.org/browse/gtk+/tree/README.in#n91

the application code should conform to that.


So does GNOME's default icon theme constrain the icon size to some maximum?

The /usr/share/pixmaps/vim.svg installed by vim-gui-common has a width 
and height of 550pt.  On my system currently, it is shown at a size of 
688x688 pixels by both Nautilus's "Open With" handler and by "Image 
Viewer" (eog).  However the "Open With" tab on Nautilus's file 
"Properties" dialog shows the icon at a small size.  Is the large icon 
shown by the "Open With" handler a bug in Nautilus or some GNOME/GTK+ 
library?


A workaround is to install a GNOME icon theme that includes its own vim 
icon (for example "gnome-colors-common") and select that icon theme in 
the GNOME Tweak Tool.  gnome-colors-common installs a bunch of fixed 
size vim.png icons and a scalable vim.svg (with a size of 48x48 pixels).



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

Bug#765069: vim-gnome: huge icon in application selection menu

[Ian Abbott]

On Mon, 13 Oct 2014 12:13:50 +0200 Niklas Fiekas 
 wrote:

Package: vim-gnome
Version: 2:7.4.430-1
Severity: normal

Dear maintainer,

a huge icon is displayed for vim-gnome in Gnome's application selection
menu.

Steps to reproduce:

 1. Open nautilus.
 2. Right click a text file.
 3. Hover "Open with ..."
 4. A list of text editors is displayed. The icons are something like
32x32 pixels. The icon of vim-gnome is huge instead.

I believe this was fine in earlier versions.

Best regards
Niklas Fiekas

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.gnome
/usr/bin/vim is /usr/bin/vim.gnome
/usr/bin/gvim is /usr/bin/vim.gnome

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages vim-gnome depends on:
ii  libacl1 2.2.52-2
ii  libbonoboui2-0  2.24.5-2
ii  libc6   2.19-11
ii  libgdk-pixbuf2.0-0  2.30.8-1+b1
ii  libglib2.0-02.42.0-2
ii  libgnome-2-02.32.1-5
ii  libgnomeui-02.24.5-3
ii  libgpm2 1.20.4-6.1
ii  libgtk2.0-0 2.24.24-1
ii  libice6 2:1.0.9-1
ii  liblua5.2-0 5.2.3-1
ii  libpango-1.0-0  1.36.8-2
ii  libperl5.20 5.20.1-1
ii  libpython2.72.7.8-7
ii  libruby2.1  2.1.3-1
ii  libselinux1 2.3-2
ii  libsm6  2:1.2.2-1
ii  libtcl8.6   8.6.2+dfsg-1
ii  libtinfo5   5.9+20140913-1
ii  libx11-62:1.6.2-3


I see the same problem on my system, except I don't have vim-gnome 
installed.  I have vim-gtk installed.  I suspect the bug may be in the 
vim-gui-common package.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-


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

Bug#658514: libgssapi-krb5-2: krb5_gss_get_name_attribute() fails to set *display_value on success

[Ian Abbott]

The upstream bug was fixed in release 1.10.1 on 08 Mar 2012.  Is there 
any news on an updated Debian package?




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

Bug#658514: libgssapi-krb5-2: krb5_gss_get_name_attribute() fails to set *display_value on success

[Ian Abbott]

Package: libgssapi-krb5-2
Version: 1.10+dfsg~beta1-2
Severity: important
Tags: upstream

Dear Maintainer,

There is a really nasty bug in krb5_gss_get_name_attribute(), called
indirectly from the public gss_get_name_attribute() function.  The
bug is around lines 389-394 of "src/lib/gssapi/krb5/naming_exts.c":

if (display_value != NULL) {
if (code != 0)
code = data_to_gss(&kdisplay_value, display_value);
else
free(kdisplay_value.data);
}

The "if (code != 0)" test should be inverted, otherwise
*display_value is updated on error instead of on success.

What is meant to happen is that on success, if display_value is
non-NULL, display_value->length and display_value->value describe
some dynamically allocated blob of data or refer to NULL with a
length of 0.  (Similarly for the 'value' parameter which is not
affected by the bug.)

I found this problem when investigating a problem in Samba's smbd
whicj kept dumping core when I browsed a Samba share (using security
= "ads") from Windows Explorer running on Windows XP.

In Samba 3.6.1 and 3.6.3, the problem occurs in gse_get_pac_blob()
in "source3/librpc/crypto/gse.c".  It calls gss_get_name_attribute()
with the 'value' and 'display_value' pointers pointing to
uninitialized variables on the stack (called 'pac_buffer' and
'pac_display_buffer' respectively).  When the function return value
indicates success, it later passes pointers to these same variables
(which are assumed to be valid) to gss_release_buffer() which
eventually calls free().  However, because of the bug in
krb5_gss_get_name_attribute(), only the first of these variables
('pac_buffer') is valid, the second one ('pac_display_buffer') being
still in its uninitialized state.  Crucially, its '.value' member is
uninitialized, but is meant to be either NULL or a pointer to
dynamically allocated memory, so when gss_release_buffer() tries to
release this memory it blows up.  (As an aside, gse_get_pac_blob()
does nothing else with the 'pac_display_buffer' variable.)

I emailed a bug report to  about 90 minutes ago,
but so far it hasn't appeared in the archive for the list.  (I'm not
subscribed, so its probably awaiting moderator approval.)

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

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

Versions of packages libgssapi-krb5-2 depends on:
ii  libc6  2.13-24
ii  libcomerr2 1.42-1
ii  libk5crypto3   1.10+dfsg~beta1-2
ii  libkeyutils1   1.5.2-2
ii  libkrb5-3  1.10+dfsg~beta1-2
ii  libkrb5support01.10+dfsg~beta1-2
ii  multiarch-support  2.13-24

libgssapi-krb5-2 recommends no packages.

Versions of packages libgssapi-krb5-2 suggests:
ii  krb5-doc   1.10+dfsg~beta1-2
ii  krb5-user  1.10+dfsg~beta1-2

-- 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#595482: (no subject)

[Ian Abbott]

Since this package is now considered "stable", it would be really handy
if this bug could be fixed by modifying the CFLAGS as J suggested in the
original report.  My main concern is that amavisd-new depends on 'pax'
but this bug in pax causes amavisd-new to avoid checking any tar file
for viruses.  It thinks any such tar files are a mail bomb, due to the
mis-reported sizes of the contents.

At the moment, I have to hold back pax to the earlier 1.5-1 version just
to avoid this bug.



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

Bug#595482: (no subject)

[Ian Abbott]

J's suggestion of adding -DLONG_OFF_T to CFLAGS worked on my 32-bit system.

I also tried replacing -DLONG_OFF_T with -D_FILE_OFFSET_BITS=64 in an
attempt to get large file support, but that caused the following
compilation error:

cc -Wall -O2 -g -DNET2_STAT -D_PATH_DEFTAPE=\"/dev/rmt0\" -DDEBIAN
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64   -c -o ftree.o ftree.c
In file included from ftree.c:54:
/usr/include/fts.h:41:3: error: #error " cannot be used with
-D_FILE_OFFSET_BITS==64"



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

Bug#595482: (no subject)

[Ian Abbott]

On my i386 (actually i686) system, pax seemed to be showing directories
with size 2^33 (8589934592) and was adding 2^32 (4294967296) to the size
of files.

This bus has knock-on effects for amavisd, and causes it to treat an
email containing a (possibly compressed) tar archive as a mail bomb,
issuing a warning like this:

WARNING: NOT CHECKED FOR VIRUSES (mail bomb?):
  Exceeded storage quota 183074000 bytes by do_pax...



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

Bug#569588: pure-ftpd-common: The 'IPV4Only' and 'IPV6Only' config files are ignored.

[Ian Abbott]

Package: pure-ftpd-common
Version: 1.0.24-1
Severity: normal

The 'IPV4Only' and 'IPV6Only' configuration files in
'/etc/pure-ftpd/conf' are ignored by the pure-ftpd-wrapper script.

The cause of the problem is this section of the script:

for (@conffiles) {
# simply skip files with non-word characters
next unless /^[A-Za-z]+$/;

The above regular expression does not match the 'IPV4Only' and
'IPV6Only' options, so these files are skipped.

Since all currently supported options start with an upper case letter
followed by any case alphanumerics, and are at least 2 characters long,
perhaps the following regex will do:

next unless /^[A-Z][A-Za-z0-9]+$/;

but let's leave that to the maintainer!

Regards,
Ian Abbott

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)

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

Versions of packages pure-ftpd-common depends on:
ii  debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii  libpam-modules1.1.0-4Pluggable Authentication Modules f
ii  perl-modules  5.10.1-9   Core Perl modules

Versions of packages pure-ftpd-common recommends:
ii  pure-ftpd 1.0.24-1   Pure-FTPd FTP server

pure-ftpd-common suggests no packages.

-- debconf information:
* pure-ftpd/ftpwho-setuid: true
* pure-ftpd/virtualchroot: true
  pure-ftpd/minuid:
  pure-ftpd/config-obsolete-note:
  pure-ftpd/saved-inetd-config:
* pure-ftpd/standalone-or-inetd: inetd



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