Bug#727656: Status of libpaper fork

[Reuben Thomas]

On Wed, 24 Apr 2024 at 22:03, Bastian Germann  wrote:

>
> I have seen Simon's post about this. The new gnulib package has a new
> README that describes how to use the Debian
> package. There is a slight chance that FTP Masters might intervene in
> having a git bundle in a package because their
> reasoing to forbid the 3.0 (git) source format in the archive is that it
> is far easier to confirm that a file set is
> legally distributable when it is a plain tar archive. We will see.


One might hope that gnulib would be accepted because as a project it is
particularly careful about licensing. In particular, gnulib-tool lets you
vet the licenses of the modules you install in your package.


>
> For libpaper, we can think of using the new gnulib package when it has
> passed NEW. It is sitting in there waiting for an
> ack.


OK, thanks for staying up-to-date on this!

-- 
https://rrt.sc3d.org

Bug#727656: Status of libpaper fork

[Reuben Thomas]

On Tue, 19 Mar 2024 at 21:46, Reuben Thomas  wrote:

> On Tue, 19 Mar 2024 at 21:37, Bastian Germann  wrote:
>
>>
>> As nobody has provided any patch yet and I do not have an idea how to use
>> gnulib properly generally and in Debian
>> context, I came up with this. I have actually tried to use Debian's
>> gnulib but could not get the thing to work.
>>
>
I've just had some information that may help. Simon Josefsson writes in a
thread on the gnulib mailing list:

The latest gnulib in Debian contains a
git bundle of gnulib, so you can Build-Depends on gnulib and via
GNULIB_REVISION pick out exactly the gnulib git revision that libpaper
needs.  This avoids including gnulib files in the tarball that is
uploaded to Debian, and there is no risk that you will get gnulib code
from a different git commit.  It requires an added 'Build-Depends: git'
in libpaper, though, which is unfortunate but I don't see how to avoid
it.  I should write a post to debian-devel describing this pattern on
how to use gnulib in Debian packages, but you can infer everything from
the links given in my blog post [1] and the latest upload of libntlm
into Debian.

[1]
https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
[2] https://salsa.debian.org/auth-team/libntlm/-/tree/master/debian

Bug#1066203: recode: FTBFS: error.c:197:43: error: implicit declaration of function ‘strcmp’ [-Werror=implicit-function-declaration]

[Reuben Thomas]

On Wed, 27 Mar 2024 at 20:25, Santiago Vila  wrote:

>
> When I had already a bunch of them, I realized there is a macro
> STDC_HEADERS which is not properly detected.


Ah, I suspect the configure code is too old. Regenerating configure etc.
(autoreconf) might help.

-#if STDC_HEADERS
> +#if STDC_HEADERS || 1
>

But this is a good test to see if you've identified the problem.

-- 
https://rrt.sc3d.org

Bug#727656: Status of libpaper fork

[Reuben Thomas]

On Tue, 19 Mar 2024 at 21:37, Bastian Germann  wrote:

>
> As nobody has provided any patch yet and I do not have an idea how to use
> gnulib properly generally and in Debian
> context, I came up with this. I have actually tried to use Debian's gnulib
> but could not get the thing to work.
>

Fair enough. From my point of view, I don't think your patch should
introduce any functional problem.

I think this will end up in syntax errors but you can try. The obvious fix
> for me would be putting the quotation marks
> around each of the three format strings that the quoted strings are
> inserted in.
>

Ah, you're quite right as the arguments to quote() are variables. Your fix
works for me. The result is just a minor cosmetic deficiency compared to
upstream.

-- 
https://rrt.sc3d.org

Bug#727656: Status of libpaper fork

[Reuben Thomas]

On Mon, 18 Mar 2024 at 23:33, Bastian Germann  wrote:

> Hi,
>
> I have updated the salsa repo to build without gnulib.
>

Fantastic, thanks for doing this!

I am a little puzzled, I thought that the idea was to build with Debian
gnulib? I think that could be a simpler patch.

Looking at the patches, nothing seems really a problem though, except that
`quote(q)` should put single quotation marks around its argument. You could
use ASCII apostrophe for this:

#define quote(q) "'" q "'"

-- 
https://rrt.sc3d.org

Bug#809931: org-mode: Correction to report

[Reuben Thomas]

On Thu, 24 Aug 2023 at 01:40, Nicholas D Steeves  wrote:

>
> Wow, it seems no one saw this bug for quite some time...  I recently did
> some Debian Emacsen Team uploads for org-mode, and I noticed that the
> following are not currently installed in the elpa-org package:
>
>   etc/csl/locales-en-US.xml
>   etc/styles/OrgOdtContentTemplate.xml
>   etc/styles/OrgOdtStyles.xml
>
> however, emacs-common installs this:
>
>   /usr/share/emacs/28.2/etc/org/OrgOdtStyles.xml
>
> Do you know if the copy bundled with Emacs is sufficient,


I'm sorry, I don't know; these days I install org-mode manually from ELPA.
However, it would seem to make sense that elpa-org would get its own copy,
although at the same time, presumably that file doesn't change that often.

-- 
https://rrt.sc3d.org

Bug#1040430: ddclient: Upstream is unmaintained

[Reuben Thomas]

Package: ddclient
Version: 3.9.1-7
Severity: important
Tags: upstream

As of yesterday, upstream has marked the project unmaintained and archived the 
GitHub project. See https://github.com/ddclient/ddclient/

I and at least one other person offered to take over the project;
unfortunately, since the GitHub project has been archived and hence the
issue trackers cannot now be updated, it’s hard for those of us interested
in continuing the project to coordinate.

I have therefore unilaterally announced my intention to maintain the project
at least for the immediate future.

My announcement is here: https://github.com/rrthomas/ddclient/issues/1

I am filing an issue in the BTS about this to let the Debian maintainer and
users know. I am a long-time user of ddclient in Debian/Ubuntu; I’m a DM;
and I’m upstream for many Debian packages (in particular, many mature
packages whose previous maintainers handed them over to me).

Therefore, Debian may be interested in using my fork as upstream.

There don’t seem to be many outstanding bugs in the BTS for this package,
and no serious ones. I don’t propose to make major changes to the package,
though I do plan to remove some code (see my announcement).

I welcome input from the Debian community.

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-76-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ddclient depends on:
ii  debconf [debconf-2.0] 1.5.79ubuntu1
ii  init-system-helpers   1.62
ii  libdata-validate-ip-perl  0.30-1
ii  lsb-base  11.1.0ubuntu4
ii  perl  5.34.0-3ubuntu1.2

Versions of packages ddclient recommends:
ii  libdigest-sha-perl   6.02-1build4
ii  libio-socket-inet6-perl  2.73-1
ii  libio-socket-ssl-perl2.074-2
ii  perl [libjson-pp-perl]   5.34.0-3ubuntu1.2

ddclient suggests no packages.

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/sbin/ddclient (from ddclient package)

Bug#1002514: psutils: New major release with PDF support

[Reuben Thomas]

Package: psutils
Version: 1.17.dfsg-4
Followup-For: Bug #1002514

As an encouragement to update psutils in Debian, I have just released
version 3, which adds full support for PDF, with transparent filetype
detection, using exactly the same commands as before.

I have rewritten the package completely in typed Python, thoroughly checked
with mypy and pylint added more tests, and improved the documentation.

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-72-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages psutils depends on:
ii  libc6  2.35-0ubuntu3.1
ii  libpaper1  1.1.28build2

Versions of packages psutils recommends:
ii  ghostscript  9.55.0~dfsg1-0ubuntu5.2

psutils suggests no packages.

-- no debconf information

Bug#1036309: xdg-utils: xdg-mime pauses for around 2 seconds running xprop to detect XFCE

[Reuben Thomas]

Package: xdg-utils
Version: 1.1.3-4
Severity: normal

I was noticing that xdg-mime was very slow on one system; this turned out to
be a server where I did not have a desktop environment, so xdg-mime was
going through all of its DE checks every time. Commenting out the calls to
“xprop” fixed it; perhaps because I was ssh-ing into the system, and hence
xprop was querying my local X server over the net?

In any case, xdg-mime shouldn’t run a command that could wait for multiple
seconds like this, at least not just to diagnose its environment.

-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=GNOME

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-72-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.31-1
ii  libnet-dbus-perl   1.2.0-1build3
ii  libx11-protocol-perl   0.56-7.1
ii  x11-utils  7.7+5build2
ii  x11-xserver-utils  7.7+9build1

xdg-utils suggests no packages.

-- no debconf information

Bug#1013933: xsane: Another vote for XSane!

[Reuben Thomas]

Package: xsane
Version: 0.999-11ubuntu1
Followup-For: Bug #1013933

Thanks for keeping XSane alive in Debian.

I am a long-time user myself, out of necessity: I have tried several times
to use simple-scan (the only alternative I can find), and it just doesn’t
offer the functionality of XSane. XSane is clunky and buggy, but it gets the
job done. I have provided patches for XSane in the past, and will continue
to do so when I can find the time. It’s a shame that there’s no better
alternative, but I fear that flatbed scanning is increasingly a niche area,
as people now more and more use their phones to scan documents on the rare
occasions that they actually need a scan of a paper document. Therefore,
doing our best to keep XSane working is probably the best we can manage,
absent someone coming up with the sort of investment that saw simple-scan
created.

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-56-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xsane depends on:
ii  libc6   2.35-0ubuntu3.1
ii  libgimp2.0  2.10.30-1build1
ii  libglib2.0-02.72.4-0ubuntu1
ii  libgtk2.0-0 2.24.33-2ubuntu2
ii  libjpeg88c-2ubuntu10
ii  liblcms2-2  2.12~rc1-2build2
ii  libpng16-16 1.6.37-3build5
ii  libsane11.1.1-5
ii  libtiff54.3.0-6ubuntu0.3
ii  sensible-utils  0.0.17
ii  xsane-common0.999-11ubuntu1
ii  zlib1g  1:1.2.11.dfsg-2ubuntu9.2

Versions of packages xsane recommends:
ii  chromium-browser [www-browser]  1:110.0.5481.177-0ubuntu0.22.04.1sav0
ii  cups-client 2.4.1op1-1ubuntu4.1
ii  firefox-esr [www-browser]   102.8.0esr+build2-0ubuntu0.22.04.1
ii  links [www-browser] 2.25-1build1
ii  lynx [www-browser]  2.9.0dev.10-1
ii  w3m [www-browser]   0.5.3+git20210102-6ubuntu0.1

Versions of packages xsane suggests:
ii  gimp 2.10.30-1build1
ii  gocr 0.52-3
ii  gv   1:3.7.4-2
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr4.1.1-2.1build1

-- no debconf information

Bug#1032427: xsane: Help>Show license does nothing

[Reuben Thomas]

Package: xsane
Version: 0.999-11ubuntu1
Severity: minor

When I select Help→Show license, nothing happens.

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-56-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xsane depends on:
ii  libc6   2.35-0ubuntu3.1
ii  libgimp2.0  2.10.30-1build1
ii  libglib2.0-02.72.4-0ubuntu1
ii  libgtk2.0-0 2.24.33-2ubuntu2
ii  libjpeg88c-2ubuntu10
ii  liblcms2-2  2.12~rc1-2build2
ii  libpng16-16 1.6.37-3build5
ii  libsane11.1.1-5
ii  libtiff54.3.0-6ubuntu0.3
ii  sensible-utils  0.0.17
ii  xsane-common0.999-11ubuntu1
ii  zlib1g  1:1.2.11.dfsg-2ubuntu9.2

Versions of packages xsane recommends:
ii  chromium-browser [www-browser]  1:110.0.5481.177-0ubuntu0.22.04.1sav0
ii  cups-client 2.4.1op1-1ubuntu4.1
ii  firefox-esr [www-browser]   102.8.0esr+build2-0ubuntu0.22.04.1
ii  links [www-browser] 2.25-1build1
ii  lynx [www-browser]  2.9.0dev.10-1
ii  w3m [www-browser]   0.5.3+git20210102-6ubuntu0.1

Versions of packages xsane suggests:
ii  gimp 2.10.30-1build1
ii  gocr 0.52-3
ii  gv   1:3.7.4-2
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr4.1.1-2.1build1

-- no debconf information

Bug#1032426: xsane: Help>About XSane crashes without opening a window

[Reuben Thomas]

Package: xsane
Version: 0.999-11ubuntu1
Severity: normal

If I select Help→About XSane, the application pauses for a couple of seconds
then crashes. (The changes in Ubuntu’s version are just to depend on a
different JPEG library, so I think it’s reasonable to file a bug here.)

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-56-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xsane depends on:
ii  libc6   2.35-0ubuntu3.1
ii  libgimp2.0  2.10.30-1build1
ii  libglib2.0-02.72.4-0ubuntu1
ii  libgtk2.0-0 2.24.33-2ubuntu2
ii  libjpeg88c-2ubuntu10
ii  liblcms2-2  2.12~rc1-2build2
ii  libpng16-16 1.6.37-3build5
ii  libsane11.1.1-5
ii  libtiff54.3.0-6ubuntu0.3
ii  sensible-utils  0.0.17
ii  xsane-common0.999-11ubuntu1
ii  zlib1g  1:1.2.11.dfsg-2ubuntu9.2

Versions of packages xsane recommends:
ii  chromium-browser [www-browser]  1:110.0.5481.177-0ubuntu0.22.04.1sav0
ii  cups-client 2.4.1op1-1ubuntu4.1
ii  firefox-esr [www-browser]   102.8.0esr+build2-0ubuntu0.22.04.1
ii  links [www-browser] 2.25-1build1
ii  lynx [www-browser]  2.9.0dev.10-1
ii  w3m [www-browser]   0.5.3+git20210102-6ubuntu0.1

Versions of packages xsane suggests:
ii  gimp 2.10.30-1build1
ii  gocr 0.52-3
ii  gv   1:3.7.4-2
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr4.1.1-2.1build1

-- no debconf information

Bug#1032173: identity recoding is too identical

[Reuben Thomas]

On Wed, 1 Mar 2023 at 01:33, Zefram  wrote:

>
> The invocation with both encodings the same superficially looks like
> it's requesting an identity transformation, and it would correctly have
> the behaviour of an identity transformation on input that were correctly
> encoded.  Because of the input checking that recode(1) usually provides,
> it seems like this kind of invocation would be useful, as something
> that copies its input while checking the encoding.  Apparently it's
> being optimised incorrectly, to a pure identity transformation without
> the checking.
>

I agree that this behaviour is undesirable. Unfortunately it's deep-seated.
I have done some work on it, but I don't yet have something I can release.

Here's the existing upstream issue:
https://github.com/rrthomas/recode/issues/37

-- 
https://rrt.sc3d.org

Bug#1030140: rsyslog: Property-basesd filters are prevented from working by systemd config

[Reuben Thomas]

On Wed, 1 Feb 2023 at 17:04, Michael Biebl  wrote:

> Am 31.01.23 um 16:05 schrieb Reuben Thomas:
> > Package: rsyslog
> > Version: 8.2112.0-2ubuntu2.2
>
> This appears to be an Ubuntu version not known in the Debian archive
>

Apologies.


> > Severity: normal
> >
> > In order to work around a bug in scanbd (#901695), I tried to add a
> > property-based filter as /etc/rsyslog.d/99-scanbd.conf:
> >
> > :msg, regex, "/usr/sbin/scanbd: abandon polling of"
> ^/usr/local/sbin/restart-scanbd
>
> What exactly does restart-scanbd do? Does it call systemctl?
>

Yes it does. I see what you're saying: it's running systemctl "recursively"
that causes the error? If so, sorry, I got confused.

-- 
https://rrt.sc3d.org

Bug#992024: Enthusiastic support

[Reuben Thomas]

I found this bug when I was about to file a WNPP bug myself. I just
installed AirSane from source on my Ubuntu system and was delighted by how
well it worked, and how easy it was.

-- 
https://rrt.sc3d.org

Bug#1030144: scanbd: systemd and inetd configurations clash

[Reuben Thomas]

Package: scanbd
Version: 1.5.1-6build1
Severity: important

When I first installed scanbd, I found that the systemd unit could not
start, because inetd was already listening on the scanbd port.

It seems to me that scanbd should only configure one of systemd or
inetd when it installs. In particular, scanbd depends on openbsd-inetd
| inet-superserver, so it forces the installation of some inetd, and
this will always happen.

In my case, I have inetd installed anyway, but only for one or two
legacy services that I have not yet migrated to a systemd
configuration.

Maybe it would be reasonable only to add active inetd configuration on
systems that aren't running systemd?

(Some more general feedback: I see in README.Debian for this package
that "a lot of work went into smoothening the scanbd experience on
Debian". For me, scanbd was a lot of work to get working; so, I am
very grateful for this work, but it seems there is more to do, in
particular to fix upstream bugs. If I can find time, I will look into
this myself; meanwhile, thanks very much for the packaging work,
without which I'm sure I would have given up altogether.)

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-58-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages scanbd depends on:
ii  init-system-helpers   1.62
ii  libc6 2.35-0ubuntu3.1
ii  libconfuse2   3.3-2
ii  libdbus-1-3   1.12.20-2ubuntu4.1
ii  libsane1  1.1.1-5
ii  libudev1  249.11-0ubuntu3.6
ii  lsb-base  11.1.0ubuntu4
ii  openbsd-inetd [inet-superserver]  0.20160825-5
ii  sane-utils1.1.1-5
ii  update-inetd  4.51

scanbd recommends no packages.

scanbd suggests no packages.

-- Configuration Files:
/etc/scanbd/scanner.d/pixma.conf changed [not included]

-- no debconf information

Bug#1030140: rsyslog: Property-basesd filters are prevented from working by systemd config

[Reuben Thomas]

Package: rsyslog
Version: 8.2112.0-2ubuntu2.2
Severity: normal

In order to work around a bug in scanbd (#901695), I tried to add a
property-based filter as /etc/rsyslog.d/99-scanbd.conf:

:msg, regex, "/usr/sbin/scanbd: abandon polling of" 
^/usr/local/sbin/restart-scanbd

The filter appeared to trigger correctly, but my program was not being
run.

In syslog, I found messages like this:

syslog:Jan 29 13:49:15 femur systemd[1]: rsyslog.service: Got notification 
message from PID 1608569, but reception only permitted for main PID 1608338

I had to add the following override stanza with 'sudo systemctl edit rsyslog':

[Service]
NotifyAccess=all

It may be that 'NotifyAccess=cgroup' would have sufficed;
unfortunately I didn't have time to test that.

It may be that for security reasons it is not possible to have
property-based filters working OOTB; in that case, it would be good to
document this and the configuration change required in
rsyslog.conf(5). If on the other hand it's OK to allow them, it would
be good to fix this functionality.

(As an aside, I also considered using the omprog output module to run
my program, but it seemed that this would feed all of rsyslog's output
to the program, which would then have to do its own matching, whereas
property-based filters did exactly what I wanted with much simpler
code at my end.)

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-58-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rsyslog depends on:
ii  adduser   3.118ubuntu5
ii  libc6 2.35-0ubuntu3.1
ii  libestr0  0.1.10-2.1build3
ii  libfastjson4  0.99.9-1build2
ii  libsystemd0   249.11-0ubuntu3.6
ii  libuuid1  2.37.2-4ubuntu3
ii  ucf   3.0043
ii  zlib1g1:1.2.11.dfsg-2ubuntu9.2

Versions of packages rsyslog recommends:
ii  logrotate  3.19.0-1ubuntu1.1

Versions of packages rsyslog suggests:
ii  apparmor  3.0.4-2ubuntu2.1
pn  rsyslog-doc   
pn  rsyslog-gssapi
pn  rsyslog-mongodb   
pn  rsyslog-mysql | rsyslog-pgsql 
pn  rsyslog-openssl | rsyslog-gnutls  
pn  rsyslog-relp  

-- Configuration Files:
/etc/logcheck/ignore.d.server/rsyslog [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/rsyslog'

-- no debconf information

Bug#901695: Bug does not appear to depend on device name changing; workaround suggested

[Reuben Thomas]

I am experiencing the same issue with a Canon 9000F scanner: when I switch
the scanner off then back on, scanbd fails to reconnect to it. The error
message is identical (mutans mutatis) to that in the logs posted here, but
in my case `scanimage -L` shows that the device name has not changed.

Nonetheless, sane is still returning SANE_STATUS_INVAL.

I have turned on debug output in scanbd, and looked at the source code, but
I can't see why the call to sane_open is succeeding the first time, but not
subsequently. It might be worth debugging inside libsane to make progress,
but I'd welcome assistance from experts!

For now, I added an rsyslog filter that runs a program to restart scanbd
whenever it logs an "abandon" message.

This in itself requires a few steps:

1. Compile the following C program, setuid, as
/usr/local/sbin/restart-scanbd:

#include 

int main (void)
{
  system ("sudo systemctl restart scanbd.service");
}

2. Write the rsyslog filter to execute it (/etc/rsyslog.d/99-scanbd):

:msg, regex, "/usr/sbin/scanbd: abandon polling of"
^/usr/local/sbin/restart-scanbd

3. Edit systemd's unit for rsyslog to add "NotifyAccess=all" (sudo
systemctl edit rsyslog), otherwise the filter doesn't get executed.

4. Run visudo and add the following to /etc/sudoers:

# Allow syslog to restart scanbd
syslog ALL=(root) NOPASSWD: /usr/bin/systemctl restart scanbd.service

It's a painful workaround, but for me it worked flawlessly.

-- 
https://rrt.sc3d.org

Bug#1030139: scanbd: Please allow MaxConnections=2 for scanbm.socket service

[Reuben Thomas]

Package: scanbd
Version: 1.5.1-6build1
Severity: normal

I am using the excellent AirSane (sadly unpackaged for Debian):
https://github.com/SimulPiscator/AirSane

In order to get it to work, I had to increase MaxConnections to 2 for the
scanbm.socket systemd unit file.

I am sorry, it took me about 8 hours of work to get scanbd functional (I
will be filing other bug reports that I hope are helpful), so I did not
investigate this issue further to work out exactly what the problem is; but
raising MaxConnections by 1 seems a fairly simple and low-risk workaround,
if indeed there is a bug somewhere here.

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-56-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages scanbd depends on:
ii  init-system-helpers   1.62
ii  libc6 2.35-0ubuntu3.1
ii  libconfuse2   3.3-2
ii  libdbus-1-3   1.12.20-2ubuntu4.1
ii  libsane1  1.1.1-5
ii  libudev1  249.11-0ubuntu3.6
ii  lsb-base  11.1.0ubuntu4
ii  openbsd-inetd [inet-superserver]  0.20160825-5
ii  sane-utils1.1.1-5
ii  update-inetd  4.51

scanbd recommends no packages.

scanbd suggests no packages.

Bug#1030137: build-rdeps: does not notice when dose-ceve is killed

[Reuben Thomas]

Package: devscripts
Version: 2.22.1ubuntu1
Severity: normal

I was puzzled by getting no results from build-rdeps; running with --debug did 
not help.

Finally, I ran the dose-ceve command manually, and found out that it was
being killed because it used more memory than the VM I was using had
allocated.

build-rdeps should check the return code of dose-ceve so that it can detect
this sort of problem and report an error.

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBSIGN_KEYID=24093F016FFE8602EF449BB84C8EF3DA3FD37230

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-56-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.1ubuntu2.1
ii  fakeroot  1.28-1ubuntu1
ii  file  1:5.41-3
ii  gnupg 2.2.27-3ubuntu2.1
ii  gpgv  2.2.27-3ubuntu2.1
ii  libc6 2.35-0ubuntu3.1
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.005004-3
ii  libwww-perl   6.61-1
ii  patchutils0.4.2-1build2
ii  perl  5.34.0-3ubuntu1.1
ii  python3   3.10.6-1~22.04
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2build3

Versions of packages devscripts recommends:
ii  apt2.4.8
ii  curl   7.81.0-1ubuntu1.7
ii  dctrl-tools2.24-3build2
ii  dput   1.1.0ubuntu2
ii  libdistro-info-perl1.1build1
ii  libdpkg-perl   1.21.1ubuntu2.1
ii  libencode-locale-perl  1.05-1.1
ii  libgit-wrapper-perl0.048-1
ii  libgitlab-api-v4-perl  0.26-1
ii  liblist-compare-perl   0.55-1
ii  libstring-shellquote-perl  1.04-1
ii  libtry-tiny-perl   0.31-1
ii  liburi-perl5.10-1
ii  licensecheck   3.2.14-2
ii  lintian2.114.0ubuntu1.2
ii  man-db 2.10.2-1
ii  patch  2.7.6-7build2
ii  python3-apt2.4.0
ii  python3-debian 0.1.43ubuntu1
ii  python3-magic  2:0.4.24-2
ii  python3-requests   2.25.1+dfsg-2
ii  python3-unidiff0.5.5-2
ii  python3-xdg0.27-2
ii  strace 5.16-0ubuntu3
ii  unzip  6.0-26ubuntu3.1
ii  wget   1.21.2-2ubuntu1
ii  xz-utils   5.2.5-2ubuntu1

Versions of packages devscripts suggests:
ii  adequate 0.15.6
ii  at   3.2.5-1ubuntu1
ii  autopkgtest  5.20ubuntu1
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-2build2
ii  build-essential  12.9ubuntu3
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.6ubuntu1
ii  debian-keyring   2021.12.24
pn  diffoscope   
pn  disorderfs   
ii  dose-extra   7.0.0-1build1
pn  duck 
pn  elpa-devscripts  
ii  equivs   2.3.1
pn  faketime 
ii  gnuplot  5.4.2+dfsg2-2
ii  gnuplot-x11 [gnuplot]5.4.2+dfsg2-2
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1.1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-2
ii  liblwp-protocol-https-perl   6.10-1
pn  libnet-smtps-perl
pn  libsoap-lite-perl
ii  libterm-size-perl0.211-1build1
ii  libtimedate-perl 2.3300-2
ii  libyaml-syck-perl1.34-1build2
pn  mmdebstrap   
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:8.9p1-3ubuntu0.1
ii  piuparts 1.1.5
pn  postgresql-client
pn  pristine-lfs 
ii  pristine-tar 1.49
ii  quilt0.66-2.1
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3+git20210102-6ubuntu0.1

-- no debconf information

Bug#1024789: xdg-utils: xdg-screensaver does not work on recent GNOME, and I have a fix

[Reuben Thomas]

Package: xdg-utils
Version: 1.1.3-4.1ubuntu3~22.04.1
Severity: important
Tags: patch upstream

I’m the upstream maintainer of Caffeine, and noticed that it was no longer
working on my GNOME 42 system.

Of course, the actual bug was in xdg-screensaver: until recently,
gnome-screensaver ran on GNOME systems, and xdg-screensaver used that. Now,
it needs to use the freedesktop DBus API.

Unfortunately, the freedesktop-related code in xdg-screensaver was also
buggy (at least, it didn’t match the DBus API spec).

Fortunately, the fix was easy, as the code used to handle gnome-screensaver
can. with small modifications, be used for a correct implementation.

I have provided the fix as a Merge Request to xdg-utils:
https://gitlab.freedesktop.org/xdg/xdg-utils/-/merge_requests/62

I am filing this bug report because I know that xdg-utils upstream is slow
(Debian already has a patch of mine in its packaging from 2016).

-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=GNOME

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-52-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.31-1
ii  libnet-dbus-perl   1.2.0-1build3
ii  libx11-protocol-perl   0.56-7.1
ii  x11-utils  7.7+5build2
ii  x11-xserver-utils  7.7+9build1

xdg-utils suggests no packages.

-- no debconf information

Bug#996894: colordiff: Error messages interrupt output

[Reuben Thomas]

Package: colordiff
Version: 1.0.18-1
Severity: normal

Error messages are not correctly interleaved with output; for example:

-Foo
diff: bar/baz.html+Bar
: No such file or directory

Here, the error message should say

diff: bar/baz.html: No such file or directory

but the (presumably stderr) line has been split in the middle, and
interleaved with the (presumably stdout) output.

I see that there’s a new version of colordiff 1.0.19, but the changelog does
not mention this issue.

Thanks for working on colordiff!

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0-37-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages colordiff depends on:
ii  perl  5.30.0-9ubuntu0.2

colordiff recommends no packages.

colordiff suggests no packages.

-- no debconf information

Bug#991340: ukui-polkit: Package description is hard to understand

[Reuben Thomas]

Package: ukui-polkit
Version: 1.2.1-1
Severity: normal

The package description doesn’t make sense:

“The ukui-polkit package supports general authentication and biometric
authentication that the service is provided by the biometric-auth package. “
   

The problem is the words I’ve highlighted. I suspect what’s intended is:

“The ukui-polkit package supports general authentication, and biometric
authentication provided by the biometric-auth package.”

But I’m not actually sure! It would be good if the description were
rewritten to be comprehensible.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-59-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ukui-polkit depends on:
ii  libc6  2.31-0ubuntu9.3
ii  libgcc-s1  10.3.0-1ubuntu1~20.04
ii  libpolkit-qt5-1-1  0.113.0-0ubuntu2
ii  libqt5core5a   5.12.8+dfsg-0ubuntu1
ii  libqt5dbus55.12.8+dfsg-0ubuntu1
ii  libqt5gui5 5.12.8+dfsg-0ubuntu1
ii  libqt5widgets5 5.12.8+dfsg-0ubuntu1
ii  libstdc++6 10.3.0-1ubuntu1~20.04
ii  policykit-10.105-26ubuntu1.1

ukui-polkit recommends no packages.

Versions of packages ukui-polkit suggests:
pn  biometric-auth  

Bug#149873: mmv: Options for dealing with this problem

[Reuben Thomas]

Thanks, Axel for your kind words, and also for your analysis.

I've had a look at renameutils, of which I was not aware, though I have it
installed on my machine already!

It seems to me that it covers interactive usage neatly, so I'd be happy to
remove that from mmv, retaining the -n flag, but removing the ability to
read renames from standard input.

-- 
https://rrt.sc3d.org

Bug#149873: mmv: Options for dealing with this problem

[Reuben Thomas]

Package: mmv
Version: 1.01b-19build1
Followup-For: Bug #149873

Hi, I’m the (new) upstream maintainer of mmv, and I would like to fix this 
problem.

Clearly, it is not possible to fix in a backwards-compatible way, so I see a 
few options:

1. Fix it in a backwards-incompatible way. For an interactive option, this
is not as bad as for a non-interactive option.

2. Deprecate the functionality.

3. Remove the functionality.

Looking at those options in reverse order:

3. I don’t think it’s a good idea to keep broken functionality if it’s
possible to remove it: it is a foot-gun, with which users will shoot
themselves in the foot. Fortunately, there is a replacement:

https://github.com/itchyny/mmv

This works in a different way: it is *always* interactive, and what it does
is dump the user into an editor, allow the user to do some editing
(typically search and replace), and then renames all the files whose names
have changed when the file is saved (matching them line by line). Unnamed
files are untouched.

The obvious problems are that i) this program is not (yet?) packaged in
Debian, and ii) its identical name (the author has previously refused to
change the name, but I have filed an issue asking whether an “official”
alternative name could be added).

2. This is basically the current situation: the functionality comes with a
nice pair of warnings in the man page. It would be possible to add a similar
warning in the code, so that for example when you use it it prints a
warning. Or one could add an annoying “danger” flag
--i-really-want-interactive-operation, and refuse to work without it. I
don’t find this satisfactory, though.

1. Fix the behaviour. The usual tactic in this situation is to use NUL
delimiters, but this won’t work here, because the output of mmv is designed
to be edited. I suggest the following record format:

\\OLD// => \\NEW//\n

The idea is that “//” never occurs in a valid fully canonicalized path, so
is an unambiguous delimiter. “\\” is used at the start for two reasons: i)
to form a visual bracket with “//”, and ii) to avoid visual confusion at the
start of an absolute path.

The record is still terminated with a newline (though in general it may
contain newlines). This allows other lines, in particular those starting
with spaces, to be ignored.

This is a somewhat laboured design, but if it’s correct it does at least
allow a solution that doesn’t involve using broken functionality, or having
to install a program that wants the same name and that works in a somewhat
different way.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-44-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mmv depends on:
ii  libc6  2.31-0ubuntu9.2

mmv recommends no packages.

mmv suggests no packages.

-- no debconf information

Bug#824223: dehydrated: Example cron script

[Reuben Thomas]

Package: dehydrated
Version: 0.6.5-1
Followup-For: Bug #824223

An example cron job script is provided by the hosting company Mythic Beasts
at: https://www.mythic-beasts.com/support/domains/letsencrypt_dns_01

/etc/cron.daily/dehydrated:
#!/bin/sh
exec /usr/bin/dehydrated -c >>/var/log/dehydrated-cron.log 2>&1

/etc/logrotate.d/dehydrated:
/var/log/dehydrated-cron.log
{
rotate 12
monthly
missingok
notifempty
delaycompress
compress
}

It would be great to see this functionality added to the Debian package!

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-44-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dehydrated depends on:
ii  ca-certificates  20210119~20.04.1
ii  curl 7.68.0-1ubuntu2.4
ii  openssl  1.1.1f-1ubuntu2.2

dehydrated recommends no packages.

dehydrated suggests no packages.

-- no debconf information

Bug#969473: Please don't close bugs automatically, move them to enchant 2

[Reuben Thomas]

Enchant 2 is just a new version of Enchant, only a separate package for
ease of transition, so please reassign bugs to it rather than mass closing.

(I'm the upstream maintainer!)

-- 
https://rrt.sc3d.org

Bug#980374: cron: English fix for crontab(5)

[Reuben Thomas]

Package: cron
Version: 3.0pl1-136ubuntu1
Severity: minor

[I checked this against other bugs, so I think it’s not already been
reported.]

The sentences:

  Please note that startup, as far as @reboot is concerned, is the time when
  the cron(8) daemon startup.
  In particular, it may be before some system daemons, or other facilities,
  were startup.

would be better written:

  Please note that startup, as far as @reboot is concerned, is the time when
  the cron(8) daemon starts up.
  In particular, it may be before some system daemons, or other facilities,
  are started.

In both sentences, it’s the text around “startup” that has been fixed.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-62-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cron depends on:
ii  adduser  3.118ubuntu2
ii  debianutils  4.9.1
ii  init-system-helpers  1.57
ii  libc62.31-0ubuntu9.1
ii  libpam-runtime   1.3.1-5ubuntu4.1
ii  libpam0g 1.3.1-5ubuntu4.1
ii  libselinux1  3.0-1build2
ii  lsb-base 11.1.0ubuntu2
ii  sensible-utils   0.0.12+nmu1

cron recommends no packages.

Versions of packages cron suggests:
ii  anacron 2.3-29
pn  checksecurity   
ii  logrotate   3.14.0-4ubuntu3
ii  postfix [mail-transport-agent]  3.4.13-0ubuntu1

Versions of packages cron is related to:
pn  libnss-ldap   
pn  libnss-ldapd  
pn  libpam-ldap   
pn  libpam-mount  
pn  nis   
pn  nscd  

-- no debconf information

Bug#976172: xfonts-utils: fonttosfnt gives error "Couldn't select character map"

[Reuben Thomas]

Package: xfonts-utils
Version: 1:7.7+6
Severity: normal

It seems that the call to FT_Select_Charmap at read.c:231 does not work for
some fonts, at least. I tried it with a Latin-1 encoded BDF font.

By default, fonttosfnt wants to reencode as Unicode, which is fine. Freetype
finds the Latin-1 encoding of the BDF font, and thus decides it needs to be
reencoded, although for some reason it records the charmap as Unicode (which
is fine, being a superset of Latin-1).

The logic at read.c:228 then tries to select the ft_encoding_none charmap,
which is only valid for bitmap fonts with no encoding (reading the freetype
source, ftobjs.c:3512). But this bitmap font has an encoding, so it is not
allowed.

I think the test at line 228 is bogus: for a symbol font (i.e. one that
declares no encoding) it’s OK to use ft_encoding_none. Otherwise, if we’re
recoding (i.e. we have a mapping) then we should use ft_encoding_unicode. If
we’re in neither case, then we should just use the existing charmap, i.e.
not call FT_Select_Charmap. Hence, this stanza should look something like:

rc = 0; // In case we do nothing
if(symbol)
rc = FT_Select_Charmap(face, ft_encoding_none);
else if(mapping)
rc = FT_Select_Charmap(face, ft_encoding_unicode);

Of course in my case, the selection of a Charmap is a no-op, since it merely
reselects the only charmap in the font.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-54-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfonts-utils depends on:
ii  libc6 2.31-0ubuntu9.1
ii  libfontenc1   1:1.1.4-0ubuntu1
ii  libfreetype6  2.10.1-2ubuntu0.1
ii  x11-common1:7.7+19ubuntu14
ii  xfonts-encodings  1:1.0.5-0ubuntu1
ii  zlib1g1:1.2.11.dfsg-2ubuntu1.2

xfonts-utils recommends no packages.

xfonts-utils suggests no packages.

-- no debconf information

Bug#976159: xfonts-utils: bdftopcf(1) documentation of some flags is misleading

[Reuben Thomas]

Package: xfonts-utils
Version: 1:7.7+6
Severity: normal

The -t and -i flags for bdftopcf are documented thus:

   -t  When this option is specified, bdftopcf will convert fonts into 
"terminal" fonts when possible.  A terminal
   font has each glyph image padded to the same size; the X server 
can usually render these types of fonts
   more quickly.

   -i  This option inhibits the normal computation of ink metrics.  
When a font has glyph images which do not fill
   the bitmap image (i.e., the "on" pixels don't extend to the 
edges of the metrics) bdftopcf computes the
   actual ink metrics and places them in the .pcf file; the -t 
option inhibits this behaviour.

However, looking at the source code bdftopcf.c, they are both parsed, but
ignored. I suggest changing the man page to read:

   -t, -i  Ignored.

Further, it may be worth patching the code, as currently it reads:

case 't':  /* attempt to make terminal fonts if possible */
if (argv[0][2] != '\0')
goto usage;
break;

case 'i':  /* inhibit ink metric computation */
if (argv[0][2] != '\0')
goto usage;
break;

It might make sense to add a “TODO:” at the start of each comment.

Further investigation might reveal that the flags used to do something, but
the above changes would at least help reduce confusion without prejudice to
(unlikely?) future improvements.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-54-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfonts-utils depends on:
ii  libc6 2.31-0ubuntu9.1
ii  libfontenc1   1:1.1.4-0ubuntu1
ii  libfreetype6  2.10.1-2ubuntu0.1
ii  x11-common1:7.7+19ubuntu14
ii  xfonts-encodings  1:1.0.5-0ubuntu1
ii  zlib1g1:1.2.11.dfsg-2ubuntu1.2

xfonts-utils recommends no packages.

xfonts-utils suggests no packages.

-- no debconf information

Bug#975056: libpodofo-utils: Typo in man page podofoimpose(1)

[Reuben Thomas]

Package: libpodofo-utils
Version: 0.9.6+dfsg-5build1
Severity: minor

The word “interpretor” should be “interpreter” everywhere.

Thanks for packaging PoDoFo!

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-52-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpodofo-utils depends on:
ii  libc6   2.31-0ubuntu9.1
ii  libgcc-s1   10.2.0-5ubuntu1~20.04
ii  liblua5.1-0 5.1.5-8.1build4
ii  libpodofo0.9.6  0.9.6+dfsg-5build1
ii  libssl1.1   1.1.1f-1ubuntu2
ii  libstdc++6  10.2.0-5ubuntu1~20.04

libpodofo-utils recommends no packages.

libpodofo-utils suggests no packages.

-- no debconf information

Bug#974945: Acknowledgement (xsane: Resolution of saved images does not match scan resolution)

[Reuben Thomas]

Having looked into this further, I think this may be a bug in the
proprietary lexmark_nscan backend: it provides an option --scan-resolution,
which is available in "Standard options", but (I am guessing) not the
standard "resolution" option. Therefore, xsane can't tell that it supports
different resolutions.

Feel free to close this bug, therefore.

-- 
https://rrt.sc3d.org

Bug#974945: xsane: Resolution of saved images does not match scan resolution

[Reuben Thomas]

Package: xsane
Version: 0.999-8ubuntu2
Severity: minor

The resolution of saved PNMs is hardwired to 72dpi. Is there a good reason
for that? If not, I would be happy to prepare a patch that sets the
resolution of the PNM to the scan resolution.

Similarly, and perhaps it is the same problem, it would be good if the
preview showed 100% at the same size regardless of the scan resolution.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-52-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xsane depends on:
ii  libc6   2.31-0ubuntu9.1
ii  libgimp2.0  2.10.18-1
ii  libglib2.0-02.64.3-1~ubuntu20.04.1
ii  libgtk2.0-0 2.24.32-4ubuntu4
ii  libjpeg88c-2ubuntu8
ii  liblcms2-2  2.9-4
ii  libpng16-16 1.6.37-2
ii  libsane 1.0.29-0ubuntu5.2
ii  libtiff54.1.0+git191117-2build1
ii  sensible-utils  0.0.12+nmu1
ii  xsane-common0.999-8ubuntu2
ii  zlib1g  1:1.2.11.dfsg-2ubuntu1.2

Versions of packages xsane recommends:
ii  cups-client2.3.1-9ubuntu1.1
ii  firefox [www-browser]  82.0.3+build1-0ubuntu0.20.04.1
ii  links [www-browser]2.20.2-1
ii  lynx [www-browser] 2.9.0dev.5-1
ii  w3m [www-browser]  0.5.3-37

Versions of packages xsane suggests:
ii  gimp 2.10.18-1
ii  gocr 0.52-3
ii  gv   1:3.7.4-2
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr4.1.1-2build2

-- no debconf information

Bug#970244: libx11-data: Some comments in en_US.UTF-8 confuse "UP TACK" and "DOWN TACK"

[Reuben Thomas]

Package: libx11-data
Version: 2:1.6.9-2ubuntu1.1
Severity: minor

In the following lines, “UP” should be “DOWN” and vice versa. U+22a5 is the
“UP TACK” and U+22a4 is the “DOWN TACK”. See e.g.

https://util.unicode.org/UnicodeJsps/character.jsp?a=22A4
https://util.unicode.org/UnicodeJsps/character.jsp?a=22A5

   5955:  : "⍊"   U234a   # _ ⊥ 
APL FUNCTIONAL SYMBOL DOWN TACK UNDERBAR
   5956:  : "⍊"   U234a   # ⊥ _ 
APL FUNCTIONAL SYMBOL DOWN TACK UNDERBAR
   5963:   : "⍎"   U234e   # ∘ ⊥ 
APL FUNCTIONAL SYMBOL DOWN TACK JOT
   5964:   : "⍎"   U234e   # ⊥ ∘ 
APL FUNCTIONAL SYMBOL DOWN TACK JOT
   5971:  : "⍑"   U2351   # ¯ ⊤ 
APL FUNCTIONAL SYMBOL UP TACK OVERBAR
   5972:  : "⍑"   U2351   # ⊤ ¯ 
APL FUNCTIONAL SYMBOL UP TACK OVERBAR
   5979:   : "⍕"   U2355   # ∘ ⊤ 
APL FUNCTIONAL SYMBOL UP TACK JOT
   5980:   : "⍕"   U2355   # ⊤ ∘ 
APL FUNCTIONAL SYMBOL UP TACK JOT
   6006:   : "⍡"   U2361   # ¨ ⊤ 
APL FUNCTIONAL SYMBOL UP TACK DIAERESIS
   6007:   : "⍡"   U2361   # ⊤ ¨ 
APL FUNCTIONAL SYMBOL UP TACK DIAERESIS


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-47-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#970203: xdg-screensaver: does not work on windows with no title or non-ASCII title

[Reuben Thomas]

Package: xdg-utils
Version: 1.1.3-2ubuntu1
Severity: normal
Tags: patch

Here is the upstream bug and patch: 
https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/98

Owing to the glacial rate of xdg-maintenance currently (and with thanks to
those currently trying to speed the process up!) it would be great if this
patch could be applied for the moment in Debian. In particular, it stops
Caffeine from working properly when a full-screen window has no title or a
non-ASCII title. (I’m the Caffeine upstream maintainer.)

-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=GNOME

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-47-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.29-1
ii  libnet-dbus-perl   1.2.0-1
ii  libx11-protocol-perl   0.56-7
ii  x11-utils  7.7+5
ii  x11-xserver-utils  7.7+8

xdg-utils suggests no packages.

-- no debconf information

Bug#964257: Correctly handle apostophes in English dictionaries

[Reuben Thomas]

Package: hunspell-en-us
Version: 1:2019.10.06-1
Followup-For: Bug #964257

It is worth noting that quotation marks are correctly handled by
hunspell-en-gb, which has a different source package
(libreoffice-dictionaries).

(I declare an interest as the upstream maintainer of the meta-spellchecker
Enchant, and as a contributor to Emacs’s ispell.el—as a result, I am getting
grief about this problem! :) )

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-42-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hunspell-en-us depends on:
ii  dictionaries-common  1.28.1

hunspell-en-us recommends no packages.

Versions of packages hunspell-en-us suggests:
ii  hunspell   1.7.0-2build2
pn  openoffice.org-hunspell | openoffice.org-core  

-- no debconf information

Bug#608013: recode h..us doesn't replace with ASCII equivalents

[Reuben Thomas]

 On Sun, 26 Dec 2010 07:58:49 +0800 jida...@jidanni.org wrote:
>
> I note that recode --force h..us causes » to disappear, when it
> could easily better make a >>, or " like uni2ascii -B.

In other words, doing something with `--force` can go wrong. Not a bug.

> OK, recode h..utf8|uni2ascii -B works.

And recoding to a charset that contains the relevant characters works.

Conclusion: there's no bug here.

Bug#754945: recode: A possible buffer overflow when the input filename is too long

[Reuben Thomas]

 On Thu, 12 Jan 2017 18:19:51 +0300 Alexander Gerasiov 
wrote:
> Package: recode
> Version: 3.6-23
> Followup-For: Bug #754945
>
> Another possible solution would be dinamically allocate buffer for
> output_name. Please see patch attached.

This is already done in recode 3.7.

Bug#607021: -k doesn't work (fwd)

[Reuben Thomas]

 This is fixed in current 3.7.7.

Bug#969388: debsums: Add bash completion

[Reuben Thomas]

Package: debsums
Version: 2.2.5
Severity: wishlist
Tags: patch

Here are bash completions for debsums. The implementation of
_comp_dpkg_installed_packages() is from dpkg’s bash completions; I don’t
know whether there’s a way to share them? Or, since
/usr/share/bash-completion/completions/dpkg is in the bash-completion
package, perhaps this bug would be better filed there?

_have grep-status && {
_comp_dpkg_installed_packages()
{
grep-status -P -e "^$1" -a -FStatus 'ok installed' -n -s Package
}
} || {
_comp_dpkg_installed_packages()
{
command grep -A 1 "Package: $1" /var/lib/dpkg/status 2>/dev/null | \
command grep -B 1 -Ee "ok installed|half-installed|unpacked| \
half-configured" \
-Ee "^Essential: yes" | \
awk "/Package: $1/ { print \$2 }" 2>/dev/null
}
}

_debsums()
{
local cur prev words cword
_init_completion || return

if [[ "$cur" == -* ]]; then
COMPREPLY=( $( compgen -W '$( _parse_help "$1" )' -- "$cur" ) )
else
COMPREPLY=( $(_comp_dpkg_installed_packages "$cur") )
fi
} &&
complete -F _debsums -o default debsums

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-42-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debsums depends on:
ii  libdpkg-perl  1.19.7ubuntu3
ii  libfile-fnmatch-perl  0.02-2build6
ii  perl  5.30.0-9build1
ii  ucf   3.0038+nmu1

debsums recommends no packages.

debsums suggests no packages.

-- Configuration Files:
/etc/debsums-ignore [Errno 2] No such file or directory: '/etc/debsums-ignore'

-- no debconf information

Bug#961136: recode: Consider switching upstream and package new version (3.7.1)?

[Reuben Thomas]

On Wed, 20 May 2020 at 16:24, Boyuan Yang  wrote:

> According to https://www.gnu.org/software/recode/ , the new upstream
> of package recode is now https://github.com/rrthomas/recode . GNU
> is no longer hosting this software. Please consider switching the
> upstream and package new version (3.7.1).
>

This is correct, and I'm "rrthomas"!

I'm also a DM, and happy to help get recode 3.7 (latest release 3.7.6) into
Debian.
-- 
https://rrt.sc3d.org

Bug#956881: enchant: Keep out of bullseye

[Reuben Thomas]

Upstream Enchant maintainer (and DM) here! I'm delighted to see the
transition is happening; if there are any problems with Enchant 2, I'm very
happy to help. I am not sure which Debian notifications I get about
Enchant, so if I seem to overlook something that could use my attention,
feel free to ping me directly.

Bug#952732: recode: Incorrect encoding of some characters when recoding to HTML_1.1

[Reuben Thomas]

On Fri, 28 Feb 2020 at 09:00, Paul Courbis BV 
wrote:

>* What was the outcome of this action?
>Incorrect HTML code :
>
>

As far as I can tell from looking at the code, these names are correct for
HTML 1.1. The new names are used in HTML 1.2 (
https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt) and later (and
recode generates them correctly for those versions too, though recode only
recognises version 2, not 1.2).

I'm afraid I can't find a spec for HTML 1.1 online; it seems to be so old
that it's not really considered a standard at all, and in any case there's
no reason to be using it. I'm reluctant to make any changes without
definitive documentation: looking at the code, this coding in recode has
not changed since recode 3.4 in 1994, and François Pinard was pretty
careful about this sort of thing (and both those letters are in his first
language).

-- 
https://rrt.sc3d.org

Bug#949851: systemd-cron: Typo in package description: "dirrectly" should be "directly"

[Reuben Thomas]

Package: systemd-cron
Version: 1.5.13-1
Severity: minor

In the package description: "dirrectly" should be "directly"

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-72-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd-cron depends on:
ii  libc6 2.27-3ubuntu1
ii  python3   3.6.7-1~18.04
ii  systemd-sysv  237-3ubuntu10.33

Versions of packages systemd-cron recommends:
ii  esmtp-run [mail-transport-agent]  1.2-15

systemd-cron suggests no packages.

Bug#940146: perforate FTCBFS: does not pass cross tools to make

[Reuben Thomas]

On Fri, 13 Sep 2019 at 05:33, Helmut Grohne  wrote:

> Source: perforate
> Version: 1.2-5.1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> perforate fails to cross build from source, because it does not pass
> cross tools to make. The easiest way of doing so - using dh_auto_build -
> makes perforate cross buildable. Please consider applying the attached
> patch.


Thanks for this. I'm currently trying to replace perforate with a new
version of the package, finddup: https://github.com/rrthomas/finddup/

Currently I'm stuck on trying to get the latest version uploaded to the NEW
queue; if by any chance someone could help with that, that would be great
(I'm a DM, not a DD). I did have some help before, but I've not been able
to get in touch with the DDs concerned in the last year.

-- 
https://rrt.sc3d.org

Bug#929000: sloccount: --autogen flag seems not to work

[Reuben Thomas]

Package: sloccount
Version: 2.26-5.2
Severity: normal

If I have files foo.py and foo.py.in, and run sloccount foo.py, I get no
lines counted. The same happens for foo.py.in (perhaps because sloccount
does not recognise “.in” as a language?).

So I try sloccount --autogen foo.py, but that still gives 0 lines.

I confirm that it seems to be the autogen detection that is in play by
removing foo.py.in, and rerunning sloccount foo.py: this now gives me a
non-zero count.

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-48-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sloccount depends on:
ii  libc6  2.27-3ubuntu1
ii  perl   5.26.1-6ubuntu0.3

sloccount recommends no packages.

Versions of packages sloccount suggests:
ii  doc-base  0.10.8

-- no debconf information

Bug#926988: gengetopt: Package long description is outdated

[Reuben Thomas]

Package: gengetopt
Version: 2.22.6+dfsg0-2
Severity: minor

Gengetopt does not generate a skeleton main.c (presumably it once did);
instead, it generates a command-line parser, and a header.

I suggest the following wording for the long description:

 gengetopt reads an interface description file, and writes a file containing
 a command-line parser function.  gengetopt supports: long and short options,
 11 types of parameters (including flag, int, double, string, and function
 call), and a usage message.

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-43-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gengetopt depends on:
ii  libc6   2.27-3ubuntu1
ii  libgcc1 1:8.2.0-1ubuntu2~18.04
ii  libstdc++6  8.2.0-1ubuntu2~18.04

gengetopt recommends no packages.

gengetopt suggests no packages.

-- no debconf information

Bug#920529: libtool: Please cherry-pick upstream commit f9970d99 to support -fuse-ld=

[Reuben Thomas]

Package: libtool
Version: 2.4.6-2
Severity: wishlist

Currently it’s not possible to use -fuse-ld=gold, for example, cleanly with
libtool. This upstream commit:

http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=f9970d99293faf908fdc153a653fa5781095fb7a

adds the requisite support.

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports'), (90, 'disco')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-43-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtool depends on:
ii  autotools-dev   20180224.1
ii  clang-6.0 [c-compiler]  1:6.0-1ubuntu2
ii  cpp 4:7.3.0-3ubuntu2.1
ii  file1:5.32-2ubuntu0.1
ii  gcc [c-compiler]4:7.3.0-3ubuntu2.1
ii  gcc-7 [c-compiler]  7.3.0-27ubuntu1~18.04
ii  gcc-8 [c-compiler]  8.2.0-1ubuntu2~18.04
ii  libc6-dev [libc-dev]2.27-3ubuntu1

Versions of packages libtool recommends:
ii  libltdl-dev  2.4.6-2

Versions of packages libtool suggests:
ii  autoconf 2.69-11
ii  automake [automaken] 1:1.15.1-3ubuntu2
ii  automake1.11 [automaken] 1:1.11.6-4
pn  gcj-jdk  
ii  gfortran 4:7.3.0-3ubuntu2.1
ii  gfortran-7 [fortran95-compiler]  7.3.0-27ubuntu1~18.04
ii  libtool-doc  2.4.6-2

-- no debconf information

Bug#916120: automake: "info automake" does not work (has to be "info automake-1.xx")

[Reuben Thomas]

Package: automake
Version: 1:1.15.1-3ubuntu2
Severity: minor

Running “info automake” does not work. It would be nice if the automake
package installed suitable links or whatever to the actual, versioned, info
file. (I understand that the existence of the automake1.11 package requires
the versioning and hence causes the original problem.)

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports'), (90, 'disco')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-39-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages automake depends on:
ii  autoconf   2.69-11
ii  autotools-dev  20180224.1

automake recommends no packages.

Versions of packages automake suggests:
ii  autoconf-doc   2.69-11
ii  gnu-standards  2010.03.11-1

-- no debconf information

Bug#907222: Preferences: Tracks>Spectrograms panel (only) does not respect GTK theme

[Reuben Thomas]

Package: audacity
Version: 2.2.1-1
Severity: normal

The Debian package seems to be patched to make Audacity work properly with
dark themes (thanks very much!).

Oddly, the Tracks>Spectrograms panel of Preferences still does not work in
this regard: the background comes up white with white text on my
Adwaita-dark–themed GNOME desktop. To be clear, all the other Preferences
panels come up as desired, with dark coloring.

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-32-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages audacity depends on:
ii  audacity-data   2.2.1-1
ii  libasound2  1.1.3-5ubuntu0.1
ii  libavcodec577:3.4.4-0ubuntu0.18.04.1
ii  libavformat57   7:3.4.4-0ubuntu0.18.04.1
ii  libavutil55 7:3.4.4-0ubuntu0.18.04.1
ii  libc6   2.27-3ubuntu1
ii  libexpat1   2.2.5-3
ii  libflac++6v51.3.2-1
ii  libflac81.3.2-1
ii  libgcc1 1:8-20180414-1ubuntu2
ii  libgdk-pixbuf2.0-0  2.36.11-2
ii  libglib2.0-02.56.1-2ubuntu1
ii  libgtk2.0-0 2.24.32-1ubuntu1
ii  libid3tag0  0.15.1b-13
ii  liblilv-0-0 0.24.2~dfsg0-1
ii  libmad0 0.15.1b-8ubuntu1
ii  libmp3lame0 3.100-2
ii  libogg0 1.3.2-1
ii  libportaudio2   19.6.0-1
ii  libportsmf0v5   0.1~svn20101010-5ubuntu1
ii  libsndfile1 1.0.28-4
ii  libsoundtouch1  1.9.2-3
ii  libsoxr00.1.2-3
ii  libstdc++6  8-20180414-1ubuntu2
ii  libsuil-0-0 0.10.0~dfsg0-1
ii  libtwolame0 0.3.13-3
ii  libvamp-hostsdk3v5  2.7.1~repack0-1
ii  libvorbis0a 1.3.5-4.2
ii  libvorbisenc2   1.3.5-4.2
ii  libvorbisfile3  1.3.5-4.2
ii  libwxbase3.0-0v53.0.4+dfsg-3
ii  libwxgtk3.0-0v5 3.0.4+dfsg-3

audacity recommends no packages.

Versions of packages audacity suggests:
ii  cmt [ladspa-plugin]  1.16-2
ii  ladspa-sdk [ladspa-plugin]   1.13-3ubuntu2
ii  mcp-plugins [ladspa-plugin]  0.4.0-6
ii  swh-plugins [ladspa-plugin]  0.4.17-2

-- no debconf information

Bug#639221: replace folding.el with elpa-folding

[Reuben Thomas]

On Mon, 25 Jun 2018, 23:47 Nicholas D Steeves,  wrote:

>
> Given that whatever we do will require a new source package in the
> archive, maybe it would be a good time to consider alternative folding
> addons?  Jaalto's project of course wins for backwards-compatibility ;-)


For my purposes, an alternative is fine.

In general I'm not sure there's much value in packaging Emacs lisp in
Debian, given the availability and ease of use of package.el and the
various package archives.

Bug#891636: latexmk: Please do upload this

[Reuben Thomas]

Package: latexmk
Version: 1:4.41-1
Followup-For: Bug #891636

It would be great to have this, as I am finding bugs in latexmk 4.41 that
are fixed since then, and already it is too late for Ubuntu 16.04. It would
be nice not to have to work around these bugs, or have to install a newer
version of latexmk manually, for too many more years!

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-36-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages latexmk depends on:
ii  perl5.22.1-9ubuntu0.2
ii  texlive-latex-base  2017.20170619-1~16.04.york0

Versions of packages latexmk recommends:
ii  evince [postscript-viewer]   3.18.2-1ubuntu4.3
ii  ghostscript [postscript-viewer]  9.18~dfsg~0-0ubuntu2.7
ii  mupdf [pdf-viewer]   1.7a-1
ii  okular [postscript-viewer]   4:15.12.3-0ubuntu1

Versions of packages latexmk suggests:
ii  ghostscript  9.18~dfsg~0-0ubuntu2.7

-- no debconf information

Bug#890019: zile testsuite fails with TERM=unknown

[Reuben Thomas]

On 10 February 2018 at 17:48, Axel Beckert <a...@debian.org> wrote:

> Hi Reuben,
>
> Reuben Thomas wrote:
> >​I just want to check, do you nonetheless consider this an upstream
> > bug?
>
> No. And my fix is adding "env TERM=vt100" debian/rules. :-)
>

​Thanks for the clarification!
​​

-- 
https://rrt.sc3d.org

Bug#890019: zile testsuite fails with TERM=unknown

[Reuben Thomas]

On 10 February 2018 at 09:52, Axel Beckert  wrote:

> Control: tag -1 + confirmed
>
> Hi Matthias,
>
> Matthias Klose wrote:
> > make  check-TESTS check-local
> > make[5]: Entering directory '/<>'
> > echo ./tests/*.el ./tests/interactive/*.el | abs_srcdir=/<>
> > srcdir=. TERM=unknown VALGRIND="" EMACSPROG="" xargs /usr/bin/perl
> > ./tests/run-lisp-tests.pl
> > make[6]: Entering directory '/<>'
> > Error opening terminal: unknown.
> > Zile failed to run test `backward-char' with error code 256
> > Error opening terminal: unknown.[...]
>
> This probably happens for a long time, but my try to make the build
> not garble my terminal during package build testing with "cat -v" had
> covered dh_auto_test's exit code. The latter is fixed now and hence
> test suite failures come to surface as they should
>
> Anyway, confirmed locally with
>
> $ env TERM=foobar debuild -uc -us
>
> > seen on the Ubuntu buildds.
>
> Interestingly not on Debian's buildds (except hurd-i386) nor in
> pbuilder (which AFAIK doesn't pass $TERM).
>
> Will add a fix.
>

​I just want to check, do you nonetheless consider this an upstream bug?
Should I recognise the value "unknown" as being equivalent to unset TERM?
The problem for me is that I don't want to override any setting from the
user: for example, it is nice if a user who builds from source gets the
tests run against the terminal they happen to be using.

-- 
https://rrt.sc3d.org

Bug#890019: zile testsuite fails with TERM=unknown

[Reuben Thomas]

On 10 February 2018 at 08:25, Matthias Klose  wrote:

> Package: src:zile
> Version: 2.4.14-5
>
> The zile tests apparently expect a working terminal. Please set it
> explicitly
> when running the tests, e.g. TERM=xterm.
>

​See tests/Makefile.am:

TERM ?= vt100

This suggests that it has been explicitly set in the environment to
"unknown".

Bug#888320: python2.7: Please supply Valgrind suppressions file

[Reuben Thomas]

Package: python2.7
Version: 2.7.12-1ubuntu0~16.04.3
Severity: minor

README.Valgrind, which is supplied (thanks) mentions valgrind-python.supp,
which I can’t find (it comes from the Misc/ directory of the sources).

This would be really handy to have installed in /usr/lib/valgrind for ease
of using Valgrind with Python on Debian.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-26-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python2.7 depends on:
ii  libpython2.7-stdlib  2.7.12-1ubuntu0~16.04.3
ii  mime-support 3.59ubuntu1
ii  python2.7-minimal2.7.12-1ubuntu0~16.04.3

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.26.1-1ubuntu1~16.04.6
ii  python2.7-doc  2.7.12-1ubuntu0~16.04.3

-- no debconf information

Bug#748984: Info received (recode: This would need some extra design and coding)

[Reuben Thomas]

I have made an issue for this in the Recode bug tracker:
https://github.com/rrthomas/Recode/issues/1

Bug#638144: Added to Recode bug tracker

[Reuben Thomas]

I have made an issue for this: https://github.com/rrthomas/Recode/issues/2

Bug#748984: recode: This would need some extra design and coding

[Reuben Thomas]

Package: recode
Version: 3.6-22
Followup-For: Bug #748984

The problem with fixing this is that currently recode effectively assumes
that the HTML input is ISO-8859-1 encoded; it has no notion of the encoding
separate from its being in HTML.

I’m not exactly sure, but it seems to me that HTML (and other similar
encodings such as LaTeX) should rather be surfaces.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-26-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages recode depends on:
ii  libc6   2.23-0ubuntu10
ii  librecode0  3.6-22

recode recommends no packages.

recode suggests no packages.

-- no debconf information

Bug#348909: recode: This is a problem with iconv's API

[Reuben Thomas]

Package: recode
Version: 3.6-22
Followup-For: Bug #348909

I looked into this bug. The problem starts with the fact that iconv returns
EILSEQ (invalid input) when in fact the input is simply untranslatable.

It is possible to diagnose this situation by running another conversion with
the output encoding the same as the input (so that it will always succeed on
valid input) at the same point.

Unfortunately, I can’t work out what to do next: in particular, there’s no C
API I can use in general to skip the valid but untranslatable character. (At
least, none I can see; ideas welcome!)

For now, I’ve implemented a partial workaround: untranslatable text is
detected, and one byte is skipped. The typical result is that invalid input
is diagnosed on the next step, resulting in the same problem as at present.

There are two possible workarounds:

1. Set abort_level to RECODE_UNTRANSLATABLE.
2. Don’t use iconv.

I have documented these.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-26-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages recode depends on:
ii  libc6   2.23-0ubuntu10
ii  librecode0  3.6-22

recode recommends no packages.

recode suggests no packages.

-- no debconf information

Bug#321437: recode: Seems to be fixed in 3.7

[Reuben Thomas]

Package: recode
Version: 3.6-22
Followup-For: Bug #321437

I just tested this with the upcoming 3.7, and it seems to be fixed.

I put the given text in a file foo.txt, then:

$ cat foo.txt|recode "utf8..iso-8859-1"
recode: Invalid input in step `UTF-8..ISO-8859-1'
$ cat foo.txt|recode -f "utf8..iso-8859-1"
Imports System
$ cat foo.txt|recode "utf8..utf16"|recode "utf16..iso-8859-1"
recode: Invalid input in step `UTF-16..ISO-8859-1'
$ cat foo.txt|recode "utf8..utf16"|recode -f "utf16..iso-8859-1"
Imports System

In other words, we now get the same result whether going directly from UTF-8
to ISO-8859-1 or via UTF-16.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-26-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages recode depends on:
ii  libc6   2.23-0ubuntu10
ii  librecode0  3.6-22

recode recommends no packages.

recode suggests no packages.

-- no debconf information

Bug#363502: closed by Debian FTP Masters <ftpmas...@ftp-master.debian.org> (Bug#877240: Removed package(s) from unstable)

[Reuben Thomas]

On 19 November 2017 at 20:46, Vincent Lefevre  wrote:

> BTW, since readline6 has been replaced by readline7: I have not tried
> readline7. If it has the same problem, then I suppose that this bug
> should be reopened and reassigned to readline7.
>

​My notes suggested that this bug was fixed in readline6, but I just tried
it and it's still present, so yes, you're right.​

​One of the other bindings I have is for "\C-w", which turns out (I had not
realised) to be one of the combinations that, bizarrely, one can bind to a
macro but not a command. Sigh…I've added this to the top of my todo list
(not that that means it'll get looked at soon, though!)

-- 
https://rrt.sc3d.org

Bug#363502: closed by Debian FTP Masters <ftpmas...@ftp-master.debian.org> (Bug#877240: Removed package(s) from unstable)

[Reuben Thomas]

Something has gone wrong here: the bug is in libreadline5 (which still
exists), not libreadline6 (which has been removed).

On 19 November 2017 at 01:00, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the libreadline6 package:
>
> #363502: libreadline6: Something is wrong with binding keys to functions
>
> It has been closed by Debian FTP Masters <ftpmas...@ftp-master.debian.org
> >.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters <
> ftpmas...@ftp-master.debian.org> by
> replying to this email.
>
>
> --
> 363502: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363502
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Debian FTP Masters <ftpmas...@ftp-master.debian.org>
> To: 363502-d...@bugs.debian.org, 556583-d...@bugs.debian.org,
> 574518-d...@bugs.debian.org, 577012-d...@bugs.debian.org,
> 591632-d...@bugs.debian.org, 608517-d...@bugs.debian.org,
> 701931-d...@bugs.debian.org, 737955-d...@bugs.debian.org,
> 761459-d...@bugs.debian.org, 773891-d...@bugs.debian.org,
> 783136-d...@bugs.debian.org, 840397-d...@bugs.debian.org,
> 848170-d...@bugs.debian.org, 857297-d...@bugs.debian.org,
> 877197-d...@bugs.debian.org
> Cc: readli...@packages.debian.org, readli...@packages.qa.debian.org
> Bcc:
> Date: Sun, 19 Nov 2017 00:58:12 +
> Subject: Bug#877240: Removed package(s) from unstable
> Version: 6.3-9+rm
>
> Dear submitter,
>
> as the package readline6 has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.
>
> For details on the removal, please see https://bugs.debian.org/877240
>
> The version of this package that was in Debian prior to this removal
> can still be found using http://snapshot.debian.org/.
>
> This message was generated automatically; if you believe that there is
> a problem with it please contact the archive administrators by mailing
> ftpmas...@ftp-master.debian.org.
>
> Debian distribution maintenance software
> pp.
> Scott Kitterman (the ftpmaster behind the curtain)
>
> -- Forwarded message --
> From: Reuben Thomas <r...@sc3d.org>
> To: Debian Bug Tracking System <sub...@bugs.debian.org>
> Cc:
> Bcc:
> Date: Wed, 19 Apr 2006 15:11:20 +0100
> Subject: libreadline5: Something is wrong with binding keys to functions
> Package: libreadline5
> Version: 5.1-7
> Severity: important
>
> In my .inputrc I have the following lines:
>
> "\M-n": history-search-forward
> "\M-p": history-search-backward
> "\C-u": kill-whole-line
>
> With readline 5.0 they work fine, but with 5.1 they don't work.
>
> Oddly, if I bind to macros, e.g.
>
> "\C-u": "foo"
>
> it works fine. Also, I can make the first two work by using
>
> "\en": history-search-forward
> "\ep": history-search-backward
>
> I can get some Ctrl-letter keys to work by doing things like:
>
> "\x1": kill-whole-line # binds C-a to kill-whole-line
>
> but \x15 does not work as expected (trying various codes indicates
> that most C-letters can be bound in this way, but a few can't).
>
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.12-hibernate
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
>
> Versions of packages libreadline5 depends on:
> ii  libc6 2.3.6-7GNU C Library: Shared
> libraries
> ii  libncurses5   5.5-1.1Shared libraries for terminal
> hand
> ii  readline-common   5.1-7  GNU readline and history
> libraries
>
> libreadline5 recommends no packages.
>
> -- no debconf information
>
>
>


-- 
https://rrt.sc3d.org

Bug#617242: mlmmj-make-ml does not ensure correct permissions for created files and directories

[Reuben Thomas]

On 6 November 2017 at 03:07, Chris Knadle  wrote:

> tag 617242 + moreinfo
> thanks
>
> Although this bug is very old I think it deserves are maintainer response.
>
> > I have my umask set to 0027. If I run mlmmj-make-ml with sudo, then
> > this umask is inherited, and used to create all the files and
> > directories for a new mailing list, which is wrong. The files and
> > directories should be explicitly chmodded to the correct permissions.
>
> The mlmmj package in Debian doesn't come with pre-configuration for a
> specific MTA, nor setting up a user for mlmmj, instead giving
> administrative guidance for basic setups with various MTAs, and allowing
> for more complex configurations by leaving ownership and permissions
> configuration to the administrator. As far as I can tell, the specific
> permissions for files in /var/spool/mlmmj/ likely differ depending on
> the specific setup used.
>

​To be honest, I don't think (it's a long time ago now, as you say) that
this had occurred to me.​

Do you believe there are specific permissions that always neeed to be
> used regardless of specific MTA and setup?
>

​No. However, it would be good to have some opinionated defaults.
Otherwise, this is just another hard-to-set-up package that requires lots
of reading and fiddling, one is not sure (unless one becomes an expert)
that it is set up properly, securely etc., and one gravitates towards
proprietary products or cloud offerings that are simply easier and make
this sort of thing Someone Else's Problem, which is a shame.


So for example​ having an out-of-the-box Postfix integration, along the
lines described above, would be great.


​Given that ​mlmmj is not itself opinionated, offering the choice of
essentially "unconfigured" or "opinionated setup integrated with other
commonly-used Debian  packages" seems like an excellent way to cover both
causal and expert use.

-- 
https://rrt.sc3d.org

Bug#405444: perforate: Zum already does this

[Reuben Thomas]

Package: perforate
Followup-For: Bug #405444

I’m a bit puzzled by this bug report, as zum already reports space saved.

However, it was out by a factor of (blksize / 512). This is fixed in the
upcoming release 2.0.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-32-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perforate depends on:
ii  libfile-slurp-perl .19-4
ii  libstring-shellquote-perl  1.03-1.2
ii  libyaml-perl   1.15-1

perforate recommends no packages.

perforate suggests no packages.

-- no debconf information

Bug#449602: perforate: Fixed in upcoming 2.0

[Reuben Thomas]

Package: perforate
Followup-For: Bug #449602

Thanks, I’ve adapted the patch and it will be in the next release.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-32-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perforate depends on:
ii  libfile-slurp-perl .19-4
ii  libstring-shellquote-perl  1.03-1.2
ii  libyaml-perl   1.15-1

perforate recommends no packages.

perforate suggests no packages.

-- no debconf information

Bug#412013: perforate: May be better in 2.0, but no specific fix

[Reuben Thomas]

Package: perforate
Followup-For: Bug #412013

The upcoming 2.0 version of zum uses cp, so it may work better.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-32-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perforate depends on:
ii  libfile-slurp-perl .19-4
ii  libstring-shellquote-perl  1.03-1.2
ii  libyaml-perl   1.15-1

perforate recommends no packages.

perforate suggests no packages.

-- no debconf information

Bug#294297: perforate: Not much zum can do here

[Reuben Thomas]

Package: perforate
Version: 1.2-5.1
Followup-For: Bug #294297

I don’t think there’s much zum can do: sparseness is not something that file
systems advertise. Putting the information in zum’s man page would
inevitably lead to its being incomplete and/or out of date.

zum is a low-level tool, so really should only be used with an understanding
of the underlying file system.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-32-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perforate depends on:
ii  libfile-slurp-perl .19-4
ii  libstring-shellquote-perl  1.03-1.2
ii  libyaml-perl   1.15-1

perforate recommends no packages.

perforate suggests no packages.

-- no debconf information

Bug#412005: perforate: Explanation of behavior with no command-line args

[Reuben Thomas]

Package: perforate
Version: 1.2-5.1
Followup-For: Bug #412005

To clear up the confusion: when given no command-line arguments, zum reads a
list of files to perforate from stdin.

This behavior will be documented in the next release. (However, I would
still be happy for a patch to perforate stdin, using the common syntax ‘zum
-’.)

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-32-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perforate depends on:
ii  libc6 2.23-0ubuntu9
ii  libjson-perl  2.90-1

perforate recommends no packages.

perforate suggests no packages.

-- no debconf information

Bug#412014: perforate: In fact, cp does perforate files, so no need for this

[Reuben Thomas]

Package: perforate
Followup-For: Bug #412014

cp does “perforate” files, even by default (see the --sparse option), so
there’s no need for this.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-32-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perforate depends on:
ii  libc6 2.23-0ubuntu9
ii  libjson-perl  2.90-1

perforate recommends no packages.

perforate suggests no packages.

-- no debconf information

Bug#566998: perforate: This bug is a misunderstanding combined with a misfeature

[Reuben Thomas]

Package: perforate
Version: 1.2-5
Followup-For: Bug #566998

The reason that finddup fails in this case is that it was run in verbose
mode (in two ways: first by passing the -v option, and secondly by passing
the -n option, which implies -v).

The verbose mode’s messages are sent to stdout, and so get into the output
file finddup.out.

finddup does not know how to parse this, so it doesn’t work properly when it
is run on that file.

Finally, the -o option does not take an argument; rather, the old output
must be supplied on stdin.

The following two commands work correctly, after the test setup given by the
reporter:

# finddup -d test > finddup.out
# finddup -o < finddup.out

To make it less likely to get into this mess, I’ve changed -v to print to
stderr in my recent improvements (shortly coming as version 1.3).

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-32-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perforate depends on:
ii  libc6  2.23-0ubuntu9

perforate recommends no packages.

perforate suggests no packages.

-- no debconf information

Bug#169437: xzgv: Fixed in 0.9.2

[Reuben Thomas]

Package: xzgv
Tags: fixed-upstream
Followup-For: Bug #169437

This is fixed in the upcoming 0.9.2, which adds “panoramic zoom”.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-30-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xzgv depends on:
ii  libc6   2.23-0ubuntu9
ii  libgdk-pixbuf2.0-0  2.32.2-1ubuntu1.2
ii  libglib2.0-02.48.2-0ubuntu1
ii  libgtk2.0-0 2.24.30-1ubuntu1.16.04.1
ii  libx11-62:1.6.3-1ubuntu2

xzgv recommends no packages.

xzgv suggests no packages.

Bug#869731: man-db: apropos does not work for directories found from PATH

[Reuben Thomas]

On 26 July 2017 at 00:05, Colin Watson  wrote:

>
> I think it might be worth revisiting the change in man-db 2.4.2-3 to
> turn off MAN_DB_CREATES, which means that man doesn't create databases
> that doesn't already exist (once the database exists, man should
> automatically keep it up to date, although other tools such as apropos
> won't necessarily).  I made that change in response to a variety of
> bugs, so it can't be simply reverted; but that was way back in 2003
> before a great deal of other improvements, so perhaps there are better
> ways to address those bugs now.
>

​Sounds good!​

Fair, but I think it would be better to fix the problem properly
> instead, since man-db does have at least part of the internal tooling
> required to do so.
>

​Absolutely.​

-- 
https://rrt.sc3d.org 

Bug#869731: man-db: apropos does not work for directories found from PATH

[Reuben Thomas]

On 25 July 2017 at 23:49, Colin Watson <cjwat...@debian.org> wrote:

> On Tue, Jul 25, 2017 at 11:24:18PM +0100, Reuben Thomas wrote:
> > I just noticed that man pages installed in ~/.local/share/man are not
> found
> > by apropos. This appears to be because there’s no database for this
> > directory. man finds the directory via the corresponding ~/.local/bin
> entry
> > in PATH. It would be nice if apropos worked too.
>
> Have you tried just running mandb as your user?  That should create a
> suitable database.
>

​That's great, thanks.​ However, the beauty of man itself is that it just
works.

mandb isn't automatically run when man pages are installed, so it doesn't.

​I can get nearly as good a result by adding a user cron job that runs
mandb daily (and I'll do that, because I'll forget about this problem!),
but that's still not as good as the way man simply works without any action
on my part.

> Since a workaround is to use man -K, how about defaulting -k to try
> > the -K method where no database or whatis file is found?
>
> -K searches rather a lot more of the page text than -k does, though, so
> will often give dramatically different results.
>

​In this case, it would simply give some results (only being run on
directories on which otherwise man would give up), which, I submit, is
better than no results.

-- 
https://rrt.sc3d.org <http://rrt.sc3d.org>

Bug#869731: man-db: apropos does not work for directories found from PATH

[Reuben Thomas]

Package: man-db
Version: 2.7.5-1
Severity: normal

I just noticed that man pages installed in ~/.local/share/man are not found
by apropos. This appears to be because there’s no database for this
directory. man finds the directory via the corresponding ~/.local/bin entry
in PATH. It would be nice if apropos worked too. Since a workaround is to
use man -K, how about defaulting -k to try the -K method where no database
or whatis file is found?

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-58-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages man-db depends on:
ii  bsdmainutils   9.0.6ubuntu3
ii  debconf [debconf-2.0]  1.5.58ubuntu1
ii  dpkg   1.18.4ubuntu1.2
ii  groff-base 1.22.3-7
ii  libc6  2.23-0ubuntu9
ii  libgdbm3   1.8.3-13.1
ii  libpipeline1   1.4.1-2
ii  zlib1g 1:1.2.8.dfsg-2ubuntu4.1

man-db recommends no packages.

Versions of packages man-db suggests:
ii  chromium-browser [www-browser]  59.0.3071.109-0ubuntu0.16.04.1291
ii  firefox [www-browser]   54.0+build3-0ubuntu0.16.04.1
ii  groff   1.22.3-7
ii  less481-2.1ubuntu0.2
ii  links [www-browser] 2.12-1
ii  lynx [www-browser]  2.8.9dev8-4ubuntu1
ii  w3m [www-browser]   0.5.3-26ubuntu0.1

-- debconf information:
  man-db/install-setuid: false
  man-db/auto-update: true

Bug#864486: xsane: XSane writes bogus icm_profile field in output

[Reuben Thomas]

Package: xsane
Version: 0.999-3ubuntu1
Severity: normal
Tags: patch

xsane doesn’t initialise the icm_profile field of Image_info structs, and
hence when saving edited images, it can write bogus information into this
field, which causes some readers to barf, e.g. gthumb can no longer read the
output files.

The patch below fixes this in the case that I tested, though there may well
be more.

--- xsane-0.999/src/xsane-save.c2017-06-09 11:23:51.0 +0100
+++ xsane-0.999-rrt/src/xsane-save.c2017-06-09 11:19:00.000587262 +0100
@@ -427,6 +427,8 @@
  char buf[TEXTBUFSIZE];
  int items_done;

+  memset(image_info, '\0', sizeof(Image_info));
+
   fgets(buf, sizeof(buf)-1, file);
   DBG(DBG_info, "filetype header :%s", buf);

---patch ends---

I guess this should go upstream, but upstream’s website appears to be years
out of date (it doesn’t mention release 0.999); I hope the package
maintainers have a better idea than I do how to upstream the fix (and of
course, perhaps improve it).

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-78-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xsane depends on:
ii  libc6 2.23-0ubuntu7
ii  libgimp2.02.8.16-1ubuntu1.1
ii  libglib2.0-0  2.48.2-0ubuntu1
ii  libgtk2.0-0   2.24.30-1ubuntu1
ii  libjpeg8  8c-2ubuntu8
ii  liblcms2-22.6-3ubuntu2
ii  libpng12-01.2.54-1ubuntu1
ii  libsane   1.0.25+git20150528-1ubuntu2.16.04.1
ii  libtiff5  4.0.6-1ubuntu0.2
ii  xsane-common  0.999-3ubuntu1
ii  zlib1g1:1.2.8.dfsg-2ubuntu4.1

Versions of packages xsane recommends:
ii  chromium-browser [www-browser]  58.0.3029.110-0ubuntu0.16.04.1281
ii  cups-client 2.1.3-4ubuntu0.2
ii  firefox [www-browser]   53.0.3+build1-0ubuntu0.16.04.2
ii  links [www-browser] 2.12-1
ii  lynx [www-browser]  2.8.9dev8-4ubuntu1
ii  w3m [www-browser]   0.5.3-26ubuntu0.1

Versions of packages xsane suggests:
ii  gimp 2.8.16-1ubuntu1.1
ii  gocr 0.49-2
ii  gv   1:3.7.4-1
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr3.04.01-4

-- no debconf information

Bug#862972: xsane: Typo in Preferences>Copy dialog

[Reuben Thomas]

Package: xsane
Version: 0.999-5
Severity: minor
Tags: patch

“Paper geometrie” → “Paper geometry”

[In case the Version: header looks suspicious: I’m running 0.999-3ubuntu1,
but I checked that this typo remains unfixed in the current 0.999-5.]

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-77-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xsane depends on:
ii  libc6 2.23-0ubuntu7
ii  libgimp2.02.8.16-1ubuntu1.1
ii  libglib2.0-0  2.48.2-0ubuntu1
ii  libgtk2.0-0   2.24.30-1ubuntu1
ii  libjpeg8  8c-2ubuntu8
ii  liblcms2-22.6-3ubuntu2
ii  libpng12-01.2.54-1ubuntu1
ii  libsane   1.0.25+git20150528-1ubuntu2.16.04.1
ii  libtiff5  4.0.6-1ubuntu0.1
ii  xsane-common  0.999-3ubuntu1
ii  zlib1g1:1.2.8.dfsg-2ubuntu4.1

Versions of packages xsane recommends:
ii  chromium-browser [www-browser]  58.0.3029.110-0ubuntu0.16.04.1281
ii  cups-client 2.1.3-4ubuntu0.2
ii  firefox [www-browser]   53.0.2+build1-0ubuntu0.16.04.2
ii  links [www-browser] 2.12-1
ii  lynx [www-browser]  2.8.9dev8-4ubuntu1
ii  w3m [www-browser]   0.5.3-26ubuntu0.1

Versions of packages xsane suggests:
ii  gimp 2.8.16-1ubuntu1.1
ii  gocr 0.49-2
ii  gv   1:3.7.4-1
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr3.04.01-4

-- no debconf information

Bug#849517: The valgrind diagnostic is a false positive

[Reuben Thomas]

On 14 April 2017 at 13:47, Florian Weimer <f...@deneb.enyo.de> wrote:

> * Reuben Thomas:
>
> > ​A workaround is to build bash with --without-bash-malloc (but I presume
> > there's a good reason not to do that?).​
>
> FWIW, Fedora and Red Hat Enterprise Linux compile bash this way, so it
> can't be *that* bad.
>

​I hadn't appreciated that. It would seem to be a good way to fix this
problem and also avoid any bugs in bash's malloc; presumably the
performance hit is of relatively little interest given that bash is no
longer the default /bin/sh.

-- 
http://rrt.sc3d.org

Bug#849517: Alternative fix

[Reuben Thomas]

A Valgrind maintainer pointed out that an alternative to disabling bash's
malloc is to configure bash with CPPFLAGS=-DDISABLE_MALLOC_WRAPPERS=1. This
disable the debugging wrappers that confuse valgrind.

I guess it's still preferable not to do that. The obvious alternative is to
ship either bash or valgrind with a suppression for this.

If a maintainer would express an opinion on what a reasonable solution
would be, and would like any help implementing it, I'd be happy to assist!

-- 
http://rrt.sc3d.org

Bug#849517: The valgrind diagnostic is a false positive

[Reuben Thomas]

See:

https://bugs.kde.org/show_bug.cgi?id=378732
https://lists.gnu.org/archive/html/bug-bash/2017-04/msg00042.html

​The problem, in short, is that valgrind does not intercept the malloc call
(which is made via bash's built-in malloc), but does intercept the free
call, and hence concludes that the free is invalid.

​A workaround is to build bash with --without-bash-malloc (but I presume
there's a good reason not to do that?).​

-- 
http://rrt.sc3d.org

Bug#713051: bash: in /etc/skel/.bashrc, check if bash_completion has already run before

[Reuben Thomas]

Package: bash
Version: 4.4-4
Followup-For: Bug #713051

This bug report is correct, however, the situation is a little more
complicated.

/etc/profile.d/bash_completion.sh already contains code that checks whether
bash_completion has already run. Hence, there should be no need to uncomment
the code in /etc/bash.bashrc.

However, /etc/profile.d/bash_completion.sh does not load bash_completion if
the current bash is non-interactive. Thus, it depends how your login shell
is set up whether bash_completion is loaded at this stage or not: in a
console login it is loaded, whereas at least on my systemd/GNOME
combination, it is not (it was previously loaded when upstart was in charge
rather than systemd).

It would be nice to simplify the setup. Fortunately, it only involves two
packages: bash supplies /etc/bash.bashrc and /etc/skel/.bashrc, and
bash-completion supplies /etc/profile.d/bash_completion.sh.

This file /etc/profile.d/bash_completion.sh does everything that is
required: it checks that the bash running is new enough, that it is being
run interactively, and that bash_completion has not already been run.

Therefore, it seems to me the logical thing to do is always to call this
file.

Hence, the simplest fix seems to me to replace the code in /etc/bash.bashrc
and in /etc/skel/.bashrc with something like the following (I give the
/etc/skel version, where the code is uncommented, and have added a phrase to
the comment to note that it may not run from /etc/profile):

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc in an interactive shell).
if [ -f /etc/profile.d/bash_completion.sh ]; then
. /etc/profile.d/bash-completion.sh
fi

This has another advantage: it also checks for user-overridden
bash_completion in XDG_CONFIG_HOME.

As a consequence, the script should arguably be moved to
/usr/share/bash-completion and suitably renamed, but that’s a matter for the
bash-completion package.


There is another question which is a matter for the bash-completion package:
since bash-completion is only useful in interactive shells, why not remove
the /etc/profile script? The current default is to have the code commented
out in /etc/bash.bashrc, which is fine, because, as I observed above, the
default systemd/GNOME combination won’t run it anyway, and to have
bash_completion loaded by default in .bashrc, which again is fine, because
it’s needed there, and also desirable.

If this simplification is not adopted, then the comment above should be
expanded to mention /etc/profile.d/bash_completion, as otherwise users
administering their own machines may be confused that, for example in a
console login, bash-completion is active even if disabled in both ~/.bashrc
and /etc/bash.bashrc.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-67-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bash depends on:
ii  base-files   9.4ubuntu4.4
ii  dash 0.5.8-2.1ubuntu2
ii  debianutils  4.7
ii  libc62.23-0ubuntu5
ii  libtinfo56.0+20160213-1ubuntu1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.2ubuntu1.1

Versions of packages bash suggests:
ii  bash-doc  4.3-14ubuntu1.1

-- no debconf information

Bug#856464: xdg-utils: Remove hard-wired fallbacks

[Reuben Thomas]

Package: xdg-utils
Version: 1.1.1-1ubuntu1.16.04.1
Severity: normal

See https://bugs.freedesktop.org/show_bug.cgi?id=98509

The upstream maintainer of xdg-utils doesn’t think hard-wired fallbacks are
useful for upstream, and this seems sensible. Perhaps they should be removed
from the Debian patches as well, therefore?

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-59-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
ii  libfile-mimeinfo-perl  0.27-1
ii  libnet-dbus-perl   1.1.0-3build1
ii  libx11-protocol-perl   0.56-7
ii  x11-utils  7.7+3
ii  x11-xserver-utils  7.7+7

Versions of packages xdg-utils suggests:
ii  gvfs-bin  1.28.2-1ubuntu1~16.04.1

-- no debconf information

Bug#695179: psnup(1) has a confusing bit

[Reuben Thomas]

On 21 January 2017 at 19:36, Ian Jackson 
wrote:

>
> In the absence of time to fix this properly by listing the available
> units I have at least dropped the confusing sentence.
>

​I have since become upstream, and have rewritten the documentation. I need
to do a bit more work (of indeterminate wall-clock duration), so this fix
is appreciated (thanks!), but I should eventually have a Debian-ready
rewrite.

-- 
http://rrt.sc3d.org

Bug#809801: dailystrips: Correction to last update

[Reuben Thomas]

Package: dailystrips
Version: 1.0.28-11
Followup-For: Bug #809801

Apologies, my last update didn’t actually work.

Here is a corrected version, which should also be more robust:

class gocomics-srch
homepage http://www.gocomics.com/$strip/
searchpage http://www.gocomics.com/$strip/%Y/%m/%d
type search
searchpattern 

Bug#809801: dailystrips: Further update

[Reuben Thomas]

Package: dailystrips
Version: 1.0.28-11
Followup-For: Bug #809801

The gocomics web site appears to have changed again. Here is a new
gocomics-srch class definition; as before, only tested for Doonesbury.

class gocomics-srch
homepage http://www.gocomics.com/$strip/
searchpage http://www.gocomics.com/$strip/%Y/%m/%d
type search
searchpattern 

Bug#801067: Bug still present in nfs-utils 1.3.4-1

[Reuben Thomas]

The README.Debian.nfsv4 file is now ten years old. My previous comments
apply, only more so (owing to the passing of time).

-- 
http://rrt.sc3d.org

Bug#796938: Bug still present in nfs-utils 1.3.4-1

[Reuben Thomas]

This bug is still present, and the fix I give will still work.

-- 
http://rrt.sc3d.org

Bug#725910: colormake: man page refers to non-existent configuration file

[Reuben Thomas]

On 29 November 2016 at 20:04, Ludovic Rousseau <ludovic.rouss...@free.fr>
wrote:

> On Wed, 09 Oct 2013 23:54:23 +0100 Reuben Thomas <r...@sc3d.org> wrote:
>
>> Package: colormake
>> Version: 0.9-1
>> Severity: minor
>>
>> colormake(1) refers to /usr/share/colormake/colormake.rc, which does not
>> exist.
>>
>
> Exact.
> This file is not installed by the Debian package. The file also does not
> exist in the upstream tarball.
>
> The idea is that the admin can _create_ this file so the same
> configuration will be used, by default, for all the system users.
> The syntax is the same as for ~/.colormakerc
>
> How do you propose to solve this bug?
>

​I hadn't read the man page closely enough to realise that this is a
configuration file, thanks!

​A system-wide configuration file should surely be under /etc, not under
/usr/share. So I would propose to solve the bug by moving the file. I guess
this is an upstream bug?​

-- 
http://rrt.sc3d.org

Bug#840793: emacsen-common: Making of symlinks to debian-startup.el breaks emacs-snapshot

[Reuben Thomas]

Package: emacsen-common
Version: 2.0.8
Severity: normal

The problem is these lines in
/usr/lib/emacsen-common/packages/install/emacsen-common:

(cd /usr/share/${FLAVOR}/site-lisp
  ln -s ../../emacs/site-lisp/debian-startup.el .)

The use of ../.. assumes that the Emacs installation is in /usr.

There's a useful setup for installing Emacs from source but
integrating it with Debian, which I maintain:

https://github.com/rrthomas/src-emacs-on-debian

This package assumes that Emacs is installed from source in /usr/local
(as is only sensible, don't want it trampling over alternatives in
/usr/bin etc.!).

However, this causes the above code to make broken links.

The obvious fix is to make the relative path absolute (refer to
/usr/share...), but I don't know whether that would cause other
problems (I tested it, and it didn't seem to!). This fix would involve
replacing the above two lines with:

ln -s /usr/share/emacs/site-lisp/debian-startup.el 
/usr/share/${FLAVOR}/site-lisp/

There's no problem with the other relative symlink, just above the one
I quote, to /etc/${FLAVOR}/site-start.d, as emacs-snapshot ensures
that /etc, not /usr/local/etc, is used.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-38-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#833191: offlineimap: Please add default value of sslcacertfile

[Reuben Thomas]

On 8 September 2016 at 12:14, Ilias Tsitsimpis 
wrote:

>
> Currently, the man page does not document any of the available options
> in the configuration file. These are documented in the example file:
> /usr/share/doc/offlineimap/examples/offlineimap.conf.gz
>
> Maybe we could create an offlineimaprc man page, that would document the
> above options
> ​.
>

​It might be simpler and better simply to add a pointer to the examples
file to the man page.

-- 
http://rrt.sc3d.org

Bug#833191: offlineimap: Please add default value of sslcacertfile

[Reuben Thomas]

On 8 September 2016 at 11:48, Ilias Tsitsimpis 
wrote:

>
> I am afraid this cannot be done easily, because OfflineIMAP distinguish
> between sslcacertfile having and not having a value.
>

[snip]​

This means that if Debian provides a default value for the
> sslcacertfile, then it is not possible to connect to a server without
> verifying its certificate (and thus rendering the cert_fingerprint
> option obsolete).
>

​Is it not possible for the user to unset sslcacertfile?

If that were necessary in order to use just cert_fingerprint, that would be
an extra signal to the user that they are making their setup potentially
less secure.
​​

> That said, OfflineIMAP provides the special value OS-DEFAULT for the
> sslcacertfile option which will automatically determine the system-wide
> location of the standard trusted CA roots file.
>

​That's a help, thanks (I've used it); perhaps it could be documented in
the man page?​

-- 
http://rrt.sc3d.org

Bug#682031: unison: Bash completion does not work

[Reuben Thomas]

Package: unison-gtk
Version: 2.48.3-1
Followup-For: Bug #682031

Update to my previous message:

1. I see after purging and reinstalling the package that the bash-completion
file is indeed installed in /usr/share/bash-completion/completions/ , so my
finding it in /etc/bash_completions.d appears to be a minor upgrade bug (I
don’t propose to file a report for that).

2. However, the completions file is still not loaded: it should not be
placed in a unison-gtk subdirectory of the completions directory.

3. Finally, the previous points about completing unison and unison-gtk still
hold; in fact, there’s another case I didn’t catch before, namely
unison-2.MAJORVERSION-gtk; that is, currently unison-2.48-gtk.

Thus, for the current version of unison-gtk, the last line of the
completions file should be something like:

complete -o plusdirs -F _unison_2_48_3_gtk unison-2.48.3-gtk unison-2.48-gtk 
unison-gtk unison

Similarly, in the unison completions file, a line such as

complete -o plusdirs -F _unison_2_48_3 unison-2.48.3 unison-2.48 unison

will be needed.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-31-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unison-gtk depends on:
ii  libc6   2.23-0ubuntu3
ii  libgdk-pixbuf2.0-0  2.32.2-1ubuntu1
ii  libglib2.0-02.48.1-1~ubuntu16.04.1
ii  libgtk2.0-0 2.24.30-1ubuntu1
ii  libpango-1.0-0  1.38.1-1

Versions of packages unison-gtk recommends:
ii  openssh-client [ssh-client]  1:7.2p2-4ubuntu1
ii  ssh-askpass-gnome [ssh-askpass]  1:7.2p2-4ubuntu1

Versions of packages unison-gtk suggests:
pn  unison-all-gtk  

-- no debconf information

Bug#833191: offlineimap: Please add default value of sslcacertfile

[Reuben Thomas]

Package: offlineimap
Version: 6.6.1+dfsg1-2
Severity: wishlist

As a bit of Debian integration, it would seem reasonable to add a default
value for sslcacertfile (/etc/ssl/certs/ca-certificates.crt).

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-31-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages offlineimap depends on:
ii  python-imaplib2  2.53-1
pn  python:any   

Versions of packages offlineimap recommends:
ii  python-socks  1.5.0+dfsg-4

Versions of packages offlineimap suggests:
ii  doc-base 0.10.7
pn  python-kerberos  

-- no debconf information

Bug#642486: Acknowledgement (libgc-dev: Valgrind suppressions for libgc)

[Reuben Thomas]

[​Apologies for not replying to comments on this bug sooner; for some
reason I'm not getting emails about it.]

I have tested "valgrind inkscape" with the *original* suppressions I
supplied, and they work fine with inkscape 0.91/valgrind 3.11.0: inkscape
starts up and runs.

If I run without the suppressions I get lots of errors as before.

I wonder whether David's problem really was a stack overflow as suggested
by valgrind? I didn't look at memory consumption, but I have quite a lot
and a reasonably fast machine, and inkscape took over a minute to start.

Hence, I still suggest these suppressions be added to the libgc package!

Bug#814552: chromium-browser: Please allow spelling to use user’s word lists

[Reuben Thomas]

Package: chromium-browser
Version: 48.0.2564.82-0ubuntu0.14.04.1.1108
Severity: normal

Chromium, like many other Debian programs, uses hunspell for spelling.
However, unlike most other apps that use hunspell directly or indirectly
(e.g. Firefox, Pidgin, LibreOffice), Chromium uses a custom personal word
list format, and hence can’t share a per-user word list. (The other programs
mentioned can simply have their user wordlist file symlinked to a single
file, e.g. ~/.hunspell_en_GB.)

Would it be possible to patch Chromium to integrate it better with Debian in
this respect?

-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (100, 'trusty-backports'), (90, 'xenial-updates'), (90, 'xenial')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chromium-browser depends on:
ii  bash  4.3-7ubuntu1.5
ii  chromium-codecs-ffmpeg-extra  48.0.2564.82-0ubuntu0.14.04.1.1108
ii  dpkg  1.17.5ubuntu5.5
ii  gconf-service 3.2.6-0ubuntu2
ii  libasound21.0.27.2-3ubuntu7
ii  libatk1.0-0   2.10.0-2ubuntu2
ii  libc6 2.19-0ubuntu6.6
ii  libcairo2 1.13.0~20140204-0ubuntu1.1
ii  libcomerr21.42.9-3ubuntu1.3
ii  libcups2  1.7.2-0ubuntu1.7
ii  libdbus-1-3   1.6.18-0ubuntu4.3
ii  libexpat1 2.1.0-4ubuntu1.1
ii  libfontconfig12.11.0-0ubuntu4.1
ii  libfreetype6  2.5.2-1ubuntu2.5
ii  libgcc1   1:4.9.3-0ubuntu4
ii  libgconf-2-4  3.2.6-0ubuntu2
ii  libgcrypt11   1.5.3-2ubuntu4.2
ii  libgdk-pixbuf2.0-02.30.7-0ubuntu1.2
ii  libglib2.0-0  2.40.2-0ubuntu1
ii  libgnome-keyring0 3.8.0-2
ii  libgssapi-krb5-2  1.12+dfsg-2ubuntu5.2
ii  libgtk2.0-0   2.24.23-0ubuntu1.3
ii  libk5crypto3  1.12+dfsg-2ubuntu5.2
ii  libkrb5-3 1.12+dfsg-2ubuntu5.2
ii  libnspr4  2:4.10.10-0ubuntu0.14.04.1
ii  libnspr4-0d   2:4.10.10-0ubuntu0.14.04.1
ii  libnss3   2:3.19.2.1-0ubuntu0.14.04.2
ii  libpam0g  1.1.8-1ubuntu2
ii  libpango-1.0-01.36.3-1ubuntu1.1
ii  libpangocairo-1.0-0   1.36.3-1ubuntu1.1
ii  libpangoft2-1.0-0 1.36.3-1ubuntu1.1
ii  libstdc++65.2.1-15ubuntu1
ii  libx11-6  2:1.6.2-1ubuntu2
ii  libxcomposite11:0.4.4-1
ii  libxcursor1   1:1.1.14-1
ii  libxdamage1   1:1.1.4-1ubuntu1
ii  libxext6  2:1.3.2-1ubuntu0.0.14.04.1
ii  libxfixes31:5.0.1-1ubuntu1.1
ii  libxi62:1.7.1.901-1ubuntu1.1
ii  libxrandr22:1.4.2-1
ii  libxrender1   1:0.9.8-1build0.14.04.1
ii  libxss1   1:1.2.2-1
ii  libxtst6  2:1.2.2-1
ii  xdg-utils 1.1.0~rc1-2ubuntu7.1
ii  zlib1g1:1.2.8.dfsg-1ubuntu1

Versions of packages chromium-browser recommends:
ii  chromium-browser-l10n  48.0.2564.82-0ubuntu0.14.04.1.1108

Versions of packages chromium-browser suggests:
pn  adobe-flashplugin   
pn  unity-chromium-extension
pn  webaccounts-chromium-extension  

-- Configuration Files:
/etc/chromium-browser/default changed [not included]
/etc/default/chromium-browser [Errno 2] No such file or directory: 
u'/etc/default/chromium-browser'

-- no debconf information

Bug#784224: dailystrips: Slight simplification of xkcd

[Reuben Thomas]

Package: dailystrips
Version: 1.0.28-11
Followup-For: Bug #784224

I noticed I had a redundant “searchpage” setting in my previous definition.

strip xkcd
name xkcd
homepage http://xkcd.com/
type search
baseurl http://imgs.xkcd.com
searchpattern 

Bug#809801: dailystrips: Update to doonesbury

[Reuben Thomas]

Package: dailystrips
Version: 1.0.28-11
Severity: normal

Here’s an updated definition:

class gocomics-srch
homepage http://www.gocomics.com/$strip/
searchpage http://www.gocomics.com/$strip/%Y/%m/%d
type search
searchpattern 

Bug#809931: org-mode: Correction to report

[Reuben Thomas]

Package: org-mode
Version: 8.3.2-1
Followup-For: Bug #809931

The correct value for org-odt-data-dir is actually

/usr/share/emacs/site-lisp/org-mode/etc

(not …/styles as I previously said).

-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (100, 'trusty-backports'), (90, 'xenial-updates'), (90, 'xenial')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages org-mode depends on:
ii  emacs24 24.4+1-4ubuntu1
ii  emacsen-common  2.0.8

Versions of packages org-mode recommends:
ii  texlive-generic-recommended  2015.20151116-1ubuntu1
ii  texlive-latex-recommended2015.20151116-1ubuntu1

Versions of packages org-mode suggests:
pn  ditaa  
ii  texlive-fonts-recommended  2015.20151116-1ubuntu1
ii  texlive-latex-extra2015.20151225-2

-- no debconf information

Bug#809931: org-mode: org-odt-data-dir is incorrectly set

[Reuben Thomas]

Package: org-mode
Version: 8.3.2-1
Severity: normal

Exporting as ODT does not work, because org-odt-data-dir is set by default
to /usr/share/emacs/etc/org, while the relevant files are installed in
/usr/share/emacs/site-lisp/org-mode/etc/styles/

Either org-odt-data-dir should be set to the latter directory, or the files
installed in the former.

-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (100, 'trusty-backports'), (90, 'xenial-updates'), (90, 'xenial')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages org-mode depends on:
ii  emacs24 24.4+1-4ubuntu1
ii  emacsen-common  2.0.8

Versions of packages org-mode recommends:
ii  texlive-generic-recommended  2015.20151116-1ubuntu1
ii  texlive-latex-recommended2015.20151116-1ubuntu1

Versions of packages org-mode suggests:
pn  ditaa  
ii  texlive-fonts-recommended  2015.20151116-1ubuntu1
ii  texlive-latex-extra2015.20151225-2

-- no debconf information

Bug#801067: nfs-common: Remove or updated README.Debian.nfsv4

[Reuben Thomas]

Package: nfs-common
Version: 1:1.2.8-6ubuntu1.1
Severity: normal

The README.Debian.nfsv4 file is now rather old; is NFSv4 really still
considered experimental?

Parts of this file may be worth keeping (I’m not an expert!), but at least
that claim should be removed, and mention of kernel versions and patch sets.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
1000241   udp  43250  status
1000241   tcp  59720  status
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_GSSD=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
[Mapping]
Nobody-User = rrt
Nobody-Group = rrt
-- /etc/fstab --

-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (400, 'trusty-proposed'), (100, 'trusty-backports'), (90, 
'wily-updates'), (90, 'wily')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages nfs-common depends on:
ii  adduser 3.113+nmu3ubuntu3
ii  initscripts 2.88dsf-41ubuntu6.2
ii  libc6   2.19-0ubuntu6.6
ii  libcap2 1:2.24-0ubuntu2
ii  libcomerr2  1.42.9-3ubuntu1.3
ii  libdevmapper1.02.1  2:1.02.77-6ubuntu2
ii  libevent-2.0-5  2.0.21-stable-1ubuntu1.14.04.1
ii  libgssglue1 0.4-2ubuntu1
ii  libkeyutils11.5.6-1
ii  libkrb5-3   1.12+dfsg-2ubuntu5.1
ii  libmount1   2.20.1-5.1ubuntu20.7
ii  libnfsidmap20.25-5
ii  libtirpc1   0.2.2-5ubuntu2
ii  libwrap07.6.q-25
ii  lsb-base4.1+Debian11ubuntu6
ii  mountall2.53
ii  rpcbind 0.2.1-2ubuntu2.2
ii  sysv-rc 2.88dsf-41ubuntu6.2
ii  ucf 3.0027+nmu1

Versions of packages nfs-common recommends:
ii  python  2.7.5-5ubuntu3

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

Versions of packages nfs-kernel-server depends on:
ii  libblkid1 2.20.1-5.1ubuntu20.7
ii  libc6 2.19-0ubuntu6.6
ii  libcap2   1:2.24-0ubuntu2
ii  libsqlite3-0  3.8.2-1ubuntu2.1
ii  libtirpc1 0.2.2-5ubuntu2
ii  libwrap0  7.6.q-25
ii  lsb-base  4.1+Debian11ubuntu6
ii  ucf   3.0027+nmu1

-- no debconf information