Bug#1067505: libc-bin: iconv: misleading error "illegal input sequence"

[Frank Heckenbach]

Package: libc-bin
Version: 2.36-9+deb12u4
Severity: normal
File: /usr/bin/iconv

% printf '\xc3\xa4' | iconv -futf8 -tascii
iconv: illegal input sequence at position 0

- First, according to the FSF's own coding standards
  (https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html),
  it should be "invalid" instead of "illegal" since this byte sequence is not
  "prohibited by law".

- The input sequence is not even invalid. It's correct UTF-8 for U+00E4.
  The actual problem is that this character is not representable in the output
  charset. The message gives no indication about this.

- I tried to report it upstream, but that's also broken. According to
  https://www.gnu.org/software/libc/manual/html_node/Reporting-Bugs.html, bugs
  should be reported at https://www.gnu.org/software/libc/bugs.html, but this
  page redirects to https://www.gnu.org/savannah-checkouts/gnu/libc/index.html
  which does not mention reporting bugs.

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc-bin depends on:
ii  libc6  2.36-9+deb12u4

Versions of packages libc-bin recommends:
ii  manpages  6.03-2

libc-bin suggests no packages.

-- debconf-show failed

Bug#777584: wrap long lines

[Frank Heckenbach]

Hello Georges,

> thank you for your response.

I was busy otherwise recently. I suppose, this is still open, isn't it?

> cron is a key command for UNIX systems, and it is supposed to remain
> lightweight and efficient. This is why it does not implement the mailing
> features, and relies on other UNIX commands to do this job (`mail` or
> `sendmail`)
> 
> You can browse the file do_command.c in cron's source package, and read,
> near line 360, how cron does its job to collect data coming from
> children commands, and compose an e-mail.
>
> So far, the output of the child command is just appended to a text
> stream, which begins with From:, To:, Subject:, Date: lines. However you
> are searching to address the case when the output of the command is too
> big to be just appended to such a text file.
>
> In the case of a big output, the solution would be to encode it (QP or
> base64 are possible encodings), but in such a case, they should not be
> appended to the same stream which contains From:, To:, Subject:, Date:
> lines, but included in a separate stream, and handed to `send` or
> `sendmail` command as an attachment.

Not necessarily an attachment. They can be appended to the stream,
provided that the Content-Transfer-Encoding header is set
appropriately, which would have to be done retroactively when we
encounter long lines.

However, when reading the code, I noticed that cron uses 8bit
transfer encoding by default, but already accepts the environment
variable CONTENT_TRANSFER_ENCODING and passes it through to the mail
header, but without doing any encoding itself. So this only works if
the cron command's output is already encoded which seems strange.
I don't know how people use this option (and I guess neither do
you?). Maybe it's just a relic from back when cron used 7bit by
default, so it was needed for any non-ASCII output at all.

Anyway, given that this variable exists, perhaps we can add a
special value, say "auto", which cron would turn into some encoding
(I'd suggest quoted-printable). So if the environment variable is
set to some other value, nothing will change, but if set to "auto",
it will put QP in the header and do QP encoding itself.

This would be backward-compatible. However, it would require
everyone who's affected by this problem to put something like
"CONTENT_TRANSFER_ENCODING=auto" in their crontab, and in a few
years, people will wonder why such a silly thing is required.

We could go one step further and make "auto" the default. I *think*
these days every mail client should support QP, but you never know
(https://xkcd.com/1172/). In any case, those who want the old
behaviour could still get it by setting
"CONTENT_TRANSFER_ENCODING=8bit".

So that would be a transparent bugfix, but not
100% backward-compatible, and may require action by (I hope) just a
few users.

What do you think?

> ---
> 
> Would you please be kind enough to propose a patch for the file
> do_command.c, which implements encoding and attaching big outputs?

I think I can write the code. Fortunately, QP is not too complex and
rather easy to implement on the fly without any dependencies.

> If you can do it, I would be very pleased to read your code and include
> your patch to the series of patches which are part of the debian source
> package, in order to create this new feature.
> 
> By the way, if you modify the way cron sends e-mails, please can you
> propose a simple test to check whether your modification is running as
> expected? This test will be appended to the series used in autopkgtest,
> in order to prevent eventual future regressions.

Unfortunately, I'm not familiar with the test framework. I can
certainly provide some crontabs and expected mails, but I'd have to
leave it to you to integrate them.

Regards,
Frank

Bug#1053740: /usr/bin/rsvg-convert (pdf): different x/y scale only respected for stroke, not fill of same text

[Frank Heckenbach]

Package: librsvg2-bin
Version: 2.54.7+dfsg-1~deb12u1
Severity: normal
File: /usr/bin/rsvg-convert

% cat test.svg

ABC

% rsvg-convert -f pdf -o test.pdf test.svg

The resulting pdf has the outline (stroke) correctly, but the filled
letters are spaced without respecting the scale, see attached
screenshot from okular. When both x and y are scaled the same, the
result is correct. (Honestly, I find it hard to imagine what would
cause such a strange bug, shouldn't the placement of the letters
always be the same for stroke and fill?)

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-11-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages librsvg2-bin depends on:
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  librsvg2-2   2.54.7+dfsg-1~deb12u1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1

librsvg2-bin recommends no packages.

librsvg2-bin suggests no packages.

-- no debconf information

Bug#777584: wrap long lines

[Frank Heckenbach]

Hello,

> I am the new maintainer for cron package, since a few months. Please can
> one elaborate a little longer about use cases where too long lines are a
> problem?

Thanks for picking up this issue again. I'm not the original
reporter, but also effected, as I wrote in my comment last year.

SMTP standards (RFC 2822) specify a maximum line length of 998
characters.

It can be avoided by encoding the mail. QP (quoted-printable) and
base64 are common encdings. QP can break source lines (by inserting
"=\n" anywhere), and base64 output doesn't care about line breaks at
all.

> Would it be sufficient to truncate such lines to 998 characters, hoping
> that such a length would be sufficient to diagnose a problem?

This would lose information. I don't think I'd like this unless the
original content was stored somewhere and the mail contains a link
where to find it. But that seems more work than the alternatives.

> It would
> be more secure than splitting them and making it possible to overflow
> the file system (for example with too big messages, repeated every
> minute during one day).

Overflowing the file system is a separate issue which can just as
well happen with many short lines. Sure, you might want to handle
this too, but for that you'd might want to set a maximum size (say,
in MB and perferably configurable) independent of line lengths.

Regards,
Frank

Bug#1042862: Xspice crashes on start

[Frank Heckenbach]

Package: xserver-xspice
Version: 0.1.6-1
Severity: grave
Justification: renders package unusable

See #1038648.

As I wrote there, 0.1.6-1 doesn't fix the problem, but this was
ignored, so I'm sending a new bug report.

The buggy patch is now upstream, but that doesn't make it correct.
I've already explained how to fix it correctly.

Bug#1038648: closed by Debian FTP Masters (reply to Timo Aaltonen ) (Bug#1038648: fixed in xserver-xorg-video-qxl 0.1.6-1)

[Frank Heckenbach]

Doesn't fix the problem.

Bug#1038648: Xspice crashes on start

[Frank Heckenbach]

Control: tags patch

I think I found the problem. It seems to be
Fix-a-build-error-with-Xorg-master.patch

To be honest, I don't really understand the patch. According to the
comment, instead of just changing one renamed parameter, it changes
the calling conventions at the cost of an unnecessary "slight
performance drop" in not one but three functions "for consistency"
and goes on to explain why it should work which sounds questionable
to me and apparently doesn't work after all.

So instead doing the simple thing seems to work. I suggest replacing
the patch with this one:

Index: xserver-xorg-video-qxl-0.1.5+git20200331/src/qxl_option_helpers.c
===
--- xserver-xorg-video-qxl-0.1.5+git20200331.orig/src/qxl_option_helpers.c
+++ xserver-xorg-video-qxl-0.1.5+git20200331/src/qxl_option_helpers.c
@@ -34,7 +34,7 @@ int get_bool_option(OptionInfoPtr option
 const char* value = getenv(env_name);
 
 if (!value) {
-return options[option_index].value.bool;
+return options[option_index].value.boolean;
 }
 if (strcmp(value, "0") == 0 ||
 strcasecmp(value, "off") == 0 ||

Bug#1038648: Xspice crashes on start

[Frank Heckenbach]

Package: xserver-xspice
Version: 0.1.5+git20200331-3
Severity: grave
Justification: renders package unusable

Since upgrading to bookworm, Xspice always crashes when I try to
start it:

Xspice --config xspice.1.conf :25

(EE) Caught signal 6 (Aborted). Server aborting

Full log: xspice.1.log

https://gitlab.freedesktop.org/xorg/driver/xf86-video-qxl/-/issues/14
describes a similar problem and suggest to add some options in the
config file. When I do this, I get a segfault instead:

Xspice --config xspice.2.conf :25

(EE) Caught signal 11 (Segmentation fault). Server aborting

Full log: xspice.2.log

The page above mentions this too and refers to
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-qxl/+bug/1967719

That report was closed since they were "confident it was fixed in
https://launchpad.net/ubuntu/+source/xserver-xorg-video-qxl/0.1.5+git20200331-3";.
However, the same version seems to be in bookworm (unless Debian
made its own changes to it), and the problem does occur.

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xserver-xspice depends on:
ii  libc6  2.36-9
ii  libspice-server1   0.15.1-1
ii  libxfont2  1:2.0.6-1
ii  python33.11.2-1+b1
ii  xserver-xorg   1:7.7+23
ii  xserver-xorg-core [xorg-video-abi-25]  2:21.1.7-3

xserver-xspice recommends no packages.

xserver-xspice suggests no packages.

-- no debconf information


xspice.1.conf
Description: Binary data


xspice.1.log
Description: Binary data


xspice.2.conf
Description: Binary data


xspice.2.log
Description: Binary data

Bug#1037524: libortp: still missing -lbctoolbox (was: Bug#994437: fixed in ortp 1:5.0.37-1)

[Frank Heckenbach]

> > You added a "Requires.private" in the .pc, but that doesn't help.
> > "Requires" is required (sic!) because a program that links to ortp
> > apparently must also link to bctoolbox.
> 
> Dude, did you not see that the string "bctbx_set_log_level_mask" does
> not occur anywhere in your program?  And that as a consequence the
> error message does not really make any sense?  Because if you did see
> it then you could have said something.

Sorry, I did suggest to add it as "Requires:" (not private) and
added a simple demo program to check it.

> It was not immediately obvious to me that ortp_set_log_level_mask() in
> the distant past was provided by libortp.so, but then replaced with
> bctbx_set_log_level_mask() from libbctoolbox.so and the name change
> papered over with a macro (instead of a wrapper function which would
> have preserved the old linkage relationship).

I didn't know these details and history either (my code using the
library was a few years old then, so I didn't remember all of it at
the time), just saw the error message and found that adding
-lbctoolbox fixed it.

> Anyway, I'll fix it when preparing 1:5.2.x which I'll try to get to in
> the coming weeks.

Thanks.

Bug#1037524: libortp: still missing -lbctoolbox (was: Bug#994437: fixed in ortp 1:5.0.37-1)

[Frank Heckenbach]

Package: libortp-dev
Version: 1:5.1.64-2
Severity: normal


> This is an automatic notification regarding your Bug report
> which was filed against the libortp-dev package:
>
> #994437: libortp: missing -lbctoolbox
>
> It has been closed by Debian FTP Masters 
> (reply to Bernhard Schmidt ).
>
> 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  pmas...@ftp-master.debian.org> (reply to Bernhard Schmidt  >) by
> replying to this email.

It's actually not fixed!

You added a "Requires.private" in the .pc, but that doesn't help.
"Requires" is required (sic!) because a program that links to ortp
apparently must also link to bctoolbox.

My original test program still applies:

% cat a.c
#include 

int main ()
{
  ortp_init ();
  ortp_set_log_level_mask (ORTP_LOG_DOMAIN, ORTP_FATAL);
}
% gcc a.c  `pkg-config --cflags --libs ortp`
/usr/bin/ld: /tmp/ccnMlrim.o: undefined reference to symbol 
'bctbx_set_log_level_mask'
/usr/bin/ld: /lib/x86_64-linux-gnu/libbctoolbox.so.1: error adding symbols: DSO 
missing from command line
collect2: error: ld returned 1 exit status
% gcc a.c  `pkg-config --cflags --libs ortp` -lbctoolbox
% ./a.out

Bug#1034708: lintian: false positive "build-depends-on-versioned-berkeley-db Build-Depends:libdb5.3-sql-dev"

[Frank Heckenbach]

Package: lintian
Version: 2.116.3
Severity: normal

I get the warning "build-depends-on-versioned-berkeley-db 
Build-Depends:libdb5.3-sql-dev"

My package used to depend on libdb-sql-dev, but this package doesn't
exist anymore in bookworm, so I think I have to depend on
libdb5.3-sql-dev now, don't I?

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.21
ii  dpkg-dev1.21.21
ii  file1:5.44-3
ii  gettext 0.21-12
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.13.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.35-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.21
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.003+ds-1
ii  libsereal-encoder-perl  5.003+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.16-1
ii  libwww-perl 6.68-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzop1.04-2
ii  man-db  2.11.2-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  plzip [lzip-decompressor]   1.10-5
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.1-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#1031380: install: options --compare (-C) and --preserve-timestamps are mutually exclusive

[Frank Heckenbach]

Package: coreutils
Version: 8.32-4+b1
Severity: normal

===

% install -C -p x y
install: options --compare (-C) and --preserve-timestamps are mutually exclusive
Try 'install --help' for more information.
% install --help
Usage: install [OPTION]... [-T] SOURCE DEST
  or:  install [OPTION]... SOURCE... DIRECTORY
  or:  install [OPTION]... -t DIRECTORY SOURCE...
  or:  install [OPTION]... -d DIRECTORY...

This install program copies files (often just compiled) into destination
locations you choose.  If you want to download and install a ready-to-use
package on a GNU/Linux system, you should instead be using a package manager
like yum(1) or apt-get(1).

In the first three forms, copy SOURCE to DEST or multiple SOURCE(s) to
the existing DIRECTORY, while setting permission modes and owner/group.
In the 4th form, create all components of the given DIRECTORY(ies).

Mandatory arguments to long options are mandatory for short options too.
  --backup[=CONTROL]  make a backup of each existing destination file
  -b  like --backup but does not accept an argument
  -c  (ignored)
  -C, --compare   compare each pair of source and destination files, and
in some cases, do not modify the destination at all
  -d, --directory treat all arguments as directory names; create all
components of the specified directories
  -D  create all leading components of DEST except the last,
or all components of --target-directory,
then copy SOURCE to DEST
  -g, --group=GROUP   set group ownership, instead of process' current group
  -m, --mode=MODE set permission mode (as in chmod), instead of rwxr-xr-x
  -o, --owner=OWNER   set ownership (super-user only)
  -p, --preserve-timestamps   apply access/modification times of SOURCE files
to corresponding destination files
  -s, --strip strip symbol tables
  --strip-program=PROGRAM  program used to strip binaries
  -S, --suffix=SUFFIX  override the usual backup suffix
  -t, --target-directory=DIRECTORY  copy all SOURCE arguments into DIRECTORY
  -T, --no-target-directory  treat DEST as a normal file
  -v, --verbose   print the name of each directory as it is created
  --preserve-context  preserve SELinux security context
  -Z  set SELinux security context of destination
file and each created directory to default type
  --context[=CTX] like -Z, or if CTX is specified then set the
SELinux or SMACK security context to CTX
  --help display this help and exit
  --version  output version information and exit

The backup suffix is '~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX.
The version control method may be selected via the --backup option or through
the VERSION_CONTROL environment variable.  Here are the values:

  none, off   never make backups (even if --backup is given)
  numbered, t make numbered backups
  existing, nil   numbered if numbered backups exist, simple otherwise
  simple, never   always make simple backups

GNU coreutils online help: 
Report any translation bugs to 
Full documentation 
or available locally via: info '(coreutils) install invocation'

===

I see no explanation there why these options should be mutually exclusive.
(RTFS did not reveal any insight either.)

If the error message is unnecessary, please remove it.

Otherwise, please provide an explanation why and possible workarounds.

What I want to achieve is to preserve timestamps and to avoid doing extra work.
Both goals seem rather natural, and I see no reason why they should not be 
combined.

(In fact it seems "-p" should make it *easier* to implement "-C" as
timestamps will compare equal when nothing's changed. Then again,
need_copy() doesn't seem to care about times at all, so why should
it be incompatible with "-p"?)

-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13+deb11u5
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1029913: Fwd: Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability

[Frank Heckenbach]

Siep Kroonenberg wrote:

> The problem was that the test was specifically for a file rather
> than for any filesystem item.
> 
> In the updated TL package, the test has been removed altogether
> since there was already a later test for successful generation of a
> temp subdirectory.
> 
> The updated package is now available as both a CTAN package and a TL
> package.

I tried it, and it fixes the problem as I reported.

Of course, chdir into /tmp is a bit risky as any file creation
before the next chdir would be susceptible to the same problem, but
I assume you made sure this won't happen.

BTW, when looked at the changes made, I noticed this:

  io.stdout:write('cannot cd into '..d..'\n')

I don't know much about Lua conventions, but normally I'd expect
such messages to be written to stderr, not stdout.

Bug#1029913: texlive-pictures: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu: /tmp write vulnerability

[Frank Heckenbach]

Package: texlive-pictures
Version: 2020.20210202-3
Severity: grave
File: /usr/share/texlive/texmf-dist/scripts/epspdf/epspdf.tlu

Classic /tmp write vulnerability: function dir_writable writes to
"/tmp/1" (and if this fails, "/tmp/2" etc.) without sufficient
checks.

Harmless demonstration:

% mkfifo /tmp/1
% epspdf /etc/hostname /dev/null  # any non-empty input file will do

hangs indefinitely trying to write to the pipe (as can be seen using
strace).

That's already a bug (and incidentally the one that actually
happened to me), but it seems it can be turned into an exploit using
a symlink. Though on my system this seems to be mitigated due to
this kernel patch:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5

But on systems where the patch is not installed or not active, it
would be possible to get any other user, possibly root, that runs
this program to write "test" to a new file of the attacker's choice.
I don't know how to turn this into a more serious privilege
escalation, but that's just my lack of fanatsy and knowledge of e.g.
every possible file and subdirectory under /etc. In any case,
writing such a file is already transgressing privileges.

To avoid this, as usual for this kind of exploit, files written
under publicly writable directories such as /tmp must be opened with
O_CREAT|O_EXCL (whatever the equivalent in texlua is, if any), or a
subdirectory must be created since mkdir will fail if the target
exists already, even as a dangling symlink.

Bug#1015293: wrong row targeted with "insert ... on duplicate" and "replace", leading to data corruption

[Frank Heckenbach]

Forwarded: https://jira.mariadb.org/browse/MDEV-30046

Bug#1015294: spamprobe: a few patches

[Frank Heckenbach]

e()
 openImage();
 digestImage();
 parseImageRecords();
+return true;
   } catch (runtime_error &ex) {
 return false;
   }
Index: spamprobe-1.4d/src/parser/JpegParser.cc
===
--- spamprobe-1.4d.orig/src/parser/JpegParser.cc
+++ spamprobe-1.4d/src/parser/JpegParser.cc
@@ -61,6 +61,7 @@ bool JpegParser::parseImage()
 initializeSource();
 digestImage();
 tokenizeImage();
+return true;
   } catch (runtime_error &ex) {
 return false;
   }
Index: spamprobe-1.4d/src/parser/MbxMailMessageReader.cc
===
--- spamprobe-1.4d.orig/src/parser/MbxMailMessageReader.cc
+++ spamprobe-1.4d/src/parser/MbxMailMessageReader.cc
@@ -85,6 +85,7 @@ bool MbxMailMessageReader::readMBXRecord
   cerr << "MBX: SKIPPED DELETED MESSAGE" << endl;
 }
   }
+  return true;
 }
 
 OWNED MailMessage *MbxMailMessageReader::readMessage()
Index: spamprobe-1.4d/src/parser/PngParser.cc
===
--- spamprobe-1.4d.orig/src/parser/PngParser.cc
+++ spamprobe-1.4d/src/parser/PngParser.cc
@@ -73,6 +73,7 @@ bool PngParser::parseImage()
   try {
 digestImage();
 initializeImage();
+return true;
   } catch (runtime_error &ex) {
 return false;
   }
Description: Avoid deprecated strstream
Author: Frank Heckenbach 
Index: spamprobe-1.4d/src/database/FrequencyDBImpl_bdb.cc
===
--- spamprobe-1.4d.orig/src/database/FrequencyDBImpl_bdb.cc
+++ spamprobe-1.4d/src/database/FrequencyDBImpl_bdb.cc
@@ -32,7 +32,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include "CleanupManager.h"
 #include "LockFile.h"
 #include "WordData.h"
@@ -67,10 +67,9 @@ inline int throw_on_error(const char *fu
 return rc;
   }
   if (rc != 0) {
-static char buffer[4096];
-ostrstream msg(buffer, sizeof(buffer));
+ostringstream msg;
 msg << function_name << ": " << db_strerror(rc) << " (" << rc << ")" << ends;
-throw runtime_error(buffer);
+throw runtime_error(msg.str());
   }
   return rc;
 }
Index: spamprobe-1.4d/src/database/FrequencyDBImpl_pbl.cc
===
--- spamprobe-1.4d.orig/src/database/FrequencyDBImpl_pbl.cc
+++ spamprobe-1.4d/src/database/FrequencyDBImpl_pbl.cc
@@ -32,7 +32,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include "CleanupManager.h"
 #include "LockFile.h"
@@ -55,10 +55,9 @@ inline int throw_on_error(const char *fu
 return PBL_ERROR_NOT_FOUND;
   }
 
-  static char buffer[4096];
-  ostrstream msg(buffer, sizeof(buffer));
+  ostringstream msg;
   msg << function_name << ": " << pbl_errstr << " (" << pbl_errno << ")" << ends;
-  throw runtime_error(buffer);
+  throw runtime_error(msg.str());
 }
 
 inline int warn_on_error(const char *function_name,
Description: use reproducible pseudo-random numbers in AutoTrainMailMessageReader
Author: Frank Heckenbach 
Index: spamprobe-1.4d/src/parser/AutoTrainMailMessageReader.cc
===
--- spamprobe-1.4d.orig/src/parser/AutoTrainMailMessageReader.cc
+++ spamprobe-1.4d/src/parser/AutoTrainMailMessageReader.cc
@@ -29,6 +29,7 @@
 //
 
 #include 
+#include 
 #include "MailMessage.h"
 #include "AutoTrainMailMessageReader.h"
 
@@ -140,5 +141,15 @@ OWNED MailMessage *AutoTrainMailMessageR
 
 bool AutoTrainMailMessageReader::shouldUseSpam()
 {
-  return (m_totalCount >= 0) && ((random() % m_totalCount) < m_spamCount);
+  /* The original code uses "random" here without seeding it.
+ But some DB backends (e.g. BDB) seed the PRNG internally.
+ This gives the worst of both worlds: No real randomness,
+ yet different results with different backends which makes
+ it hard to compare them for performance or correctness.
+ Now, this uses a separate PRNG and leaves it unseeded,
+ to make results comparable, at the cost of no real
+ randomness which does not seem so important here. */
+  static mt19937 PRNG;
+  uniform_int_distribution dist(0, m_totalCount - 1);
+  return (m_totalCount >= 0) && (dist(PRNG) < m_spamCount);
 }

Bug#1015293: wrong row targeted with "insert ... on duplicate" and "replace", leading to data corruption

[Frank Heckenbach]

Package: mariadb-server-core-10.5
Version: 1:10.5.15-0+deb11u1
Severity: important

Using the MySQL interface, these statements:

DROP TABLE IF EXISTS t;
CREATE TABLE t (s BLOB, n INT, UNIQUE (s));
INSERT INTO t VALUES ('Hrecvx_0004ln-00',1), ('Hrecvx_0004mm-00',1);
INSERT INTO t VALUES ('Hrecvx_0004mm-00',2) ON DUPLICATE KEY UPDATE n = VALUES 
(n);
SELECT * FROM t;

produce this output:

s   n
Hrecvx_0004ln-002
Hrecvx_0004mm-001

So the latter "INSERT" updates the wrong row.

This happens whether the first column is "BLOB" or "TEXT", but only
with specific values. (In my actual use case with ~1 million rows,
it happened a few dozen times, which might be consistent e.g. with
collisions of a 32 bit hash or so.)

Likewise, these statements:

DROP TABLE IF EXISTS t;
CREATE TABLE t (s BLOB, n INT, UNIQUE (s));
INSERT INTO t VALUES ('Hrecvx_0004ln-00',1), ('Hrecvx_0004mm-00',1);
REPLACE INTO t VALUES ('Hrecvx_0004mm-00',2);
SELECT * FROM t;

give the error:

ERROR 1062 (23000) at line 4: Duplicate entry 'Hrecvx_0004mm-00' for key 's'

In my understanding, this error should actually be impossible with
"REPLACE INTO".

It might be the same issue, i.e. it tries to delete the wrong row
before inserting the new one, so it's still duplicate.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-14-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server-core-10.5 depends on:
ii  libaio1 0.3.112-9
ii  libc6   2.31-13+deb11u3
ii  libcrypt1   1:4.4.18-4
ii  liblz4-11.9.3-2
ii  libpcre2-8-010.36-2
ii  libsnappy1v51.1.8-1
ii  libssl1.1   1.1.1n-0+deb11u3
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-7
ii  mariadb-common  1:10.5.15-0+deb11u1
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

mariadb-server-core-10.5 recommends no packages.

mariadb-server-core-10.5 suggests no packages.

-- no debconf information

Bug#1014201: spamprobe hangs in libdb; use MySQL instead?

[Frank Heckenbach]

Package: spamprobe
Version: 1.4d-14+b2
Severity: important
Tags: upstream

I posted this upstream at https://sourceforge.net/p/spamprobe/bugs/40/, but as 
expected got no reaction there.

Is anyone here maintaining spamprobe anymore, or am I on my own?

---

I had used spamprobe for many years without major problems. But recently it 
started hanging.

strace shows it blocks on a futex call which is strange enough since it's 
single-threaded and no other instances were running at the same time.

Once it happens, it seems to happen every time. Rebuilding the database helped, 
but only for a short while. After few days, it would hang again.

gdb shows the offending calls come from some libdb functions. Since I don't 
feel like debugging libdb, and you might not either, this got me thinking if 
using a file-based DB such as Berkeley is really the best option here.

Using a DB server such as MySQL might, apart from hopefully avoiding such 
locking bugs, be better for performance since it doesn't have to load the whole 
DB on each invocation, but can cache it if used frequently, as it normally does.

I see a similar request was made recently (well, 17 years ago ;) in 
https://sourceforge.net/p/spamprobe/feature-requests/23/ (with yet another 
reason), but got no replies.

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-14-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages spamprobe depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u3
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libgcc-s1 [libgcc1]10.2.1-6
ii  libgif75.1.9-2
ii  libjpeg62-turbo1:2.0.6-4
ii  libpng16-161.6.37-3
ii  libstdc++6 10.2.1-6

Versions of packages spamprobe recommends:
ii  procmail  3.22-26

spamprobe suggests no packages.

-- debconf-show failed

Bug#777584: wrap long lines

[Frank Heckenbach]

The limit according to RFC 2822 is 998 characters.
Current versions of exim4, e.g., enforce this limit.

So if you do wrapping, you might as well use the correct limit.

Of course, wrapping slightly alters the content.

If this is deemed inacceptable, you might need to MIME encode the
message (QP or base64).

Bug#1003639: gdb sometimes doesn't set hardware breakpoint for no discernible reason

[Frank Heckenbach]

Package: gdb
Version: 10.1-1.7
Severity: normal

>From a coomplicated gdb session
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003638):

(gdb) p (float*)$2
$29 = (float *) 0x556e612bd530
(gdb) watch *(float*)$29
Hardware watchpoint 10: *(float*)$29
(gdb) d 10
[...]
(gdb) watch *(float*)$30
Watchpoint 21: *(float*)$30
(gdb) d 21
(gdb) p $30
$31 = (float *) 0x556e614692d0
(gdb) p $30==(float*)0x556e614692d0
$32 = 1
(gdb) watch *(float*)0x556e614692d0
Hardware watchpoint 22: *(float*)0x556e614692d0
(gdb) d 22

So watching a float at some address (*$2) creates a hardware
watchpoint, but at another one (*$30) only a software watchpoint
(which in this case was unusably slow).

But watching the same address typed explicitly (and verified with
"==" to rule out copy/paste error) gave a hardware watchpoint again
(which did help to find the other bug :).

Nothing in the docs or on the net I could find gives any explanation
when and why gdb uses hardware watchpoints (only an option to force
software watchpoints which is the opposite I want).

I don't see any reason here, so I suppose it's a bug. If not, it
would be useful to at least tell the user why it doesn't.

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.8-1+b3
ii  libc6   2.31-13+deb11u2
ii  libdebuginfod1  0.183-1
ii  libexpat1   2.2.10-2
ii  libgcc-s1   10.2.1-6
ii  libipt2 2.0.3-1
ii  liblzma55.2.5-2
ii  libmpfr64.1.0-3
ii  libncursesw66.2+20201114-2
ii  libpython3.93.9.2-1
ii  libreadline88.1-1
ii  libsource-highlight4v5  3.1.9-3+b1
ii  libstdc++6  10.2.1-6
ii  libtinfo6   6.2+20201114-2
ii  libxxhash0  0.8.0-2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.31-13+deb11u2

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information

Bug#1003638: mbeq: uninitialized field access corrupts output

[Frank Heckenbach]

Package: swh-plugins
Version: 0.4.17-2+fh1
Severity: important
Tags: upstream patch

mbeq_1197.xml:

float coefs[FFT_LENGTH / 2];

[...]

coefs[0] = 0.0f;
for (bin=1; bin < (FFT_LENGTH/2-1); bin++) {
coefs[bin] = ((1.0f-bin_delta[bin]) * gains[bin_base[bin]])
  + (bin_delta[bin] * gains[bin_base[bin]+1]);
}

[...]

for (i = 1; i < FFT_LENGTH/2; i++) {
comp[i] *= coefs[i];
comp[FFT_LENGTH-i] *= coefs[i];
}

The first loop leaves coefs[FFT_LENGTH/2-1] uninitialized because it
only runs while bin < FFT_LENGTH/2-1.

The second loop reads from coefs[FFT_LENGTH/2-1], boom!

With some bad luck (which I had, of course, and of course only in
hard to reproduce circumstances) the uninitialized value will be NaN
which due to the FFT poisons the whole output with NaN.

Fix (note the "-1" is not needed at all. Maybe someone thought so
because of the "+1" in the line below, but that doesn't apply to bin
at all):

--- mbeq_1197.xml
+++ mbeq_1197.xml
@@ -140,7 +140,7 @@
 
 // Calculate coefficients for each bin of FFT
 coefs[0] = 0.0f;
-for (bin=1; bin < (FFT_LENGTH/2-1); bin++) {
+for (bin=1; bin < (FFT_LENGTH/2); bin++) {
coefs[bin] = ((1.0f-bin_delta[bin]) * gains[bin_base[bin]])
  + (bin_delta[bin] * gains[bin_base[bin]+1]);
 }

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages swh-plugins depends on:
ii  libc6 2.31-13+deb11u2
ii  libfftw3-single3  3.3.8-2
ii  libgsm1   1.0.18-2

swh-plugins recommends no packages.

swh-plugins suggests no packages.

-- no debconf information

Bug#1003482: libre2-dev: re2.pc contains "-std=c++11"

[Frank Heckenbach]

Package: libre2-dev
Version: 20210201+dfsg-1
Severity: normal

re2.pc contains "-std=c++11". This conflicts with other "-std"
options, especially if one wants to use a newer standard (which
otherwise works with libre2, as indicated by its support for
string_view, e.g.).

In order to make sure it's used only with C++11 or newer, you may
want to check __cplusplus in the header instead.

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libre2-dev depends on:
ii  libre2-9  20210201+dfsg-1

libre2-dev recommends no packages.

libre2-dev suggests no packages.

-- no debconf information

Bug#1003012: Fixing #1003012 in bullseye (was: Re: Bug#1003012: closed by Salvatore Bonaccorso (Re: Accepted bash 5.1-6 (source) into unstable))

[Frank Heckenbach]

Hi Salvatore,

> > Thanks for the quick fix!
> 
> Just in avoidance of doubt, thanks goes to Matthias, I just fixed the
> BTS metadata as the bug was not closed along with the upload.

Thanks to Matthias then! :)

> >From a security team perspective, we do not plan to release the fix as
> a DSA via the security-archive, but a fix would be welcome to be
> included in the next bullseye point release.
> 
> Apart the patch "014" for this issue, maybe it makes sense to pick up
> as well other of the applied patches (have not looked at the others).

Upstream did this; bash-5.1.16 includes this patch and other recent
patches.

> Matthias, would you prepare such an update? TTBOMK the next bullseye
> release will be around february 2022, according to the planning of the
> release team.

OK, that's too late for me, so I'm patching it myself. Thanks for
the info.

Frank

Bug#1003012: closed by Salvatore Bonaccorso (Re: Accepted bash 5.1-6 (source) into unstable)

[Frank Heckenbach]

Thanks for the quick fix!

However, it's not clear to me if the fix will go to
bullseye-security or at least bullseye-updates or only to testing.
(Is there some way to find this out on the web site or so?)

I need to know because now I have to either wait for the bullseye
package or backport it myself, and I'd like to avoid having to do
both (and thus rebooting my systems twice).

Frank

Bug#1003012: bash: Corrupted multibyte characters in command substitutions

[Frank Heckenbach]

Package: bash
Version: 5.1-2+b3
Severity: critical
Justification: breaks unrelated software
Tags: patch upstream l10n

I've reported this bug on bug-bash:
https://lists.gnu.org/archive/html/bug-bash/2022-01/msg0.html

only to learn that it's known and not fixed for months (it was known
before bullseye was released, so a timely fix would have prevented
the bug ever reaching stable):
https://savannah.gnu.org/patch/?10035

I'm reporting it as critical because it causes silent data
corruption and potentially affects each bash script in the system.

Since the bash developers don't seem to take that seriously, I'm
asking the Debian maintainers to put out a fixed version ASAP to
prevent further damage -- hopefully as a security patch. (I'm no
expert in writing exploits, but I think it's quite possible such a
bug can be exploited. I hope you don't have to wait for an actual
exploit in order to fix the bug.)

Both reports listed above contain a patch. They're different, but
either one will fix the immediate problem.

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bash depends on:
ii  base-files   11.1+deb11u2
ii  debianutils  4.11.2
ii  libc62.31-13+deb11u2
ii  libtinfo66.2+20201114-2

Versions of packages bash recommends:
ii  bash-completion  1:2.11-2

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#1002457: rsvg-convert: incorrect text rendering with small font-size (regression)

[Frank Heckenbach]

Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal
File: /usr/bin/rsvg-convert

Text with small font-size is rendered incorrectly. In the attached
exmples, letters are rendered on top of each other instead of next
to each other.

It was rendered correctly under buster (see font-tiny-2.44.10.png).
It also renders correctly in Firefox and Chromium.

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), 
(500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librsvg2-bin depends on:
ii  libc6 2.31-13+deb11u2
ii  libcairo2 1.16.0-5
ii  libglib2.0-0  2.66.8-1
ii  librsvg2-22.50.3+dfsg-1

librsvg2-bin recommends no packages.

librsvg2-bin suggests no packages.

-- no debconf information

Bug#929612: sispmctl: support EG-PMS2 aka usb-id 04b4:fd15

[Frank Heckenbach]

I wrote:

: Still broken in stable and testing.

Still broken in current stable, testing and unstable.

: upstream 4.1 still works out of the box.

Still does.

: Does anyone read these bug reports at all?

Apparently not. :(

Bug#1001070: command-not-found: crashes when entering an unknown command

[Frank Heckenbach]

Package: command-not-found
Version: 20.10.1-1
Severity: grave
Justification: renders package unusable

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917455

Bug #917455 was closed with:

  Marked as fixed in versions 20.10.1-1

This is *NOT* the case!

After upgrading to bullseye, which includes
command-not-found 20.10.1-1, the bug is there again!

% foo
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.9.2 final 0
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Exception information:

unable to open database file
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 90, in main
cnf = CommandNotFound.CommandNotFound(options.data_dir)
  File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line 
79, in __init__
self.db = SqliteDatabase(dbpath)
  File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
__init__
self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file

The temporary fix still works:

  sudo chmod 644 /var/lib/command-not-found/commands.db

But after the next update, the permissions are set wrong again.

The actual fix is (and probably always has been) to set in
/sbin/update-command-not-found:

  os.umask (0o022)

I see no trace of this having been done. In fact, there's no
occurrence of "umask" anywhere in the sources (including Debian
patches) -- except for debian/changelog!??? (And a much older
changelog entry anyway.)

So it doesn't seem this bug was actually ever fixed.

Bug#996872: librsvg2-bin: stroke-dasharray rendered wrong

[Frank Heckenbach]

Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal

% cat a.svg



% rsvg-convert -f pdf -o a.pdf a.svg
%

The resulting PDF (attached) contains a thin line across the part of
the path that should not be drawn.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librsvg2-bin depends on:
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libglib2.0-0  2.66.8-1
ii  librsvg2-22.50.3+dfsg-1

librsvg2-bin recommends no packages.

librsvg2-bin suggests no packages.

-- no debconf information


a.pdf
Description: Adobe PDF document

Bug#994437: libortp: missing -lbctoolbox

[Frank Heckenbach]

Package: libortp-dev
Version: 1:4.4.13-2
Severity: normal
File: libortp

% cat a.c
#include 

int main ()
{
  ortp_init ();
  ortp_set_log_level_mask (ORTP_LOG_DOMAIN, ORTP_FATAL);
}
% gcc a.c  `pkg-config --cflags --libs ortp`
/usr/bin/ld: /tmp/ccnMlrim.o: undefined reference to symbol 
'bctbx_set_log_level_mask'
/usr/bin/ld: /lib/x86_64-linux-gnu/libbctoolbox.so.1: error adding symbols: DSO 
missing from command line
collect2: error: ld returned 1 exit status
% gcc a.c  `pkg-config --cflags --libs ortp` -lbctoolbox
% ./a.out

So I think "-lbctoolbox" should be added to ortp.pc,
probably via "Requires:".

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libortp-dev:amd64 depends on:
ii  libbctoolbox-dev  4.4.13-2
ii  libortp15 1:4.4.13-2

libortp-dev:amd64 recommends no packages.

libortp-dev:amd64 suggests no packages.

-- no debconf information

Bug#994436: librsvg2-bin: error reporting

[Frank Heckenbach]

Package: librsvg2-bin
Version: 2.50.3+dfsg-1
Severity: normal

% cat bogus.svg

% rm -f bogus.pdf
% rsvg-convert -f pdf -o bogus.pdf bogus.svg
Error reading SVG:XML parse error: error code=201 (3) in (null):1:71: Namespace 
prefix xlink for href on use is not defined


% ls -la bogus.*
-rw--- 1 frank frank  0 16. Sep 05:07 bogus.pdf
-rw--- 1 frank frank 79 16. Sep 05:06 bogus.svg
%

The error itself is correct AFAIK, but the location is given with
"(null)" instead of the correct filename.

Afterwards, an empty output file is left which can be problematic
e.g. when run from a makefile. Of course, it can be worked around
with something like '|| { rm -f "$@"; false; }', but that really
shouldn't be necessery.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_WARN
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librsvg2-bin depends on:
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libglib2.0-0  2.66.8-1
ii  librsvg2-22.50.3+dfsg-1

librsvg2-bin recommends no packages.

librsvg2-bin suggests no packages.

-- no debconf information

Bug#987981: exim4: misleading bounce and error message "message is too big (transport limit = 1)"

[Frank Heckenbach]

Package: exim4
Version: 4.92-8+deb10u5
Severity: normal

When I tried to send a mail, exim sent me this bounce:

  Subject: Mail delivery failed: returning message to sender

  This message was created automatically by mail delivery software.

  A message that you sent could not be delivered to one or more of its
  recipients. This is a permanent error. The following address(es) failed:

[...]

  --
  Content-type: message/delivery-status

  Reporting-MTA: dns; mars

  Action: failed
  Final-Recipient: rfc822;[...]
  Status: 5.0.0

which contains no indication of what's wrong. (AFAICG, 5.0.0
actually means "Message Not Delivered: Unknown issue").

In the log it says:

  message is too big (transport limit = 1)

which is also misleading (the message was not very large, and what
does "transport limit = 1" even mean, 1 what?).

I had to google this message to finally find some other reports
containing it which hinted at the 998 character line length limit
per RFC.

This was indeed the problem with my mail, but nothing in what exim
told me gave any indication of that.

Improving the bounce seems more important, since it's the sender,
not the admin, who can usually fix the problem. But improving the
log message, too, would also help.

-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/24 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE= 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  exim4-base 4.92-8+deb10u5
ii  exim4-daemon-light 4.92-8+deb10u5

Bug#980364: sudo: segfault when /var/lib/sudo/lectured not writable

[Frank Heckenbach]

Hi Marc,

> Is it ok for you if I close this bug?

Sure.

> > Most likely unrelated, but one thing I did notice when checking the
> > code is that sudo_mkdir_parents might UB if path is an empty string,
> > since it first does "char *slash = path; strchr (slash + 1, '/');".
> > 
> > Now I don't know if it's actually possible that it's called with an
> > empty string, so it might not be an actual bug, but since I see it's
> > coded very defensively overall, an empty string check here might not
> > hurt.
> 
> Would it be ok for you to file an issue in upstream's bugzilla? Or would
> it be more comforable for you if I took this issue upstream? It is
> generally more useful when the bug reporter has a direct communications
> link to upstream in such cases.

I'd prefer if you do it. I don't really have anything more to say
about it, nor any kind of test case. (As I said, it may not even be
a bug, just a matter of defensive programming.)

Greetings,
Frank

Bug#980364: sudo: segfault when /var/lib/sudo/lectured not writable

[Frank Heckenbach]

> > On a system with disk errors, which had therefore remounted its
> > file systems read-only, I tried to sudo in order to do further
> > diagnostics as root, but sudo crashed with a segfault.
> 
> I tried reproducing this with sudo 1.8.27-1+deb10u3, on a clean file
> system, mounted read-only, on /var/lib/sudo:
> and then tried to become root from a normal user account:
>
> The timestamp, in this case, gets written to /run/sudo, which is a tmpfs
> on Debian systems. After sudo -k, another try to invoke sudo will result
> in the lecture being repeated. I don't see a segfault in any of these
> cases, and root privileges were obtained, making repair work possible.
> 
> Could it be possible that the filesystem was not only mounted read-only,
> but also broken or wrongfully mounted? Please note that you received an
> Input/Output error, while my tests ended with "Read-only file system".

Probably. I had misinterpreted the segfault as a consequence of the
reported write error because it was shown right after it.

I've now checked the code and see that sudo does continue properly
after this particular error, which is good, though it means that the
segfault could be from any code run afterwards -- or it could be a
consequence of sudo itself or one of its libraries corrupted on
loading.

Unfortunately, I can't easily try to reproduce it, either. (It was a
server, so we had to quickly reboot it to get it running again and
replace the defective disk soon after; when it happened, I didn't
have much time to do further tests, and without gdb or strace
available for a suid program, my options were very limited, anyway.)
So I guess we have to leave it at that.

Most likely unrelated, but one thing I did notice when checking the
code is that sudo_mkdir_parents might UB if path is an empty string,
since it first does "char *slash = path; strchr (slash + 1, '/');".

Now I don't know if it's actually possible that it's called with an
empty string, so it might not be an actual bug, but since I see it's
coded very defensively overall, an empty string check here might not
hurt.

Bug#905015: xserver-xorg-input-elographics: Xorg hangs on start when touchscreen does not answer

[Frank Heckenbach]

> This was a bug in X server 1.19 fixed in 1.19.4 with
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/d8f63717e05ae8d820ceae74216916ebd180441d
> 
> Unfortunately this bug is in the X server in stretch and won't get fixed 
> there now that stretch is LTS, but the versions in buster and later 
> should be fine.

I guess that explains why I got reports of touchscreens not working
reliably in buster:

I had applied the above patch to xserver-xorg-input-elographics,
after duly checking it hadn't been applied yet. But of course, I had
no way of knowing that the problem was fixed another way in another
package.

The result now was apparently an overcorrection, resulting in
timeouts being too short and sometimes timing out ...

Bug#757582: closed by Bernhard Schmidt (Closing bugs opened for old Gtk client)

[Frank Heckenbach]

> You seem to forget that

What you (and apparently many other maintainers) seem to forget is:

> a) we are all volunteers

Most bug reporters (including me) are volunteers too.

Well managed projects treat good bug reports as a valuable resource
to increase the quality of the project. Others consider them a
nuisance which must be gotten rid of.

Always good to know which kind of project this is. I promise you I
won't bother you with any further bug reports.

Though it would be easier for everyone to know this up front, and
I'm only half kidding here. Maybe a flag can be introduced so
reportbug will say "maintainers don't really want any bug reports,
do you really need to continue?"

> b) we are not upstream

Then forward it to upstream.

Debian strongly recommends users to report bugs via reportbug (see
https://www.debian.org/Bugs/Reporting). That's well and good because
some bugs may be due to Debian specific changes (*cough* openssl).
But you know (I hope) who's upstream and can forward
non-Debian-specific bugs there.

> c) noone has looked at the project for several years

Now that's really bad, especially for such a program. And I guess
the last thing someone did was the change of GUI toolkits which is
of course the most important thing for a phone program (not!).

So I consider linphone a dead project now, that's all.

> d) not all bugs can be clearly reproduced.

We're not talking about all bugs, but one specific bug. My original
bug report gave a very easy and clear description how to reproduce
it. I don't think anyone actually tried to reproduce it.

Did you set it to "wontfix" at least?

Bug#980364: sudo: segfault when /var/lib/sudo/lectured not writable

[Frank Heckenbach]

Package: sudo
Version: 1.8.27-1+deb10u2
Severity: normal

On a system with disk errors, which had therefore remounted its
file systems read-only, I tried to sudo in order to do further
diagnostics as root, but sudo crashed with a segfault.

I think it should be possible (perhaps with a special option) to
continue without writing this file, even if it means I'll be
lectured again if I run sudo again soon. In a situation like this,
it might be more important to get root access at all.

Even if it won't do this, a segfault is certainly a bug.

% sudo su

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

[sudo] password for frank: 
sudo: unable to mkdir /var/lib/sudo/lectured: Input/output error
Segmentation fault

-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/24 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=de_DE 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sudo depends on:
ii  libaudit1   1:2.8.4-3
ii  libc6   2.28-10
ii  libpam-modules  1.3.1-5
ii  libpam0g1.3.1-5
ii  libselinux1 2.8-1+b1
ii  lsb-base10.2019051400

sudo recommends no packages.

sudo suggests no packages.

-- no debconf information

Bug#757582: closed by Bernhard Schmidt (Closing bugs opened for old Gtk client)

[Frank Heckenbach]

> you have reported a bug against Linhone 3.12 or earlier. This version
> has been deprecated upstream for a couple of years

Well, I did report the bug many years ago, so ...

> We are sorry we could not deal with your bug report in time.

s/could not/did not choose to/ !

You certainly could have if you wanted to!

Honestly, I don't understand why such kind of bugs don't have
highest priority for you. After all, phone calls are a real-time,
real-world activity with real consequences, so any bugs that affect
this core function should by definition be much more important than
changing the GUI toolking or other look&feel changes:

- Not terminating the call may not only confuse the party on the
  other side, but possibly also run up costs if it's a
  paid-by-the-minute connection which may be left open for a long
  time when the user thinks they have terminated.

- Likewise, another bug I had back then (losing its configuration,
  especially sound config, so when picking up a call, I'd sometimes
  get no audio, because it would use the default sound device
  instead of the headset I had configured) had real-world
  consequences, since the caller would hear just silence and assume
  the call didn't work or I didn't pick up, because I can't just fix
  the configuration and pick up again. (I could do this for incoming
  calls, not for outgoing calls.) I don't know if this bug is still
  open (can't find the bug report anymore, probably also too old).

> Unfortunately, due to depending on Qt 5.12+ linphone-desktop cannot be
> provided in buster-backports. If you can, please try the new client on
> testing and report bugs. If the issue is still present please feel free
> to reopen your bug.

Meanwhile, I have a different router from a different internet
provider, and I'd first have to learn if it supports a SIP server,
and if so, how to set it up.

This would take me some time, but honestly, why should I invest the
time, just to be able to confirm that the bug probably still exists,
so you can ignore it for some more years!?

I'm a software developer too, and I know that most bugs don't come
into existence by themselves, but are errors made in the source
code. Likewise, bugs don't just disappear by themselves unless
fixed.

So if you didn't address this bug at any time, it's rather safe to
assume that it's still present.

At this point it's probably less effort if you take the old linphone
sources to reproduce the bug with them, than for me to set up a new
test environment.

Otherwise, please at least be so honest and mark it as "wontfix", so
other users know what they're getting.

Bug#968757: command-not-found: breaks apt-get update

[Frank Heckenbach]

Package: command-not-found
Version: 18.04.5-1
Severity: critical
Justification: breaks unrelated software

% apt-get update
Hit:1 http://raspbian.raspberrypi.org/raspbian buster InRelease
Hit:2 http://archive.raspberrypi.org/debian buster InRelease
Traceback (most recent call last):
  File "/usr/lib/cnf-update-db", line 26, in 
col.create(db)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 94, 
in create
self._fill_commands(con)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 132, 
in _fill_commands
self._parse_single_contents_file(con, f, fp.stdout)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 271, 
in _parse_single_contents_file
priority = component_priorities[component]
KeyError: 'rpi'
Reading package lists... Done
E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test 
-w /var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then 
/usr/lib/cnf-update-db > /dev/null; fi'
E: Sub-process returned an error code

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv6l

Kernel: Linux 4.19.118+
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  10.2019051400+rpi1
ii  python3  3.7.3-1
ii  python3-apt  1.8.4.1

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

Bug#916783: Bug#917455: command-not-found: "command-not-found unable to open database file"

[Frank Heckenbach]

> It's a minor issue of a missing database that fixes itself the
> next time you run apt update.

I now found out, it does *NOT* fix itself. In contrast, it unfixes
itself! Even when I correct the permissions manually, they're wrong
some time later (probably after the next upgrade).

So the bug still exists, makes the package basically unusable
(actually worse than that -- more annyoing than helpful) and has
been reported many times for a long time now!

So can you please fix it finally, if it's so minor as you say?

Bug#929612: sispmctl: support EG-PMS2 aka usb-id 04b4:fd15

[Frank Heckenbach]

Still broken in stable and testing.

upstream 4.1 still works out of the box.

Does anyone read these bug reports at all?

Bug#961761: psmisc: killall fails to kill processes with names longer than 15 characters

[Frank Heckenbach]

> On Fri, 29 May 2020 at 09:21, Frank Heckenbach  
> wrote:
> > killall fails to kill processes with names longer than 15
> > characters.
> Actually it does. But the comm length has increased for some kernels.
> 
> If you're asking it to kill something with another name because the
> comm is "killall-bug-wit" not "killall-bug-with-long-names" it used to
> work even though the command is wrong because it just cut the extra
> characters off. This won't work when the comm length is increased.

Don't know what you mean by "the command is wrong" (I gave the full
name), and honestly I don't (and shouldn't have to) care about comm
length etc.

Fact is, it doesn't match the documented behaviour (in its own man
page!). It used to do so before. So it's clearly a regression.

Again, as I quoted, the man page says:

:   -e, --exact
:  Require an exact match for very long names.  If a command
:  name is longer than 15 characters, the full name may be
:  unavailable (i.e.  it is swapped  out). In  this case,
:  killall will kill everything that matches within the first
:  15 characters.  With -e, such entries are skipped.  [...]

So logically, there are two possibilities (without "-e"):

- The full name is available, in which case it should work since I
  gave the full name.

- The full name is not available, in which case it should also work
  since the first 15 characters match.

> $ ps -o comm 1739632
> COMMAND
> killall-bug-wit
> $ killall killall-bug-wit

I know that's a workaround. But as I wrote:

: I think that's at least "serious", because it makes killall by name
: basically unusable, at least in automated contexts, unless you want
: to replace:
:
:   killall "$x"
:
: everywhere with some beast such as (untested):
:
:   killall "$(echo "$x" | cut -c-15)"

The duplicate report you mention below also calls that problematic
"so I don't have to count letters when I'm typing into my shell, and
can write shellscripts that work regardless of what the kernel limit
is."

> However 23.3 has a work-around where if the comm length is exactly 15
> characters then it matches on this too.
> This is a duplicate of bug #912748 and fixed in psmisc 23.3-1

Then please provide a backport for buster (possibly even as a
security fix, as I explained).

Debian developers tend to forget that stable is the
release Debian itself recommends to use (see
https://www.debian.org/releases/index.en.html),
so if you leave such a serious bug unfixed, I guarantee
you'll get more duplicate reports!

Frank

Bug#961761: psmisc: killall fails to kill processes with names longer than 15 characters

[Frank Heckenbach]

Package: psmisc
Version: 23.2-1
Severity: serious

killall fails to kill processes with names longer than 15
characters.

According to the manpage:

  -e, --exact
 Require an exact match for very long names.  If a command
 name is longer than 15 characters, the full name may be
 unavailable (i.e.  it is swapped  out). In  this case,
 killall will kill everything that matches within the first
 15 characters.  With -e, such entries are skipped.  [...]

So without "-e" it should kill everything that matches within the
first 15 characters.

That was apparently the behaviour in previous versions, but that's
broken now. To reproduce:

(echo "#!/bin/sh"; echo "while true; do sleep 1; echo 'Still running!'; done") 
> killall-bug-with-long-names-demo
chmod 755 killall-bug-with-long-names-demo
./killall-bug-with-long-names-demo &
killall killall-bug-with-long-names-demo

I think that's at least "serious", because it makes killall by name
basically unusable, at least in automated contexts, unless you want
to replace:

  killall "$x"

everywhere with some beast such as (untested):

  killall "$(echo "$x" | cut -c-15)"

It could even have more adverse consequences if you rely on a script
killing some process with killall, which has worked before and
breaks now, especially if this process continues to waste resources
or give access to privileges you meant to stop etc. (That's almost
what happened to me when I found the problem, though in my case the
worst thing it caused, fortunately, was blocking a network port.)

In the worst case, this could be security-critical. (Not sure if
this justifies "grave"!?)

Sure, you may say one should check the status of each command,
including killall, but that's hard to do when the status is the
same (1) as in the case when the program isn't running at all, so
one would have to check with something like pidof before (which does
still find long program names), worry about race-conditions etc.

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=de_DE 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages psmisc depends on:
ii  libc62.28-10
ii  libselinux1  2.8-1+b1
ii  libtinfo66.1+20181013-2+deb10u2

psmisc recommends no packages.

psmisc suggests no packages.

-- debconf-show failed

Bug#940661: swh-plugins: analogueOsc produces NaN under some conditions (reloaded)

[Frank Heckenbach]

Package: swh-plugins
Version: 0.4.17-2
Severity: normal
Tags: upstream patch

The bug from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781997
has reappeared!

The same test program as given there fails again, even though my
patch from then has been applied.

I suppose this is due to more aggressive optimizations by newer
compiler versions, in connection with the "-ffast-math" option.

In particular, my isnan() check doesn't work because "-ffast-math"
ignores NaNs (see https://stackoverflow.com/a/38981307).

So I tried a different fix now by checking for the problematic case
before NaN is produces. This seems to work for me.

This patch undoes my previous patch, so it's to be applied on top of
it.

It also fixes another instance of the problem (which my previous
patch didn't) that occurs when q is close to zero, i.e. when warm is
close to 0.999f (which is in the valid range!).

Though I wonder if "-ffast-math" should be used at all. As another
answer on the SO page linked above says: "No, you cannot safely use
-ffast-math except on code designed to be used with it. There are
all sorts of important constructs for which it generates completely
wrong results." I think edge cases like the one causing this problem
are exactly the kind of things one must watch out for when using
"-ffast-math", so I wonder if the code has actually been checked
carefully for "-ffast-math" compatibility. If not, it might be
worthwhile to sacrifice a few CPU cycles for correct results. Of
course, that's a bigger decision that I can't make in a bug fix, but
you may want to consider it.
--- analogue_osc_1416.xml
+++ analogue_osc_1416.xml
@@ -59,12 +59,13 @@
 rnda *= 59;
 osc->ph.all += (((rnda + rndb)/2) % max_jump) - max_jump/2;
 osc->ph.all &= osc->ph_mask;
-	y = (x - q) / (1.0f - f_exp(-1.2f * (x - q))) +
-  q / (1.0f - f_exp(1.2f * q));
-	/* Catch the case where x ~= q */
-	if (isnan(y) || fabs(y) > 1.0f) {
-		y = 0.8f + q / (1.0f - f_exp(1.2f * q));
-	}
+	/* If x - q or q are close to 0, these computations would produce NaN.
+	   To avoid this, substitute the limit instead -- the results aren't
+	   noticeably different (in float) from the limit already around 1e-8. */
+	y = fabs(x - q) < 1e-10 ? 0.8f
+	  : (x - q) / (1.0f - f_exp(-1.2f * (x - q)));
+	y += fabs(q) < 1e-10 ? -0.8f
+	   : q / (1.0f - f_exp(1.2f * q));
 	otm2 = otm1;
 otm1 = leak * otm1 + y - itm1;
 itm1 = y;

Bug#940218: gpg: --textmode doesn't work in verify mode

[Frank Heckenbach]

Package: gpg
Version: 2.2.12-1
Severity: normal
Tags: upstream

I got a number of "invalid signatures" recently, and when I
investigated, I found that the "--textmode" option apparently has no
effect during verify operations, unlike what I expected, so I had to
manually convert the input to CR/LF to get successful verification.

Ideally, of course, I'd like "--textmode" to work in verify. If
that's not feasible, it should at least be made clear that it
doesn't in the documentation, including the man page. Currently it
just says:

  -t, --textmode

  Treat input files as text and store them in the OpenPGP canonical
  text form with  standard  "CRLF"  line endings. [...]

One might argue that "input files" implies that it's only for
signing, but the text is an input, too, during verify, and nothing
else states that it doesn't apply to verify. Making that clear would
at least have saved me some searching and experimenting.

Of course, it would have been better if the signatures were created
in text mode, but that's on the sender's side which I probably can't
influence easily.

(It's probably an upstream problem, but reporting a bug upstream
requires a login, and I don't feel like creating an account there
just for that. So please don't ask me to forward it upstream, but do
it yourself when necessary.)

-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE=de_DE 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gpg depends on:
ii  gpgconf2.2.12-1
ii  libassuan0 2.5.2-1
ii  libbz2-1.0 1.0.6-9.2~deb10u1
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libgpg-error0  1.35-1
ii  libreadline7   7.0-5
ii  libsqlite3-0   3.27.2-3
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages gpg recommends:
ii  gnupg  2.2.12-1

gpg suggests no packages.

-- debconf-show failed

Bug#929612: sispmctl: support EG-PMS2 aka usb-id 04b4:fd15

[Frank Heckenbach]

Can confirm. Present version in buster doesn't work,
upstream 4.1 works out of the box.

Bug#917455: command-not-found: "local variable 'cnf' referenced before assignment" shown when entering an unknown command

[Frank Heckenbach]

> ack. I misremembered. It's funny that it works fine for its
> entire lifetime in Ubuntu, and only Debian users seem to be
> using different umasks for root. Kind of a niche thing.

Though it's getting off-topic, a reason may be that Ubuntu is used
more often on personal desktops (where, honestly, permissions don't
matter that much) and Debian more on servers -- I think, having a
world-readable umask as root is a bit too dangerous (and for that
matter, also as a user on a multi-user system, see xkcd 1200 :).

Bug#917455: command-not-found: "local variable 'cnf' referenced before assignment" shown when entering an unknown command

[Frank Heckenbach]

> It's a minor issue of a missing database that fixes itself the
> next time you run apt update.

1. If it's so easy, why wasn't it mentioned before?

2. Didn't work for me, neither "apt update", nor "apt-get update"
   (which I normally use).

3. After some digging, I found a solution that actually works:

   chmod 644 /var/lib/command-not-found/commands.db

4. The actual bug is not setting a correct umask in
   update-command-not-found. Was OK in stetch.

5. To reproduce:

   rm -f /var/lib/command-not-found/*
   umask=77
   update-command-not-found

   Then try to use it as non-root.

Bug#917455: command-not-found: "local variable 'cnf' referenced before assignment" shown when entering an unknown command

[Frank Heckenbach]

I get the same crash every time!

Is there any workaround? Otherwise, it seems the package is totally
broken. Shouldn't this be "grave" then?

And why include it in the stable release at all if it doesn't work?
I've seen packages banned for less severe reasons.

Apparently, the problem has been known and not fixed for more than
half a year, i.e. during the total freeze time. Isn't that what
freezes are for?

Bug#926702: dvb-apps: alevt: Font size too small

[Frank Heckenbach]

Package: dvb-apps
Version: 1.1.1+rev1500-1.1
Severity: normal
File: /usr/bin/alevt
Tags: patch upstream

The font size of alevt is very small on modern display sizes and
resolutions.

The same problem was reported on another distribution over 10 years
ago (https://bugzilla.redhat.com/show_bug.cgi?id=459294), but
apparently the patch never made it back upstream or to Debian. I've
rebased the patch provided there
(https://src.fedoraproject.org/rpms/alevt/blob/master/f/alevt-1.6.2-doublefont.patch)
against the current version and it still works (tested).

Interestingly, alevt.patch added this as a to-do item in 2010 (long
time ago, but *after* the patch above was already made) ...

--- linuxtv-dvb-apps-1.1.1+rev1457.orig/util/alevt/TODO 2011-12-08 
01:26:50.0 +1100
+++ linuxtv-dvb-apps-1.1.1+rev1457/util/alevt/TODO  2012-01-05 
22:23:33.0 +1100
-Hi, these are issues that I unfortunately cannot resolve myself:
+These are issues that I unfortunately cannot resolve myself:
[...]
+3. New BDF fonts for slightly bigger windows.
+Those BDF fonts need to be edited so that they can be transformed by 
bdf2xbm.
-Uwe Bugla, February 11th, 2010.
+Uwe Bugla, February 14th, 2010.
--- ./util/alevt/alevt.1
+++ ./util/alevt-doublefont/alevt.1
@@ -21,6 +21,9 @@
 .TP
 .B \-cs -charset 
 character set
+.BR \-doublefont / \-df
+Instructs alevt to use double sized fonts.
+.TP
 .TP
 .B \-h -help
 print this page
--- ./util/alevt/exp-gfx.c
+++ ./util/alevt-doublefont/exp-gfx.c
@@ -15,7 +15,16 @@
 int c, int dbl, int _x, int _y, int sep)
 {
   int x,y;
-  unsigned char* src= (latin1==LATIN1 ? font1_bits : font2_bits);
+  unsigned char* src = double_font ? 
+			( (latin1==LATIN1) ? font1_bits : 
+			  ( (latin1==LATIN2) ? font2_bits : 
+			  ( (latin1==KOI8) ? font3_bits :
+			  ( (latin1==GREEK) ? font4_bits : /* fallback */ font1_bits) ) ) ) 
+			  :
+			( (latin1==LATIN1) ? font1d_bits : 
+			  ( (latin1==LATIN2) ? font2d_bits : 
+			  ( (latin1==KOI8) ? font3d_bits :
+			  ( (latin1==GREEK) ? font4d_bits : /* fallback */ font1d_bits) ) ) );
   int dest_x=_x*CW;
   int dest_y=_y*CH;
   
--- ./util/alevt/font.c
+++ ./util/alevt-doublefont/font.c
@@ -3,3 +3,14 @@
 #include "font2.xbm"
 #include "font3.xbm"
 #include "font4.xbm"
+ 
+#include "font1d.xbm"
+#include "font2d.xbm"
+#include "font3d.xbm"
+#include "font4d.xbm"
+ 
+int CW;
+int CH;
+int double_font = 0;
+int font_width;
+int font_height;
--- ./util/alevt/font.h
+++ ./util/alevt-doublefont/font.h
@@ -1,19 +1,31 @@
 #ifndef FONT_H
 #define FONT_H
 
-#include "fontsize.h" /* the #defines from font?.xbm */
+// #include "fontsize.h" /* the #defines from font?.xbm */
 
-#if font1_width != font2_width || font1_height != font2_height
-#error different font sizes.
-#endif
+//#if font1_width != font2_width || font1_height != font2_height
+//#error different font sizes.
+//#endif
 
 extern unsigned char font1_bits[];
 extern unsigned char font2_bits[];
 extern unsigned char font3_bits[];
 extern unsigned char font4_bits[];
 
-#define font_width font1_width
-#define font_height font1_height
-#define CW (font_width/32) /* pixel width of a character */
-#define CH (font_height/8) /* pixel height of a character */
+extern unsigned char font1d_bits[];
+extern unsigned char font2d_bits[];
+extern unsigned char font3d_bits[];
+extern unsigned char font4d_bits[];
+
+//#define font_width font1_width
+//#define font_height font1_height
+//#define CW (font_width/32) /* pixel width of a character */
+//#define CH (font_height/8) /* pixel height of a character */
+
+extern int CW;
+extern int CH;
+extern int double_font;
+extern int font_width;
+extern int font_height;
+
 #endif
--- ./util/alevt/main.c
+++ ./util/alevt-doublefont/main.c
@@ -22,6 +22,12 @@
 static int ttpid = -1;
 u_int16_t sid = 0;
 
+/* Double font size related variables */
+extern int double_font;
+extern int font_width;
+extern int font_height;
+extern int CW;
+extern int CH;
 
 static void usage(FILE *fp, int exitval)
 {
@@ -33,6 +39,7 @@
 	"-ch -child \t\t(none)\n"
 	"-cs -charset\t\tlatin-1\n"
 	"\n"
+	"-doublefont\n"
 	"-h -help\n"
 	"-o \t\t(none;dvb only)\n"
 	"-p -parent \t\t900\n"
@@ -127,6 +134,7 @@
 	{ "-sid", "-s", 1 },
 	{ "-ttpid", "-t", 1 },
 	{ "-vbi", "-v", 1 },
+	{ "-doublefont", "-df", 0 },
 };
 int i;
 if (*ind >= argc)
@@ -159,6 +167,12 @@
 char *arg;
 sid = 0;
 
+font_width  = 288;
+font_height = 128;
+
+CW = (font_width/32);
+CH = (font_height/8);
+
 setprgname(argv[0]);
 fdset_init(fds);
 
@@ -189,6 +203,13 @@
 		else
 		fatal("bad charset (not latin-1/2/koi8-r/iso8859-7)");
 		break;
+	case 10:	// Doublefont
+		double_font = 1;
+		font_width  = 576;
+		font_height = 256;
+		CW = (font_width/32);
+		CH = (font_height/8);
+		break;
 	case 4: // help
 		usage(stdout, 0);
 		break;
--- ./util/alevt/Makefile
+++ ./util/alevt-doublefont/Makefile
@@ -33,9 +33,10 @@
 alev

Bug#925516: libreoffice: Extension Manager: exception in synchronize

[Frank Heckenbach]

Package: libreoffice
Version: 1:5.2.7-1+deb9u5
Severity: normal

This is the same bug as #853149 which was closed on a formality
(reported against the wrong package due to confusing naming -- a
base is a base and a database is a database, isn't it ... anyway).

How to reproduce:

- Start libreoffice as root and open a .doc file, exit.

=> An empty directory
   /var/spool/libreoffice/uno_packages/cache/uno_packages
   with mode 700 is created.

- Start libreoffice as a normal user

=> Gives error as in subject.

As reported in #853149, making this directory world-readable
(704 suffices) removes the error. Alternatively, removing the
directory entirely also helps.

I know one should not run libreoffice as root (I did it by
accident), but even though, I think it should not render itself
unusable by normal users then.

-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE= 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libreoffice depends on:
ii  dpkg   1.18.25
ii  fonts-dejavu   2.37-1
ii  libreoffice-avmedia-backend-gstreamer  1:5.2.7-1+deb9u5
ii  libreoffice-base   1:5.2.7-1+deb9u5
ii  libreoffice-calc   1:5.2.7-1+deb9u5
ii  libreoffice-core   1:5.2.7-1+deb9u5
ii  libreoffice-draw   1:5.2.7-1+deb9u5
ii  libreoffice-impress1:5.2.7-1+deb9u5
ii  libreoffice-java-common1:5.2.7-1+deb9u5
ii  libreoffice-math   1:5.2.7-1+deb9u5
ii  libreoffice-report-builder-bin 1:5.2.7-1+deb9u5
ii  libreoffice-writer 1:5.2.7-1+deb9u5
ii  python3-uno1:5.2.7-1+deb9u5

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-1
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-linuxlibertine5.3.0-2
ii  fonts-sil-gentium-basic 1.1-7
ii  libreoffice-librelogo   1:5.2.7-1+deb9u5
ii  libreoffice-nlpsolver   0.9+LibO5.2.7-1+deb9u5
ii  libreoffice-ogltrans1:5.2.7-1+deb9u5
ii  libreoffice-pdfimport   1:5.2.7-1+deb9u5
ii  libreoffice-report-builder  1:5.2.7-1+deb9u5
ii  libreoffice-script-provider-bsh 1:5.2.7-1+deb9u5
ii  libreoffice-script-provider-js  1:5.2.7-1+deb9u5
ii  libreoffice-script-provider-python  1:5.2.7-1+deb9u5
ii  libreoffice-sdbc-postgresql 1:5.2.7-1+deb9u5
ii  libreoffice-wiki-publisher  1.2.0+LibO5.2.7-1+deb9u5

Versions of packages libreoffice suggests:
ii  cups-bsd   2.2.1-8+deb9u3
ii  default-jre [java5-runtime]2:1.8-58
ii  gstreamer1.0-libav 1.10.4-1
ii  gstreamer1.0-plugins-bad   1.10.4-1
ii  gstreamer1.0-plugins-base  1.10.4-1
ii  gstreamer1.0-plugins-good  1.10.4-1
pn  gstreamer1.0-plugins-ugly  
ii  hunspell-en-us [hunspell-dictionary]   20070829-7
pn  hyphen-hyphenation-patterns
ii  iceweasel  60.6.1esr-1~deb9u1
ii  imagemagick8:6.9.7.4+dfsg-11+deb9u6
ii  imagemagick-6.q16 [imagemagick]8:6.9.7.4+dfsg-11+deb9u6
ii  libgl1-mesa-glx [libgl1]   13.0.6-1+b2
pn  libreoffice-gnome | libreoffice-kde
pn  libreoffice-grammarcheck   
pn  libreoffice-help-5.2   
pn  libreoffice-l10n-5.2   
pn  libreoffice-officebean 
ii  libsane1.0.25-4.1
ii  libxrender11:0.9.10-1
pn  myspell-dictionary 
pn  mythes-thesaurus   
pn  openclipart2-libreoffice | openclipart-libreoffic  
ii  openjdk-8-jre [java5-runtime]  8u212-b01-1~deb9u1
pn  pstoedit   
pn  unixodbc   

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.7+b1
ii  fonts-opensymbol  2:102.7+LibO5.2.7-1+deb9u5
ii  libboost-date-time1.62.0  1.62.0+dfsg-4
ii  libc6 2.24-11+deb9u4
ii  libcairo2 1.14.8-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

> > > Hmm, simply "./autogen.sh && ./configure && make -j" does build it
> > > for me (though with some warnings), using stretch. Does that work
> > > for you? If so, it must be something in the Debian rules; otherwise
> > > it seems to be difference between stable and testing which may be
> > > worth investigating as it may affect others too. What errors do you
> > > get?
> >
> > The compilation doesn't exercise some options if you don't have all
> > packages installed, like doxygen-gen.

Do you mean doxygen-doc? (I don't see any doxygen-gen.) I installed
this now (and had installed doxygen and doxygen-latex before) and it
still works for me.

> > Most of the build is OK, but pdflatex chokes when genereting the .pdf.
> > You can see the failure here:
> >   
> > http://debomatic-amd64.debian.net/distribution#unstable/ftgl/2.3.0-3/buildlog
> >
> > Note that the above is for the previous version, so it must have
> > happened due to changes in other Debian packages.  The problem might
> > be in the doc though, that now fails due to more strict tools that are
> > not going to be changed -- not sure.

To narrow it down, does it work if you build it manually (see
above)?

> BTW I included a patch that I noticed, fixing a duplicated entry in
> projects_using_ftgl.txt, please try to apply it.

Done.

Cheers,
Frank

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

> I checked and everything looks all right, but I've been fighting for
> 1+ hours because it cannot generate the ftgl.pdf documentation.

Hmm, simply "./autogen.sh && ./configure && make -j" does build it
for me (though with some warnings), using stretch. Does that work
for you? If so, it must be something in the Debian rules; otherwise
it seems to be difference between stable and testing which may be
worth investigating as it may affect others too. What errors do you
get?

Cheers,
Frank

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

> The idea of using both RenderDefault() and RenderBasic() as well as
> the flag, would equally work if you have just Render() and the
> behaviour of one render or the other nested in an "if/else" based on
> the flag.  Whatever makes more sense to you.  I suggested it because
> in that way it is easier to change or patch the packages.

Creating the two versions would be a lot more work, and in the end
packages need to be patched anyway.

> Let me know when it's ready, I'll try to upload the new version within
> the same day that you have the new release ready.

I did it, and briefly tested it with my code.

I think you can upload it and other packages should see no change in
behaviour for now.

But please remember (see ~/work/ftgl/README-LegacyOpenGLState),
after the release of Buster, add

  FTLibrary::Instance().LegacyOpenGLState(true);

and depend on ftgl>=2.4.0 in all packages that use FTGL.

Cheers,
Frank

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

> > My suggestion of 2018-11-25 still stands. But if you want me to do
> > my part of it, please do your review quickly and tell me soon
> > (or, if it's indeed necessary for the soft freeze, immediately) to
> > avoid running out of time.
> 
> Your plan sounds OK.  Changing packages after the release, with time,
> should be OK.  I can submit automatic bug reports for the affected
> packages.

OK.

> Maybe it would even be possible to have the applications set a global
> variable, e.g.:
> 
>   enum class Render { Default = 1, Basic };
>   FTGL->setRender(Render  renderType);
> 
> and then the Render() function(s) would dispatch to either
> RenderDefault() or RenderBasic() versions as appropriate?

I generally don't much like global flags, but in this particular
case, it might be the least painful approach.

It wouldn't be foolproof. If two pieces of code, e.g. libraries,
that are used in the same program, use Render() with different
settings of this flag, one of them would do the wrong thing. (And
manually changing this flag every time code from the other library
may be used would be a maintenance nightmare.)

So maybe the following is even easier to implement, while also not
foolproof:

- No RenderDefault() and RenderBasic(), just Render() as is.

- A flag similar to your proposal (though I wouldn't actually call
  it "Render..."; if we aren't renaming the Render functions, we can
  use a more specific name), such as LegacyOpenGLState, and it can
  be a bool actually.

- However, ftgl will only allow setting this flag to one value ever
  (but any number of times, so libraries that expect the same
  setting can work together). I.e., if it's set to false, further
  calls setting it to false will succeed, but a call setting it to
  true will abort, indicating a mix of incompatible code pieces; and
  vice versa.

  If it's never set, if will default to true (legacy behaviour);
  I'll have to accept that.

- In my code I'll set it to false; likewise for others relying on
  this behaviour. (My code actually contains libraries using ftgl,
  so I'll make sure to set it from within the libraries, rather than
  the programs using them.)

- Programs relying on the "old" behaviour need no change
  immediately, but should soon (so for Debian, after the release of
  Buster), add a "true" call. This would be a single line change
  near the start, so easy to do even if it affects a number of
  packages.

- Both kinds of program will need to require ftgl>=2.4.0 because of
  the new call.

- Sometime in the future, I hope I can require setting this flag,
  first with a warning, later with an error if it's not set before
  the first rendering. Provided you've added the call to all
  packages by then, nothing will break.

Cheers,
Frank

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

> Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
>  escreveu:
> >
> > According to https://release.debian.org/buster/freeze_policy.html:
> >
> > 2019-01-12 - Transition freeze
> >
> > Is there still time yet to get a fix in, or is it FUBAR already?
> 
> Transition freeze means ABI changes in libraries are forbidden.  We're
> almost in soft-freeze now, more info at:
> https://lists.debian.org/debian-devel-announce/2019/01/msg8.html

So do we have time until the soft freeze on 2019-02-12 (I hope not)
or the full freeze (2019-03-12) to get a 2.4.0 uploaded?

> I have to review the situation again, I completely swapped it out of
> my memory.

My suggestion of 2018-11-25 still stands. But if you want me to do
my part of it, please do your review quickly and tell me soon
(or, if it's indeed necessary for the soft freeze, immediately) to
avoid running out of time.

> Assuming that the changes in a new release do not change
> other behaviour, or that I can cherry pick a targeted fix for this
> problem, we're still good to go.

Not much to cherry pick AFAICS. This issue is the only discrepancy
between our versions and if we find a (transitory) solution, we'll
be in sync.

Cheers,
Frank

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

According to https://release.debian.org/buster/freeze_policy.html:

2019-01-12 - Transition freeze

Is there still time yet to get a fix in, or is it FUBAR already?

Frank

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

Hi Manuel,

> > That seems to me the best solution indeed. So I can offer this:
> >
> > - I add these two new versions for all functions involved (quite a
> >   few); we'd just need to agree about naming ("old" and "new" won't
> >   do, since in this complicated situation it's not even clear which
> >   one is old and which one is new; different users will view it
> >   differently, just like in special relativity ;), also "old" and
> >   "new" in function names always sounds silly; so perhaps something
> >   like "RenderBasic" and "RenderDefault" or so ...).
> >
> > - I deprecate the "Render" functions, adding a special README to
> >   explain things.
> >
> > - I change my sources to use "RenderBasic" (or whatever it'll be
> >   called) and test them. Other users of this fork will have to do
> >   the same (hopefully after seeing the deprecation warnings and
> >   reading that README).
> >
> > - I release 2.4.0 with those changes.
> >
> > - You put 2.4.0 in Debian. Applications using it will get the
> >   deprecation warnings, but should otherwise work.
> >
> > - A bit later, I remove the deprecated functions and release 3.0.0.
> >
> > - After the release of Buster, you put 3.0.0 in Debian with the
> >   required transitions.
> >
> > - Applications using it will break, but fixing them will only
> >   require changing "Render" to "RenderDefault" in some places
> >   (which are found by compiler errors). This can also be done before
> >   you upload 3.0.0 (as "RenderDefault" will be available in 2.4.0
> >   already), so the transition can be smoohter.
> >
> > Does this sound like a viable plan?
> 
> I am not sure if I understand.  According to your plan, do the
> applications in Debian using ftgl will need to change anything at all
> to keep working?  Because there's not much time for making changes
> before the freeze, I will be quite busy for a couple of weeks at least
> (so please excuse delays in replies if they don't arrive in a timely
> manner), and changes of this kind usually take months to be
> accomplished.  It's not like we can commit changes to one or several
> git repos and rebuild the packages, it's quite more complex than that.
>
> IMO from the Debian side and for Buster there's no material time for
> changes to all packages that depend on fgtl, the only practical
> solutions are either to revert the change making some applications
> unuseable via extra patch from Debian; or have this transition and
> deprecation messages etc. in a way that existing packages don't need
> changes at all.
> 
> Sorry, but I don't think that anything else works for Buster.

As I said, in the first step (2.4.0), they should not (assuming some
new warnings while recompiling are no problems).

Some changes will be necessary for 3.0.0, after Buster.

Cheers,
Frank

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

Hi,

coming back to my own mail, after thinking about it some more:

: > And I think that the default would have to be the old behaviour, yes,
: > because after many years behaving in that way the applications must
: > have learned to adapt or cope, and no one knows that they have to use
: > a different flag or invoke the method with an extra parameter.
:
: For some value of "the applications". You're talking about Debian
: only again, of course, but there are other applications that have
: come to expect the new behaviour (obviously at least mine and the
: patch author's ones, possibly more -- there's a number of forks of
: FTGL on github, probably by people who use(d) it).
:
: > I realise that maybe this is not what you like because applications
: > will ever remain buggy, but reallistically,
:
: The same applies vice-versa for applications that rely on the new
: behaviour if we make the old one the default.
:
: The problem is we have different semantics already (and for almost
: 10 years apparently).
:
: Perhaps the only sane way out is to add *two* new versions of each
: rendering function, one with each behaviour, and deprecate the old
: ones entirely. This will require changes in all applications (if
: only to select the correct one of the two which should be easy if
: ones knows which branch of the library they used before), but at
: least it will be clear at compile time.

That seems to me the best solution indeed. So I can offer this:

- I add these two new versions for all functions involved (quite a
  few); we'd just need to agree about naming ("old" and "new" won't
  do, since in this complicated situation it's not even clear which
  one is old and which one is new; different users will view it
  differently, just like in special relativity ;), also "old" and
  "new" in function names always sounds silly; so perhaps something
  like "RenderBasic" and "RenderDefault" or so ...).

- I deprecate the "Render" functions, adding a special README to
  explain things.

- I change my sources to use "RenderBasic" (or whatever it'll be
  called) and test them. Other users of this fork will have to do
  the same (hopefully after seeing the deprecation warnings and
  reading that README).

- I release 2.4.0 with those changes.

- You put 2.4.0 in Debian. Applications using it will get the
  deprecation warnings, but should otherwise work.

- A bit later, I remove the deprecated functions and release 3.0.0.

- After the release of Buster, you put 3.0.0 in Debian with the
  required transitions.

- Applications using it will break, but fixing them will only
  require changing "Render" to "RenderDefault" in some places
  (which are found by compiler errors). This can also be done before
  you upload 3.0.0 (as "RenderDefault" will be available in 2.4.0
  already), so the transition can be smoohter.

Does this sound like a viable plan?

Cheers,
Frank

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

Hi,

> Em qua, 21 de nov de 2018 às 15:15, Frank Heckenbach
>  escreveu:
> >
> > > I think that we should revert this change for the time being, though,
> > > because if it was working in this way for about a decade and the
> > > programs using FTGL worked "fine" despite having some bug there,
> >
> > Sorry, they did *NOT* all work fine, see my bug report.
> 
> I agree with that, that's why I said "fine" with quotes included.  I
> thought about adding "(for some value of 'fine')", but stopped short
> :-)
> 
> However, from how I understand it, having completely blank rectangles
> in the position of letters (which happens with critterding and
> darkradiant for example) is worse than what happened before in your
> original report -- it would perhaps be the worst case scenario of what
> could happen before.

For some value of "worse". For me, it could as well draw unicorn
rainbows; shipping my software with wrong colour effects is simply
inacceptable.

> Is there a way to easily determine when the applications are buggy by
> searching the code?  Maybe we can find an upper limit to the
> problematic applications, or provide patches, if feasible.

The upper limit is of course, all applications that use FTGL and
render letter (which is probably the same as all applications that
use FTGL at all). As things can be resolved differently in the
caller (which is basically the purpose of the change), I don't think
there's an easy way to check it automatically.

> > - A slightly more complex solution would be a flag to select the
> >   behaviour. Of course, it would need to be a runtime flag. It may
> >   default to the old behaviour, but that should be deprecated (and
> >   print a strong depreciation message -- unfortunately that would
> >   have to be at runtime too AFAICS, or is there a way to warn at
> >   compile time when a program, say, does *not* reference a
> >   particular function?).
> 
> I am not familiar with OpenGL stuff.  Is there a way to detect if a
> "Blending Mode" is provided at runtime, when the function is called,
> and if not, provide a default one like the one before, and possibly
> emitting errors for it to raise attention (both compile time and
> runtime)?

All I know is that OpenGL state is a complex beast, and even if
there's a way to query relevant info, it wouldn't be recommended as
it adds a round-trip and thus latency. OpenGL is supposed to be used
unidirectionally as much as possible. And it would smell like a
kludge anyway.

> Another option would be to have an extra argument in the function, say:
> 
>   inline FTPoint FTBitmapFontImpl::RenderI(const T* string,
>const int len,
>FTPoint position,
>FTPoint spacing,
>int renderMode,
>bool disableBlend = false);

Apart from the (slight) runtime overhead, this seems to make it hard
to change the default to the new behaviour later.

> Or perhaps a new function to enable/disable globally if the library is
> initialised, or an env flag, or similar.

That's more like what I had in mind. But if the default is the old
behaviour if this function is not called, and we want to deprecate
this, we can only warn at runtime (unless, as I said, there's a way
to find out at compile time that the function is not referenced --
sure, one could reference the function without calling it, but that
would be malicious, not worth worrying about).

> And I think that the default would have to be the old behaviour, yes,
> because after many years behaving in that way the applications must
> have learned to adapt or cope, and no one knows that they have to use
> a different flag or invoke the method with an extra parameter.

For some value of "the applications". You're talking about Debian
only again, of course, but there are other applications that have
come to expect the new behaviour (obviously at least mine and the
patch author's ones, possibly more -- there's a number of forks of
FTGL on github, probably by people who use(d) it).

> I realise that maybe this is not what you like because applications
> will ever remain buggy, but reallistically,

The same applies vice-versa for applications that rely on the new
behaviour if we make the old one the default.

The problem is we have different semantics already (and for almost
10 years apparently).

Perhaps the only sane way out is to add *two* new versions of each
rendering function, one with each behaviour, and deprecate the old
ones entirely. This will require changes in all applic

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

Hi,

> I think that we should revert this change for the time being, though,
> because if it was working in this way for about a decade and the
> programs using FTGL worked "fine" despite having some bug there,

Sorry, they did *NOT* all work fine, see my bug report. And if we
apply my patch from 742469 instead, that might break programs in
other ways (and will require yet another breaking change in the
future, when we apply sammy's patch properly).

> there's no need to change this now and break applications with only a
> few weeks to fix this in 15+ other packages before the freeze.

For me, there was very much a need to change. This was one of the
reasons I started working on ftgl at all if you remember. Without
either fix (sammy's or mine), ftgl is useless to me, so I'm not
gonna do this in my repo.

> Otherwise we have to get the fix in several of this packages, which is
> way more difficult, specially if not well maintained in Debian,
> upstream or both.

As I said, it's a messy situation. A bug that was actually fixed in
2009, not applied downstream, rediscovered by me in 2014, and
accidentally pulled downstream by syncing from the repo you pointed
me do early this year (which I had (naively?) assumed to be mostly
in sync with your version). I'm used to bugs in Debian getting
ignored for years and the wontfixed (or silenly buried), but that
mess seems to be special even in comparison.

So what can we actually do now?

- If you view it as an ABI breaking change, I can bump the version
  to 3.0.0, just let me know. (This would mean that programs using
  the library would need to be rechecked anyway, right? So if we
  document this prominently, they'll know what to look for, both in
  source code and in program behaviour.)

- If you insist on a version without either of those bugfixes, do
  this in your code, but then I'm out, sorry. For me this will mean
  at least 2 more years working with an out-of-distro version (and I
  fear it would get neglected again, so maybe more like 10 more
  years or forever), so I'd have no reason to care about the distro
  version.

- Otherwise just let the other packages find and fix the resulting
  bugs, like the saying goes "better ask for forgiveness than for
  permission".

- A slightly more complex solution would be a flag to select the
  behaviour. Of course, it would need to be a runtime flag. It may
  default to the old behaviour, but that should be deprecated (and
  print a strong depreciation message -- unfortunately that would
  have to be at runtime too AFAICS, or is there a way to warn at
  compile time when a program, say, does *not* reference a
  particular function?).

Cheers,
Frank

Bug#914153: Update to version 2.3.0-3 breaks Megaglest

[Frank Heckenbach]

Hi Evgeny,

> >After updating libftgl2 from version 2.1.3~rc5-5 to version 2.3.0-3, text 
> >rendering in Megaglest is broken. Text is shown correctly in menus, but text 
> >displayed in the game itself is replaced by white rectangles.
> 
> Thanks for the report.
> 
> Any idea of what's going on, Frank?
> 
> For me it works in some menus, there are white squares in others.  zaz,
> another application using ftgl, seems to work fine, while critterding
> also shows white squares.

That's probably a consequence of a fix made by sammy in 2009(!)
(commit 29603ae: "Remove GL_BLEND tampering. It's the caller
application's responsibility to enable or disable blending").

For some reason, that patch (and a few others) hadn't made it into
Debian before and only now got in as a "bycatch" when we
synchronized everything.

Though it is an incompatible change, it was a necessary one, since
what the library did before was wrong (which prompted a bug report
of my own, #742469 which would solve it for some particular cases
while adding a dependency on GL_GLEXT_PROTOTYPES). So the better
solution is probably the earlier (and now current) one which puts
the responsibility on the caller.

I had seen the same problem in another test program recently, and in
this case it helped to add the following two lines in an appropriate
place. You can try the same in your code (shouldn't hurt if compiled
with older ftgl versions as well):

  glEnable(GL_BLEND);
  glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

Or, if you like a better blending function (see my description in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742469), you can
use this instead:

#define GL_GLEXT_PROTOTYPES

  glEnable(GL_BLEND);
  glBlendFuncSeparate(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
  GL_ONE, GL_ONE_MINUS_SRC_ALPHA);

Regards,
Frank

Bug#905033: xserver-xorg-input-elographics: locks up system on EOF from touchscreen

[Frank Heckenbach]

Package: xserver-xorg-input-elographics
Version: 1:1.4.1-1
Severity: normal
Tags: patch

When reading from the touchscreen device returns 0 (EOF), the driver
goes into an endless loop of poll and read. This locks up the Xorg
server, and when trying to kill it with -9, it hangs the whole
system (no idea how it manages to do that, but only an unfriendly
reboot seems to help):

  watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [Xorg:3781]

Patch to handle EOF like error return:

--- src/xf86Elo.c
+++ src/xf86Elo.c
@@ -251,6 +251,10 @@
 ErrorF("System error while reading from Elographics touchscreen.");
 return !Success;
   }
+  if (num_bytes == 0) {
+ErrorF("EOF while reading from Elographics touchscreen.");
+return !Success;
+  }
   DBG(4, ErrorF("Read %d bytes\n", num_bytes));
 
   while (num_bytes) {

Well, I thought that would help, but it didn't. Seems I
misunderstood the comment above: "Okay, give up."

That's not what I understand by giving up, it still keeps retrying
and spamming the log with "EOF while reading from Elographics
touchscreen." -- at this point I also noticed the missing "\n" in
the error messages.

So without changing too much (the fd is passed by value, so I can't
easily change it; also I don't know when this function is called
from where etc.), for a quick and dirty solution I just reassign the
fd to something harmless. /dev/null doesn't work as it always
returns ready in poll and EOF in read too, so I create a pipe,
discard one end, so the other end will be not ready for reading.
This seems to work for me, but a permanent solution should probably
do something more elegant:

--- src/xf86Elo.c
+++ src/xf86Elo.c
@@ -58,6 +58,8 @@
 
 #include "xf86Module.h"
 
+#include 
+
 /**
  * models to be treated specially.
  */
@@ -248,7 +250,18 @@
* Okay, give up.
*/
   if (num_bytes < 0) {
-ErrorF("System error while reading from Elographics touchscreen.");
+ErrorF("System error while reading from Elographics touchscreen.\n");
+return !Success;
+  }
+  if (num_bytes == 0) {
+/*
+ * Avoid reading from fd again, quick and dirty. Discard one end of a pipe,
+ * so the other end never gets EOF (unlike /dev/null) or reads anything.
+ */
+int dummy[2];
+pipe(dummy);
+dup2(dummy[0], fd);
+ErrorF("EOF while reading from Elographics touchscreen.\n");
 return !Success;
   }
   DBG(4, ErrorF("Read %d bytes\n", num_bytes));

Bug#905015: xserver-xorg-input-elographics: Xorg hangs on start when touchscreen does not answer

[Frank Heckenbach]

Package: xserver-xorg-input-elographics
Version: 1:1.4.1-1
Severity: normal
Tags: patch

See subject.

Reason: ELO_MAX_WAIT is microseconds, but xf86WaitForInput expects
milliseconds.

Patch (line numbers after #776990):

--- src/xf86Elo.c
+++ src/xf86Elo.c
@@ -459,7 +459,7 @@
  * timeout and each wrong packet.
  */
 DBG(4, ErrorF("Waiting %d ms for data from port\n", ELO_MAX_WAIT / 1000));
-result = xf86WaitForInput(fd, ELO_MAX_WAIT);
+result = xf86WaitForInput(fd, ELO_MAX_WAIT / 1000);
 if (result > 0) {
   ok = xf86EloGetPacket(reply, &reply_p, &sum, fd);
   /*

Bug#760571: libftgl2: problems with bitmap fonts, incorrect blending function, etc.

[Frank Heckenbach]

I wrote:

> Manuel A. Fernandez Montecelo wrote:
>
> > Now, what I can offer is that if you are interested in the package, want
> > to take responsability for the changes, and want to fix the problems in
> > the long term (including maybe switching to the fork in github, which
> > seems more lively), I will ask you to prepare a new upload fixing these
> > and maybe other problems, and will then try to help and sponsor your
> > changes.
> >
> > Does it sound interesting?
>
> I wasn't aware of the github fork, thanks for mentioning it.
>
> [...] I guess my best chances are to offer my patches as pull
> requests on github. I'm doing that now.
>
> If/when they are accepted, you might consider uploading that version
> to Debian. Until then, a Debian upload of the old version with my
> fixes seems like a waste of time. (I've been using a patched
> packages for many years now anyway, nobody else seems interested,
> and as you said, it would only fix the issues in Debian.)

My patches (plus a bugfix to them by Olivier Sohn) are now pulled
into this repository, as well as my fork
https://github.com/frankheckenbach/ftgl (ATM both are identical;
ulrichard doesn't really want to "take over" the library, as he
wrote in the mail CCed to you, so you might want to use my fork).

So can you use it make a Debian upload, or what else do we need to
go on?

Any opinion from the original developers (still CCed)?

Regards,
Frank

Bug#760571: libftgl2: problems with bitmap fonts, incorrect blending function, etc.

[Frank Heckenbach]

Manuel A. Fernandez Montecelo wrote:

> So basically the package has been unmaintained all these years, and
> still is.  Sorry that your patches were ignored, but it seems that the
> maintainers are simply not available, and the rest of the Debian folks
> don't always take a look to packages unless they are interested in it
> for some reason.

Sorry for my late reply, I was busy with other stuff ...

> I just uploaded another NMU fixing other problems (related with
> cross-compilation, because it affects other packages), and considered
> including some of your patches, but they are a bit complex (it not just
> a fix initialising a variable, or avoiding a leak, etc),

Actually the first part of my patch is -- but the rest isn't. :)

> and nobody else
> "seconded" the change (I'm CCing other addressed of the authors) or
> asked for the patches to be applied, or pointed that the patch is
> already battle-tested because it's shipped in new upstream releases...
> 
> Essentially, I have very little knowledge about the matter at hand and I
> am not interested in maintaining the package long term, so without
> investing a significant amount of time and effort I don't know what's
> currently wrong with the behaviour, how to test it with the available
> packages using the library (or if I have to create a sample program to
> test the new features of the fonts to rotate them, for example),

I included some test programs with the changes (see below).

> I don't
> know either if they will break applications relying on the current
> behaviour (even if possibly buggy),

That's certainly possible. If bug-compatibility is important, we
basically can't change anything, and I'll have to keep my fixes to
myself.

> I cannot evaluate if you're
> introducing errors in the package as part of a mistake or a nefarious
> plan...

Of course I am. ;>

> and even then, the fixes will be only applied in Debian (and
> possibly derivatives), with behaviour possibly diverging from other
> platforms.

Of course, I'd like the bugs fixed upstream. My understanding (many
years ago when I reported the bugs) was that I should not send a
copy to the upstream software maintainers myself, as it is possible
that the bug exists only in Debian. If necessary, the maintainer of
the package will forward the bug upstream.

Incidentally, that's still what it says today on
https://www.debian.org/Bugs/Reporting (my text is almost a verbatim
quote!). I've had those irritations with many other bug reports I've
made on Debian, and I still don't know what's going on. Is the page
about bug reporting buggy itself? Should we report upstream now?

Then again, the last upstream release is from 2013, so this might be
futile, too.

> (This also happened in the past with SDL packages in Debian for example,
> which contained patches not applied upstream for years changing
> important things about the behaviour).

So why weren't they forwarded upstream? Because nobody cared?

> Now, what I can offer is that if you are interested in the package, want
> to take responsability for the changes, and want to fix the problems in
> the long term (including maybe switching to the fork in github, which
> seems more lively), I will ask you to prepare a new upload fixing these
> and maybe other problems, and will then try to help and sponsor your
> changes.
> 
> Does it sound interesting?

I wasn't aware of the github fork, thanks for mentioning it.

So as I see it, the original version is dead. (Original authors who
are included int he discussion may feel free to contradict me.) This
also concerns me WRT long-term viability. At the moment, I'm using X
and OpenGL, but at some point I'll probably (have to) switch to
Wayland and Vulkan or whatever, and a maintained library has a
better chance to make the switch, I hope.

I've tried it now. I see one of my bugs (3.) is already fixed there
(independently), another one (incorrect blending function) has been
obsoleted by moving it to the caller (I'm fine with that).

So for the other 4 bugs (and 1 new one I found while testing), I
guess my best chances are to offer my patches as pull requests on
github. I'm doing that now.

If/when they are accepted, you might consider uploading that version
to Debian. Until then, a Debian upload of the old version with my
fixes seems like a waste of time. (I've been using a patched
packages for many years now anyway, nobody else seems interested,
and as you said, it would only fix the issues in Debian.)

Regards,
Frank

Bug#887411: fgfs: segfaults when receiving UDP data too early

[Frank Heckenbach]

Package: flightgear
Version: 1:2016.4.4+dfsg-3+deb9u1
File: /usr/games/fgfs
Severity: normal

When receiving UDP data too early, fgfs segfaults after giving the
message:

  AI error: updating aircraft without traffic record at ...

I've traced the segfault to trafficcontrol.cxx:984

At this point, "current" is uninitialized, so UB.

I think the function (FGTowerController::updateAircraftInformation)
should return after giving the above warning.

The same seems to apply to some other functions (e.g.
FGStartupController::updateAircraftInformation,
FGApproachController::updateAircraftInformation), but of course,
I only see the first segfault that occurs.

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE= 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /stretch/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flightgear depends on:
ii  flightgear-data-all   1:2016.4.2+dfsg-1
ii  freeglut3 2.8.1-3
ii  libc6 2.24-11+deb9u2
ii  libcurl3-gnutls   7.52.1-5+deb9u3
ii  libdbus-1-3   1.10.24-0+deb9u1
ii  libexpat1 2.2.0-2+deb9u1
ii  libflite1 2.0.0-release-3+b1
ii  libgcc1   1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgsm1   1.0.13-4+b2
ii  libhtsengine1 1.08-1+b1
ii  libice6   2:1.0.9-2
ii  libopenal11:1.17.2-4+b2
ii  libopenscenegraph100v53.2.3+dfsg1-2+b4
ii  libopenthreads20  3.2.3+dfsg1-2+b4
ii  libplib1  1.8.5-7
ii  libpng16-16   1.6.28-1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libsm62:1.2.2-1+b3
ii  libspeex1 1.2~rc1.2-1+b2
ii  libspeexdsp1  1.2~rc1.2-1+b2
ii  libsqlite3-0  3.16.2-5+deb9u1
ii  libstdc++66.3.0-18
ii  libudev1  232-25+deb9u1
ii  libudns0  0.4-1+b1
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1
ii  libxmu6   2:1.1.2-2
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages flightgear recommends:
ii  flightgear-phi  2016.4.2+dfsg1-1

flightgear suggests no packages.

-- debconf-show failed

Bug#622340: udev - system hangs about 90 seconds on boot (first line,"Loading, please wait") -> ata1.00: failed command: IDENTIFY PACKET DEVICE

[Frank Heckenbach]

FYI, my drive that triggered this bug has now broken down, probably
just the optical/mechanical part (not worth investigating); it's
still seen by the computer and can probably be used to debug it if
someone's interested. (So far it doesn't seem so to me, and I won't
care about this bug now either.)

If someone wants it, let me know by Thursday, otherwise I'm gonna
throw it away.

Bug#864649: bash: SIGINT isn't handled after "wait -n" etc.

[Frank Heckenbach]

Package: bash
Version: 4.3-11+deb8u1
Severity: normal

In the following program, bash hangs when interrupting (Ctrl-C) the
read. It seems to depend on all the previous statements, including
"wait -n" and the pipe.

#!/bin/bash
: &
wait -n
: | :
read

strace shows the following:

read(0, 0x6fe4c0, 128)  = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
kill(26493, SIGINT) = 0
rt_sigreturn()  = -1 EINTR (Interrupted system call)
--- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=26493, si_uid=1002} ---
kill(26493, SIGINT) = 0
rt_sigreturn()  = -1 EINTR (Interrupted system call)
--- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=26493, si_uid=1002} ---
kill(26493, SIGINT) = 0
rt_sigreturn()  = -1 EINTR (Interrupted system call)
--- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=26493, si_uid=1002} ---
kill(26493, SIGINT) = 0
rt_sigreturn()  = -1 EINTR (Interrupted system call)
--- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=26493, si_uid=1002} ---
kill(26493, SIGINT) = 0
rt_sigreturn()  = -1 EINTR (Interrupted system call)
[...]

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 4.8.11 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bash depends on:
ii  base-files   8+deb8u8
ii  dash 0.5.7-4+b1
ii  debianutils  4.4+b1
ii  libc62.19-18+deb8u9
ii  libncurses5  5.9+20140913-1+b1
ii  libtinfo55.9+20140913-1+b1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#772874: closed by IOhannes m zmölnig (Debian/GNU) (either fixed or wontfix upstream.)

[Frank Heckenbach]

> 3) incompatible VOC files: upstream denies that there is a problem here.
> also i agree with upstream that the error message is pretty clear:
> "Error in VOC file, incompatible VOC sections" doesn't say "your VOC
> file is broken" but instead "it is incompatible with my notion of VOC
> files due to some issue with sections";

No, that's not what it says. It tries to shift the blame, instead of
at least saying something like: "Sorry, we don't support your VOC
files." (And now I reread my original report and see I suggested
this back then already, even with more detailed analysis. So
apparently you/upstream don't care about this, so I think it's best
to remove VOC support completely from the library.)

> in the future, please try report each issue in a separate bug, so they
> can be closed independently.

I guess in the future I won't bother to report bugs at all.

I mean, honestly, after almost 3 years you come and close one bug
(incorrectly IMHO), forward another one (that I did report
separately, #761240) and still ignore two more (#760898 and
#761307).

Of course, I didn't get to wait quite as long, so I've worked around
libsndfile long ago (for Ogg/Vorbis I use libvorbisfile, for WAV I
wrote a simple parser myself, and for VOC I call avconv as a
subprocess, which apparently has a better "notion of VOC files").

So I don't really care about those bugs anymore. For my sake, close
them all as wontfix.

At least I got a new mail signature out of this ...

-- 
"Error in Debian bug database, incompatible notion of bugs!" (#772874)

Bug#859008: dvb-tools: dvbv5-scan segfaults with DVB-T2 HD service that just started in Germany

[Frank Heckenbach]

I got the same problem, only on some channels though, e.g. ZDF using
this input:

[CH34]
DELIVERY_SYSTEM = DVBT2
FREQUENCY = 57800
BANDWIDTH_HZ = 800
MODULATION = QAM/16

*** Error in `dvbv5-scan': malloc(): memory corruption: 0x00fe13c0 ***

I did some debugging with gdb and valgrind (using the upstream
version v4l-utils-1.12.3.tar.bz2 since I needed to recompile anyway
to get debug info).

I found an invalid access in descriptors/desc_t2_delivery.c:55

  memcpy(&d->centre_frequency, p, len);

Before this, dvb_extension_descriptor_init had

  desc_type == 4 (T2_delivery_system_descriptor)

and

  dvb_ext_descriptors[4].size == sizeof(struct dvb_desc_t2_delivery) (23)

so it allocated only 23 bytes, but didn't change desc_len which was
still 68, causing the overflow.

Setting desc_len to 23 didn't help, but just allocating 68 bytes
did:

--- v4l-utils-1.12.3/lib/libdvbv5/descriptors/desc_extension.c
+++ v4l-utils-1.12.3/lib/libdvbv5/descriptors/desc_extension.c
@@ -149,7 +149,7 @@
if (!size)
size = desc_len;
 
-   ext->descriptor = calloc(1, size);
+   ext->descriptor = calloc(1, desc_len);
 
if (init) {
if (init(parms, p, ext, ext->descriptor) != 0)

NOTE: This is probably not a proper fix, just a bandaid. Since
scanning channels is mostly a one-off job, I'm happy now that I got
my channels list and don't plan to invest more time resarching the
issue.

Bug#805259: automatically move instead of close bugs in removed (upgraded) package versions

[Frank Heckenbach]

> On Wed, 21 Sep 2016, Frank Heckenbach wrote:
> > I've just experienced another such case after gcc-4.9 was "removed"
> > (#785249, which was reported upstream, and probably a whole more,
> > some of which are probably lost now).
> 
> These all still exist, and generally speaking, they get reassigned to
> the new version of the package when someone notices them and reassigns
> them.

That's the point -- *if* someone notices them. From my POV, for
those bugs I reported, it just seems like an (involuntary) wontfix.
(As I wrote, I had reported them upstream, so they were not lost for
that reason, but at least for the older two of them, there was no
indication of that in the Debian bug database, and no one asked me
about it, and it's been over a year, so I don't think they would
have been noticed otherwise.)

> As far as automatically reassigning, that will eventually happen when
> the BTS actually knows that a particular source package was based on
> another source package with a different name. There's code to do that,
> but it's not complete.

Good to know it's being worked on. I hope it will be deployed soon.
Thanks for the info!

Frank

Bug#805259: automatically move instead of close bugs in removed (upgraded) package versions

[Frank Heckenbach]

I've just experienced another such case after gcc-4.9 was "removed"
(#785249, which was reported upstream, and probably a whole more,
some of which are probably lost now).

PS: It's quite ironic that a bug report in which I also complained
about so many Debian bug reports sitting idly in the bug database
for years has now itself been sitting idly in the database for
almost a year without as much as a single response (not even a
"wontfix" if you don't care about this problem). To repeat myself, I
really wonder why I should report bugs at all anymore. :(

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Frank Heckenbach]

Hi,

> On Sat, Sep 03, 2016 at 10:57:13PM +0200, Frank Heckenbach wrote:
> >
> > Will this fix be pushed by security.debian.org as well now, or will
> > I have to install it manually?
> 
> It will be pushed via security.debian.org archive "soon", since we
> have not confirmation. It's not intended that you will have to fix
> those manually on your machines. We will issue a follow-up DSA for it.
> 
> > I'm asking because I'm involved with a number of machines that
> > probably all have gotten the bad update by now, if I have to patch
> > them all myself now. (I'm also asking because I found another bug in
> > a security update of another package, incidentally on the same day
> > as this one?!) What's the usual procedure for non-security bugs
> > introduced by security updates? (Couldn't find anything about it on
> > the web site.)
> 
> I guess it is about a regression in the imagemagick update? If so it's
> as well already on security team's radar, and we will need to issue a
> regression update for that (there are filled bugs for those, e.g.
> #835488, #835650, #836189).

Yes, I meant this one (#835650 is from me).

Thanks for the info. I'll await the updates then.

Frank

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Frank Heckenbach]

Hi,

> On 02/09/16 06:31, Salvatore Bonaccorso wrote:
> > On Thu, Sep 01, 2016 at 12:14:02PM +0100, Robert Shearman wrote:
> >> Alternatively, I'm pretty sure that adding the resulting changes to skel.c
> >> in 0006-CVE-2016-6354.patch would work too.
> >
> > I uploaded new varaiants of the builds and the corresponding source
> > package to the same location. Still subject to testing/review before
> > doing any other steps.
> 
> FWIW, I've tested the new packages you've uploaded and can confirm that 
> they fix the reported compile warning.

Me too.

Will this fix be pushed by security.debian.org as well now, or will
I have to install it manually?

I'm asking because I'm involved with a number of machines that
probably all have gotten the bad update by now, if I have to patch
them all myself now. (I'm also asking because I found another bug in
a security update of another package, incidentally on the same day
as this one?!) What's the usual procedure for non-security bugs
introduced by security updates? (Couldn't find anything about it on
the web site.)

Frank

Bug#835650: Imagemagick regression pin point patch

[Frank Heckenbach]

> I suppose 
> https://github.com/ImageMagick/ImageMagick/commit/f6242e725c819a69bee2a444f8e4a3c7718b2b3f
> 
> Fix it. If so plezse merge  this bug with the other one régression about pdf

Yes, this seems to fix my problem, thanks.

Frank

Bug#835650: Imagemagick regression pin point patch

[Frank Heckenbach]

> On Wed, Aug 31, 2016 at 8:42 AM, Bastien ROUCARIES
>  wrote:
>
> > Patches are needed for a security point of view but it is likely a
> > problem of backport intereaction.
> >
> > Could you help by pin point the problem.
> >
> > as root install a few package needed for imagemagick compilation:
> > apt-get install git
> > apt-get build-dep imagemagick

Just for my reference:
libbz2-dev libdjvulibre-dev libexif-dev libharfbuzz-dev libharfbuzz-gobject0 
libilmbase-dev libjasper-dev libjbig-dev liblcms2-dev liblqr-1-0-dev 
liblzma-dev libopenexr-dev libpango1.0-dev libperl-dev libtiff5-dev libtiffxx5 
libwmf-dev pkg-kde-tools xsltproc

> > as a user
> >  git clone   git://git.debian.org/git/collab-maint/imagemagick.git
> > cd imagemagick
>
> HERE run
> git checkout debian-patches/6.8.9.9-5+deb8u3
> 
> > git checkout debian-patches/6.8.9.9-5+deb8u4

So I ran both (first +deb8u3, then +deb8u4), right?
(Otherwise, +deb8u3 would be the same as in "good" below.)

> > git bisect start
> > git bisect bad
> > git bissect good debian-patches/6.8.9.9-5+deb8u3
> >
> >   Once you have specified at least one bad and one good commit, git
> > bisect selects a commit in the middle of that range of history, checks
> > it out, and outputs something similar to the following:
> >
> >Bisecting: 675 revisions left to test after this (roughly 10 
> > steps)
> >
> >  You should now compile the checked-out version and test it. If that
> > version works correctly, type. Compiling is done by typing
> > ./configure
> > make check

That already gave an error (see test-suite.log). (I first ran make
with "-j16", then reran "make check" (but didn't rebuild) without
"-j", same result.) I'll be ignoring this (and further test-suite
errors I got while bisecting).

> > you could run the command without installing by runing the convert.sh 
> > wrapper
> > ./magick.sh convert geometry 40% tux.png tux-scaled-old.ppm
> >
> > if bad run
> > git bisect bad
> > and rerun compile and testing
> > if good run
> > git bisect good
> >
> > Some pointer could be found in man git bisect

26d910675e0cd1b62e988139dba8eb11931260ac is the first bad commit
commit 26d910675e0cd1b62e988139dba8eb11931260ac
Author: Cristy 
Date:   Sat Jan 30 09:37:10 2016 -0500

Fix out of bound in quantum handling

Bug: https://github.com/ImageMagick/ImageMagick/issues/105
bug-ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1539053
origin: upstream, 
https://github.com/ImageMagick/ImageMagick/commit/c4e63ad30bc42da691f2b5f82a24516dd6b4dc70
bug-debian: https://bugs.debian.org/832506

:04 04 41e16d89455879892777d50135af38993b5be722 
e841bf15b62dee866b54eab729a93163d85aee68 M  magick

git diff 3e07cd10a9a2215c9edcc0c0e1541c125371cfbc 
26d910675e0cd1b62e988139dba8eb11931260ac
shows that the change essentially replaced image->columns by
MagickMax(image->columns,image->rows) in several places. This might
explain why the bug only occurs with portrait. I see that some
callers of GetQuantumExtent() use its result as the length parameter
to ReadBlob and similar, so it seems strange to use the max of width
and height here. Others callers might use it for a work buffer where
this might be correct (and probably what the change was meant to
fix), but it might be necessary to separate those two cases.

Frank


test-suite.log.bz2
Description: Binary data

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Frank Heckenbach]

Package: flex
Version: 2.5.39-8+deb8u1
Severity: normal

After this update, I get the following warning when compiling the
flex generated code with gcc, which I didn't get before:

scan.cpp: In function ‘int yy_get_next_buffer(yyscan_t)’:
scan.cpp:758:18: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
scan.cpp:1384:3: note: in expansion of macro ‘YY_INPUT’

Looking at the code:

#define YY_INPUT(buf,result,max_size) \
if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
{ \
int c = '*'; \
size_t n; \
for ( n = 0; n < max_size && \

Invoked as:

int num_to_read = ...
YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
yyg->yy_n_chars, num_to_read );

So indeed an unsigned value (n) is compared with a signed one
(num_to_read). If this is correct, the warning can be silenced with
a cast of the appropriate one of them.

flex hasn't exactly been known for generating warning-free code,
but what really worries me is that this is a security update. Fixing
a security problem by introducing a sign-problem seems fishy to me.

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flex depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  install-info   5.2.0.dfsg.1-6
ii  libc6  2.19-18+deb8u5
ii  libfl-dev  2.5.39-8+deb8u1
ii  m4 1.4.17-4

Versions of packages flex recommends:
ii  clang-3.5 [c-compiler]  1:3.5-10
ii  gcc [c-compiler]4:4.9.2-2
ii  gcc-4.8 [c-compiler]4.8.4-1
ii  gcc-4.9 [c-compiler]4.9.2-10

Versions of packages flex suggests:
ii  bison2:3.0.2.dfsg-2
ii  build-essential  11.7

-- no debconf information

Bug#826072: alevt: Program table overflow

[Frank Heckenbach]

Package: dvb-apps
Version: 1.1.1+rev1500-1+fh1
Severity: normal
File: /usr/bin/alevt
Tags: patch

progtbl has a size of 16 (actually, only 15 are used due to the
check "progcnt >= sizeof(progtbl)/sizeof(progtbl[0])"; maybe this
should be ">", unless the last entry is needed as a terminator).

Anyway, one channel I receive (DE-Nuremberg, DVB-T, 78600 Hz,
Eurosport etc.) has a size of 17, so it's too small either way and
alevt aborts with the message given in the subject.

I don't know if there are official size limits, or whether there are
side-effects to my change, but for now, just increasing the size
seems to work for me.

The same code exists in the alevt package, may need to be patched
there, too.

--- util/alevt/vbi.c
+++ util/alevt/vbi.c
@@ -628,7 +628,7 @@
u_int8_t txttype;
u_int8_t txtmagazine;
u_int8_t txtpage;
-   } progtbl[16], *progp;
+   } progtbl[32], *progp;
u_int8_t tbl[4096];
u_int8_t * ppname, * psname, pncode, sncode, pnlen, snlen;
int r;

Bug#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes

[Frank Heckenbach]

Hi Martin,

> Thank you for your bug report!
> 
> Judging from the code that reproduces the bug (two subsequent seeks to 
> 0) and from the related vorbis code you are mentioning, this sounds a 
> lot like #782831, which was fixed in 1.3.4-3. Could you confirm or 
> refute that theory by testing your code (I guess you have further 
> examples apart from the one you posted) with 1.3.4-3?

1.3.4-3 isn't on the main server anymore, but luckily I recently
learned about snapshot.debian.org. It may be old news for you, but
for anyone else who may be reading this report and doesn't know
about it, I fetched the following two files and rebuilt them
(together with the origial libvorbis_1.3.4.orig.tar.gz from jessie).
I didn't try 1.3.5 yet as I want to change as little as possible in
the system.

http://snapshot.debian.org/archive/debian/20151001T033412Z/pool/main/libv/libvorbis/libvorbis_1.3.4-3.dsc
http://snapshot.debian.org/archive/debian/20151001T033412Z/pool/main/libv/libvorbis/libvorbis_1.3.4-3.debian.tar.xz

It did indeed fix the test case, and also my real case where I found
the problem. I'll do some more tests soon and report if I find more
problems, but I hope not.

Thanks,
Frank

Bug#821321: libvorbisfile: ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes

[Frank Heckenbach]

Package: libvorbisfile3
Version: 1.3.4-2
Severity: important

ov_pcm_seek wrongly returns OV_EOF or segfaults sometimes. I've
observed it in some situations, below is a very simple one to
reproduce. It's an important problem to me, because (unless fixed or
you can tell me exactly when seeking will work), I'd have to treat
all Ogg/Vorbis files as unseekable in my code, which would be a huge
performance penalty (decoding sequentially and buffering all in
memory).

% cat test.c
#include 
#include 

int main ()
{
  OggVorbis_File vf;
  fprintf (stderr, "%i\n", ov_fopen ("foo.ogg", &vf));
  fprintf (stderr, "%i\n", ov_pcm_seek (&vf, 0));
  fprintf (stderr, "%i\n", ov_pcm_seek (&vf, 0));
  return 0;
}
% head -c 10 /dev/zero|oggenc -Q -r - -o foo.ogg&& gcc -g test.c 
-lvorbisfile && ./a.out

On i386:
0
0
-2

On amd64:
0
0
Segmentation fault

I tried to debug it and found: The 2nd time ov_pcm_seek_is_called
(from the 2nd ov_pcm_seek call), at line 1461

  if(bisect!=vf->offset){
result=_seek_helper(vf,bisect);
if(result) goto seek_error;
  }

begin == 3997 and vf->offset == 3997, so the call to _seek_helper is
skipped. However, ftell((FILE*)vf->datasource) == 4076, so it goes
on with a wrong file position, so _get_next_page fails and og
remains unintialized and ogg_page_serialno(&og) (line 1554) results
in UB.

I don't really understand the code: Telling from this line,
vf->offset should reflect the actual position of the data source.
But if so, I'd expect it to be adjusted after each successfull call
of seek_func (that's correctly done) and read_func. read_func is
only called from _get_data, but it doesn't adjust vf->offset.
Instead it puts the data into an internal buffer AFAIUI, so the
users of the data from the buffer are probably responsible for
adjusting vf->offset, but apparently something goes wrong there.

If I just set vf->offset to 4076 before line 1461 (2nd time), it
continues correctly. That's of course, not a fix, just an indication
that the wrong value of vf->offset is the real problem here.

Maybe vf->offset just needs to be revalidated before line 1461, but
it's used in many places, and I don't know how many of them might be
affected too.

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvorbisfile3:amd64 depends on:
ii  libc6  2.19-18+deb8u4
ii  libogg01.3.2-1
ii  libvorbis0a1.3.4-2
ii  multiarch-support  2.19-18+deb8u4

libvorbisfile3:amd64 recommends no packages.

libvorbisfile3:amd64 suggests no packages.

-- no debconf information

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> On 28 March 2016 at 12:18, Frank Heckenbach  wrote:
> > Felipe Sateler wrote:
> >
> >> BTW, systemd has been uploaded to proposed-updates[1] fixing #805133.
> >> Could you please upgrade to that version and try using the
> >> After=swap.target workaround?
> >
> > Actually, I'm not sure if it works. I could not reproduce the bug
> > now (but it wasn't 100% reproducible anyway).
> >
> > However, "systemd-analyze blame" still shows tmp.mount started
> > before the swap targets. Is this not the right tool to check? Any
> > other way to check the order dependencies systemd actually uses, so
> > I can positively verify that it does things in the correct order and
> > it wasn't just lucky timing?
> 
> You can check `systemctl list-dependencies --after tmp.mount`

OK, this confirms it works correctly.

> >> If it works, then using
> >> overcommit_memory would require adding the After= snippet, and this
> >> bug could be turned into a documentation bug (but where?).
> >
> > It doesn't really depend on overcommit_memory. You get the bug also
> > with tmpfs usage larger than physical RAM. So if that's the
> > solution, "After=swap.target" should always be there, i.e. in the
> > tmp.mount as installed.
> >
> > Or is there any case where swapoff needs to be before umount /tmp?
> > The only possibility I could imagine, in the spirit of
> > https://bugzilla.redhat.com/show_bug.cgi?id=1031158, is when a swap
> > file is in a tmpfs, but that's just silly. ;) So I think in most
> > cases, the order doesn't matter, and if it does, umount before
> > swapoff is correct. So it shouldn't hurt to always do the ordering.
> 
> This makes sense to me, but I'll defer to others (in particular, this
> is probably something best brought up upstream).

https://github.com/systemd/systemd/issues/2930

Regards,
Frank

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

Felipe Sateler wrote:

> BTW, systemd has been uploaded to proposed-updates[1] fixing #805133.
> Could you please upgrade to that version and try using the
> After=swap.target workaround?

Actually, I'm not sure if it works. I could not reproduce the bug
now (but it wasn't 100% reproducible anyway).

However, "systemd-analyze blame" still shows tmp.mount started
before the swap targets. Is this not the right tool to check? Any
other way to check the order dependencies systemd actually uses, so
I can positively verify that it does things in the correct order and
it wasn't just lucky timing?

> If it works, then using
> overcommit_memory would require adding the After= snippet, and this
> bug could be turned into a documentation bug (but where?).

It doesn't really depend on overcommit_memory. You get the bug also
with tmpfs usage larger than physical RAM. So if that's the
solution, "After=swap.target" should always be there, i.e. in the
tmp.mount as installed.

Or is there any case where swapoff needs to be before umount /tmp?
The only possibility I could imagine, in the spirit of
https://bugzilla.redhat.com/show_bug.cgi?id=1031158, is when a swap
file is in a tmpfs, but that's just silly. ;) So I think in most
cases, the order doesn't matter, and if it does, umount before
swapoff is correct. So it shouldn't hurt to always do the ordering.

Regards,
Frank

Bug#819327: bash: executes statement after "exit"

[Frank Heckenbach]

Package: bash
Version: 4.3-11+b1
Severity: normal

% cat bash-bug
#!/bin/bash

if true; then
  $[()]
  exit
fi

echo "Should not get here."
% ./bash-bug
./bash-bug: line 4: (): syntax error: operand expected (error token is ")")
Should not get here.

The error is correct, but after that it should continue with exit,
or with "set -e", abort immediately. In both cases it goes on to
execute the statement below.

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bash depends on:
ii  base-files   8+deb8u3
ii  dash 0.5.7-4+b1
ii  debianutils  4.4+b1
ii  libc62.19-18+deb8u4
ii  libncurses5  5.9+20140913-1+b1
ii  libtinfo55.9+20140913-1+b1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#788303: State of the bug?

[Frank Heckenbach]

Hi,

> I am experiencing this bug on 20 low memory Jessie VMs. But only in 20%
> of rebbot attempts. Adding memory might perhaps solve the problem, but
> also rises budget, and can I be sure? Its a real problem anyway.
> 
> It took me some time to find out this might be a bug at all, because it
> happens only at some of the reboots. Further I searched for other
> reasons, until I found this bugreport and the corresponding log entry:
> 
> Mar 23 17:21:22 x swapoff[4187]: swapoff:
> /dev/disk/by-uuid/38cd3812-d2ae-4d79-971a-1ed9b8b08505: swapoff failed:
> Nicht genügend Hauptspeicher verfügbar
> 
> at shutdown time.
> 
> Thanks for the reporting and analysis so far!
> 
> @Frank Heckenbach: I would love to give the "workaround" a try, but I
> don't fully understand, what will be achieved by
> 
> > ExecStop=/bin/sh -c 'while mount | grep -q "on /tmp "; do umount /tmp;
> sleep 1; done; while ! swapoff -a; do sleep 1; done'
> 
> in systemctl shutdown phase. This is only working with /tmp as mount or
> am I wrong? I don't think this can work for me.

Yes, only for /tmp. That's why it's only a workaround. ;)

It works for me (tm), because /tmp is my only tmpfs that ever
carries significant amounts of data. (Of course, there's /run etc.,
but there's not much in it.)

In those cases where I had problems shutting down, swapoff failed
because /tmp used too much space, more than would fit into RAM
without swap. So my workaround was to umount /tmp to free this
space, then swapoff would work.

Your situation may be different. You could try to find out what uses
the memory. There should not be many processes left running at this
point, unless you explicitly prevent them from stopping (or there
are other bugs ...). If you have another large tmpfs, you can try
umounting that instead (or in addition). If that's not it, you'll
need to find out what it is ...

In the worst case (before I'd waste money on more RAM just for
shutting down, which seems quite ridiculous ;), there's a real
hackish solution:

You can forcibly shut down a system with the "magic sysrq key",
using S(ync), U(mount), O(ff). You can also script this using
/proc/sys/kernel/sysrq and /proc/sysrq-trigger. You can google for
that stuff. If necessary, ask me again.

But that should really be a last resort. It will completely bypass
systemd (of course, it hasn't deserved better, if it causes us such
problems ... ;)

> Is there a general solution on the way or in work?

They said they fixed it upstream, but it doesn't look like it will
be backported to jessie, and therefore I haven't tried it. So from
my point of view, I can only hope it will be fixed in the next
stable release. Until then, I hope my workaround will work for me.

Regards,
Frank

Bug#818037: vorbis-tools: vcut always(?) segfaults

[Frank Heckenbach]

> I debugged it and found the problem. It was a simple indexing problem
> that seemed to have slipped away during quite some time because of a 
> lucky memory layout: The pointer resulting from the wrong indexing 
> points to the stack and therefore to valid memory (in terms of memory 
> management), unless the block is too big. Now the memory layout has 
> changed for some reason (GCC 5?), therefore we read a different value as 
> block size, the block is too big for the stack and we get the 
> segmentation faults.

Not GCC 5, jessie still uses 4.9.2 (and I tried rebuilding it
myself, same bug), but anyway.

> The patch is in the git repository.

Where can I get it (just the patch, so I can try it against the
jessie version)?

https://git.xiph.org/ says:
vorbis-tools.git ... Last change 5 months ago

Regards,
Frank

Bug#818037: vorbis-tools: vcut always(?) segfaults

[Frank Heckenbach]

> It's not yet in the upstream git repository (I submitted the patch
> through their bug tracker, but someone from upstream has to check it and 
> apply it), but in our (the Debian package's) git repository.
> 
> You can find the patch here:
> 
> https://anonscm.debian.org/cgit/pkg-xiph/vorbis-tools.git/tree/debian/patches/Fix-segfault-in-vcut.patch

Seems to work for me. Thanks.

Frank

Bug#818045: libspice-server1: cursor disappears in KDE in Xspice

[Frank Heckenbach]

Package: libspice-server1
Version: 0.12.5-1+deb8u2
Severity: normal
Tags: patch

When running KDE in Xspice, the cursor disappears.

To reproduce, I start the server like this:

#!/bin/sh
set -e
export DISPLAY=:30
zcat /usr/share/doc/xserver-xspice/spiceqxl.xorg.conf.example.gz > 
/tmp/xspice.conf
Xspice --config /tmp/xspice.conf --disable-ticketing "$DISPLAY" &
sleep 1
dbus-launch startkde

(Note: Since xserver-xspice is missing in jessie, I use the version
xserver-xorg-video-qxl_0.1.1-3+ubuntu which can be built from
sources under jessie without problems.)

Then I start the client with:

spicec -h localhost -p 5900

When I move the cursor over the spicec window (containing KDE), it
becomes invisible most of the time (occasionally, some garbage is
drawn instead). The patch below seems to fix the problem.

Note, the regression was apparently introduced in 0.12.5-1+deb8u2
which is a security fix. I don't suppose the cursor being visible
was the vulnerability fixed, and it was rather a mistake. However,
it did not do a security check of my patch. (I use spice in a
private network, and for me a possibly-insecure, working version is
better than a possibly-secure, non-working one ...)

As far as I could debug, the cause of the problem is that
0001-worker-validate-correctly-surfaces.patch moves up
VALIDATE_SURFACE_RET(), not only (correctly) before the access of
worker->surfaces[surface_id], but also before
flush_display_commands(). In this situation, apparently, the
commands to be flushed cause the surface to become valid. So the
surface is mistakenly seen as invalid too early. By moving up
flush_display_commands(), it becomes valid in time:

--- server/red_worker.c
+++ server/red_worker.c
@@ -10882,12 +10882,12 @@
 QXLRect *qxl_dirty_rects = msg->qxl_dirty_rects;
 uint32_t clear_dirty_region = msg->clear_dirty_region;
 
+flush_display_commands(worker);
 VALIDATE_SURFACE_RET(worker, surface_id);
 
 rect = spice_new0(SpiceRect, 1);
 surface = &worker->surfaces[surface_id];
 red_get_rect_ptr(rect, qxl_area);
-flush_display_commands(worker);
 
 spice_assert(worker->running);

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libspice-server1:amd64 depends on:
ii  libc6  2.19-18+deb8u4
ii  libglib2.0-0   2.42.1-1+b1
ii  libjpeg62-turbo1:1.3.1-12
ii  libopus0   1.1-2
ii  libpixman-1-0  0.32.6-3
ii  libsasl2-2 2.1.26.dfsg1-13+deb8u1
ii  libssl1.0.01.0.1k-3+deb8u4
ii  multiarch-support  2.19-18+deb8u4
ii  zlib1g 1:1.2.8.dfsg-2+b1

libspice-server1:amd64 recommends no packages.

libspice-server1:amd64 suggests no packages.

-- no debconf information

Bug#818037: vorbis-tools: vcut always(?) segfaults

[Frank Heckenbach]

Package: vorbis-tools
Version: 1.4.0-6
Severity: grave
File: /usr/bin/vcut
Justification: renders package unusable

Sorry for the brief description, but for what I can tell, that's
really it. I tried various cases, and vcut always seems to just
segfault. Here's one example:

% head -c 50 /dev/zero | oggenc -Q -r -o 1.ogg -
% vcut 1.ogg 2.ogg 3.ogg +1
Processing: Cutting at 1,00 seconds
Segmentation fault

Tried on both i386 and amd64.

It did work correctly under squeeze and wheezy.

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vorbis-tools depends on:
ii  libao4   1.1.0-3
ii  libc62.19-18+deb8u4
ii  libcurl3-gnutls  7.38.0-4+deb8u3
ii  libflac8 1.3.0-3
ii  libogg0  1.3.2-1
ii  libspeex11.2~rc1.2-1
ii  libvorbis0a  1.3.4-2
ii  libvorbisenc21.3.4-2
ii  libvorbisfile3   1.3.4-2

vorbis-tools recommends no packages.

vorbis-tools suggests no packages.

-- no debconf information

Bug#622340: udev - system hangs about 90 seconds on boot (first line,"Loading, please wait") -> ata1.00: failed command: IDENTIFY PACKET DEVICE

[Frank Heckenbach]

Hi Jort,

> Great comment and recommendation. I was using SB04 and experienced the 90
> second boot delay. Workaround was functioning as described before, however
> udev rules might easily get overwritten so it's not an ideal solution.
> 
> I have a dual boot OS.
> What I did:
> Booted to windows and downloaded the SB07 firmware (auto-flashed from
> executable).
> Rebooted to linux (I'm running mint):
> 
>- Reinstated the original line from
>/lib/udev/rules.d/60-persistent-storage.rules
>- update-initramfs -u
>- Reboot again and check boot time + dmesg.
> 
> It seems to have worked for me, I tried some other reboots to see whether I
> could get it to break again without 'success'.
> 
> So it might be worth the one time effort for people to plug the drive to a
> windows box and flash it, or boot to win OS.
> 
> Download link I used (official tsstodd):
> http://www.tsstodd.com/TotalLib/popup/Download.asp?path=fwdownload&lang=eng&fname=SH-S223C_SB07.exe
> 
> Note that you should also be able to use MacOS with the separate TSDNMAC
> firmware flash program and extracting the .bin from the windows download
> above (it's just an archive).

Nice that it works for you. OTOH, I don't have any other OS on
my machine, and removing the drive and taking it to a friend's
Windows machine quite frankly seems more effort than the drive is
worth. Probably "cheaper" to buy a new one then. But as long as the
workaround works, I can use this. (If you know a method to upgrade
under Linux, or maybe FreeDos which I could probably set up quickly,
I'd still like to try it.)

I understand that it's the drive that's doing something wrong, but
so far udev is the only thing that seems to have a problem with it,
everything else works fine regardless. It's not the first software
workaround for hardware bugs I've had to use either. (The kernel has
a number of those, and at least one of my former MBs definitely
needed one to use UDMA reliably.) Such is life in the hardware-near
world, so maybe udev could just adapt this little workaround ...

Regards,
Frank

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> > This seems to work. However, given that this single line is now >1
> > KB and more than 3 times as long as my work-around service, and
> > heavily depends on the system configuration, I doubt whether it's
> > actually less hackish. (I do occasionally change my swap partitions.
> > I also build system images to run on different machines.)
> >
> > One could try to auto-generate this, of course. Not too hard, but
> > when should it run? From a systemd service run during boot, which
> > modifies another systemd run during boot -- doesn't seem like a good
> > idea. (And it would break if swap partitions are added/removed after
> > boot.)
> >
> > So I'll stick with my work-around, but I think the above can perhaps
> > serve as an example for what to do in systemd interally (the only
> > place I could image it working reliably), maybe similar to the patch
> > in https://github.com/systemd/systemd/issues/1902 (but I don't know
> > the internals well enough to really tell).
> 
> Once this package is fixed in stable, the workaround can be reduced to
> After=swap.target.
> 
> I don't think we want to diverge locally (ie, in Debian) from what
> dependencies are automatically added to tmpfs mounts. I figure if you
> change overcommit_memory you can also specify the tpmfs ordering...

Not really. overcommit_memory is a simple, static setting
/etc/sysctl.d/local.conf whereas as I said the tmpfs change is
rather long and system-dependent (if you have a solution for
auto-generating it, let me know).

I suggest we keep this bug open until it's fixed in stable (and I
keep using my work-around until then). When it's done, I can try
"After=swap.target" and report if it works.

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> Due to the other bug I linked, this may not be sufficient. Please list
> all the swap units listed in
> 
> % systemctl list-units '*.swap'
> 
> You'll see that there are multiple units each of the different ways
> you can access the underlying partition (by uuid, did, wwm and sdX
> name).
> 
> I don't think you need to quote differently.

This seems to work. However, given that this single line is now >1
KB and more than 3 times as long as my work-around service, and
heavily depends on the system configuration, I doubt whether it's
actually less hackish. (I do occasionally change my swap partitions.
I also build system images to run on different machines.)

One could try to auto-generate this, of course. Not too hard, but
when should it run? From a systemd service run during boot, which
modifies another systemd run during boot -- doesn't seem like a good
idea. (And it would break if swap partitions are added/removed after
boot.)

So I'll stick with my work-around, but I think the above can perhaps
serve as an example for what to do in systemd interally (the only
place I could image it working reliably), maybe similar to the patch
in https://github.com/systemd/systemd/issues/1902 (but I don't know
the internals well enough to really tell).

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> What if instead of this service, you add an:
> 
> After=swap.target
> 
> To your tmp.mount ?

Doesn't work. Also, systemctl still lists tmp.mount before the swap
targets, which means (I suppose) it will be stopped after them.

I thought maybe swap.target is just a virtual target that depends on
the actual swap targets, so I should put them there, but it also
doesn't work. Or do I need to quote the names differently?

After=dev-disk-by\x2duuid-01db9e17\x2d60e5\x2d428c\x2dbbbf\x2dfd817e2f1ec9.swap 
dev-disk-by\x2duuid-740bd0c3\x2da38f\x2d4732\x2d9120\x2da88b78f889a6.swap 
dev-disk-by\x2duuid-8178b5f7\x2d410f\x2d46c4\x2da4c3\x2d5003af570dbc.swap 
dev-disk-by\x2duuid-fe4e8739\x2d2114\x2d4994\x2d9ada\x2d2bf7b275e42e.swap

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

As a work around, I've put the following in
/etc/systemd/system/workaround-788303.service and activated it with
systemctl enable workaround-788303

This seems to work for me for now. Of course, I'd prefer a real
bugfix. (And so should the systemd author, seeing how much he hates
using the shell ... ;)

[Unit]
Description=Work-around for Debian bug #788303
After=local-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/bin/sh -c 'while mount | grep -q "on /tmp "; do umount /tmp; sleep 1; 
done; while ! swapoff -a; do sleep 1; done'

[Install]
WantedBy=multi-user.target

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

> On 6 Jan 2016 02:45, "Frank Heckenbach"  wrote:
> >
> > I did some more debugging, and found out some things:
> >
> > - In a debug shell after the failed shutdown, I did:
> >
> >   systemctl status `systemctl | grep failed | grep swap | awk '{print
> $2}'`
> >
> >   and found an error message like this:
> >
> >   swapoff: /dev/sdxx: swapoff failed: Cannot allocate memory
>
> Maybe related to:
> 
> https://github.com/systemd/systemd/issues/1902
> 
> I don't think we have backported that fix to stable. Could you try the
> workaround of ordering the aliased swap units?
> 
> Add a file /etc/systemd/system/swap.target.d/override.conf
> 
> [Unit]
> After=$swapunits
> 
> You can find out the precise swap units by using `systemctl list-units
> --type swap`
> 
> You need to do systemctl daemon-reload after adding the file.

Doesn't help, and I hadn't really expected it to. It seems to be
about the ordering relative to swap.target, but what I need is for
swapoff to be ordered after unmounting (of at least all tmpfs
mounts).

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

I did some more debugging, and found out some things:

- In a debug shell after the failed shutdown, I did:

  systemctl status `systemctl | grep failed | grep swap | awk '{print $2}'`

  and found an error message like this:

  swapoff: /dev/sdxx: swapoff failed: Cannot allocate memory

- Manually running "swapoff -a" while my system is up, also often
  fails with this error (especially if KDE and Firefox are running
  and overcommit_memory is disabled), even though there seems to be
  enough free memory. This is explained here (including the links in
  the comments):

  
http://unix.stackexchange.com/questions/89514/swapoff-fails-when-overcommit-memory-2

  This may be the root cause of our problems, not a systemd bug (but
  don't close the issue yet, read on).

- I also wondered, why do swapoff at all before shutdown/restart?
  This is apparently answered in:

  https://bugzilla.redhat.com/show_bug.cgi?id=1031158

  Though I don't really agree with that reasoning (breaking the
  shutdown process for many people, as indicated in this, that, and
  all the merged bug reports, just for the sake of a rather unlikely
  IMHO niche case), that seems to be the way it is and it's not
  strictly a bug, either.

- However, to answer the question asked there (I don't have an RH
  account to post there, and the report there is closed already, so
  I'll write it here; feel free to forward it to RH and/or systemd):

  "What is using the memory in your case?"

  At least in one case I debugged, it seems to be a tmpfs which
  indeed had grown to several GB size (which I'd normally expect to
  be discarded on shutdown, that's fine).

  Apparently, systemd tries to swapoff before unmounting the tmpfs.
  It does so, apparently, because tmpfs was mounted before swapon,
  and shutdown order is reverse startup order.

  So swapoff fails because tmpfs uses too much memory. Then tmpfs is
  unmounted (successfully), but swapoff is never retried, shutdown
  is considered failed, and the system is basically dead.

So AFAICS there are at least two issues to fix in systemd:

1. Do swapoff *after* umount.

   I know this might be difficult given systemds concepts of
   depedencies and ordering, but I don't care. I didn't ask for it,
   it was systemd that introduced it (and Debian who throw systemd
   on us), so it's your job to sort out the mess. If a proper
   solution is not feasible easily, at least do an additional
   swapoff after umounting.

2. Handle shutdown failures better (i.e., at all).

   Currently, all you get is a message which (unlike in sysvinit) is
   not even shown on the console, but only in its journal (which you
   normally can't even read, because you have no shell at this
   point, so the message might as well not exist at all).

   Then the system just hangs (I wasn't as patient as Will Aoki and
   didn't wait for 27 minutes, but I assume it will hang forever),
   unless you take harder measures ...

   That's not really acceptable behaviour. systemd must know that
   shutdown has failed and nothing can progress anymore. If so, at
   least give me a maintenance shell or something! And tell me about
   the error (see above)!

   (I know this might be difficult etc., see above.)

Bug#788303: systemd: Hangs indefinitely on >90% of reboot attempts

[Frank Heckenbach]

Just saying me too (also to get informed about news on this front).
It happenes both on reboot and shutdown attempts.

I can also offer to help debugging it, if there's something specific
I can do (in jessie).

Also, I'd suggest to increase the severity, since, you know, not
shutting down the system properly seems a pretty big deal to me. For
all its perceived weaknesses, sysvinit has been able to do that for
decades. (I'm getting used to shut down by raising elephants --
still easier to do than manually doing swapoff every time -- but
that really can't be the way to go.):

Bug#809633: socat: exits with incorrect status when terminated by signal

[Frank Heckenbach]

Package: socat
Version: 1.7.2.4-2
Severity: normal
Tags: upstream

When socat is terminated by a signal that it catches (e.g. SIGTERM),
it exits with status 128+signum (socat_signal() -> diag_exit() ->
_diag_exit() -> Exit() -> exit()).

Though 128+signum is a convention used by common shells to set $?
for processes killed by a signal, it's not actually the same;
wait() on such a process returns different statuses.

I noticed this when I tried to use socat in a systemd service. When
terminating it properly (i.e. via SIGTERM), systemd would
(correctly) describe it as "failed":

  Active: failed (Result: exit-code)
  Process: 1096 ExecStart=/usr/bin/socat [...] (code=exited, status=143)

rather than "dead" as it does after proper termination:

  Active: inactive (dead)
  Process: 20422 ExecStart=/some/other/program (code=killed, signal=TERM)

The usual way to achieve the correct behaviour, i.e. acting on a
signal and then terminating as if by the signal, is to restore the
handler to SIG_DFL, then raise() the signal again.

This would require small changes to the intermediate functions
listed above, and maybe manual calling atexit() functions, but
should otherwise be a rather easy fix.

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages socat depends on:
ii  libc62.19-18+deb8u1
ii  libssl1.0.0  1.0.1k-3+deb8u2
ii  libwrap0 7.6.q-25

socat recommends no packages.

socat suggests no packages.

-- no debconf information

Bug#622340: udev - system hangs about 90 seconds on boot (first line,"Loading, please wait") -> ata1.00: failed command: IDENTIFY PACKET DEVICE

[Frank Heckenbach]

Bob B wrote:

> It's curious whether the problem can be resolved
>
> by updating the ODD's firmware
>
> to the latest version (currently "SB07"):
>
> http://www.tsstodd.com/eng/firmware/fwdownload/?functionvalue=view&no=733

I'd like to try it if there's some way to update the firmware.
The web site only seems to support other OSs.

Bug#805259: automatically move instead of close bugs in removed (upgraded) package versions

[Frank Heckenbach]

Package: bugs.debian.org
Severity: normal

Consider bugs such as #588087 and #593086 which I reported some
years ago against then-current gcc-4.4 and which were recently
closed when gcc-4.4 was removed from Debian.

However, the bugs haven't actually been fixed. I've checked that
both still exist in the current (as of this writing) gcc-4.9.2.

Now, I think I understand why e.g. gcc-4.4 and gcc-4.9 must be
distinct packages in Debian. But their contents are not really
distinct (such as gcc vs. clang) -- they're still different versions
of the same code base. So the default assumption should be that a
bug that hasn't been fixed in one version is still present in newer
versions (just as is the case for other software that doesn't need
distinct packages for different versions).

Therefore, I'd ask that for such packages, when old versions are
removed, open bugs are not automatically closed, but automatically
moved to a newer version of the software. Besides gcc this should
apply to many libraries, among others.

Sure, this risks occasional false positives, but this seems much
better than the many false negatives we have currently. (Just as an
example: Together with the two above-mentioned bugs, a few dozen
other bugs were automatically closed, as can be seen in the close
message; I'd bet many of them are actually still open in current gcc
versions. FWIW, I've reported my two bugs upstream meanwhile, so
it's not about these, but about the general issue.)

This is important to me because many of the bugs I've reported in
Debian so far have been sitting idly in the bug database for years
(and looking at other packages, this doesn't seem specific to my
reports, but rather the norm in Debian, unfortunately). At least the
database serves as a kind of documentation of existing bugs (also
for other users who don't need to report the same issues again).
However, when bugs are simply removed after some time on a (IMHO)
technicality, even this little usefulness disappears, and I really
wonder why I should report bugs at all anymore.