Bug#1069294: [PATCH] install emacs-nox desktop file

[Brendan O'Dea]

Package: emacs-nox
Version: 1:29.3+1-1
Tags: patch

A minor typo in debian/rules installs the emacs.term-desktop file in the
wrong location for emacs-nox.

It appears to be a simple typo (copy-and-paste error).  Compare the
entries in /usr/share/applications of:

  https://packages.debian.org/sid/amd64/emacs-gtk/filelist
  https://packages.debian.org/sid/amd64/emacs-nox/filelist

Patch follows.

--bod

diff --git a/debian/rules b/debian/rules
index b7ab47c912f..6250f60ea9b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -565,9 +565,9 @@ override_dh_auto_install: $(autogen_install_files)
  $(call emacs_inst,build-nox,$(install_dir_nox))
  $(call 
install_common_binpkg_bits,$(install_dir_nox),$(pkgdir_nox),emacs-nox,nox)
   # install desktop entry
- install -d $(pkgdir_gtk)/usr/share/applications
+ install -d $(pkgdir_nox)/usr/share/applications
  install -m 0644 \
-   debian/emacs-term.desktop $(pkgdir_gtk)/usr/share/applications/
+   debian/emacs-term.desktop $(pkgdir_nox)/usr/share/applications/
  rm -rf $(install_dir_nox)
 endif
 

Bug#1068124: exec-path-from-shell-el 2.1-1 FTBFS if network is unavailable

[Brendan O'Dea]

Package: exec-path-from-shell-el
Version: 2.1-1
Tags: patch

The upstream Makefile attempts to run some sanity checks on the
library, including running `package-lint`, which it attempts to
download via `package.el`.  This fails when the build daemon does not
have network access:

 * 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/exec-path-from-shell-el.html
 * 
https://bugs.launchpad.net/ubuntu/+source/exec-path-from-shell-el/+bug/2034630

Given that the Makefile doesn't actually do anything useful to anyone
other than the upstream maintainer (package-lint, byte compile, remove
byte compile output), the attached patch disables the build entirely.

--bod


rules.patch
Description: Binary data

Bug#1067238: Add support for man preprocessors, like tbl

[Brendan O'Dea]

On Thu, 21 Mar 2024 at 03:27, Faidon Liambotis  wrote:
> In trixie and above, including tables in a manpage does not work
> anymore, unless the "tbl" preprocessor is added explicitly.  [...]

I'm not aware of a change to help2man which would have affected this,
so I'm assuming that it is a man/groff change.

> help2man does not output any tables by default (AIUI) but in case one
> adds text e.g. in their DESCRIPTION that includes tables, it won't work.

help2man is intended to take `--help` output and massage it into a
manual page.  The `--help` output still needs to be readable however,
since people do invoke `foo --help` from the command line.  One option
would be to have help2man recognize markdown-format tables, which
would preserve the property of the `--help` output being readable.  A
simpler option would be to add the table to an include file:
https://www.gnu.org/software/help2man/#Including-text

> While my issue is specific to the "tbl" preprocessor, man(1) supports
> other preprocessors, including eqn (e), grap (g), pic (p), tbl (t),
> vgrind (v), refer (r). See the `-p` argument. Perhaps help2man should
> just gain an argument to support adding arbitrary preprocessors to its
> output?

I will look into that.

--bod

Bug#1006193: Remove luit, now packaged separately

[Brendan O'Dea]

On Sun, Nov 12, 2023 at 04:39:30PM -0500, Thomas Dickey wrote:
>On Wed, Mar 02, 2022 at 03:09:37PM -0500, Thomas Dickey wrote:
>While this has been applied, it's not moving along because the related
>version x11-utils (7.7+6) has not gone into testing yet - more than a year.

It hasn't reached testing because it hasn't yet been uploaded to
unstable.

Sven, do you want me to upload?  There are a couple of other changes to
pick up as well.

I send an access requst to join https://salsa.debian.org/xorg-team some
time ago which is still pending, but for it shouldn't be needed for this
upload if I'm just pushing what's already been comitted to the default
branch.

--bod

Bug#1032651: vile FTCBFS: broken cross-compilation specific autoconf test

[Brendan O'Dea]

On Mon, Mar 13, 2023 at 11:03:11AM +0100, Helmut Grohne wrote:
>On Sat, Mar 11, 2023 at 08:24:40AM +1100, Brendan O'Dea wrote:
>> This was fixed in 9.8y-2 (closing #1029956).
>
>This is partially correct. The bug was closed. The actual problem was
>fixed at the root indeed. But this really wasn't fixed in practice and I
>failed to notice my earlier bug report which I should have reopened
>instead.

Apologies Helmut, I was blindly assuming that dh_autoreconf would have
dealt with the generation...  But it turns out that I don't use it for
this package (at some point in the past it was using a patched autoconf
which wasn't packaged for Debian).

I'll upload a new version shortly with the configure change.

--bod

Bug#1032651: vile FTCBFS: broken cross-compilation specific autoconf test

[Brendan O'Dea]

tags 1032651 unreproducible
thanks

On Fri, Mar 10, 2023 at 12:24:26PM +0100, Helmut Grohne wrote:
>Source: vile
>Version: 9.8y-2
>
>vile fails to cross build from source, because the cross-compilation
>specific test contains a syntax error. This will become obvious once
>looking at the attached patch. Thus it fails to define GETPRGP_VOID and
>that produces a compilation error later.

This was fixed in 9.8y-2 (closing #1029956).

I can't reproduce with the source packages:

  % apt-get source vile
  [...]
  Get:1 http://mirror.aarnet.edu.au/debian unstable/main vile 9.8y-2 (dsc) 
[2,034 B]
  Get:2 http://mirror.aarnet.edu.au/debian unstable/main vile 9.8y-2 (tar) 
[1,735 kB]
  Get:3 http://mirror.aarnet.edu.au/debian unstable/main vile 9.8y-2 (diff) 
[10.3 kB]
  [...]
  % cd vile-9.8y 
  % fgrep -c \$ac_includes_default aclocal.m4 
  15
  % fgrep -c \#ac_includes_default aclocal.m4 
  0  

See also:

  
https://salsa.debian.org/debian/vile/-/commit/f57788a3b30cfb3d860bd31a01ce57fc43b9c0e6

Did you pull the package from git?  I just noticed that I'd neglected to
push that version, and have just done so now.

--bod

Bug#1024997: install-info: dir entry for emacs is bolloxed

[Brendan O'Dea]

On Mon, Jan 30, 2023 at 10:37:00AM +0100, Hilmar Preuße wrote:
>Am 30.01.2023 um 06:51 teilte Brendan O'Dea mit:
>> This is still present in the unstable version of the package.  You
>> should probably keep this open until 7.0 gets to unstable.
>> 
>IIRC the Debian BTS is based on versions, unless it is an RC bug. So
>I'll probably forget about this bug. Please be so kind to close it, when
>TInfo 7.0.x entered unstable. I'm not sure, if this will happen before
>bookworm.

There is no automatic promotion from experimental.

It is reasonable to mark a bug as fixed/closed on successful upload to
unstable, because over time that fix will make it to testing, stable,
old-stable, etc without further involvement from the maintainer.

You shouldn't mark a bug as fixed however when only the experimental
version works, since making that fix more widely available will take an
additional upload to unstable.  That unstable upload should be the one
which closes the bug.

https://www.debian.org/Bugs/Developer#closing says that problems are
considered fixed when "the bug fix enters the Debian archive".  The
experimental distribution is not "the Debian archive".

>From https://www.debian.org/doc/manuals/debian-faq/ftparchives.en.html#dists:

  "Experimental is used for packages which are still being developed,
   and with a high risk of breaking your system." and "Users shouldn't
   be using packages from there [..]"

--bod

Bug#1024997: install-info: dir entry for emacs is bolloxed

[Brendan O'Dea]

reopen 1024997 !
thanks

On Mon, Nov 28, 2022 at 11:46:49PM +0100, Hilmar Preuße wrote:
>Version: 7.0-1
>
>Am 28.11.2022 um 23:28 teilte Barak A. Pearlmutter mit:
>
>> Yes! That fixes it.
>> 
>Closing then.

This is still present in the unstable version of the package.  You
should probably keep this open until 7.0 gets to unstable.

This can be reproduced reliably by running:

  rm -f /tmp/dir[12]
  install-info /usr/share/info/muttrc-mode.info.gz /tmp/dir1
  install-info /usr/share/info/mutt-alias.info.gz /tmp/dir2

The contents of both resulting files have garbage in them.  There may be
other info files which have this problem, but those were the two on my
system which were corrupting the directory.

Package versions:

  install-info 6.8-6+b1
  elpa-muttrc-mode 1.2.1-3
  elpa-mutt-alias  1.5-4

--bod

Bug#1012474: [PATCH] Xsession does not recognise shell builtins as session-type

[Brendan O'Dea]

Package: x11-common
Version: 1:7.7+23
Severity: normal
Tags: patch
X-Debbugs-Cc: b...@debian.org

A recent change[1] to 20x11-common_process-args causes
"/etc/X11/Xsession true" to pop up an xmessage error, followed by
running the default session.

The default xpra configuration contains such an invocation in order to
run /etc/X11/Xsession.d/* without  actually running ~/.xsession.

The reason is that "command -v true" returns "true", which fails the
test for both -e and -x.

Given that "command -v program" already checks if program exists and is
executable, then the test may be simplified to just that invocation.

[1] 
https://salsa.debian.org/xorg-team/xorg/-/commit/3d6bd60c17ff052fc3f35eb0f17553fcf3d0b23f

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

Kernel: Linux 5.17.0-2-686-pae (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages x11-common depends on:
ii  lsb-base  11.2

x11-common recommends no packages.

x11-common suggests no packages.

-- no debconf information
--- 20x11-common_process-args.orig  2021-08-18 20:58:20.0 +1000
+++ 20x11-common_process-args   2022-06-08 09:55:01.933452629 +1000
@@ -33,14 +33,8 @@
 ;;
   *)
 # Specific program was requested.
-STARTUP_FULL_PATH=$(command -v "${1%% *}" || true)
-if [ -n "$STARTUP_FULL_PATH" ] && [ -e "$STARTUP_FULL_PATH" ]; then
-  if [ -x "$STARTUP_FULL_PATH" ]; then
-STARTUP="$1"
-  else
-message "unable to launch \"$1\" X session ---" \
-"\"$1\" not executable; falling back to default session."
-  fi
+if command -v "${1%% *}" >/dev/null 2>&1; then
+  STARTUP="$1"
 else
   message "unable to launch \"$1\" X session ---" \
   "\"$1\" not found; falling back to default session."

Bug#1006193: Remove luit, now packaged separately

[Brendan O'Dea]

Package: x11-utils
Version: 7.7+5
Severity: normal
Tags: patch
X-Debbugs-Cc: b...@debian.org

Merge request to remove luit from x11-utils:

  https://salsa.debian.org/xorg-team/app/x11-utils/-/merge_requests/1

now packaged separately, this commit removes luit and adds a recommends for
the new package.

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

Kernel: Linux 5.16.0-1-686-pae (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages x11-utils depends on:
ii  libc6   2.33-6
ii  libfontconfig1  2.13.1-4.4
ii  libfontenc1 1:1.1.4-1
ii  libgl1  1.4.0-1
ii  libx11-62:1.7.2-2+b1
ii  libx11-xcb1 2:1.7.2-2+b1
ii  libxaw7 2:1.0.13-1.1
ii  libxcb-shape0   1.14-3
ii  libxcb1 1.14-3
ii  libxcomposite1  1:0.4.5-1
ii  libxext62:1.3.4-1
ii  libxft2 2.3.2-2
ii  libxi6  2:1.8-1
ii  libxinerama12:1.1.4-3
ii  libxkbfile1 1:1.1.0-1
ii  libxmu6 2:1.1.3-3
ii  libxmuu12:1.1.3-3
ii  libxrandr2  2:1.5.2-1
ii  libxrender1 1:0.9.10-1
ii  libxt6  1:1.2.1-1
ii  libxtst62:1.2.3-1
ii  libxv1  2:1.0.11-1
ii  libxxf86dga12:1.1.4-1+b3
ii  libxxf86vm1 1:1.1.4-1+b2

x11-utils recommends no packages.

Versions of packages x11-utils suggests:
pn  mesa-utils  

-- no debconf information

Bug#894126: help2man: Problem with encoding kk_KZ.RK1048

[Brendan O'Dea]

On Wed, Jan 05, 2022 at 02:54:48PM +0100, Marcus Hardt wrote:
>I'm experiencing the same problem every now and then, because reprotest
>uses this encoding to verify reproducible builds.
>
>The problem seems to be triggered by setting this environment:
>
>LANG=kk_KZ.RK1048
>LANGUAGE=kk_KZ.RK1048:fr

As noted earlier in this bug, the only error reports that I've had about
this issue are from reprotests, and not actual users wanting to use
RK1048 as their language encoding for kk_KZ.

I've prepared a change which should fix this problem, by falling back to
calling iconv from libc-bin to handle unrecognised encodings.

Hopefully this should resolve the issue for reprotests, although I've
tried to make it sufficiently general that it might actually be useful
for someone with an unusual, unsupported encoding.

--bod

Bug#1004660: [PATCH] lintian-annotate-hints: line-wrapping broken when stdin is not a terminal

[Brendan O'Dea]

Package: lintian
Version: 2.114.0
Severity: normal
Tags: patch

When lintian-annotate-hints reads input from a file, or has lintian
ouput piped to it (as is suggested in the manual), the terminal width is
unset, which produces warnings to stderr and wrapping at 19 colums:

  % lintian *.dsc *.changes | lintian-annotate-hints
  N:
  W: luit-dbgsym: elf-error In program headers: Unable to find program 
interpreter name 
[usr/lib/debug/.build-id/70/10dc50cc05821fbf5aa86813b0dc6b341982d8.debug]
  Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 398,  line 1.
  Use of uninitialized value $columns in subtraction (-) at 
/usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 413,  line 1.
  Increasing $Text::Wrap::columns from  to 19 to accommodate length of 
subsequent tab at /usr/share/lintian/bin/../lib/Lintian/Output/EWI.pm line 423.
  N:
  N:   The
  N:   file
  N:   appears
  N:   to
  N:   be
  N:   in
  N:   ELF
  N:   format
  N:   but

Attached is a patch which provides sensible defaults for the case that
stdin is not a tty.

--bod
--- lintian-annotate-hints.orig	2021-11-28 04:20:56.0 +1100
+++ lintian-annotate-hints	2022-01-31 21:36:19.026248518 +1100
@@ -55,7 +55,7 @@
 
 const my $NEW_PROGRAM_NAME => q{lintian-annotate-hints};
 
-my $TERMINAL_WIDTH;
+my $TERMINAL_WIDTH = $ENV{COLUMNS} || 80;
 ($TERMINAL_WIDTH, undef, undef, undef) = GetTerminalSize()
   if is_interactive;
 

Bug#1002990: ITS: byacc

[Brendan O'Dea]

[+m...@qa.debian.org]

On Sun, Jan 02, 2022 at 05:05:20AM -0500, Thomas Dickey wrote:
>Package: byacc
>Version: 20220101
>Severity: important
>
>Dear Maintainer,
>
>   * byacc package has not been updated in Debian since 2014.
>   * sent email to package maintainer (December 4, 2021)
>   * package maintainer did not respond to email.
>   * package maintainer should update to the current version of byacc
>
>I've been preparing an NMU, will proceed when I have sponsor's approval.
>
>-- System Information:
>Debian Release: 10.11
>  APT prefers oldstable-updates
>  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 4.19.0-18-amd64 (SMP w/2 CPU cores)
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
>LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
>LC_ALL set to en_US.UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>Versions of packages byacc depends on:
>ii  libc6  2.28-10
>
>byacc recommends no packages.
>
>byacc suggests no packages.
>
>-- no debconf information

Bug#972741: help2man: version-string too restrictive, needs to allow empty version

[Brendan O'Dea]

severity 972741 wishlist
thanks

On Fri, Oct 23, 2020 at 11:29:28AM +0800, Drew Parsons wrote:
>help2man is too restrictive with regards to the version string.  Often
>a program does not support the --version flag at all, but help2man
>does not handle that tidily.  The only way you can manage that is to
>set --version-string explicitly.
>
>Other times you simply might not want to use the version string even
>if it is available.
>
>But you can't set
>
>  help2man --version-string=""
>
>An empty string gives an error:
>  Option version-string requires an argument
>
>So the version string handling is too restrictive. A better default
>(in my opinion) is to use an empty version string if the command does
>not provide one, and to make it possible to set --version-string=""

The problem of converting arbitrary unstructured help/version text into a
manual page is somewhat beyond the capability of this simple Perl script.

help2man is documented[0] to handle "reasonably standard `--help' and
`--version' outputs", and here "standard" means what is described in the GNU
standards manual[1].

If your program doesn't support --version at all, then my suspicion would be
that the --help output is probably not in the format the script expects
either.

I would be interested to see sample --help output.  What is the program?

--bod

[0] https://www.gnu.org/software/help2man/#Overview
[1] 
https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html#Command_002dLine-Interfaces

Bug#958345: help2man generates invalid .TH line for pasdoc

[Brendan O'Dea]

On Tue, 21 Apr 2020 at 04:39, Paul Gevers  wrote:
> Package: help2man
> Version: 1.47.13
> Severity: normal
>
> change in the output of help2man. dh_installman determines the section
> based on the .TH line. [...]

Sorry, unintended consequence of a recent change.  I've reverted that
mostly for 1.47.14 and it appears to work with the pasdoc --version
output.  Will upload shortly.

Bug#953604: vile: Mismatched source format vs source version

[Brendan O'Dea]

On Wed, Mar 11, 2020 at 12:57:59AM +0100, Guillem Jover wrote:
>From the historical data in snapshot.debian.org, this would appear as
>the build was done with a missing orig so dpkg-source considered it a
>native format?

Thanks for the report, and the pointer to the possible cause.

Indeed, this error was introduced into the builds of 9.8t-2 and -3, probably
as a result of the .orig.tar.gz having been inadvertantly removed.

I'll build a non-native 9.8t-4 now.

--bod

Bug#948403: help2man: Produces man pages with warnings that cause lintian check to fail

[Brendan O'Dea]

On Sat, Jan 11, 2020 at 08:45:10PM +1100, Brendan O'Dea wrote:
>[...]  I've attached a shell script which outputs an amended --help text for
>qmi-firmware-update which may work better.  Use "help2man X | man -l -" to
>test, where "X" is the filename you saved it to.  Make sure that file is
>executable.

Oops, *really* attach script...

--bod
#!/bin/sh

for arg; do
  case $arg in
--help) cat <

Bug#948403: help2man: Produces man pages with warnings that cause lintian check to fail

[Brendan O'Dea]

On Wed, Jan 08, 2020 at 08:26:22AM +, Bob Ham wrote:
>I'm creating a package of an updated version of libqmi which uses
>help2man to generate its man pages.  Unfortunately, the resulting man
>pages have issues which cause lintian checks for the package to fail:
>
>W: libqmi-utils: manpage-has-errors-from-man 
>usr/share/man/man1/qmi-firmware-update.1.gz 99: warning [p 2, 6.5i, div 
>'an-div', 0.0i]: can't break line
>W: libqmi-utils: manpage-has-errors-from-man usr/share/man/man1/qmicli.1.gz 
>76: warning [p 2, 1.5i, div 'an-div', 0.0i]: cannot adjust line

There is really not much that can be done to deal with the long arguments,
sorry.  You may need to add a lintian override for that one, as it does
actually appear to render, despite the warning.

The "*** warning ***" message needs to be changed in order that it looks
reasonable in both the --help output, and on the manuage page.  I've attached
a shell script which outputs an amended --help text for qmi-firmware-update
which may work better.  Use "help2man X | man -l -" to test, where "X" is the 
filename you saved it to.  Make sure that file is executable.

The output from the script also adjusts the Usage in the output to work with
help2man.  What is expected is:

  Usage: program [ARGS]

  What this program does.

which is not what qmi-firmware-update is producing.  See the info page for
the recommended format:

  info '(help2man)--help recommendations'

--bod

Bug#934601: help2man: FTBFS when binNMUed

[Brendan O'Dea]

Ah, never mind me.  It was the very last change I made that seems to have
tickled this problem.  Uploading shortly.

On Mon, 12 Aug 2019 at 22:19, Brendan O'Dea  wrote:

> This is due to a sanity check that I've added to ensure that everything is
> prepared for an "upstream" release to both Debian and GNU.  This is the
> first time in ~16 years of the package containing an arch-specific binary
> that I've come across a case where a bin-NMU has been required for
> help2man.  Out of curiosity, why?  libc update?
>
> I'll upload a change shortly to skip these checks if the version number
> matches the bin-NMU pattern.
>
> On Mon, 12 Aug 2019 at 22:03, Ivo De Decker  wrote:
>
>> package: src:help2man
>> version: 1.47.10
>> severity: serious
>> tags: ftbfs
>>
>> Hi,
>>
>> The latest version of help2man in unstable fails on i386 because it was
>> binNMUed there:
>>
>> https://buildd.debian.org/status/package.php?p=help2man
>>
>> dpkg-buildpackage
>> -
>>
>> Command: dpkg-buildpackage -us -uc -mamd64 / i386 Build Daemon
>> (x86-ubc-02)  -B -rfakeroot
>> dpkg-buildpackage: info: source package help2man
>> dpkg-buildpackage: info: source version 1.47.10+b1
>> dpkg-buildpackage: info: source distribution sid
>>  dpkg-source --before-build .
>> dpkg-buildpackage: info: host architecture i386
>>  fakeroot debian/rules clean
>> test -x configure  # autoconf has been run
>> grep -qF 'help2man-1.47.10+b1.tar' README  # exists and up to date
>> make: *** [debian/rules:122: check-maint-prep] Error 1
>> dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned
>> exit status 2
>>
>> Cheers,
>>
>> Ivo
>>
>

Bug#934601: help2man: FTBFS when binNMUed

[Brendan O'Dea]

This is due to a sanity check that I've added to ensure that everything is
prepared for an "upstream" release to both Debian and GNU.  This is the
first time in ~16 years of the package containing an arch-specific binary
that I've come across a case where a bin-NMU has been required for
help2man.  Out of curiosity, why?  libc update?

I'll upload a change shortly to skip these checks if the version number
matches the bin-NMU pattern.

On Mon, 12 Aug 2019 at 22:03, Ivo De Decker  wrote:

> package: src:help2man
> version: 1.47.10
> severity: serious
> tags: ftbfs
>
> Hi,
>
> The latest version of help2man in unstable fails on i386 because it was
> binNMUed there:
>
> https://buildd.debian.org/status/package.php?p=help2man
>
> dpkg-buildpackage
> -
>
> Command: dpkg-buildpackage -us -uc -mamd64 / i386 Build Daemon
> (x86-ubc-02)  -B -rfakeroot
> dpkg-buildpackage: info: source package help2man
> dpkg-buildpackage: info: source version 1.47.10+b1
> dpkg-buildpackage: info: source distribution sid
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture i386
>  fakeroot debian/rules clean
> test -x configure  # autoconf has been run
> grep -qF 'help2man-1.47.10+b1.tar' README  # exists and up to date
> make: *** [debian/rules:122: check-maint-prep] Error 1
> dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned
> exit status 2
>
> Cheers,
>
> Ivo
>

Bug#932560: vile: Don't build against flex-old

[Brendan O'Dea]

On Sat, Jul 20, 2019 at 01:10:19PM -0400, Thomas Dickey wrote:
>Actually it's debatable whether flex "new" is maintained.

I did a test build against the current version (2.6.4), and it no longer has
the issue[0] which caused me to revert to flex-old some time ago.

Some brief testing of a handful of modes (mail, ada, html, c) appears to work
pretty much the same as the package built with flex-old.  There may be subtle
behaviour changes which I didn't see, but the egregious symbol naming issue is
gone.  I don't recall if that was changed in flex, or worked around in
configure at this point.

Note that there seem to have been quite a few changes made to flex since I
last used it, and it appears to produce code with less warnings now than
flex-old does (using these[1] gcc warning flags).  I'll note that some are
conversion flags, and you've suggested that there may be issues with those,
but there are still fewer in the newer flex.

Compilation output of awk-filt.l attached for both.

I can't think of a compelling reason at this point to stick with flex-old, so
will upload a new package with the build-dependency changed and see how that
goes.

--bod

[0] http://bugs.debian.org/832973
[1] https://invisible-island.net/personal/lint-tools.html#tool_gcc
/bin/sh ../../plink.sh gcc -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wshadow -Wconversion -rdynamic   -o vile-au3-filt.so -shared au3-filt.o
compiling awk-filt.l
echo '#include ' > awk-filt.c
flex -Pawk_ -t ../../filters/awk-filt.l >> awk-filt.c
gcc -c -fPIC -I. -I.. -I../../filters -I../.. -DHAVE_CONFIG_H 
-I../../filters/filters -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=500 
-D_FILE_OFFSET_BITS=64 -I../../filters/filters -Wall -Wstrict-prototypes 
-Wmissing-prototypes -Wshadow -Wconversion -rdynamic  -Dfilter_def=define_awk 
-Dprivate_yywrap=awk_wrap ./awk-filt.c
../../filters/awk-filt.l: In function ‘awk_lex’:
../../filters/awk-filt.l:92:28: warning: conversion from ‘int’ to ‘YY_CHAR’ 
{aka ‘unsigned char’} may change value [-Wconversion]
 
^
../../filters/awk-filt.l:102:13: warning: conversion from ‘int’ to ‘YY_CHAR’ 
{aka ‘unsigned char’} may change value [-Wconversion]
 pop_state();
 ^~~~   
../../filters/awk-filt.l:104:56: warning: conversion to ‘unsigned int’ from 
‘short int’ may change the sign of the result [-Wsign-conversion]
 
^
../../filters/awk-filt.l: In function ‘yy_get_next_buffer’:
../../filters/awk-filt.l:282:35: warning: conversion to ‘yy_size_t’ {aka 
‘unsigned int’} from ‘int’ may change the sign of the result [-Wsign-conversion]
../../filters/awk-filt.l:282:4: warning: conversion to ‘int’ from ‘yy_size_t’ 
{aka ‘unsigned int’} may change the sign of the result [-Wsign-conversion]
../../filters/awk-filt.l:299:20: warning: conversion to ‘int’ from ‘yy_size_t’ 
{aka ‘unsigned int’} may change the sign of the result [-Wsign-conversion]
../../filters/awk-filt.l:321:49: warning: conversion to ‘yy_size_t’ {aka 
‘unsigned int’} from ‘int’ may change the sign of the result [-Wsign-conversion]
../../filters/awk-filt.l:321:18: warning: conversion to ‘int’ from ‘yy_size_t’ 
{aka ‘unsigned int’} may change the sign of the result [-Wsign-conversion]
../../filters/awk-filt.l: In function ‘yy_get_previous_state’:
../../filters/awk-filt.l:377:27: warning: conversion from ‘int’ to ‘YY_CHAR’ 
{aka ‘unsigned char’} may change value [-Wconversion]
../../filters/awk-filt.l:387:12: warning: conversion from ‘int’ to ‘YY_CHAR’ 
{aka ‘unsigned char’} may change value [-Wconversion]
../../filters/awk-filt.l:389:55: warning: conversion to ‘unsigned int’ from 
‘short int’ may change the sign of the result [-Wsign-conversion]
../../filters/awk-filt.l: In function ‘yy_try_NUL_trans’:
../../filters/awk-filt.l:422:11: warning: conversion from ‘int’ to ‘YY_CHAR’ 
{aka ‘unsigned char’} may change value [-Wconversion]
../../filters/awk-filt.l:424:54: warning: conversion to ‘unsigned int’ from 
‘short int’ may change the sign of the result [-Wsign-conversion]
../../filters/awk-filt.l: At top level:
../../filters/awk-filt.l:479:12: warning: function declaration isn’t a 
prototype [-Wstrict-prototypes]
../../filters/awk-filt.l: In function ‘awk__create_buffer’:
../../filters/awk-filt.l:622:19: warning: conversion to ‘yy_size_t’ {aka 
‘unsigned int’} from ‘int’ may change the sign of the result [-Wsign-conversion]
../../filters/awk-filt.l: In function ‘awk__scan_buffer’:
../../filters/awk-filt.l:751:18: warning: conversion to ‘int’ from ‘yy_size_t’ 
{aka ‘unsigned int’} may change the sign of the result [-Wsign-conversion]
../../filters/awk-filt.l: In function ‘awk__scan_bytes’:
../../filters/awk-filt.l:796:6: warning: conversion to ‘yy_size_t’ {aka 
‘unsigned int’} from ‘int’ may change the sign of the result [-Wsign-conversion]
At top level:
../../filters/awk-filt.l:877:13: warning: ‘yy_fatal_error’ defined but not used 
[-Wunused-function]
../../filters/awk-filt.l:479:12: 

Bug#930653: libapt-pkg-perl: Port to apt 1.9.0

[Brendan O'Dea]

On Mon, Jun 17, 2019 at 06:47:53PM +0200, Julian Andres Klode wrote:
>Package: libapt-pkg-perl
>Version: 0.1.34

>Ports libapt-pkg-perl to apt 1.9.0 (coming soon to experimental), this 
>
>removes:
>
>- IsOk() method of a PkgFileIterator
>- GetMatch() method of a Policy
>- GetPriority(Package) of Policy
>
>adds:
>
>- GetPriority(Version) of Policy

Thanks, I'm uploading 0.1.35 now to unstable which should address these changes.

Tested against apt 1.8.2 (unstable) and 1.9.1 (experimental).

--bod

Bug#925136: help2man: FTBFS in unstable (dh_clean fails)

[Brendan O'Dea]

On Fri, Mar 22, 2019 at 05:42:37PM +0100, Sven Joachim wrote:
>On 2019-03-21 20:45 +1100, Brendan O'Dea wrote:
>> I suspect that it is related to reproducible builds, [...]
>There has indeed been such a change in dpkg-source:
>
>,
>| - Generate reproducible source tarballs by using the new GNU tar
>|   --clamp-mtime option in Dpkg::Source::Archive, to make sure no file
>|   in source packages has an mtime later than the changelog entry time.
>`
>
>However, that was in version 1.18.10, uploaded July 2016.
>
>It seems that in previous versions of help2man help2man.PL was older
>than debian/changelog, so you did not hit the problem.

Ah thanks.  I assumed that this was more recent.  Looking at some previous
source packages, the max date is indeed clamped, but it just so happened that
I updated the version in help2man.PL before making the changelog entry so
didn't trip over this.

Incidentally, I'm slightly puzzled at this behaviour for native packages.
Under what circumstances would the source tar ball for a released package be
re-built without changing the version?

>> I'll try to find a way to revise this check that will be more robust to this
>> kind of timestamp modification.  Somewhat annoyingly, the "test" builtin has
>> -nt and -ot options, but no way to test that timestamps are newer or equal 
>> (or
>> even just equal).
>
>A negated test with the -ot option might help:
>
>   ! test README -ot help2man.PL # maintainer sanity check

Thanks, good suggestion but rather ungainly.  I've cooked up a different
solution for the next release which doens't depend on the mtimes.

--bod

Bug#925136: help2man: FTBFS in unstable (dh_clean fails)

[Brendan O'Dea]

On Wed, Mar 20, 2019 at 10:21:39AM +0100, Gianfranco Costamagna wrote:
>Looks like README needs a newer timestamp wrt help2man.PL file?
[...]
>dpkg-buildpackage: info: host architecture amd64
> fakeroot debian/rules clean
>test README -nt help2man.PL  # maintainer sanity check
>make: *** [debian/rules:40: clean] Error 1

Well this is odd, it seems that there has been a change in dpkg-source which
breaks this particular sanity check (intended to ensure that I've run the
maint-prep step since updating the version in help2man.PL).

I suspect that it is related to reproducible builds, since the timestamps that
ended up in the tarball have been changed to the changlog timestamp (in fact
there are no files in the tarball with later dates).

 ~/debian/help2man-1.47.9 $ ls -l README help2man.PL
 -rw-r--r--   1 bodbod   540 2019-03-18 19:16 README
 -rwxr-xr-x   1 bodbod 23166 2019-03-18 19:13 help2man.PL
 ~/debian/help2man-1.47.9 $ tar tvJf ../help2man-1.47.9.tar.xz 
help2man-1.47.9/README help2man-1.47.9/help2man.PL
 -rw-r--r-- 0/0 540 2019-03-18 19:10 help2man-1.47.9/README
 -rwxr-xr-x 0/0   23166 2019-03-18 19:10 help2man-1.47.9/help2man.PL
 ~/debian/help2man-1.47.9 $ dpkg-parsechangelog -S Date
 Mon, 18 Mar 2019 19:10:35 +1100

I'll try to find a way to revise this check that will be more robust to this
kind of timestamp modification.  Somewhat annoyingly, the "test" builtin has
-nt and -ot options, but no way to test that timestamps are newer or equal (or
even just equal).

--bod

Bug#894126: help2man: Problem with encoding kk_KZ.RK1048

[Brendan O'Dea]

On Mon, Mar 26, 2018 at 01:05:21PM -0300, Iñaki Malerba wrote:
>Found a bug while running reprotests with the kk_KZ.RK1048 LC_ALL option
>
>How to reproduce:
>```
># LC_ALL=kk_KZ.RK1048 help2man
>Unknown encoding 'RK1048' at /usr/bin/help2man line 56.
>```

Unfortunately, Perl's Encode module does not support that encoding.  I can
punt the requirement to support it upstream, but outside of that there is not
a whole lot I can do.

Re-encoding is done for all messages to the user, since the translations are
encoded in UTF-8, which is not necessarily the user's encoding.  For example
if the user's locale is LANG=ru_RU.cp1251, error and help text should be
readable even though the translations are encoded in UTF-8.

Is this an actual problem which you have, in which case I'll persue the
upstream fix, otherwise I'll downgrade to a wishlist bug.

Note that LANG=kk_KZ.UTF-8 works fine (although currently has no translated
messages).

--bod

Bug#682347: mark 'editor' virtual package name as obsolete

[Brendan O'Dea]

On Wed, Aug 23, 2017 at 11:03:23PM -0700, Russ Allbery wrote:
>Would anyone on the Policy list or any of the maintainers bcc'd want to
>make a case for keeping the virtual package "editor"?

No strong objection to removing this virtual package.

>In previous discussions, no one seemed to feel that it was helpful as a
>virtual package.  Virtual packages are only useful for another package to
>depend on (or recommend or suggest), or for someone to manually use as in
>"apt-get install editor", neither of which seem like useful actions here.
>(Or to conflict with, but that's obviously wrong here.)  No packages
>currently declare any type of dependency on editor.

Note that there *are* a handful packages which still depend/recommend/suggest
editor and will need bugs raised along with those for the editors providing
it.

  $ apt-cache showpkg editor
  Package: editor
  Versions:

  Reverse Depends:
dnsvi,editor
xpaint,editor
udo-doc-en,editor
udo-doc-de,editor
libproc-invokeeditor-perl,editor
  [...]

--bod

Bug#872391: libapt-pkg-perl: Please provide Uploaders in AptPkg::Source

[Brendan O'Dea]

On 17 August 2017 at 12:25, Norbert Preining  wrote:
> I am writing a tool for generating graph database from the apt cache,
> but I am missing access to the uploaders in AptPkg::Source.

Unfortunately that field is not exposed in the underlying libapt-pkg
library.  The best I can provide is AsStr, which is the entire source
record, from which you can extract Uploaders.

The AptPkg::Source man page in the 0.1.33 version (pending upload) has
sample parsing code, or you can write your own regex.

--bod

Bug#869541: lintian warns both with and without autotools-dev build-dep

[Brendan O'Dea]

Package: lintian
Version: 2.5.52

I added calls to dh_autotools-dev_{update,restore}config to the debian/rules
for vile* in order to update/restore the config.guess/config.sub.  I added a
versioned build-dependency for the version of autotools-dev which added these
commands:

  autotools-dev (>= 20100122.1)

lintian issued the folowing warning:

  W: vile source: useless-autoreconf-build-depends autotools-dev

If I remove the dependency, lintian then gives the error:

  E: vile source: missing-build-dependency-for-dh_-command 
dh_autotools-dev_restoreconfig => autotools-dev

* https://anonscm.debian.org/gitweb/?p=collab-maint/vile.git

Bug#851951: AptPkg::Cache: installed packages in TriggersAwaited or TriggersPending state have no CurrentState() at all!

[Brendan O'Dea]

merge 851951 852273
thanks

On Fri, Jan 20, 2017 at 06:22:35PM +0800, Michael Deegan wrote:
>It looks like (according to a brief grep through the source) AptPkg hasn't 
>been updated since dpkg gained triggers.

Right, it hasn't been changed for some time.  I'll take a look at the
triggers.

>The (untested!) beginnings of a suitable patch (which fixes only my problem)
>is attached.  I'm also tempted to suggest that perhaps it would be better to
>return "Other" or "Unknown" instead of undef for unknown CurrentState
>values, but of course that's not my call. :)

Either you omitted the patch, or the BTS ate it.

--bod

P.S. Sorry for the delayed response, just returned from vacation.

Bug#833656: cme fails with dpkg error

[Brendan O'Dea]

reassign -1 lintian 2.5.45
thanks

On Sun, Aug 14, 2016 at 01:00:33PM +0200, David Kalnischkies wrote:
>On Sun, Aug 14, 2016 at 05:27:39PM +1000, Brendan O'Dea wrote:
>> which suggests that the _config object has been modified prior to this code
>> being run.  Not sure where, perhaps there is another use of AptPkg in cme?
>
>The first is correct, the later indicates that $_config->init was never called
>as Dir couldn't be empty in that case (and that Dir::State gets its default
>value here is actually an unattended but harmless side effect of the 
>dpkg/status
>finding code in its current form). Given that the error message has a '/' in
>front I lean towards assuming that the configuration is eventually initialized,
>just too late.

You're correct, there is an initialisation order issue here.  I added some
debugging, and found the sequence:

  pkgInitSystem
  pkgInitConfig
  pkgInitSystem

which previously would have been fine, but with the changes to the system
initialisation that is no longer the case.

Turns out that the first pkgInitSystem is coming from lintian, which does the
following:

  use AptPkg::Config '$_config';
  my $versioning = $_config->system->versioning;

here:

  
https://anonscm.debian.org/cgit/lintian/lintian.git/tree/lib/Lintian/Relation/Version.pm#n36

The simplest fix is simply to insert the following line before the call to
system:

  $_config->init;

Alternately, you don't need to use the global $_config at all if you're not
using AptPkg::Cache (it is an unfortunate implementation detail of the
underlying C++ class that the global is required).

I would be inclined to rewrite the lines above as follows:

  use AptPkg::Config;
  my $versioning = do {
my $config = AptPkg::Config->new;
$config->init;
$config->system->versioning;
  };

--bod

Bug#833656: cme fails with dpkg error

[Brendan O'Dea]

On Sun, Aug 14, 2016 at 12:36:03AM +0200, gregor herrmann wrote:
>use AptPkg::Config '$_config';
>use AptPkg::System '$_system';
>use AptPkg::Version;
>use AptPkg::Cache ;
>
>$_config->init;
>$_system = $_config->system;
>my $vs = $_system->versioning;
>my $apt_cache = AptPkg::Cache->new ;

This is a bit puzzling, but I am guessing that the bug is in apt:
getDpkgStatusLocation is modifying the global _config object of libapt-pkg in
such a way that if debSystem::Initialize is called twice, the results will be
different.

As far as I can make out, the code appears to be modifying the configuration
in order to get a derived value for Dir::State::status, which it then returns
so that the caller can set the value.  This means that you are effectively
doing:


  Cnf.Set("Dir::State::status", {
Cnf.Set("Dir::State::status", "status");
return Cnf.FindFile("Dir::State::status");
  });

along with some other manipulations.  If I understand your intent correctly, I
would recommend rewriting getDpkgStatusLocation to take a const reference to
the Configuration, and to use an internal temporary instance.  A brief comment
to explain what the heck it is trying to achieve wouldn't go astray either.

You could argue that the Initialize method shouldn't be called twice, but that
may be out of the caller's hands.

To clarify what's actually happening here, this line:

  $_config->init;

invokes pkgInitConfig under the hood, on the global C++ _config object.  This
populates it with general APT things, e.g. Dir::State, but not Debian-specific
things like Dir::State::status.  After that, the following line:

  $_system = $_config->system;

calls pkgInitSystem, passing in the global _config object, and populating the
global _system object (which is magically bound to $_system, so that
assignment works).  That indirectly calls debSystem::Initialize, which sets
Debian-specific things like Dir::State::status and Dir::State::extended_status.

Adding some debugging of the working code from the example directory, after
the $_config->init line I get as expected:

  RootDir=
  Dir=/
  Dir::State=var/lib/apt/
  Dir::State::status=
  Dir::State::extended_states=

and after the $_system = ... line:

  RootDir=
  Dir=/
  Dir::State=var/lib/apt/
  Dir::State::status=/var/lib/dpkg/status
  Dir::State::extended_states=extended_states

For the case of libconfig-model-dpkg-perl, I'm seeing the following for after 
the init:

  RootDir=
  Dir=
  Dir::State=var/lib/apt/
  Dir::State::status=var/lib/dpkg/status
  Dir::State::extended_states=extended_states

which suggests that the _config object has been modified prior to this code
being run.  Not sure where, perhaps there is another use of AptPkg in cme?

--bod

Bug#832973: vile-filters: vile filter for mail broken

[Brendan O'Dea]

On Tue, Aug 02, 2016 at 09:30:38PM -0400, Thomas Dickey wrote:
>(got to that point - attaching a diff which built with 2.6.0)

I'm not entirely convinced that this change captures what you're trying to
achieve with 2.6.0, as the second expression to sed makes LEX_SUBVERSION in
this case equal to 2, which is the major version, and the following
comparisons don't make sense in that case.  My inclination would be to change
the test for 2006000 to -ge and be done with it:

elif test $cf_lex_version -ge 2006000

You should probably then also drop this:

-e 's/\.[0-9.]*//'`

as I'm not sure that it adds anything in the 2.5.x case.  This is all mostly
cosmetic, as the changes to filters.h actually fixed the problem for 2.6.0.

To add to the hilarity, Debian unstable just upgraded to flex 2.6.1 which
elicits:

  checking version of flex... 2.6.1
  configure: WARNING: Sorry - your version of flex is too unstable: 2.6.1

which would be the same message you would see for 2.6.0 if you make the change
suggested above.

Either way, both 2.6.0 and 2.6.1 seem to have working loadable filters with
your patch.

>By the way, just to remind you of one of the reasons why "new" flex is
>not really a good tool.  Here's a diffstat comparing my usual build to
>"new" flex.  It adds a few compiler warnings:
>
> vmw-debian8b2-64-clang-run.log| 2568 +
> vmw-debian8b2-64-debbuild-run.log |  158
> vmw-debian8b2-64-debbuild-xvile.log   |  154
> vmw-debian8b2-64-gcc-normal-run.log   |10739 ++
> vmw-debian8b2-64-gcc-stricter-run.log |16287 
> +-
> vmw-debian8b2-64-mingw32-run.log  |  740 +
> vmw-debian8b2-64-mingw64-run.log  |  672 +
> vmw-debian8b2-64-run.log  |  973 +-
> 8 files changed, 31063 insertions(+), 1228 deletions(-)

For now, while Debian is still packaging flex 2.5.4a as "flex-old", I'll
probably stick with that.

--bod

Bug#832973: vile-filters: vile filter for mail broken

[Brendan O'Dea]

On Mon, Aug 01, 2016 at 02:41:12AM -0400, Thomas Dickey wrote:
>On Mon, Aug 01, 2016 at 04:22:37PM +1000, Brendan O'Dea wrote:
>> configure.in doesn't cope with 2.6:
>> 
>>   sed -e 's/^2.5.//
>> 
>> resulting in this output from configure:
>> 
>>   checking version of flex... 2.6.0
>>   ../configure: 5316: test: Illegal number: 2.6.0
>
>I did notice that yesterday, but since it built, didn't look too closely.

The periods in that regex should probably be escaped also.

>...so after ten years, it's no longer a beta.  I can fix this :-)

Ha.  Actually, my reading of that code is that the intent is that everything
other than .0 releases are treated as FLEX_BETA.

>>   #define YY_SKIP_YYWRAP
>>   #define yywrap() private_yywrap()
>>   #define USE_LEXWRAP(name) static int private_yywrap(void) { return 1; }
>>   #else
>>   #define USE_LEXWRAP(name) /* nothing */
>>   #endif
>>
[...]
>> Out of curiosity, why does USE_LEXWRAP take an option?  It doesn't appear to
>> do anything with it.
>
>It's used a little later in filters.h:
>
>   /*
>* We'll put a DefineFilter() in each filter program.  To handle 
> special cases
>* such as c-filt.c, use DefineOptFilter().
>*/
>   #define DefineOptFilter(name,options) \
>   USE_LEXWRAP(name##_wrap) \
>   static void init_filter(int before); \
>   static void do_filter(FILE *Input); \
>   DCL_LEXFREE \
>   FILTER_DEF filter_def = { #name, 1, init_filter, do_filter, options 
> REF_LEXFREE }

That is a different binding of "name".  As I read it, you could rewrite it as:

  #if defined(FLEX_SCANNER) && defined(FLEX_BETA)
  #define YY_SKIP_YYWRAP
  #define yywrap() private_yywrap()
  #define USE_LEXWRAP static int private_yywrap(void) { return 1; }
  #else
  #define USE_LEXWRAP /* nothing */
  #endif

  #define DefineOptFilter(name,options) \
  USE_LEXWRAP \
  ...

without losing anything.

--bod

Bug#832973: vile-filters: vile filter for mail broken

[Brendan O'Dea]

On Sun, Jul 31, 2016 at 03:40:14PM -0400, Thomas Dickey wrote:
>I normally don't build with "new" flex, but took a look today and had
>no problem building with the version in testing (which appears to match
>that in experimental).
>
>What is the problem that you are seeing when building?

The problem is not with building, but that the resulting .so refers to, but
doesn't define the whatever_wrap() function, so dynamic linking fails.

configure doesn't cope with the new version in so far as to say that it
expects to find flex >= 2.5 and <= 2.6, but the substitution on line 259 of
configure.in doesn't cope with 2.6:

  sed -e 's/^2.5.//

resulting in this output from configure:

  checking version of flex... 2.6.0
  ../configure: 5316: test: Illegal number: 2.6.0

at the time I didn't look too deeply, but just figured that it was simplest to
go back to flex-old (2.5.4) and will probably just stick with that for now.

For reference, I ran configure with flex-old (2.5.4), the newest version of
flex I could find in the archive >= 2.5 (2.5.39), and the current version
(2.6.0).  I then generated mailfilt.c for each.  See attached.

All three produced an identical config.h.

I suspect that the actual problem is this code in filters/filters.h (line
157):

  #if defined(FLEX_SCANNER) && defined(FLEX_BETA)
  #define YY_SKIP_YYWRAP
  #define yywrap() private_yywrap()
  #define USE_LEXWRAP(name) static int private_yywrap(void) { return 1; }
  #else
  #define USE_LEXWRAP(name) /* nothing */
  #endif

which doesn't choose the first case on 2.6.0, since FLEX_BETA is not defined.
See this fragment from the generated mailfilt.c:

  #define FLEX_SCANNER
  #define YY_FLEX_MAJOR_VERSION 2
  #define YY_FLEX_MINOR_VERSION 6
  #define YY_FLEX_SUBMINOR_VERSION 0
  #if YY_FLEX_SUBMINOR_VERSION > 0
  #define FLEX_BETA
  #endif

the equivalent code for 2.5.x works since YY_FLEX_SUBMINOR_VERSION is
non-zero.

Out of curiosity, why does USE_LEXWRAP take an option?  It doesn't appear to
do anything with it.

--bod


vile-vs-flex.tar.gz
Description: application/gzip

Bug#832973: vile-filters: vile filter for mail broken

[Brendan O'Dea]

The problem appears to be that flex is now version 2.6.0, which
configure doesn't appear to handle.  I'll revert to the older flex for
now.

On 30 July 2016 at 21:44, Paul van Tilburg  wrote:
> Package: vile-filters
> Version: 9.8r-1
> Severity: normal
>
> Dear Maintainer,
>
> Since the recent upgrade to 9.8r-1 in Sid, I'm unable to edit e-mails due
> to vile's mail filter being broken.  Vile drops me into the HighlightFilter
> buffer everytime I try to edit an e-mail.  If I run the
> highligh/unhighlight macros, vile reports:
>
> [Error: can't load shared object vile-mail-filt.so
>   (/usr/lib/vile/vile-mail-filt.so: undefined symbol: mail_wrap)]
>
> Probably something is wrong with the build?
>
> Kind regards,
> Paul
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (102, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages vile-filters depends on:
> ii  libc62.23-4
> ii  vile-common  9.8r-1
>
> vile-filters recommends no packages.
>
> vile-filters suggests no packages.
>
> -- no debconf information

Bug#832973: Acknowledgement (vile-filters: vile filter for mail broken)

[Brendan O'Dea]

On 30 July 2016 at 22:34, Paul van Tilburg  wrote:
> It seems that (almost) all filters are broken.
> All miss the _wrap symbol?

Not all:

  vile @/usr/share/vile/filters.rc /tmp/foo.cc

for example, highlights fine.  But you're right: there is clearly
something awry, investigating.

Bug#787444: [Reproducible-builds] Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

[Brendan O'Dea]

On 10 June 2015 at 01:59, Ximin Luo infini...@pwned.gg wrote:
 Given the above, I think it would still be good to define SOURCE_DATE as I 
 originally suggested:

 SOURCE_DATE = $(date -d $(dpkg-parsechangelog --count 1 -SDate) 
 --iso-8601=seconds) # includes the TZ offset

 - if the language/tool already has/uses a ISO8601 parser in its standard 
 library, this is as convenient as the previous SOURCE_DATE_UTC
 - if the language/tool doesn't have/use one, then SOURCE_DATE_UTC doesn't 
 actually give us any benefits:
   - it's far easier to use SOURCE_DATE_EPOCH, if you want to play with the 
 date programmatically
   - OTOH if you're just going to take substrings/regex-match it, this works 
 just as easily for SOURCE_DATE vs SOURCE_DATE_UTC, and the former contains 
 more information

 But I care less about this latter point; the main point of this email is to 
 argue for SOURCE_DATE_EPOCH over SOURCE_DATE_UTC (iso8601 locked to Z 
 timezone).

I disagree that SOURCE_DATE_UTC provides no benefit over SOURCE_DATE:
at the very least, a program could choose to use it as an
uninterpreted string (similar to the proposed --date option at the
start of this bug, but from the environment rather than a flag).
SOURCE_DATE with an arbitrary offset not so much.

I'm happy to accept SOURCE_DATE, SOURCE_DATE_UTC, SOURCE_DATE_EPOCH or
even SOURCE_DATE_EXTRACTED_FROM_DEBIAN_CHANGELOG_WITH_NO_INTERPRETATION
however.  Pick one.

--bod


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

Bug#787444: [Reproducible-builds] Bug#787444: Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

[Brendan O'Dea]

On 10 June 2015 at 20:54, Ximin Luo infini...@pwned.gg wrote:
 On 10/06/15 12:41, Brendan O'Dea wrote:
 On 10 June 2015 at 01:59, Ximin Luo infini...@pwned.gg wrote:
 SOURCE_DATE = $(date -d $(dpkg-parsechangelog --count 1 -SDate) 
 --iso-8601=seconds) # includes the TZ offset

 The TZ offset is given statically in debian/changelog, and that can also be 
 part of the uninterpreted string. It's no less arbitrary than the rest of 
 the date itself.

Your example above will emit the local timezone, and not the one from
the changelog.

 OK, then let's go with SOURCE_DATE_EPOCH.

Sold.  Adding it now.

--bod


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

Bug#787444: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

[Brendan O'Dea]

On 5 June 2015 at 21:12, Ximin Luo infini...@pwned.gg wrote:
 If we're going to mandate that it ends with Z, might I suggest that we add 
 UTC or _UTC to the variable name? It leaves the option open in the future 
 that we might allow TZ offsets.

 Note that the TZ offsets mentioned in ISO8601 and the other RFC standards are 
 not time zones or local times that are subject to DST. They are *fixed 
 offsets*, and don't require extra context (such as the TZ database) to parse 
 correctly. So it would be less of a PITA than you might think.

Agreed: it is a fixed offset which may be applied with little more
than some multiplications by 60 and the appropriate addition and
subtraction.  There are however three possible formats which need to
be handled outside of Z if you want to be thorough (±hh:mm, ±hhmm and
±hh), and given that this proposal as I understand it is to have the
build infrastructure set this variable, then pushing the complexity to
that single place and making the changes to the program which needs to
interpret this variable *as simple as possible* is likely to make
convincing the authors of such programs to add the feature somewhat
easier.

As far as the naming, given that only programs are going to be
setting/parsing this variable, it can be as descriptive as required
and should be chosen to reduce the possibility of an identically named
variable for another purpose being accidentally interpreted.  I'm
presuming that outside the scope of reproducible builds that the
variable would not be set, in which case programs should fall back to
the default behaviour such as using the current date or the
modification of a file--in which case an unrelated variable of the
same name in the environment could be a problem.

Any of UTC_SOURCE_DATE, SOURCE_DATE_UTC or
REPRODUCABLE_BUILD_SOURCE_DATE_UTC would work for me, but outside of
the concerns mentioned above I don't actually care.

--bod


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

Bug#787444: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

[Brendan O'Dea]

On 5 June 2015 at 04:40, Ximin Luo infini...@pwned.gg wrote:
 On 04/06/15 19:30, Daniel Kahn Gillmor wrote:
 What TZ should SOURCEDATE have?  ISO8601 is capable of supplying a TZ as
 well, so the current time could be written in a wide variety of ways
 while meaning the same instant:

 0 dkg@alice:~$ date '+%FT%T%z'  date -u '+%FT%T%z'
 2015-06-04T13:25:25-0400
 2015-06-04T17:25:25+
 0 dkg@alice:~$

 I feel like we should we always set it to UTC, so that the inbound
 parsed offset would be +.  sound sensible?


 I had thought about this a bit, and not yet decided the best way - hence why 
 I haven't yet written this idea up on the Debian Wiki. FWIW, here are my 
 thoughts:

 - Always setting it to UTC would be simplest, but then our format wouldn't 
 be ISO8601 - we'd have to say ISO8601 but omit the offset / ignore any 
 offset. RFC 2822 and 3339, the other formats mentioned in `man date`, also 
 include an offset.

Given that you're basically creating a standard here, you get to
mandate the format.

I would say that it must be in ISO 8601 format, in the UTC timezone,
preferably using the Z suffix, and if the program interprets that
date and emits it in some way then it should be also in UTC.

  2015-06-05T01:08:20Z
  2015-06-05T01:08:20+

 - It's neater to keep the TZ-offset the same as in debian/changelog. 
 Generated dates will then be consistent with debian/changelog. If 
 debian/changelog says Mar 2015, then the generated documentation will say 
 Mar 2015.

Local times, and daylight savings are just too much of a PITA.  Just
use UTC and if builds on the first of the month are possibly different
to the changelog, so be it.

 - However, it seems awkward to get date(1) to preserve the original offset. I 
 suppose this is an artefact of using localtime(3) as you mentioned. In 
 general the libc time stuff seems to have disastrous behaviour if you want to 
 play with time zones other than local time or UTC, and this affects some 
 other languages like python.

 - One can maybe hack around it with the TZ envvar, but it has a very weird 
 syntax [1], and the hack is dependent on the actual value:

The TZ syntax dates back to when all systems were in the Northern
Hemisphere, and pretty much all folks cared about was EST5EDT
(Eastern) and PST8PDT (Pacific).

 $ date -d 2015-06-04T20:18:13+0800 --iso-8601=seconds
 2015-06-04T14:18:13+0200 # nope, my local TZ is different

 $ TZ=UTC+08 date -d 2015-06-04T20:18:13+0800 --iso-8601=seconds
 2015-06-04T04:18:13-0800

 $ TZ=UTC-08 date -d 2015-06-04T20:18:13+0800 --iso-8601=seconds
 2015-06-04T20:18:13+0800 # argh, TZ expects the opposite sign

 [1] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

 - A possible workaround is to advise people to just extract the information 
 directly out of SOURCEDATE using a regex (or strip off the last 5 chars of 
 SOURCEDATE before giving it to localtime, maybe). But such advice is extra 
 mental work for developers who may not bother reading the document that we 
 put such advice on.

Mandate input/output in UTC and give a few examples.

  export SOURCEDATE=2015-06-05T01:08:20Z

  Shell:
$ date -u -d $SOURCEDATE;
Fri Jun  5 01:08:20 UTC 2015

  Perl:

use Time::Local 'timegm';
my $sourcedate = $ENV{SOURCEDATE};
my ($year, $mon, $mday, $hour, $min, $sec) =
$sourcedate =~
/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)(?:Z|\+)$/;
my $d = timegm $sec, $min, $hour, $mday, $mon-1, $year;
print scalar gmtime $d;

  Python:

etc.

 It would be awesome for help2man to support this.

 help2man (and any other tool that accepts $SOURCEDATE) would also need
 to ensure that it extracts the parts it wants in a TZ-independent
 fashion as well.  (not parsing back to localtime)

I'm happy to add this.

--bod


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

Bug#787444: help2man: support externally-supplied --date for reproducibility

[Brendan O'Dea]

On 4 June 2015 at 00:19, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
 On Wed 2015-06-03 08:24:51 -0400, Brendan O'Dea wrote:
 My inclination is instead to do something fairly specific to your
 project: If the environment variable DEB_BUILD_CHANGELOG (or something
 similar) is set, then the file to which it refers will be used to find
 the latest revision date, and that date will be used on the manual
 pages.  Presumably the build system could set this prior to
 build/test?

 i think this could work, but it might not apply particularly well to
 anyone outside of debian who uses help2man.  I note that help2man is a
 native package -- do you know if it's used outside of debian at all?

help2man is part of the GNU project, but since I'm the upstream and
the debian maintainer I build it as a native package, dupload the
results to Debian and upload the tarball to ftp.gnu.org at the same
time.

The idea was that unless that environment variable was set, the
behaviour would be unchanged: the current date would be used.  It
seems unlikely that DEB_BUILD_CHANGELOG would be set accidentally.

 Making the help2man run dpkg-parsechangelog also seems a little hairier
 than it ought to be, and introduces a dependency on dpkg-dev which seems
 a little weird.

I wasn't going to use dpkg-parsechangelog, it is a sufficiently
standard format that a simple capturing regex would suffice.

 If the build system is going to set environment variables, maybe it
 could set an environment variable with a parseable date string
 (ISO-8601?) and help2man could look at that environment variable and
 extract a string from it?  (ideally this extraction step would be
 TZ-independent, too)

That would also work, and if your reproducible build environment was
to pull the changelog date and stick it into an environment variable,
then you should only need to patch the tools rather than the Makefile
of every package which uses them.

At worst, for the tools you can't patch, you're in the same place you
are now--having to patch all the Makefiles, and even that is perhaps
easier as you already have the date:

  --date=${DEB_BUILD_CHANGELOG_DATE:-$(date --iso-8601=seconds)}

Regards,
Brendan


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

Bug#787444: help2man: support externally-supplied --date for reproducibility

[Brendan O'Dea]

On 2 June 2015 at 04:49, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
 Please consider the attached patch as a step on the way toward allowing
 packages that use help2man to build reproducibly.  For more info, see:

Hi Daniel,

I appreciate that you've provided a relatively generic solution to
your problem: adding an option to set the date, but it occurs to me
that most users don't actually care.  Additionally, this will require
changing the builds for anything which uses help2man to add a --date
option.

My inclination is instead to do something fairly specific to your
project: If the environment variable DEB_BUILD_CHANGELOG (or something
similar) is set, then the file to which it refers will be used to find
the latest revision date, and that date will be used on the manual
pages.  Presumably the build system could set this prior to
build/test?

Regards,
Brendan


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

Bug#601600: package protobuf-mode.el

[Brendan O'Dea]

tag 601600 +patch
thanks

On Wed, Oct 27, 2010 at 01:45:18PM -0400, mike castleman wrote:
Package: protobuf
Severity: wishlist

The upstream protobuf source includes an editors directory with an emacs 
mode for editing protocol description files. It'd be nice if this file 
could be packaged somewhere. There is also a vim file in there; I don't 
know enough about vim to suggest what to do with it, though I imagine 
there are people who would like it as well.

Patch attached to install emacs mode with emacs common.

Robert: I can push this to the collab repo if that is easier than patching.

--bod
diff --git a/debian/README.emacs b/debian/README.emacs
new file mode 100644
index 000..17486ee
--- /dev/null
+++ b/debian/README.emacs
@@ -0,0 +1 @@
+Install the protobuf-mode-el package.
diff --git a/debian/changelog b/debian/changelog
index 16060ee..4116be5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+protobuf (2.6.1-2) unstable; urgency=medium
+
+  * Split protobuf-mode.el into a separate package (closes: #601600.)
+  * Work around emacs bug #18845 when byte compiling protobuf-mode.el.
+
+ -- Brendan O'Dea b...@debian.org  Mon, 24 Nov 2014 21:53:54 +1100
+
 protobuf (2.6.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index 49097c5..8eaa09f 100644
--- a/debian/control
+++ b/debian/control
@@ -159,6 +159,7 @@ Package: python-protobuf
 Architecture: any
 Section: python
 Depends: ${shlibs:Depends}, ${python:Depends}, ${misc:Depends}
+Suggests: protobuf-mode-el
 Description: Python bindings for protocol buffers
  Protocol buffers are a flexible, efficient, automated mechanism for
  serializing structured data - similar to XML, but smaller, faster, and
@@ -196,3 +197,10 @@ Description: Java bindings for protocol buffers
  need the protoc tool (in the protobuf-compiler package) to compile your
  definition to Java classes, and then the modules in this package will allow
  you to use those classes in your programs.
+
+Package: protobuf-mode-el
+Architecture: all
+Depends: ${misc:Depends}, emacsen-common (= 2.0.8)
+Section: devel
+Description: Emacs major mode for editing protocol buffers
+ Syntax highlighting and indenting support for protocol buffers.
diff --git a/debian/protobuf-compiler.install b/debian/protobuf-compiler.install
index e772481..302bfab 100644
--- a/debian/protobuf-compiler.install
+++ b/debian/protobuf-compiler.install
@@ -1 +1,2 @@
 usr/bin
+debian/README.emacs /usr/share/doc/protobuf-compiler/editors
diff --git a/debian/protobuf-mode-el.emacsen-compat b/debian/protobuf-mode-el.emacsen-compat
new file mode 100644
index 000..573541a
--- /dev/null
+++ b/debian/protobuf-mode-el.emacsen-compat
@@ -0,0 +1 @@
+0
diff --git a/debian/protobuf-mode-el.emacsen-install b/debian/protobuf-mode-el.emacsen-install
new file mode 100644
index 000..6119a06
--- /dev/null
+++ b/debian/protobuf-mode-el.emacsen-install
@@ -0,0 +1,24 @@
+#!/bin/sh -e
+
+FLAVOR=$1
+PACKAGE=protobuf-mode-el
+
+ELDIR=/usr/share/emacs/site-lisp/${PACKAGE}
+ELCDIR=/usr/share/${FLAVOR}/site-lisp/${PACKAGE}
+files=protobuf-mode.el
+flags=-batch -no-site-file -l path.el -f batch-byte-compile
+
+if [ ${FLAVOR} != emacs ]; then
+  echo install/${PACKAGE}: Byte-compiling for ${FLAVOR}
+
+  install -m 755 -d ${ELCDIR}
+  cd ${ELCDIR}
+  for f in ${files}; do
+ln -sf ../../../emacs/site-lisp/${PACKAGE}/${f} .
+  done
+  cat  EOF  path.el
+(setq load-path (cons . load-path) byte-compile-warnings nil)
+EOF
+  ${FLAVOR} ${flags} ${files}
+  rm -f path.el
+fi
diff --git a/debian/protobuf-mode-el.emacsen-remove b/debian/protobuf-mode-el.emacsen-remove
new file mode 100644
index 000..5d23e96
--- /dev/null
+++ b/debian/protobuf-mode-el.emacsen-remove
@@ -0,0 +1,9 @@
+#!/bin/sh -e
+
+FLAVOR=$1
+PACKAGE=protobuf-mode-el
+
+if [ ${FLAVOR} != emacs ]; then
+  echo remove/${PACKAGE}: Purging byte-compiled files for ${FLAVOR}
+  rm -rf /usr/share/${FLAVOR}/site-lisp/${PACKAGE}
+fi
diff --git a/debian/protobuf-mode-el.emacsen-startup b/debian/protobuf-mode-el.emacsen-startup
new file mode 100644
index 000..6592979
--- /dev/null
+++ b/debian/protobuf-mode-el.emacsen-startup
@@ -0,0 +1,6 @@
+;; Startup for protobuf-mode.
+(if (not (file-exists-p /usr/share/emacs/site-lisp/protobuf-mode-el))
+(message protobuf-mode-el removed but not purged, skipping setup)
+  (autoload 'protobuf-mode protobuf-mode-el/protobuf-mode
+Major mode for editing Protocol Buffers description language. t)
+  (add-to-list 'auto-mode-alist '(\\.proto$ . protobuf-mode)))
diff --git a/debian/protobuf-mode-el.install b/debian/protobuf-mode-el.install
new file mode 100644
index 000..66c605e
--- /dev/null
+++ b/debian/protobuf-mode-el.install
@@ -0,0 +1 @@
+editors/protobuf-mode.el /usr/share/emacs/site-lisp/protobuf-mode-el
diff --git a/debian/rules b/debian/rules
index babb525..21515a1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -79,3 +79,6 @@ override_dh_install:
 
 	# Remove

Bug#757891: init-system-helpers: Please do not depend on perl

[Brendan O'Dea]

On 13 August 2014 17:11, Michael Stapelberg stapelb...@debian.org wrote:
 Brendan O'Dea b...@c47.org writes:
 I think an increase of 150 KiB is perfectly fine when it frees us from
 unnecessary reimplementation work, whose only potential outcome is to
 introduce new bugs :).

Sure, although this decision really lies with the Perl and Debian
Installer maintainers rather than you or I, since they are the ones
who need to deal with the potential impacts of increasing the size and
complexity (however minimally) of perl-base.

My recommendation would be to consider including File::Find, and
File::Temp.  I would be somewhat more wary about including File::Path,
which has had a particularly chequered history security wise[0], and
personally I would just use the system to call /bin/mkdir -p or
/bin/rm -rf (using the list syntax, avoiding shell).  Dropping
File::Path would also remove the need for File::Basename, which adds
10 KiB to provide[2]:

  sub basename { local $_ = shift; s#.*/##; return $_ }

 It does occur to me however that if rsyslog (or any other packages
 controlled by init for that matter) are going to be installed as part
 of the initial base system by d-i, then is it is worth simplifying the
 run-time dependencies of init-system-helpers by rewriting it in C?
 Absolutely not. I have written enough C code in my life that I really
 really don’t want to do this and I think it’d be actively harmful. The
 perl code we have is well tested and reasonably simple to understand.

This wasn't a request for *you* particularly to rewrite it, but rather
a general question about how important this package was to the
installer, and whether or not it would be appropriate to consider
changing the implementation language.

--bod

[0] Having provided much of the current rmtree implementation, I feel
justified in recommending not using it, and stand by my suggestion of
just using /bin/rm[1]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286905#34

[2] While File::Basename is more complex than my trivial subroutine,
deb-systemd-helper doesn't appear to require more than that.


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

Bug#757891: init-system-helpers: Please do not depend on perl

[Brendan O'Dea]

On 13 August 2014 05:15, Niko Tyni nt...@debian.org wrote:
 [cc'ing the rsyslog maintainers too]

 On Tue, Aug 12, 2014 at 09:02:59AM +0200, Michael Stapelberg wrote:
 Samuel Thibault sthiba...@debian.org writes:
  perl is separate from perl-base so that in tight environement, Debian
  can be installed with only perl-base. A base system installed by d-i,
  notably, is supposed to only install perl-base, not perl.  It happens
  however that d-i installs rsyslog, which depends on init-system-helpers,
  which depends on perl.  Is the whole perl really needed?  If some
  modules are needed, they could be moved to perl-base, to save having to
  install the whole perl on all Debian base systems.

 init-system-helpers uses File::Path, File::Basename, File::Find and
 Text::ParseWords — none of them is in perl-base.

 (FWIW Text::ParseWords is.)

 Please report back once you’ve made perl-base contain all of them.

 I wasn't around when the perl/perl-base split was designed, but my
 understanding is that perl-base exists to offer a usable perl interpreter
 for maintainer scripts even during upgrades, and for d-i to work.

Splitting the perl binary and a small subset of modules into a -base
package goes back a *long* time, and appears from the changelog to
have been initially done by my predecessor Darren to provide a subset
of perl 5.003 for base-floppies, apparently for the bo distribution
in 1996 (although archive.debian.org doesn't show it as a package
until hamm).  Some time later in 2001 when I wrote the revised Perl
Policy (specifically §2.2 _Base Package_), the requirement for the
package to be essential in order to be usable from maintainer scripts
was added.

As noted in the thread linked earlier[0], the initial selection of
packages for perl-base when I built the 5.6 packages was done by a
combination of grepping the archive for maintainer scripts which used
perl, and working with the debian-installer team to meet their
requirements.

 The perl-base package is Essential:yes, so inclusion there is pretty
 close to a promise of supporting that interface forever inside the
 Essential set.  So care must be taken when adding functionality there.
 IMO Perl reimplementations of /usr/bin/find, /usr/bin/basename,
 /bin/mkdir -p, and /bin/rm -r don't seem very good candidates.

Actually, if anything is to be included, then filesystem recursion
handling probably should be, as that tends to be screwed up when
people implement that[1,2,3].  The same could be said for safe
tempfile creation.

I'm not sure that File::Basename buys a great deal over s#^.*/##
myself, but it is interesting to see that Darren's earlier base
package did include both File::Basename and File::Find[4].  Given that
mine didn't, I presume that nothing was using them at the time, or
subsequently.

I don't think that it would be terrible to include some of these
packages in perl-base, but Niko is correct: extending the interface
should be done carefully and I don't see that this is the only
possible solution.

For the record, massaging the output of:

  strace -etrace=file perl -MFile::Find -MFile::Temp -MFile::Path -e 1

and identifying the new requirements which would need to move from
perl-modules to perl base, gives a delta of ~150Kib on my work
machine:

  ~% wc -c /usr/share/perl/5.18.2/File/Find.pm \
/usr/share/perl/5.18.2/File/Basename.pm \
/usr/share/perl/5.18.2/File/Temp.pm \
/usr/share/perl/5.18.2/File/Path.pm
   33181 /usr/share/perl/5.18.2/File/Find.pm
   11250 /usr/share/perl/5.18.2/File/Basename.pm
   77730 /usr/share/perl/5.18.2/File/Temp.pm
   33187 /usr/share/perl/5.18.2/File/Path.pm
  155348 total

Looking at deb-systemd-helper, it also uses Data::Dumper for some
debug messages, which is not part of perl-base either.  This could
potentially be worked around with something along the lines of:

  eval { require Data::Dumper; } or *Data::Dumper::Dumper = sub { no
Data::Dumper }

It does occur to me however that if rsyslog (or any other packages
controlled by init for that matter) are going to be installed as part
of the initial base system by d-i, then is it is worth simplifying the
run-time dependencies of init-system-helpers by rewriting it in C?

--bod

[0] https://lists.debian.org/debian-perl/2010/11/msg00039.html
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0435
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0452
[3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0448
[4] http://archive.debian.net/hamm/i386/perl-base/filelist


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

Bug#739249: dh_perl support for packages embedding perl

[Brendan O'Dea]

On 17 February 2014 13:20, Marco d'Itri m...@linux.it wrote:
 Package: debhelper
 The inn and inn2 packages, which use an embedded perl interpreter,
 currently do this to express a proper dependency on perlapi-* (see
 #182089):

 dh_gencontrol -u-VPERLAPI=$$(perl -MConfig -e 'print perlapi- . 
 ($$Config{debian_abi} || $$Config{version})')

 dh_perl adds a perlapi dependency only to packages which contain XS
 modules, so it would be nice if it could either recognize packages which
 have an embedded perl interpreter or have a flag to force this
 behaviour.

It has been some time since I looked at this, but according to policy
you should not need a dependency on perlapi* at all:

  
http://www.debian.org/doc/packaging-manuals/perl-policy/ch-embed.html#s-embedded_deps

The only required dependency is on libperl5.X, which should be added
automatically by dpkg-shlibdeps.  This will add, for the current
unstable version of perl, a dependency on libperl5.18 (= 5.18.2),
which transitively depends on the current (exact) version of
perl-base.

 (I see that it also would add a versioned dependency on perl, is it
 actually needed in my case?)

If the inn packages require anything from /usr/{lib,share}/perl
however which is not part of perl-base, you need to declare an
explicit dependency on perl.  It need not be versioned, since the
implicit perl-base dependency will handle that.

Note that the perlapi* dependencies were added for XS modules (which
is why dh_perl adds them only in that case).  They were added to
reduce the necessity of rebuilding XS modules with every minor Perl
revision when the newer revision is ABI compatible and to manage an
unversioned /usr/lib/perl5 directory, ensuring that everything in
there is compatible with the current /usr/bin/perl (not something
which is typically an issue for embedding programs).

I can see an argument however for also adding a perlapi* dependency
for packages which embed Perl, given that a non-trivial implementation
will be using just as much of the Perl internals as a typical XS
module.  This would require both a policy change, and an update to
dh_perl.

Niko: have there been cases where a dependency on both libperl5.x and
perlapi-5.X.y would have been different that just having the first
dependency?  I can imagine cases where ABI compatibility was broken by
minor versions, but don't recall an instance myself.

--bod


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

Bug#712613: libapt-pkg-perl: Size,InstalledSize fields missing

[Brendan O'Dea]

On 18 June 2013 07:38, Kevin Ryde use...@zip.com.au wrote:
 The Size and InstalledSize fields from a package Version object seem
 to have been lost in this change,

 
 http://anonscm.debian.org/gitweb/?p=users/bod/libapt-pkg-perl.git;a=commitdiff;h=03ae8d187f3081ebfbd05a2412d187a09d349d15

 Was that intentional?  Size and InstalledSize are still in the
 AptPkg::Cache pod.

You're right, this looks like a screw-up rather than an intentional
change.  Will fix shortly.

--bod


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

Bug#708027: closed by Brendan O'Dea b...@debian.org (Bug#708027: fixed in vile 9.8j-2)

[Brendan O'Dea]

On 21 May 2013 06:09, Dominic Hargreaves d...@earth.li wrote:
 Regrettably we don't seem to be quite there yet:

 vile-perl-api.pod around line 1266: =over without closing =back
 POD document had syntax errors at /usr/bin/pod2text line 84.


Sorry Dominic, I just fixed the errors listed and didn't actually test
with the new Perl version.

I've just uploaded another change for 9.8j-3 which hopefully should do it.

I tested this change with pod2{man,text,html} from your experimental
package (not installed, but run from the build directory) so hopefully
this one should nail it.

--bod


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

Bug#707142: libapt-pkg-perl: AptPkg::Cache can't iterate installed packages from foreign architectures

[Brendan O'Dea]

On 8 May 2013 04:55, Andrew Ayer b...@mm.beanwood.com wrote:
 AptPkg::Cache exhibits some strange behavior with its hash iteration on
 multi-arch systems.  [...]

Thanks for the report Andrew, you are quite correct that the
multi-arch support is broken in this respect.

The correct solution is obviously to include the architecture in the
package names returned by the iterator, either just for packages which
are not the native architecture, or unconditionally.  The first option
may be less surprising for users, but seems less logically consistent
than the second, which I've chosen to implement: package names
returned are always qualified (although you can still look up the
packages for default architecture unqualified).

I will upload a new package shortly.

--bod


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

Bug#701899: libapt-pkg-perl: Doesn't give long description

[Brendan O'Dea]

On Thu, Feb 28, 2013 at 04:03:18PM +, jep wrote:
On a fresh installation of wheezy (netinst RC1 on amd64), when I ask
this Perl module to get a package's long description, it gets the
short description instead:
[...]
I suspect this is because long descriptions are no longer kept in the
Packages files under Description, but stored separately in the
Translations files under e.g. Description-en.

Thank you for your detailed bug report.  This should hopefully be fixed with
the upload of 0.1.27 which supports loading translated descriptions.

--bod


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

Bug#563250: xvile: Warning: Cannot convert string lucidasans-10 to type FontStruct

[Brendan O'Dea]

On 15 May 2012 15:12, Jonathan Nieder jrnie...@gmail.com wrote:
 The Lucida fonts are in the xfonts-75dpi and xfonts-100dpi packages.

 Does installing both those packages remove the error for you?

 Thanks for the quick reply.  No, alas.

  $ dpkg -l xfonts-75dpi xfonts-100dpi xfonts-scalable
  Desired=Unknown/Install/Remove/Purge/Hold
  | 
 Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name                    Version                 Description
  +++-===-===-==
  ii  xfonts-100dpi           1:1.0.3                 100 dpi fonts for X

Odd.  What happens if you try another program with that font?

  xmessage -fn lucidasans-10 It was the best of times, it was the
worst of times, ...

for me, that works--I get a text box with the selected font as
expected.  Of course, if I specify a non-existent font I get the same
error you are seeing:

  Warning: Cannot convert string no-such-font to type FontStruct

Other things to check:

  xlsfonts -fn lucidasans-10
  xlsfonts -fn '-bh-lucida-medium-r-normal-sans-14-100-100-100-p-80-iso8859-1'
  grep lucidasans-10 /usr/share/fonts/X11/*/fonts.alias
  grep FontPath /etc/X11/xorg.conf

If all is well, I would expect the xlsfonts commands to produce one or
more lines, matching the argument to -fn. The fonts.alias files should
contain lines mapping the alias lucidasans-10 to a full font
specification such as the -bh-lucida-medium-yadda-yadda string
above. On a recent system, I would not expect to see an xorg.conf (or
XFree86.conf), but if such a file does exist, check the FontPath lines
in the Files section.

--bod



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

Bug#563250: xvile: Warning: Cannot convert string lucidasans-10 to type FontStruct

[Brendan O'Dea]

On 15 May 2012 06:36, Jonathan Nieder jrnie...@gmail.com wrote:
 xvile emits the following message whenever I run it:

 | Warning: Cannot convert string lucidasans-10 to type FontStruct

Sorry Jonathan, I didn't see the original bug--I think that probably
went to Paul (I've since changed the maintainer/uploader order).

The Lucida fonts are in the xfonts-75dpi and xfonts-100dpi packages.

Does installing both those packages remove the error for you?

These packages are suggested by the xserver, but it would seem that
you don't have them installed, so I guess they should probably should
be recommended by the xvile package.

--bod



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

Bug#657293: help2man and command with dash in the name

[Brendan O'Dea]

On 25 January 2012 21:57, Mathieu Malaterre mathieu.malate...@gmail.com wrote:
 Package: help2man
 Version: 1.40.5
 Severity: normal

 It would be nice if help2man would support generating man page from
 command with - (dash) in the name.

help2man uses the regular expression \S+ to identify the command name
from the Usage line in --help output, so should be fine with dashes in
the command name.

abo-compliance-checker does not produce --help output in a format that
help2man expects.  See the manual:

  info help2man -- --help recommendations

or the output of:

  cp --help

for samples of what is expected.

--bod



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

Bug#656242: perl: .packlist file missing

[Brendan O'Dea]

On 20 January 2012 20:02, Niko Tyni nt...@debian.org wrote:
 This is a very longstanding Debian deviation for both the core and the
 vendor directories. I can't easily find the full rationale and this was
 way before my time, so I'm taking the debian-perl list in the loop.
 I hope the discussion stays civil.

 The history of the perl Debian packaging that I have available only
 ranges back to 2005, and the .packlist files have been removed from the
 core packages for all that time.

The  changes in the handling of .packlist files and perllocal.pod were
made be me over ten years ago.  The masses have not been storming the
gates demanding their return over that decade.

As best as I recall, the main rationale for removing .packlist was
that in a system which was installed by dpkg, rather than
ExtUtils::Install it was redundant information, and required
maintainer scripts to manage updates to a common file for little
benefit.  The location would also likely need to be changed to
something under /var rather than /usr/lib if it were being managed by
maintainer scripts in such a fashion.

In response to Marc's comment in the bug that Unfortunately, when
debian redefined .packlist semantics this way, it _kept_ the name of
perl, instead of renaming it to, say debperl. I would say that this
is a ridiculous exaggeration.

Unless things have changed greatly since last I looked, the contents
of .packlist are a convenient way for the admin to know what is
installed, and not used for dependency checking by Makefiles (where
eval { require Foo } is more likely more reliable).

If it is essential for ExtUtils::Installed to work, then I'd say that
an appropriate fix for Debian would be to patch that module to query
dpkg first.  Patches are welcome from those who believe that this
behaviour is required.

--bod



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

Bug#479681: Perl symbol problem - release critical (Re: Bug#489132)

[Brendan O'Dea]

On 2 June 2011 20:56, Niko Tyni nt...@debian.org wrote:
 Reviewing the discussion, I think that Ian had a valid point and that
 we should revisit the vendorarch directory choice. Brendan (cc'd):
 I'd love to have your thoughts on this.

vendorarch was chosen for simplicity, and consistency with vendorlib.
So long as maintainer scripts use only essential packages, it works
rather well.  The situation of attempting to use packages if possible
was not anticipated, and I'll admit that I was somewhat surprised when
the eval { require ... } didn't work as expected.

You certainly could make vendorarch ABI dependent, and perhaps should
to avoid some of the more subtle failures (such as the 64bit issue you
mentioned).  I'm not entirely sure however that it fixes this
particular problem correctly.

The conditional inclusion of Locale::gettext is intended to provide
translations for those who want it, but not force a dependancy on the
package for those who don't.  I suspect that it is not intended to
work around upgrades--there are people for whom the configuration
dialogs suddenly reverting to English mid-upgrade could be as much a
bug as the dynamic link failure.

 First, I see all the dpkg commands in /usr/bin have been rewritten in C
 for squeeze [...]
 The debconf case is sourcing /usr/share/debconf/confmodule.sh, which
 currently tries to load three XS modules: Locale::Gettext, Text::Iconv
 and Text::CharWidth.

 Therefore, if any problems remain, they are not going to be solved
 just by integrating Locale::gettext into perl-base.

That is unfortunate.  Changing vendorarch would work around that, but
with the caveats discussed above.

Joey may be able to comment on this issue from the debconf side.  Such
as the status of cdebconf, or the possibility of providing pure-Perl
implementations of the debconf dependencies.

--bod



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

Bug#625963: vile: FTBFS on armel and s390 (hangs in configure?)

[Brendan O'Dea]

On Sat, May 07, 2011 at 02:20:33PM +0200, Julien Cristau wrote:
See https://buildd.debian.org/status/package.php?p=vile

The configure failed at different points for both armel and s390, but there is
nothing particularly exceptional about either test, moreover this exact source
package has compiled fine on both architectures recently.

Could these two builds be retried please?

--bod



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

Bug#624401: help2man: [INTL:de] Updated German translation

[Brendan O'Dea]

On 28 April 2011 17:18, Chris Leick c.le...@vollbio.de wrote:
 please find attached the updated German translation of help2man.

Thanks Chris, applied.

I also added a small unrelated correction as previously suggested by
another (see 
http://git.debian.org/?p=users/bod/help2man.git;a=commitdiff;h=8fc486e7f4ba83329a792d35b271455530e1c82f
for details).

--bod



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

Bug#620250: help2man: [INTL:fr] French translation update

[Brendan O'Dea]

On 1 April 2011 01:29, David Prévot da...@tilapin.org wrote:
 Please find attached the French translation updated, proofread by the
 debian-l10n-french mailing list contributors.

 Please note that, following your advise on #590580, I've already submit
 this version to translationproject.org: I submit this bug report in
 order to keep track of this translation via our tracker [0]. Next time,
 I should be able to update the translation before the package reaches
 Debian and I won't “bug” you any more

Thanks David, I'll apply this shortly.



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

Bug#590580: help2man: [INTL:fr] French translation update

[Brendan O'Dea]

On 8 January 2011 08:07, David Prévot da...@tilapin.org wrote:
 I'll sure take care of that as soon as I send the disclaimer to the FSF
 (I fail to understand its purpose), or when you stop require it.

The copyright to help2man has been assigned to the FSF, and as they
require this disclaimer[0] I don't believe that I can withdraw the
requirement.

As far as the purpose goes, as noted on the TP page[1]: the FSF wishes
to guarantee that these translations will always remain freely
distributable, and requires this documentation to ensure that is the
case.

I appreciate that it is annoying and seems unnecessarily pedantic, but
you should only need do it once, then never care about it again.

--bod

[0] http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html
[1] http://translationproject.org/html/whydisclaim.html



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

Bug#590580: help2man: [INTL:fr] French translation update

[Brendan O'Dea]

On 27 July 2010 23:58, David Prévot da...@tilapin.org wrote:
 Please find attached the French translation updated, proofread by the
 debian-l10n-french mailing list contributors.

Thanks David, I have included this translation in the latest release.
Could you please also submit this version to translationproject.org ?



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

Bug#579457: debian-policy: finer granularity for perlapi-*

[Brendan O'Dea]

On Fri, May 07, 2010 at 07:16:32PM +0300, Niko Tyni wrote:
Final version with the nonzero thing removed. I'm looking for seconds.

diff --git a/perl-policy.sgml b/perl-policy.sgml
index 1d26df7..1ee5df5 100644
--- a/perl-policy.sgml
+++ b/perl-policy.sgml
@@ -89,8 +89,11 @@
   /p
   p
 The packageperl-base/package package must provide
-packageperlapi-varversion/var/package for all released
-versions it is compatible with.
+packageperlapi-varabiname/var/package for all released
+package versions it is compatible with. The choice of
+varabiname/var is arbitrary, but if it differs from
+tt$Config{version}/tt, it must be specified in
+tt$Config{debian_abi}/tt.
   /p
   /sect
 
@@ -348,8 +351,9 @@ $(MAKE) install PREFIX=$(CURDIR)/debian/lt;tmpgt;/usr
   a minimum version of the packageperl/package package
   used to build the module, and must additionally depend on
   the expansion of
-  packageperlapi-$Config{version}/package using
-  the ttConfig/tt module.
+  packageperlapi-$Config{debian_abi}/package using
+  the ttConfig/tt module. If tt$Config{debian_abi}/tt
+  is empty or not set, tt$Config{version}/tt must be used.
 /p
   /sect1

Seconded.

--bod


signature.asc
Description: Digital signature

Bug#579457: debian-policy: finer granularity for perlapi-*

[Brendan O'Dea]

On 6 May 2010 23:26, Niko Tyni nt...@debian.org wrote:
 I was trying to cater for the degenerate case of $Config{debian_abi}=0
 (which breaks the above short-circuit form) so dependants wouldn't have
 to check for that.

Sure, but this is not an arbitrary string which may accidentally
contain 0.  I think that we may safely presume that no future Perl
maintainer will choose that to set debian_abi to be zero.

 New try. I replaced abiversion with abiname to emphasize that it does
 not need to look like a version number, and applied your suggestion with
  s/is not set or empty/is empty or not set/
 to avoid a slight precedence ambiguity.

Looks good to me.

--bod



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

Bug#579457: debian-policy: finer granularity for perlapi-*

[Brendan O'Dea]

I would like to include these settings in the virtual package name so
that it would be possible to make incompatible ABI changes during the
life time of a single Perl upstream version and have a clean transition
path.

As for the implementation, the name of the virtual package could be
derived from $Config{archname}, for example x86_64-linux-gnu-thread-multi.
The system type prefix seems unnecessary; stripping it out and adding
the version number would give something like
 Provides: perlabi-5.10.1-thread-multi, perlabi-5.10.0-thread-multi
or
 Provides: perlabi-5.12.0-thread-multi-64int-ld

My inclination would be not to use something this verbose.  It implies
that there could be multiple concurrent builds, which was something I
spent some time and effort removing.

It seems to me that you could leave it as-is, for this release but
additionally make this policy change:

For convenience, the perl package could include the suffix and/or the
whole string in something like $Config{debian_abi}. In that case we
should probably mandate that packages need to use it rather than derive
the string themselves.

...which I think is rather a sound idea, which allows you in the ideal
case to retain a concise dependency, but does not preclude you changing it
arbitrarily should it turn out that there are issues with 64int+ld moving
forward.  In which case anything would suffice: perlapi-5.12.0-32int for
example if you were backing out the change.  This of course need not be
permanent, the next version could be just perlapi-5.12.1 again.

The perl-base package could provide both the old perlapi-version
and the new perlabi-version-suffix during the transition period and
remove the perlapi-* one when all the packages have been changed.

This should not even be required for this transition: no prior package
will meet the 64int+lb ABI.

[1] Given that this is all about binary compatibility, I don't understand
why the virtual package is called perlapi-* and not perlabi-*.
Maybe somebody could enlighten me?

The name came from the variables in perl used to denote the oldest
compatible binary version: api_{revision,version,subversion}.

http://perl5.git.perl.org/metaconfig.git/blob/master:/U/perl/patchlevel.U#l74

Feel free to s/abi/api/ if it truely bothers you.

--bod



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

Bug#579457: debian-policy: finer granularity for perlapi-*

[Brendan O'Dea]

On 6 May 2010 04:57, Niko Tyni nt...@debian.org wrote:
 Update: this formulation avoids an unnecessary patch to the perl package
 until the ABI is actually changed. It also allows debhelper and the
 few other affected packages to easily stay compatible with older perl
 package versions.

 I'm thinking the dependants could use something like
  perlapi- . ($Config{debian_abi} || $Config{version})

Nice.

Rather than evaluates to false, I'd suggest wording it:

  If tt$Config{debian_abi}/tt is not set or empty,
tt$Config{version}/tt must be used.

as this more clearly indicates the intent.

--bod



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

Bug#571812: help2man

[Brendan O'Dea]

On Mon, Mar 1, 2010 at 9:19 AM, Will Daniels deb...@willdaniels.co.uk wrote:
 My apologies, it does not have to do with the path prefixing the command
 name, it seems the problem was that the help output does not begin with
 a description line and just starts with Usage. I must have gotten things
 muddled somehow.

I'm still not clear on the exact problem.  The output I attached to
the bug earlier was from an oauth program which similarly produced
--help output starting just with Usage:   Would you please
attach to the bug the output of the following:

  1. oauth --help
  2. oauth --version
  3. help2man oauth



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

Bug#571812: help2man: can't cope with path prefix (Usage: /usr/bin/foo bar)

[Brendan O'Dea]

On Sun, Feb 28, 2010 at 6:36 PM, Will Daniels deb...@willdaniels.co.uk wrote:
 Package: help2man
 Version: 1.36.4+nmu1
 Severity: minor

 I have an upstream bin that outputs the path of the command after Usage: in 
 --help (i.e. Usage: /usr/bin/oauth [options]... which causes help2man to 
 take Usage as the command name in error.

This should not cause a problem.  I found an oauth package here:
http://github.com/mojodna/oauth which produced similar output:

  Usage: /usr/bin/oauth [options] command

Output from the current unstable version 1.37.1 attached, although I
would be surprised if the behaviour of 1.36.4+nmu1 was different.


oauth.1
Description: Binary data

Bug#564668: libapt-pkg-perl should have a function to view upgradable packes

[Brendan O'Dea]

On Mon, Jan 11, 2010 at 2:16 PM, William Orr w...@worrbase.com wrote:
 I'm working on a patch for apt-build, and it would be really nice to have a
 function that returns upgradable packages. Using AptPkg::Policy works unless
 apt pinning is used.

In what way does it not work?  On a system with pending upgrades, the
output of the attached script may be modified by editing
/etc/apt/preferences to pin a package to the currently installed
version.


updates
Description: Binary data

Bug#552797: perl: dpkg-shlibdeps fails on suid-perl on i386

[Brendan O'Dea]

On Wed, Oct 28, 2009 at 7:13 PM, Niko Tyni nt...@debian.org wrote:
  http://git.debian.org/?p=perl/perl.git;a=commitdiff;h=063f225d0fdeca563c7906927fc30171c3684f70

This makes sure the script runs with the system perl and not the new one.

Note that one of the reasons why perl has a slightly eccentric rules
file is so that the package is able to be built on a system without
any perl installed.  This was to allow new ports to bootstrap and is
the reason why ./perl.static is used in that file rather than
/usr/bin/perl.  It is entirely possible that bit-rot has made this no
longer work, but it is still a useful goal to retain.

See debian/checkperl, which is invoked for the install rule.



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

Bug#547154: help2man: [INTL:DE] Initial German translation

[Brendan O'Dea]

On Thu, Sep 17, 2009 at 7:49 PM, Chris Leick c.le...@vollbio.de wrote:
 Please find the initial German translation help2man attached.

Would it be possible to also get a translation of the help2man.h2m
file also please?



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

Bug#546863: libapt-pkg-perl: Does not expose architecture conditions for build dependencies

[Brendan O'Dea]

On Wed, Sep 16, 2009 at 5:58 PM, Frans Pop elen...@planet.nl wrote:
 AFAICT libapt-pkg-perl currently does not expose these architecture
 conditions in the BuildDepends hash. Would it be possible to add this?

Not easily, these architecture-specific entries are filtered by the
underlying libapt-pkg APT library which includes only those
dependencies which are appropriate for the current architecture.

You can change the architecture which is used when parsing the Build-Depends:

  use AptPkg::Config '$_config';
  $_config-init;
  [...]
  $_config-{APT::Architecture} = $arch;

--bod



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

Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz

[Brendan O'Dea]

On Mon, Aug 17, 2009 at 7:01 AM, Niko Tynint...@debian.org wrote:
 There are ways around that, have the perl package provide a name which
 maps to the debian version less NMUs (either by manually updating
 debian/control, or an automated process which removes bin NMUs from
 the version).

 As binNMUs get an extra changelog entry compared to their arch:all
 counterparts, all approaches that try to make them equivalent seem
 fundamentally broken to me. But maybe I'm just misunderstanding you.

I was suggesting:

  Package: perl
  Provides: perl-${debian-base:Version}

  Package: perl-modules
  Depends: perl-${debian-base:Version}

or something similar, and to have debian-base:Version set by
debian/rules to be the Debian version =~ s/\+b\d+$//

This would mean that arch-indep packages may have a changelog which
contains one or more binary NMU lines that technically do not apply,
but as these are machine generated metadata do we really care?

 Another alternative, certainly the simplest, would be to remove
 perl-modules entirely and have those arch-indep parts included in the
 perl package. [...]
 I find this suggestion somewhat appealing, particularly as it would
 remove the dependency loop that people frequently complain about
 (#527917 / #502455) and simplify major version upgrades.

 The size of the packages is roughly
              package size    installed-size
 perl              5M               15M
 perl-modules      3M               15M

 so with ~15 architectures, the join would take on the order of 50
 megabytes more mirror space per suite, altogether something like 200
 megabytes.  That does sound a bit much, but OTOH it's less than .1 %
 of the total archive size.

Note that while size in the archive was part of the original
motivation of splitting the arch-indep parts out, it also seemed to be
the correct thing to do in so far as making scenarios such as
described in the FHS easier to manage
(http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA).

Having said that, I'm inclined to believe that merging the two is
perhaps the best course.

 A quick count shows 116 packages in sid that have a versioned dependency
 (build- or otherwise) on perl-modules. Those would have to be fixed
 first unless we provided a transitional empty perl-modules package.

My inclination would be to have an empty package.

 In any case, the join wouldn't solve the issue this bug is about
 completely, as perl-doc also has an arch:all-arch:any symlink in
 /usr/share/doc. It therefore seems to me that a possible perl/perl-modules
 join is a separate matter and should not necessarily be coupled with
 this bug.

This similarly could be solved with the provides/dependency as described above.

 I think removing the symlinks with maintainer scripts and separating
 the /usr/share/doc entries is the best course of action here.

Sure.  I would still be inclined to keep the majority of the
documentation under /usr/share/doc/perl (as it is currently), and
merely have copies of changelog.Debian.gz, copyright and perhaps a
short README.Debian in /usr/share/doc/perl-doc.

If, OTOH you think that it would be clearer to split the docs across
perl-base, perl and perl-doc, I can take a look at what machinations
would be required to apply that on update.

--bod



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

Bug#542137: perl-doc: No description of changes for version 5.10.0-25 in changelog.Debian.gz

[Brendan O'Dea]

On Tue, Aug 18, 2009 at 12:02 PM, Dave Witbrodtdawit...@sbcglobal.net wrote:
 Where's the notes for 5.10.0-25?

In the perl-base package, which you should get an update for shortly,
once the buildds are done.

There is discussion going on now (see debian bug #536384) as to if/how
this should be changed.

Interestingly, this directory layout under /usr/share/doc and symlinks
have been in place for the last 8 years.  Odd that there should be a
number of bugs about it only now...

--bod



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

Bug#541551: perl-base: detecting stopped child process fails using POSIX WIFSTOPPED

[Brendan O'Dea]

So it seems that this is an intentional upstream change*.

The perlvar entry for $? now notes that it contains the 16-bit status
word returned by the traditional Unix wait() system call (or else is
made up to look like it).  Thus, the exit value of the subprocess is
really ($?  8), and $?  127 gives which signal, if any, the process
died from, and $?  128 reports whether there was a core dump.

Unfortunately, a stopped process does not fit these semantics and
moreover the W*() macros expect the un-molested status word as
argument.

You will need to change your code to test ${^CHILD_ERROR_NATIVE}
rather than $? with the W*() macros.

--bod

* http://www.mail-archive.com/perl5-chan...@perl.org/msg11298.html



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

Bug#541551: perl-base: detecting stopped child process fails using POSIX WIFSTOPPED

[Brendan O'Dea]

On Sat, Aug 15, 2009 at 5:15 AM, torp1250272...@noid.net wrote:
 When perl is testing if a child process is stopped, the
 result of the WIFSTOPPED function is never correct:

Thanks for the bug report Tor.

It appears that the problem is actually with waitpid not setting $?
correctly when the process is stopped.  Will investigate further.



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

Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz

[Brendan O'Dea]

On Mon, Jul 13, 2009 at 6:12 AM, Niko Tynint...@debian.org wrote:
 On Fri, Jul 10, 2009 at 11:15:17PM +1000, Brendan O'Dea wrote:
 I vote that we fix this problem by simply nailing the dependencies
 between perl-base/perl/perl-modules to an exact equivalence.  [...]

 I agree with you that this is a cure worse than the disease. Furthermore,
 as Adrian stated, it has problems with binNMUs.

There are ways around that, have the perl package provide a name which
maps to the debian version less NMUs (either by manually updating
debian/control, or an automated process which removes bin NMUs from
the version).

Another alternative, certainly the simplest, would be to remove
perl-modules entirely and have those arch-indep parts included in the
perl package.  perl could transitionally provide perl-modules.  The
packages versions of perl/perl-modules were never intended to be
disjoint--the split was intended only to reduce redundancy in the
archive.  Is disk sufficiently cheap theses days that we no longer
care?



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

Bug#539145: RM: xpumon -- RoQA: RC-buggy, obsolete

[Brendan O'Dea]

On Wed, Jul 29, 2009 at 9:41 PM, Thomas Viehmannt...@beamnet.de wrote:
 xpumon has an unanswered RC bug open since May 1st.
 Its description contains
  Requires a 2.4 kernel with the /proc/pmu interface.
 and the popcon is 3.

Correct, thanks Thomas.  Please remove this package.  I no longer have
access to the hardware to support it.



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

Bug#138752: Got me again

[Brendan O'Dea]

On Sat, Jul 11, 2009 at 7:39 AM, Steve M. Robbinsst...@sumost.ca wrote:
 I wasted 20 minutes debugging help2man because it outputs
 a completely unhelpful message:

        help2man: can't get `--help' info from inspect

 when the program writes to stderr.

 David Bremner suggested to at least documenting this design
 choice.  Please consider the enclosed patch.

The design choice is simple:  don't try to parse error messages as
help, consider the following examples from a non-linux system:

  $ ls --help
  ls: unknown option -- -
  usage: ls [-1AaCcdFfghikLlmnopqRrSsTtux] [file ...]
  $ cp --help
  cp: unknown option -- -
  usage: cp [-fip] [-R [-H | -L | -P]] source target
 cp [-fip] [-R [-H | -L | -P]] source ... directory

For this reason, help2man will continue to ignore stderr by default.
I will however change the wording of the error message, and add a
--no-discard-stderr (or whatever) option.

--bod



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

Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz

[Brendan O'Dea]

On Fri, Jul 10, 2009 at 1:23 AM, Adrian Bunkb...@stusta.de wrote:
 /usr/share/doc/perl-modules is a symlink to /usr/share/doc/perl,
 and /usr/share/doc/perl/changelog.Debian.gz is shipped in the
 perl-base package.
 [...]
 the Debian source tree of perl-modules 5.10.0-24 is hardly the
 5.10.0-1 or 5.10.0-30 perl source tree.

I strongly disagree that this is a serious violation.  Completely
omitting the changelog is a serious violation.  There being the
possibility of a slight difference between perl/perl-modules is hardly
so, and for a working package in the stable distribution the intent is
that there be no difference.

For the sake of preventing further Policy lawyer bugs of this variety,
I vote that we fix this problem by simply nailing the dependencies
between perl-base/perl/perl-modules to an exact equivalence.  This may
render perl un-installable in unstable at times for some
architectures, but heck the most important thing is obviously sticking
to the letter of Policy, so let's do it.

--bod



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

Bug#527917: please break circular dependency

[Brendan O'Dea]

For reference, an install/remove of perl on current unstable:

# apt-get install perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  make perl-modules
Suggested packages:
  make-doc perl-doc libterm-readline-gnu-perl libterm-readline-perl-perl
The following NEW packages will be installed:
  make perl perl-modules
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 8106kB of archives.
After this operation, 29.6MB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp.au.debian.org unstable/main perl-modules 5.10.0-22 [3198kB]
Get:2 http://ftp.au.debian.org unstable/main perl 5.10.0-22 [4526kB]
Get:3 http://ftp.au.debian.org unstable/main make 3.81-5 [382kB]
Fetched 8106kB in 0s (9283kB/s)
Selecting previously deselected package perl-modules.
(Reading database ... 15633 files and directories currently installed.)
Unpacking perl-modules (from .../perl-modules_5.10.0-22_all.deb) ...
Selecting previously deselected package perl.
Unpacking perl (from .../perl_5.10.0-22_i386.deb) ...
Selecting previously deselected package make.
Unpacking make (from .../archives/make_3.81-5_i386.deb) ...
Processing triggers for man-db ...
Setting up make (3.81-5) ...
Setting up perl-modules (5.10.0-22) ...
Setting up perl (5.10.0-22) ...
# apt-get remove perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  make
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  perl perl-modules
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 28.7MB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 16873 files and directories currently installed.)
Removing perl ...
Removing perl-modules ...
Processing triggers for man-db ...
# exit



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

Bug#527917: please break circular dependency

[Brendan O'Dea]

On Sat, May 9, 2009 at 10:16 PM, Holger Levsen hol...@layer-acht.org wrote:
 Whats wrong with making perl depend perl-modules and making perl-modules only
 recommend perl? (I do the same with the tuxtype and tuxtype-data packages,
 and tuxtype-data is also basically useless without tuxtype. You could look at
 the images, yeah ;-)

The co-dependency between perl and perl-modules is required as these
are fundamentally one package, split only into arch any/all parts.
Modules within perl use modules within perl-modules and vice-versa.

Ideally the dependency would simply be expressed as a perl dependency
of the exact version on perl-modules (as is done for perl-base), and
this was originally how the package was set up.

This caused issues in unstable where the package became uninstallable
when a new version was available on one arch, but not built yet for
others and at the request of porters I changed the dependencies to be
looser allowing a newer version of perl-modules to be installed.  An
inverse dependency is now required however, as otherwise perl 5.6.1-1
is satisfied with perl-modules 5.10.0-22 .

Additionally these dependencies must be modified if a file moves
between the packages, an example may be seen in the changelog for
5.8.8-9 and in #377385: without the dependency changes it became
possible to have versions of perl and perl-base installed, neither of
which contained a module which had moved (similar issues occur when
moving modules to/from perl-base).

So in summary while it may not be ideal to have such package
interdependencies, these are used achieve clearly defined requirements
and are not arbitrary.  Additionally, it would seem to work: perl has
been successfully installed and upgraded  innumerable times over the
years since this dependency was introduced.

Unless there is an actual, demonstrable problem with the current
versions of perl, apt and dpkg I would suggest either closing this bug
or at least downgrading to wishlist.

--bod



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

Bug#522827: perl: policy violation with the current /usr/share/doc symlinks

[Brendan O'Dea]

On Tue, Apr 7, 2009 at 5:45 AM, Niko Tyni nt...@debian.org wrote:
 As revealed by lintian, shipping /usr/share/doc/perl/copyright
 in perl-base and symlinking /usr/share/doc/perl-base - perl
 is a policy violation. [...]
 Is there a historical reason for the current setup or is it just cosmetics?
 It's not causing any problems AFAIK, but I suppose we can't just ignore policy
 here.

This was an intentional decision and I do not believe that there is
actually a problem here.

Yes, there is potentially an issue that perl-base is a symlink,
although I believe that this is mitigated by the fact that it links to
a directory in the same package--so any tools as mentioned in policy
(such as apt-listchanges) which are looking at a single package
archive should be able to cope.

Moreover, as you've found, switching symlinks to directories and vice
versa is tricky.  I seem to recall instances where empty directories
resulted from various update orderings.

--bod



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

Bug#510895: perlivp fails

[Brendan O'Dea]

On Wed, Jan 7, 2009 at 12:21 AM, Niko Tyni nt...@debian.org wrote:
 On Mon, Jan 05, 2009 at 11:32:28AM -0800, Eric Wilhelm wrote:
 The `perlivp` program fails two of its tests.  One is due to the absence
 of '/usr/local/lib/site_perl' and the other appears to be an artifact of
 the build procedure having used a temporary directory as a prefix (e.g.
 files missing from installation:
 /tmp/st-o67qmvRP/usr/local/lib/perl/)

 I don't see the /tmp thing with the current version (-19), only these:

 # Perl @INC directory `/usr/local/lib/perl/5.10.0' does not appear to exist.
 # Perl @INC directory `/usr/local/share/perl/5.10.0' does not appear to exist.

 We could create the directories in a postinst script, but I'm not sure
 I see the point. They will be created automatically when installing
 CPAN modules.

The directories are intentionally not created, as this way they are
excluded from the search path at start-up, saving a bunch of wasted
stats at use/require time in the common case that the user has not
installed any local packages.  As Niko points out, they will be
created as required.

We could perhaps consider patching perlivp to handle the optional @INC
case more cleanly.



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

Bug#151745: [Fwd: Perl bug on Socket.pm on SO_REUSEPORT constant]

[Brendan O'Dea]

In the current version, the behaviour has changed from what was seen
in the initial report.  SO_REUSEPORT is exported, but since this
constant is not defined in asm/socket.h, using ReusePort in the
IO::Socket::INET constructor will eilicit a die Your vendor has not
defined

I figure that this is probably the correct behaviour.  What else
should IO::Socket::INET do when passed ReusePort on a platform which
does not support that socket option?



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

Bug#504042: perl-doc recommendation

[Brendan O'Dea]

On Mon, Dec 8, 2008 at 6:24 PM, Raphael Hertzog [EMAIL PROTECTED] wrote:
 Brendan meant:
 apt-get install perl should install perl-doc because the user is
 interested in perl but apt-get install dpkg-dev which does also depend
 on perl should not install perl-doc because perl-doc is not really related
 to dpkg-dev.

Exactly.

 While it's an interesting idea, I don't think it's really worth the
 complexity.

On reflection, this is really a UI issue and an additional control
field should not be necessary.  More complex UIs like aptitude, or the
venerable dselect handle this by punting the choice on a case-by case
basis to the user...  apt-get is a bit more coarse.

Perhaps APT::Install-Recommends should be a tri-state: always | never
| direct rather than a boolean to achieve the same result.  With
direct of course selecting only recommended packages which are
direct dependencies of the packages given on the command line.

Or, as you say, it may not be worth the effort.  Disk these days is
relatively cheap, and perl-doc is all of 8M.  Special cases require
special handling--If disk space, or network bandwidth is really of
such a premium, then perhaps a more judicious manual selection is
required by the user.



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

Bug#504042: perl-doc recommendation

[Brendan O'Dea]

[+#504042, debian-dpkg, deity]

On Mon, Nov 3, 2008 at 1:02 AM, Niko Tyni [EMAIL PROTECTED] wrote:
 I could use some backing with #504042 / #496770 (perl-doc gets pulled
 in by default).

 You tagged #442805 as wontfix with

 There is a bit of history with the perl-doc package...  The perl
 community has been at times very critical of the fact that the docs are
 split out *at all*.  The argument is that the docs are an integral part
 of the perl distribution.

 Have you got any references? I've been searching for a while and the
 best I came up with was

  http://www.nntp.perl.org/group/perl.perl6.stdlib/2000/09/msg109.html

 which doesn't really apply as #86154 has been fixed for ages.

 Please comment on #504042 if possible. I can see this becoming a popular
 complaint with lenny because it's the first release where apt installs
 recommends by default.

Hrm.

apt installing recommends by default certainly paints this issue with
a different colour.  An odd choice, given that the same problem
existed with dselect until joeyh provided a fix which caused the
prompt for recommended packages for installation to be presented only
once.

Many of the complaints about Debian's handling of documentation came
from IRC, where recommendations of perldoc -f whatever were often
met with a response from the querent of perdoc not found.  These
complaints have subsequently been addressed by the addition of the
stub perldoc which provides instructions to apt-get install
perl-doc.

So you may be able to downgrade the recommendation to a suggests,
although a better suggestion might be for apt/dpkg to support a
Soft-Recommends which would be installed by default only when the
package was directly selected, rather than pulled in as a dependency.

--bod



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

Bug#495394: perl: Install of diffrent versions in parallel alternatives

[Brendan O'Dea]

On Sun, Aug 17, 2008 at 7:02 PM, Peter Eisentraut [EMAIL PROTECTED] wrote:
 Actually, the solution is that postgresql-plperl-8.1 needs to be
 re-built for 5.10.

 That is not possible, because postgresql-plperl-8.1 is part of etch.

Ah, it was not clear that you were trying to do a partial upgrade.  If
you are trying to mix lenny/sid Perl with etch Postgres, then you will
need to manually rebuild at least one.

 What is in perl-base that libperl needs anyway?

A Perl interpreter requires at least some of the standard library to
run any non-trivial program.



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

Bug#495394: perl: Install of diffrent versions in parallel alternatives

[Brendan O'Dea]

reassign 495394 postgresql-plperl-8.1
thanks

On Sun, Aug 17, 2008 at 9:54 AM, Peter Niebling [EMAIL PROTECTED] wrote:
 It should be possible to have different perl versions installed in parallel.
 This concerns also perl-base and perl-modules.

This is somewhat more complicated than you might expect, given that it
would require not only multiple versions of the Perl package set, but
also of all binary modules and a number of pure Perl modules.

 Actually, postgresql-plperl-8.1 is going to be removed when upgrading perl to 
 5.10.
 This MUST NOT happen.

 The reason:
 libperl5.8 depends on perl-base (= 5.8.8-12)
 libperl5.10 depends on perl-base (= 5.10.0-13)

 The solution:
 perl, perl-base and perl-modules (maybe others) should have versioned names 
 and corresponding metapackages.
 The dependencies in other packages have to reflect the changes as well.

Actually, the solution is that postgresql-plperl-8.1 needs to be
re-built for 5.10.

 There are only a few files under /usr/bin which have to wrappers to 
 alternatives.

Some years ago there were multiple Perl packages, with /usr/bin/perl
managed by update-alternatives.  There were a number of problems with
this situation, not least of which was that using update-alternatives,
which requires /usr/bin/perl to operate, to manage that same pathname
caused some entertaining failures during upgrades.

Reassigning to postgresql-plperl-8.1.



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

Bug#474529: Perl policy vs. the search order for .1{,p} manpages

[Brendan O'Dea]

On Wed, Aug 6, 2008 at 6:34 PM, Colin Watson [EMAIL PROTECTED] wrote:
 I'd contend that you should simply divert the manual page in the same
 way. It's almost always wrong to handle manual pages differently from
 binaries in maintainer scripts - if you divert foo to foo.real, you
 should also divert foo.1.gz to foo.real.1.gz. (Similarly for
 alternatives.)

My thoughts exactly.  Although this does suggest that perhaps policy
should be amended to use .1 or .1p for both core and vendor.



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

Bug#474529: Perl policy vs. the search order for .1{,p} manpages

[Brendan O'Dea]

On Wed, Aug 6, 2008 at 4:34 AM, Niko Tyni [EMAIL PROTECTED] wrote:
 while Brendan hasn't found the time to comment on this, I think moving
 .1p up on the search list would be the best thing to do for lenny at
 least. Would you still be willing to do that?

The reason that modules manual pages have distinct extensions is to
prevent filename collisions between CORE and vendo, since they share
the same manual directory.  man-db fortunately has a mechanism to
select the correct page for a section: man Foo, or man 3 Foo will
present the first of 3pm or 3perl which it finds.

Sadly, the shell has no such selection mechanism, so even if you do
use different extensions for section 1 pages, you will still get a
collision on the script.

  
http://packages.debian.org/search?suite=sidarch=anysearchon=contentskeywords=%2Fusr%2Fbin%2Fcorelist

Is this not going to cause some large measure of grief when either of
perl or libmodule-corelist-perl upgrades?

 If a newer pod2man is going to be in a separate package (see the
 debian-perl thread), this is going to become a bit more important than
 just the libmodule-corelist-perl issue.

So this particular issue needs to be addressed.



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

Bug#492816: libperl must NOT be installed in /usr/lib

[Brendan O'Dea]

On Wed, Jul 30, 2008 at 7:52 AM, Marc Lehmann [EMAIL PROTECTED] wrote:
 On Tue, Jul 29, 2008 at 11:17:33PM +1000, Brendan O'Dea [EMAIL PROTECTED] 
 wrote:
 I think that you have some other problem.  -Lpath -lperl will search
 at compile time for libperl.so or libperl.a in path before it
 searches /usr/lib.

 No, it will srearch for libperls.o *first* in all directories and then for
 libperl.a. If the alternative perl is built without a shared library, then
 the debuian one will be picked up first.

That is not the way that any linker I have ever used works, and the
current unstable Debian linker works pretty much exactly as I would
expect.

To test this, I picked a simple function from libperl,
Perl_my_snprintf which could be used to demonstrate which library is
selected by the linker.  See attached local_libperl.c which provides
an implementation of this function, operating in a way that allows it
to be clearly distinguished from the packaged library, and test.c
which calls the function.  A transcript follows:

  $ ls -l /usr/lib/libperl.*
  -rw-r--r-- 1 root root 5424738 2008-07-17 02:32 /usr/lib/libperl.a
  lrwxrwxrwx 1 root root  15 2008-07-30 21:05 /usr/lib/libperl.so
- libperl.so.5.10
  lrwxrwxrwx 1 root root  17 2008-07-30 20:40
/usr/lib/libperl.so.5.10 - libperl.so.5.10.0
  -rw-r--r-- 1 root root 1364380 2008-07-17 02:32 /usr/lib/libperl.so.5.10.0
  $ cc -c local_libperl.c
  $ ar rv /tmp/libperl.a local_libperl.o
  ar: creating /tmp/libperl.a
  a - local_libperl.o
  $ cc test.c -o debian -lperl
  $ cc test.c -o local -L/tmp -lperl
  $ ./debian
  Debian libperl
  $ ./local
  local libperl

So on my machine, updated to latest unstable and with libperl-dev
installed, linking with -Lpath -lperl selects the library from
path, even with /usr/lib contains both .so and .a.

 If by windows process emulation? you are referring to threads, I
 suggest that you go read the POSIX standard.

 That's just a stupid ad-hominem :( I know the posix standard very well,
 but it is irrelevant: perl doesn't offer threads, what it does is emulate
 processes *using* threads (and it uses pthreads on e.g. debian to do that).

In the context of a response to the assertion that I had made some
extremely bad choices for configuration, and what appeared to be a
rather naive assertion about the nature of ithreads, I believe that I
was fairly restrained.

 When you create a perl thread, then perl actually creates a pseudo-process by
 copying the *whole* perl interpreter. There is no shared address space, 
 and the whole thing was created to emulate processes on windows, thus process
 emulation.

I am intimately aware how Perl threading works.  I can assure you that
it was not created to emulate processes on Windows.  There can be
shared address space when required (see threads::shared).

The major reason for enabling ithreads however was not primarily to
allow people to use threads, but more to allow perl to be embedded
into threaded programs (mod_perl 2.0 for example required perl to be
compiled with ithreads).

--bod


local_libperl.c
Description: Binary data


test.c
Description: Binary data

Bug#492816: libperl must NOT be installed in /usr/lib

[Brendan O'Dea]

On Wed, Jul 30, 2008 at 7:55 AM, Marc Lehmann [EMAIL PROTECTED] wrote:
 (I really wonder when debian maintainers learn to do their job properly
 and stop trying to act like bignosed idiots who know everything better -
 wasn't the we-know-better-than-openssl incident enough?).
 Sorry, but you deserved it :(

Did I, really?

You are free to choose a different distribution, or in fact operating system.

--bod



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

Bug#492816: libperl must NOT be installed in /usr/lib

[Brendan O'Dea]

On Tue, Jul 29, 2008 at 10:44 AM, Marc Lehmann
[EMAIL PROTECTED] wrote:
 debian makes it impossible to install perls in other prefixes by forcing
 libperl.so (a private library that should not be in the default search
 path) into /usr/lib, where it clashes with every other libperl.

Impossible?  Have you tried?  Many people are running non-Debian perl
installs in /opt, /usr/local or whatever.

 Unfortunately, debian completely breaks this mechanism by moving it into
 /usr/lib, where it clashes with all other libperls on the same system, as
 /usr/lib is alwas in the default linker search path. i.e.

   -L/opt/perl/lib/CORE -lperl

 will link against the correct perl library (here in /opt/perl/lib) on
 every system except on debian, as debian puts the libperl into the default
 library search path, when libperl was never intended to be put there.

I think that you have some other problem.  -Lpath -lperl will search
at compile time for libperl.so or libperl.a in path before it
searches /usr/lib.

When linking to a shared library in a directory outside of /usr/lib
either LD_RUN_PATH must also be set correctly, or -rpath passed to the
linker such that at runtime the library will be found in the correct
directory.

 (this is especially bad as debian uses some extremely bad choices for
 configuration, such as enabling the windows process emulation on unix,
 which serves no purpose except slow down perl considerably for no gain
 whatsoever on unix, so compiling one's own is practically required)

If by windows process emulation? you are referring to threads, I
suggest that you go read the POSIX standard.

--bod



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

Bug#489928: libcgi-pm-perl: tries to overwrite file owned by libcgi-fast-perl

[Brendan O'Dea]

On Wed, Jul 9, 2008 at 5:53 AM, gregor herrmann [EMAIL PROTECTED] wrote:
 On Tue, 08 Jul 2008 20:47:48 +0200, Ralf Treinen wrote:
 Possible solutions include:
 * make libcgi-pm-perl conflict (and maybe provide) with
  libcgi-fast-perl; that would mean changing the Priority to extra
  (also of depending packages)

..or changing the priority of the libcgi-fast-perl to optional.

 * remove Fast.pm from libcgi-pm-perl and depend on libcgi-fast-perl;
  that's happening right at the moment a few hundred kilometers to
  the south east from, and maybe the newer package will already be
  uploaded before this mail is finished :)

Neat.  For the short term, this seems a simple fix.

 * in the long run it might be an idea to stop building
  libcgi-fast-perl from the perl source package, add Fast.pm to
  libcgi-pm-perl again, and create a dummy transitional package with
  the usual conflicts/provides/replaces dance for libcgi-fast-perl
  from the libcgi-pm-perl source package; Brendan and Niko, what do
  you think about this idea?

For 5.10, I moved the module to the vendor directory which on
reflection was probably a bad idea (debian/rules:233-236).  I'd say
that the simplest solution would be to just reverse that decision,
which would allow libcgi-pm-perl to provide a newer version without
the path conflict.

--bod



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

Bug#479681: Perl symbol problem - release critical (Re: Bug#489132)

[Brendan O'Dea]

On Fri, Jul 4, 2008 at 6:17 AM, Raphael Hertzog [EMAIL PROTECTED] wrote:
 This is why I suggested to integrate liblocale-gettext-perl in perl-base
 itself. This would be the simplest/nicest solution IMO. It would always be
 synchronized with the current perl.

 See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479681

I'm inclined at this point to follow this suggestion.

--bod



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

Bug#484681: perl-base: imperfect package description

[Brendan O'Dea]

On Fri, Jun 6, 2008 at 9:09 PM, Niko Tyni [EMAIL PROTECTED] wrote:
 On Thu, Jun 05, 2008 at 03:16:44PM +0100, Justin B Rye wrote:
 Here's a suggestion that fixes all those and has spacing and quotes
 standardised to match the debian-l10n-english house style:

 Thanks, this looks good to me. I'd like an ack from Brendan, though,
 particularly about removing the explicit mention of the perl-doc package,
 which is a bit of a delicate issue (see #442805).

 * The only extra package I need to ask for is perl, which Depends:
   perl-modules and Recommends: perl-doc.

I inherited this description from my predecessor and had retained it
partly because it was humorous, but mostly because I couldn't be
bothered to think up an alternative.  Moreover, as an essential
package, this is not something that users generally get a choice to
remove, and I would be rather surprised if anyone looking to build a
system so stripped down that they are looking at removing essential
packages would not know what Perl was.

Having said that, the proposed alternative is certainly reasonable and
I have no real objections other than the one which Niko raised.  While
it is true that the text about additional packages is redundant in the
face of the dependencies, I see no harm in retaining the explicit
list, and if anything I would further stress the fact that this is not
intended to be a working Perl installation by itself, and should be
used only under adult supervision.

Given that the levity is being removed from the short description, we
may as well go the whole hawg and close #144193 as well.  I've also
revised the second paragraph.

 Description: minimal Perl system
  Perl is a scripting language used in many system scripts and utilities.
  .
  This package provides a Perl interpreter and the small subset of the
  standard run-time library required to perform basic tasks.  For the a
  full Perl installation, install perl (and dependencies perl-modules
  and perl-doc).

--bod



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

Bug#483834: debian-policy: contradiction how to name man pages in perl-policy

[Brendan O'Dea]

On Tue, Jun 3, 2008 at 6:22 AM, Russ Allbery [EMAIL PROTECTED] wrote:
 Ansgar Burchardt [EMAIL PROTECTED] writes:
 there is a contradiction how to name man pages for perl modules.
 Section 4.1 states

 Module packages must install manual pages into the standard
 directories (see Documentation, Section 2.4) using the extensions
 .1p and .3pm to ensure that no conflict arises where a packaged
 module duplicates a core module.

 while section 2.4 states

 Manual pages distributed with Perl packages must be installed into
 the standard directories:
 Programs
 Manual pages for programs and scripts are installed into
 /usr/share/man/man1 with the extension .1.
 Modules
   Manual pages for modules are installed into /usr/share/man/man3
   with the extension .3perl.

 This is consistent.  I think you just missed that section 2.4 is talking
 about the behavior of the Perl packages themselves (in other words, perl,
 perl-base, and perl-modules), whereas section 4.1 is talking about other
 packages of Perl modules.  The man pages that ship with the core Perl
 packages use .3perl and the man pages that ship with other packages use
 .3pm, following this standard.

 I'm not sure, however, that the .1p recommendation is followed.  Perl
 folks, could you check?  Is that really current policy and are we
 following it?

The rationale for this requirement is that since both packaged modules
and the core perl packages install manual pages to /usr/share/man,
using different extensions removes unnecessary conflicts which would
otherwise prevent modules being installed.

@Config{qw/man1ext man3ext/} are set appropriately for packaged
modules on Debian systems, and both ExtUtils::MakeMaker (perl-modules)
and Module::Build (libmodule-build-perl) use these values.  As a
result, I'd be surprised if there were very many packages in violation
of this requirement.

 Assuming that we are, I think there isn't a bug here, although if other
 people find this section confusing, maybe we should find a way to
 rephrase to make it clearer which packages are being talked about in each
 section.

I believe that the wording is sufficiently clear.



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

Bug#479711: eval require Foo with binary-incompatible XS modules

[Brendan O'Dea]

On Sat, May 31, 2008 at 4:41 AM, Raphael Hertzog [EMAIL PROTECTED] wrote:
 On Fri, 30 May 2008, Andy Dougherty wrote:
 On Sat, 31 May 2008, Brendan O'Dea wrote:
  Not really.  Adding a version into the path simply changes the failure
  from an issue loading the .so (module is unusable) to one where the
  module is not found at all (module is unusable).
 [...]
 That's wrong. The use Locale::Gettext is protected by eval {} and
 update-alternatives works well when the eval fails... as it subsitutes
 gettext() with a simple sub return { [EMAIL PROTECTED] }.
 That's why the initial request was to disable lazy symbol loading inside
 eval.

I was aware of the optional loading of Locale::gettext, but don't
believe that changing the dlopen behaviour upstream is the right
solution.

This is a Debian-specific problem, and moreover one which occurs in a
very narrow set of circumstances: programs/modules which
opportunistically load a module (hence circumventing the dependency
model) across upgrades to perl which change the binary ABI (which are
rare).

Modifying update-alternatives to set $ENV{PERL_DL_NONLAZY} would
appear to be the most appropriate solution here.

--bod



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

Bug#479711: eval require Foo with binary-incompatible XS modules

[Brendan O'Dea]

[-doughera]

On Tue, Jun 3, 2008 at 12:11 AM, Raphael Hertzog [EMAIL PROTECTED] wrote:
 On Mon, 02 Jun 2008, Brendan O'Dea wrote:
 Modifying update-alternatives to set $ENV{PERL_DL_NONLAZY} would
 appear to be the most appropriate solution here.

 I tried this but it doesn't work. The variable needs to be set before perl
 is executed apparently. So you'd need some trick so that the script exec
 itself a second time but with the environment variable set.

Really?  Something like this fails?

BEGIN {
  local $ENV{PERL_DL_NONLAZY} = 1;
  eval {
require Locale::Gettext;
Locale::Gettext-import;
  };
  if ($@) {
# handle
  }
}



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

Bug#484021: perl: evaluation of errno ($!) violates priniciple of DWIM

[Brendan O'Dea]

On Mon, Jun 2, 2008 at 8:20 AM, Stephen Gran [EMAIL PROTECTED] wrote:
 perl should clear errno before going into a function where the API
 depends on checking it afterwards.  Yes, I am aware there are other ways
 to determine that the setegid call failed.  The problem is that the
 documentation tells me that the correct way to evaluate failure is to
 check errno after calls, and the call fails to initialize errno
 correctly.  Either the docs or the function are wrong.

Normal POSIX behaviour is for errno only to be set on error, never
cleared.  See errno(3): [...] errno is never set to zero by any
library function.  I would be surprised if Perl changed this
behaviour.

Suggest that you explicitly initialise $! to 0.



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

Bug#483442: RFH: cvsweb - test -x fails with Perl 5.10

[Brendan O'Dea]

On Fri, May 30, 2008 at 10:10 AM, Daniel Leidert
[EMAIL PROTECTED] wrote:
 And real and effective UID are the same. So why does -x fail? Any idea?
 It cannot be a general bug, because a small test script prints the
 correct result.

Right.  I've attempted pretty much every combination of user and/or
other executable bits, running with $ == $ or $ != $ and I cannot
discern any -x/-X behavioural difference b/w 5.8 and 5.10.

More information required.  Can you replicate the problem outside of
apache (i.e. calling the cvsweb.cgi from the command line)?



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