Bug#1023697: wolfSSL 5.5.4 uploaded

[Felix Lechner]

Hi,

> there is considerable interest in using WolfSSL

I uploaded version 5.5.4-1, which was released last week, to the archive.

Kind regards
Felix Lechner

Bug#1023697: Keep out of testing

[Felix Lechner]

Hi,

On Fri, Nov 25, 2022 at 4:27 AM Bastian Germann  wrote:
>
> It would be great to address the CVEs with patches on 4.6.0+p1-0+deb11u1.

A proposed update for the 11.6 point release of bullseye, which is
scheduled for next weekend, was filed with the release team. [1] They
were also contacted for guidance via IRC.

Kind regards
Felix Lechner

[1] https://bugs.debian.org/1025789

cc: Security Team

Bug#1023697: Keep out of testing

[Felix Lechner]

Hi,

On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff  wrote:
>
> open security issues

I also just uploaded a backport for bullseye.

Kind regards,
Felix Lechner

Bug#1023835: wolfssl: FTBFS because of amd64-only symbols in symbols file

[Felix Lechner]

Hi,

On Thu, Nov 10, 2022 at 4:06 PM Bastian Germann  wrote:
>
> Please keep the three symbols out of the symbols file or make them optional.

Thanks. We are aware of the issue.

Unfortunately, your suggestion will likely cause a build failure on
amd64. How do you make the symbols "optional" please? Thanks!

Kind regards,
Felix Lechner

Bug#1023697: Version 5.5.3-1 is in the NEW queue

[Felix Lechner]

Hi,

FWIW, version 5.5.3-1 was accepted into the NEW queue.

Kind regards
Felix Lechner

Bug#1023697: Keep out of testing

[Felix Lechner]

Hi,

On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff  wrote:
>
> wolfssl has no active maintainer, plenty of open security issues and we 
> already
> have too many TLS libraries in our releases. Keep it out of testing. I'm going
> to file bugs against the handful of reverse deps.

Sorry, I have been out ill, but please do what you think is right.

Kind regards
Felix

Bug#1021021: Upload planned

[Felix Lechner]

Hi,

I plan to upload version 5.5.1 in the near future.

Kind regards
Felix Lechner

Bug#1010703: haskell-hashable: FTBFS on i386: unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'

[Felix Lechner]

Control: reassign -1 haskell-devscripts
Control: retitle -1 haskell-devscripts: Shell expansion breaks nested
quotes in GHC arguments
Control: affects -1 haskell-hashable

Hi,

> unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'

I believe the quotes in haskell-hashable here: [1]

DEB_SETUP_GHC_CONFIGURE_ARGS = --hsc2hs-options="$(LFS_CFLAGS)"
--gcc-options="$(LFS_CFLAGS)" --ghc-options="$(GHC_LFSFLAGS)"

are lost when the environment variable is shell-expanded in
haskell-devscripts here: [2]

# DEB_SETUP_GHC_CONFIGURE_ARGS can contain multiple arguments
# with their own quoting so run through a shell expansion
my $ghc_configure_args = run_quiet(
qw{sh -c},
'echo -n '
  . $DOUBLE_QUOTE
  . ($ENV{DEB_SETUP_GHC_CONFIGURE_ARGS} // $EMPTY)
      . $DOUBLE_QUOTE
);

Kind regards,
Felix Lechner

[1] 
https://salsa.debian.org/haskell-team/DHG_packages/-/blob/master/p/haskell-hashable/debian/rules#L6
[2] 
https://salsa.debian.org/haskell-team/haskell-devscripts/-/blob/master/lib/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm#L597-605

Bug#1000234: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #1000234 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/c39ee6ca53e0c761b6e124792c7941fd87f6e107


Tolerate multiarch acceptors in prerequisites for Debhelper commands and 
addons. (Closes: #1000234)

This fixes the issue reported here and in the cloned Bug#999810, although for
the wrong reason. Lintian currently assumes that prerequisites are met when the
unrestricted declared prerequisites imply, or satisfy, a particular requirement.

In the present situation, Lintian replaces the :native multiarch acceptor on
python3-sphinx with :any (no restrictions!) and compares it with the weakest
assertion we can make about prerequisites, which is also :any. Hey, presto!

That logic is flawed and will be fixed in additional commits in the near future.

The offending hint in cmake is now gone even if the preceeding commit is
reverted. Please note the comment about that in the preceeding commit.

Thanks to Timo Röhling for bringing the matter to our attention!


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1000234

Bug#1000476: lintian: autopkgtest regression: autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/binaries/corrupted/legacy-debug/generic.t

[Felix Lechner]

Control: tags -1 + pending

Hi,

Thanks for this message.

On Tue, Nov 23, 2021 at 12:48 PM Paul Gevers  wrote:
>
> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/odd-inputs/strings-elf-detection/generic.t

That test was already dropped from Lintian. [1]

> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/binaries/corrupted/legacy-debug/generic.t

That test was adjusted for recent versions of Binutils. [2]

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/deba665363a3dd4da8b806df07091c9c482206d7
[2] 
https://salsa.debian.org/lintian/lintian/-/commit/c16b75a7547e547a13a1f1add4d80bb72e16c361

Bug#995492: lintian: Broken --fails-on=none as default never got reverted

[Felix Lechner]

Hi Guillem,

On Fri, Oct 1, 2021 at 6:57 PM Guillem Jover  wrote:
>
> Unamused,

I am sorry that happened. Did I not accept your patch in full? [1]

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/3758bfafd5dd742c327f2312dac8e3a71b1f036e

Bug#995216: simple-scan: B&W Text scans saved as gibberish

[Felix Lechner]

Package: simple-scan
Found: 3.38.1-1
Severity: grave

Hi,

Starting earlier today (between scans) simple-scan on bullseye became
unable to save B&W text scans properly. Now they are saved as
gibberish.

It is possible the files are being saved in a format not understood by
my PDF reader, but I could not find a common reader that worked: I
tried evince, muPDF, gscan2pdf, an old trial version of Master PDF
Editor, and GIMP and Inkscape. Only LibreOffice Draw got it right.

In accordance with the recommendations here [1] I marked the bug
'grave' because I lost data because of it (or so it seemed when I
wrote). The bug is also somewhat treacherous: The image on the screen
looks fine. One has to open the saved file to see the issue.

Thanks for simple-scan! It's a great and best-in-class program!

Kind regards
Felix Lechner

[1] https://www.debian.org/Bugs/Developer#severities

Bug#995215: postgresql-semver: Wait for acceptance of backport

[Felix Lechner]

Package: postgresql-semver
Severity: serious

The sole purpose of this bug is to keep version 0.31.1-3 out of
testing until version 0.31.1-2~bpo11+1 is in backports.

Bug#993955: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #993955 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/88e5cc61afa5503ac24201c44787ef2d83f03f17


Drop recommendation to implement usr-merge for individual packages. (Closes: 
#993955)

This tag is a research tag. It was not issued for any packages, but the
description is accessible on Lintian's website and should reflect the current
consensus on the mailing lists.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/993955

Bug#993651: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #993651 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/0b5afce8edbb2cc8f0756a70299d2b4b83c4ce4e


Read checks separately from ./lib and ./checks; forego symbolic link. (Closes: 
#993651)

When pkg-js-tools is installed, dpkg does not set the symbolic link
/usr/share/lintian/checks, and none of the checks in ./lib/Lintian/Check are
found. The error is lengthy. [1]

Needed for a proper upgrade path. Reads both locations separately instead.

Also does the same for screens, but that was not relevant for the bug.

[1] https://lists.debian.org/debian-lint-maint/2021/09/msg5.html

Gbp-Dch: ignore


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/993651

Bug#982459:

[Felix Lechner]

Hi,

On Sun, Aug 15, 2021 at 2:45 AM Håkan T Johansson  wrote:
>
> I believe that I have been hit by this bug too.

Thanks for the bug amendment! The 4.1 release happened nearly three
years ago. With bullseye released, I just uploaded the latest release
candidate 4.2~rc2-2 from upstream to Debian unstable. Feel free to try
that too. Thank you!

Kind regards
Felix Lechner

Bug#982459: mdadm --examine in chroot without /proc,/dev,/sys mounted corrupts host's filesystem

[Felix Lechner]

Hi,

On Tue, Jul 13, 2021 at 12:42 AM Judit Foglszinger  wrote:
>
> tried again but still fail to reproduce

Thanks for trying to reproduce this bug! I am not sure it makes any
difference either way, but I recently uploaded upstream's new release
candidate 4.2~rc1 to experimental:

https://packages.debian.org/source/experimental/mdadm

Kind regards
Felix Lechner

Bug#985468: Please cherry-pick 7d2222cf from upstream for bullseye

[Felix Lechner]

Package: msmtp-mta
Severity: serious
Justification: Does not work with Python's widely used smtplib

Hi,

For release with bullseye, please apply the attached patch from upstream
to version 1.8.11-2 in unstable. When patched, msmtpd also accepts SMTP
commands in lowercase.

Then, the program works with Python's widely used 'smtplib' module. The
current behavior may be against RFC 821, which states that the commands
"can be any syntax, such as mAiL FroM". [1]

Please have a look at my bug report upstream. [2] I encountered the
issue when sending reminders for expiring Debian keys.  The attached
patch was tested with this script [3] and fixes the issue. It would be
nice to have the fix in bullseye.

As an experiment, I also sent email with the patched version (although
without Python's smtplib, and with the sendmail program). Perhaps it
shows that the patch does not break the program for everyone else.

I used the 'serious' level—normally only available to the maintainer—to
bring the bug to the attention of the release team, who recommended this
filing.

Below is a debdiff for the resulting sources, in addition to the patch.
Thanks for taking a look!

Kind regards
Felix Lechner

[1] https://bugs.python.org/issue29860
[2] https://github.com/marlam/msmtp-mirror/issues/45
[3] 
https://salsa.debian.org/lechner/key-expirations/-/blob/master/upcoming-expirations#L72-74

* * *

diff -Nru msmtp-1.8.11/debian/changelog msmtp-1.8.11/debian/changelog
--- msmtp-1.8.11/debian/changelog   2020-08-20 07:24:11.0 -0700
+++ msmtp-1.8.11/debian/changelog   2021-03-18 09:01:45.0 -0700
@@ -1,3 +1,13 @@
+msmtp (1.8.11-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick 7dcf from upstream for bullseye. Fixes failure to work
+with Python's widely used 'smtplib' as described here:
+- https://github.com/marlam/msmtp-mirror/issues/45
+    - https://bugs.python.org/issue29860
+
+ -- Felix Lechner   Thu, 18 Mar 2021 09:01:45 -0700
+
 msmtp (1.8.11-2) unstable; urgency=medium
 
   * Fix build options to re-enable TLS support via GnuTLS, IDN and SASL.
diff -Nru 
msmtp-1.8.11/debian/patches/7dcfd522efc13fde4df448d834bc6ba2b205-adjusted.diff
 
msmtp-1.8.11/debian/patches/7dcfd522efc13fde4df448d834bc6ba2b205-adjusted.diff
--- 
msmtp-1.8.11/debian/patches/7dcfd522efc13fde4df448d834bc6ba2b205-adjusted.diff
  1969-12-31 16:00:00.0 -0800
+++ 
msmtp-1.8.11/debian/patches/7dcfd522efc13fde4df448d834bc6ba2b205-adjusted.diff
  2021-03-18 09:01:45.0 -0700
@@ -0,0 +1,70 @@
+Description: Cherry-pick 7dcf from upstream for bullseye, adjusted
+Author: Felix Lechner 
+Origin: 
https://github.com/marlam/msmtp-mirror/commit/7dcfd522efc13fde4df448d834bc6ba2b205.diff
+Bug: https://github.com/marlam/msmtp-mirror/issues/45
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/msmtpd.c
 b/src/msmtpd.c
+@@ -26,6 +26,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -186,18 +187,18 @@ int msmtpd_session(FILE* in, FILE* out,
+ fprintf(out, "220 localhost ESMTP msmtpd\r\n");
+ if (read_smtp_cmd(in, buf, SMTP_BUFSIZE) != 0)
+ return 1;
+-if (strncmp(buf, "EHLO ", 5) != 0 && strncmp(buf, "HELO ", 5) != 0) {
++if (strncasecmp(buf, "EHLO ", 5) != 0 && strncasecmp(buf, "HELO ", 5) != 
0) {
+ fprintf(out, "500 Expected EHLO or HELO\r\n");
+ return 1;
+ }
+ fprintf(out, "250 localhost\r\n");
+ if (read_smtp_cmd(in, buf, SMTP_BUFSIZE) != 0)
+ return 1;
+-if (strncmp(buf, "MAIL FROM:", 10) != 0 && strcmp(buf, "QUIT") != 0) {
++if (strncasecmp(buf, "MAIL FROM:", 10) != 0 && strcasecmp(buf, "QUIT") != 
0) {
+ fprintf(out, "500 Expected MAIL FROM: or QUIT\r\n");
+ return 1;
+ }
+-if (strcmp(buf, "QUIT") == 0) {
++if (strcasecmp(buf, "QUIT") == 0) {
+ fprintf(out, "221 Bye\r\n");
+ return 0;
+ }
+@@ -235,19 +236,19 @@ int msmtpd_session(FILE* in, FILE* out,
+ return 1;
+ }
+ if (!recipient_was_seen) {
+-if (strncmp(buf, "RCPT TO:", 8) != 0) {
++if (strncasecmp(buf, "RCPT TO:", 8) != 0) {
+ fprintf(out, "500 Expected RCPT TO:\r\n");
+ free(cmd);
+ return 1;
+ }
+ } else {
+-if (strncmp(buf, "RCPT TO:", 8) != 0 && strcmp(buf, "DATA") != 0) 
{
++if (strncasecmp(buf, "RCPT TO:", 8) != 0 && strcasecmp(buf, 
"DATA") != 0) {
+ fprintf(out, "500 Expected RCPT TO: or DATA\r\n");
+ free(cmd);

Bug#984716: gocryptfs: data loos upon full root file system

[Felix Lechner]

Control: forwarded -1 https://github.com/rfjakob/gocryptfs/issues/550
Control: severity -1 important

Hi Matthias,

On Sun, Mar 7, 2021 at 8:39 AM Matthias Jäger  wrote:
>
> the encrypted data was missing.

Both upstream and I are stymied by your experience. I forwarded your
report upstream [1] where you can find a response from Jakob. Since
you are using the version in Debian stable, your issue is presumably
present in all versions of gocryptfs and therefore best tracked
upstream. Of course, you are still welcome to comment here.

[1] https://github.com/rfjakob/gocryptfs/issues/550

> I'm using a gocryptfs container.

It would be helpful if the bug could be reproduced—ideally, with
version 1.8.0-1.

> I can not be sure that this is caused by gocryptfs

Your loss of data warrants the highest severity, but your report is
about the stable version. Debian is currently in a release freeze,
which means your filing is also severe enough to keep version 1.8.0-1
out of bullseye. Meanwhile, I have used gocryptfs without problems for
several years in another complex setup (with kerberized NFSv4). We
also do not know for sure, as you stated, that gocryptfs is at fault.
For those reasons, I am downgrading this report to the highest non-RC
level—at least until bullseye is released.

Kind regards
Felix Lechner

Bug#962921: Please fix spam for bullseye

[Felix Lechner]

Dear maintainer,

The release team will accept this patch for bullseye. They raised the
bug status to "serious" after I asked on your behalf. Please upload a
patched version and ask for unblocking in a bug against release.d.o.

Thanks for your contributions to Debian!

Kind regards
Felix Lechner

Bug#984554: libnginx-mod-stream-geoip: ngx_stream_geoip_module.so: undefined symbol: ngx_stream_add_variable

[Felix Lechner]

The following thread is more recent and describes the same phenomenon:

https://github.com/oerdnj/deb.sury.org/issues/1437#issuecomment-734722970

Bug#984554: [SOLVED] Bug#984554: libnginx-mod-stream-geoip: ngx_stream_geoip_module.so: undefined symbol: ngx_stream_add_variable

[Felix Lechner]

Hi,

After comparing the failing upgrade with other, working installations
of 'nginx-full' and following the precedence rationale here [1], I was
able to resolve the installation impasse by running the following
command in /etc/nginx/modules-enabled:

ln -s /usr/share/nginx/modules-available/mod-stream.conf 50-mod-stream.conf

Hope that helps!

Kind regards
Felix Lechner

[1] http://mailman.nginx.org/pipermail/nginx/2016-July/051323.html

Bug#984554: libnginx-mod-stream-geoip: ngx_stream_geoip_module.so: undefined symbol: ngx_stream_add_variable

[Felix Lechner]

Package: libnginx-mod-stream-geoip
Version: 1.18.0-6+b1
Severity: grave
Justification: dependent package 'nginx-full' crashes and does not install

Hi,

When dist-upgrading from buster to bullseye, I ended up with a broken
nginx-full ("nginx-full is broken or not fully installed") due to:

/usr/share/nginx/modules/ngx_stream_geoip_module.so: undefined
symbol: ngx_stream_add_variable

in /etc/nginx/modules-enabled/70-mod-stream-geoip.conf:1.

Both libnginx-mod-geoip and libnginx-mod-geop2 are installed. Also,
both are present in ./modules-enabled but not in ./modules-available.
(Does that look like another bug?) The error is otherwise a mystery to
me because I also updated a few other nginx installations without
incident.

I filed this bug as "release critical" after asking about the
appropriate level on OFTC:#debian-release.

As a side note, I saw Bug#953034 ("nginx: improve dependency of
dynamic modules") but on first glance that did not look related.

For more detailed messages from 'apt -t bullseye dist-upgrade', please
see below. Thank you!

Kind regards
Felix Lechner

* * *

dpkg: dependency problems prevent configuration of nginx:
 nginx depends on nginx-core (<< 1.18.0-6.1~) | nginx-full (<<
1.18.0-6.1~) | nginx-light (<< 1.18.0-6.1~) | nginx-extras (<<
1.18.0-6.1~); however:
  Package nginx-core is not configured yet.
  Package nginx-full is not configured yet.
  Package nginx-light is not installed.
  Package nginx-extras is not installed.
 nginx depends on nginx-core (>= 1.18.0-6) | nginx-full (>= 1.18.0-6)
| nginx-light (>= 1.18.0-6) | nginx-extras (>= 1.18.0-6); however:
  Package nginx-core is not configured yet.
  Package nginx-full is not configured yet.
  Package nginx-light is not installed.
  Package nginx-extras is not installed.

dpkg: error processing package nginx (--configure):
 dependency problems - leaving unconfigured
Setting up node-resolve (1.19.0+~cs5.20.8-2) ...
Setting up node-ajv (6.12.6-2) ...
dpkg: dependency problems prevent configuration of python3-certbot-nginx:
 python3-certbot-nginx depends on nginx; however:
  Package nginx is not configured yet.
  Package nginx-full which provides nginx is not configured yet.
  Package nginx-core which provides nginx is not configured yet.

dpkg: error processing package python3-certbot-nginx (--configure):
 dependency problems - leaving unconfigured

* * * [and later on] * * *

Errors were encountered while processing:
 nginx-core
 nginx-full
 nginx
 python3-certbot-nginx
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up nginx-core (1.18.0-6+b1) ...
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xe" for details.
invoke-rc.d: initscript nginx, action "start" failed.
● nginx.service - A high performance web server and a reverse proxy server
 Loaded: loaded (/lib/systemd/system/nginx.service; enabled;
vendor preset: enabled)
 Active: failed (Result: exit-code) since Wed 2021-03-03 16:25:35
PST; 36ms ago
   Docs: man:nginx(8)
Process: 28896 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on;
master_process on; (code=exited, status=1/FAILURE)
CPU: 11ms

Mar 03 16:25:35 wallace-server.us-core.com systemd[1]: Starting A high
performance web server and a reverse proxy server...
Mar 03 16:25:35 wallace-server.us-core.com nginx[28896]: nginx:
[emerg] dlopen() "/usr/share/nginx/modules/ngx_stream_geoip_module.so"
failed (/usr/share/nginx/modules/ngx_stream_geoip_module.so: undefined
symbol: ngx_stream_add_variable) in
/etc/nginx/modules-enabled/70-mod-stream-geoip.conf:1
Mar 03 16:25:35 wallace-server.us-core.com nginx[28896]: nginx:
configuration file /etc/nginx/nginx.conf test failed
Mar 03 16:25:35 wallace-server.us-core.com systemd[1]: nginx.service:
Control process exited, code=exited, status=1/FAILURE
Mar 03 16:25:35 wallace-server.us-core.com systemd[1]: nginx.service:
Failed with result 'exit-code'.
Mar 03 16:25:35 wallace-server.us-core.com systemd[1]: Failed to start
A high performance web server and a reverse proxy server.

Bug#962844: marked as pending in mdadm

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #962844 in mdadm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lechner/mdadm/-/commit/cea46a2f7341b5b87d55f66d623a352fbc0bf41a


Load efivars module in initramfs, if available. (Closes: #962844)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/962844

Bug#962844: mdadm: Assembling RAID using IMSM in initrd fails due to lack of module efivarfs

[Felix Lechner]

Hi Chris,

On Sun, Feb 7, 2021 at 9:22 AM Chris Hofstaedtler  wrote:
>
> friendly ping here, are you planning to fix this for bullseye?

Thanks for the reminder! I will probably include efivars in the next
couple of days.

Kind regards
Felix

Bug#979534: wolfssl: CVE-2020-36177

[Felix Lechner]

Hi,

On Thu, Jan 7, 2021 at 12:12 PM Salvatore Bonaccorso  wrote:
>
> CVE-2020-36177[0]:

This vulnerability will be fixed in the next couple of days via upload
of version 4.6.0 to unstable. A backport of the fix is not possible
(freeze notwithstanding). Also, the patches from #978676 do not apply,
or apply only partially, because we are changing the way the sources
are repackaged.

Kind regards
Felix Lechner

Bug#977594: liblist-moreutils-perl: autopkgtest regressions, breaks lintian

[Felix Lechner]

Hi,

> There are also bug reports against lintian about this, at least #977419
> and possibly #977554.

Thanks for filing this bug and setting affects. The other two bugs
were merged into this one.

> AIUI lintian in git has a fix/workaround.

It was not a workaround. Lintian stopped using liblist-moreutils-perl
in the development head for unrelated reasons before the new version
was uploaded. (For details, please see Bug#977419.)

Also, in case it is helpful, the new version of 'any' seemed to behave
differently with the somewhat awkward use of $_[0] here.


https://salsa.debian.org/lintian/lintian/-/blob/2.104.0/checks/fields/package-relations.pm#L129

That code was likewise replaced for unrelated reasons, and is no
longer available in Lintian.

Kind regards
Felix Lechner

Bug#974829: marked as pending in mdadm

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #974829 in mdadm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lechner/mdadm/-/commit/9d92df06f661078300bacee78c0e852cc16a07da


For initramfs, copy 'rm' executable from existing location; and to /bin. 
(Closes: #974829)

Sorry, this patch was supposedly signed off by two users, including
the original filer.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/974829

Bug#970896: lintian times out while analyzing package

[Felix Lechner]

Control: severity 970896 normal

Hi Kunal,

On Thu, Sep 24, 2020 at 8:57 PM Kunal Mehta  wrote:
>
> Trying to run lintian locally against src:mediawiki 1:1.35.0~rc.3-1 never
> completed

I cannot confirm that with the version in unstable (see below) but
will also try the build artifacts from your failed job in Salsa.
Perhaps it had something to do with the fact that you were building
for bionic, a Ubuntu codename.

Meanwhile, I downgraded the severity of this bug.

Kind regards,
Felix Lechner

* * *

[/l/l/l/git]─[⎇ master]─[+]|> bin/lintian
/mirror/debian/pool/main/m/mediawiki/mediawiki_1.31.8-1.dsc
I: mediawiki source: patch-not-forwarded-upstream
debian/patches/pear-phail-fail-shebang.diff
P: mediawiki source: package-uses-old-debhelper-compat-version 12
P: mediawiki source: source-contains-browserified-javascript
resources/lib/sinonjs/sinon-1.17.3.js code
fragment:if("object"==typeof exports&&"undefined"!=typeof
module)module.exports=e();else if("fu
P: mediawiki source: source-contains-prebuilt-javascript-object
extensions/Cite/modules/ve-cite/tests/ve.dm.citeExample.js line length
is 297 characters (>256)
P: mediawiki source: source-contains-prebuilt-javascript-object
extensions/CodeEditor/modules/ace/ext-elastic_tabstops_lite.js
P: mediawiki source: source-contains-prebuilt-javascript-object
extensions/CodeEditor/modules/ace/ext-searchbox.js line length is 273
characters (>256)
P: mediawiki source: source-contains-prebuilt-javascript-object ...
use --no-tag-display-limit to see all (or pipe to a file/program)
P: mediawiki source: very-long-line-length-in-source-file
extensions/CodeEditor/modules/ace/mode-actionscript.js line length is
1381 characters (>512)
P: mediawiki source: very-long-line-length-in-source-file
extensions/CodeEditor/modules/ace/mode-apache_conf.js line length is
751 characters (>512)
P: mediawiki source: very-long-line-length-in-source-file
extensions/CodeEditor/modules/ace/mode-assembly_x86.js line length is
4030 characters (>512)
P: mediawiki source: very-long-line-length-in-source-file ... use
--no-tag-display-limit to see all (or pipe to a file/program)
N: pear/net_smtp already in Debian
O: mediawiki source: license-problem-php-license debian/copyright
N: pear/net_smtp already in Debian
O: mediawiki source: license-problem-php-license vendor/pear/net_smtp/LICENSE
N: lintian thinks a bunch of test/data/etc. files are missing source
N: because they have long lines but they're not
O: mediawiki source: source-is-missing
extensions/Cite/modules/ve-cite/tests/ve.dm.citeExample.js line length
is 297 characters (>256)
N: lintian thinks a bunch of test/data/etc. files are missing source
N: because they have long lines but they're not
O: mediawiki source: source-is-missing
extensions/CodeEditor/modules/ace/ext-elastic_tabstops_lite.js
N: lintian thinks a bunch of test/data/etc. files are missing source
N: because they have long lines but they're not
O: mediawiki source: source-is-missing
extensions/CodeEditor/modules/ace/ext-searchbox.js line length is 273
characters (>256)
N: lintian thinks a bunch of test/data/etc. files are missing source
N: because they have long lines but they're not
O: mediawiki source: source-is-missing ... use --no-tag-display-limit
to see all (or pipe to a file/program)
N: we have a composer.json file, but aren't a composer package
O: mediawiki source: composer-package-without-pkg-php-tools-builddep
N: We use upstream's keys.txt exactly for easier integrity verification
O: mediawiki source: public-upstream-key-not-minimal
upstream/signing-key.asc has 15 extra signature(s) for keyid
F6DAD285018FAC02
N: We use upstream's keys.txt exactly for easier integrity verification
O: mediawiki source: public-upstream-key-not-minimal
upstream/signing-key.asc has 7 extra signature(s) for keyid
361F943B15C08DD4
N: We use upstream's keys.txt exactly for easier integrity verification
O: mediawiki source: public-upstream-key-not-minimal
upstream/signing-key.asc has 9 extra signature(s) for keyid
C119E1A64D70938E

Bug#969663: polyphone is marked for autoremoval from testing

[Felix Lechner]

Hi Thorsten,

Uploaded, although I am still looking for it on the buildds:

> wolfssl_4.5.0+dfsg-1_source.changes uploaded successfully to localhost
> along with the files:
>   wolfssl_4.5.0+dfsg-1.dsc
>   wolfssl_4.5.0+dfsg.orig.tar.xz
>   wolfssl_4.5.0+dfsg-1.debian.tar.xz
>   wolfssl_4.5.0+dfsg-1_source.buildinfo
>
> Greetings,
>
> Your Debian queue daemon (running on host usper.debian.org)

Kind regards
Felix Lechner

Bug#969663: polyphone is marked for autoremoval from testing

[Felix Lechner]

Hi Thorsten,

> Is there anything I can help to ensure it’s not autoremoved?

I just saw it this morning and plan to upload 4.5.0 later today. From
what I understand, closing #969663 should postpone the autoremoval
process?

Kind regards
Felix

Bug#962844: mdadm: Assembling RAID using IMSM in initrd fails due to lack of module efivarfs

[Felix Lechner]

Hi Colin,

> The efivarfs module was not found in the initrd

I would like to make sure any new module requirements are also
compatible with systems booting in legacy BIOS mode. The Wikipedia
article for Intel RST states:

> When booting in a BIOS environment (legacy) and some / EFI, the RST option
> ROM is used. When booting in a true UEFI environment the Option ROM is not
> used as a SataDriver with the RST version takes over. In BIOS mode the
> legacy/BIOS booting is under CSMCORE. In true UEFI mode the RST is
> controlled under SataDriver in BIOS. [1]

The article suggests that some people use IMSM arrays in legacy BIOS
mode. Does mdadm support IMSM only when the system is booted in UEFI
mode?

Sorry that I do not know the answer to that question. I just assumed
maintenance of mdadm and do not use IMSM. At this point, I am reading
code. Thank you!

Kind regards
Felix Lechner

[1] 
https://en.wikipedia.org/wiki/Intel_Rapid_Storage_Technology#Matrix_Storage_Manager_option_ROM

Bug#964405: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #964405 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/69fdf8a8c68044bea8edef1b527cf2e044694ac8


Use new path to test recipes in autopkgtest. (Closes: #964405)

The path to the test specifications changed in commit 29ac0192. That
commit totally ignores the use of the path in autopkgtest, which is
fixed here.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/964405

Bug#964234: dpkg,firmware-nonfree: cannot unpack: dpkg-source: error: pathname 'firmware-nonfree-20190717/debian/config/libertas/sd8688_helper.bin' points outside source root

[Felix Lechner]

Hi Andreas,

> dpkg-source: error: pathname
> points outside source root

Maybe the same as Bug#964111?

Kind regards
Felix Lechner

Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies

[Felix Lechner]

Hi,

> the OpenSSL ./. GPL problem (if one sees it as a problem) is larger

There may be an alternative for some cases mentioned here. The wolfSSL
encryption library is a FIPS-certified, commercial product with a
fully usable, although incomplete, OpenSSL compatibility layer. The
developers are very friendly toward open-source. One of them uses
Ubuntu.

Licensed under the GPL (or alternatively proprietary terms), wolfSSL
avoids the linking problems OpenSSL has been trying to shed for years.
wolfSSL is popular in embedded systems. If you bought an appliance or
a car in the past ten years, you are probably using it already.

In the enterprise space, MariaDB ships with an older, captive version.
For a long time, MySQL relied on it (then called cyaSSL). I do not
know if PostgreSQL can use it.

Here is a list of projects that have been officially ported. [1]

Daniel Stenberg, the creator of cURL, works there. I see the
developers from time to time and receive free support. The library has
been in Debian for five years.

Kind regards
Felix Lechner

[1] https://www.wolfssl.com/community/

Bug#962158: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #962158 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/3758bfafd5dd742c327f2312dac8e3a71b1f036e


Restore program failure when error tags are found. (Closes: #962158)

There were some concerns that this change would be too disruptive.
They are probably valid but remain unsubstantiated.

Thanks to Guillem Jover for the patch!


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/962158

Bug#962158: lintian: New very problematic --fail-on default value

[Felix Lechner]

Hi Chris,

On Tue, Jun 9, 2020 at 11:15 PM Chris Lamb  wrote:
>
> Felix, can you help out? I am not in a position to contribute to this
> discussion itself.

Well, I wish I could. Guillem makes many alarmist statements, but
fails to explain why the change is an undue burden. I also do not know
how to engage productively with visceral and absolute responses such
as:

> Err…
> it does not make any sense whatsoever
> does not match reality
> it does not even make sense within a Debian-centric view
> I'll have to very much disagree
> you have still not explained what this default change really accomplishes
> besides inducing tons of work and breakage
> No, they did not.

It's amazing how much time and energy Guillem expended on this issue
here, on IRC, and in #962157 while dpkg has more open bugs than
Lintian.

As you know from my past behavior with 'md5sums -z' or the odd
contributor on Salsa, I am not opposed to compromise when it brings
peace. In the present case, such a compromise could be a value 'none'
to disable the default Guillem likes (and which I would like to
remove).

At the same time, the change was widely released two weeks ago. Simon
Quigley from Ubuntu announced it on debian-devel on May 25 [1], while
I advertised the change repeatedly on IRC and added a note to DevNews.
Some users may have already adapted their systems.

[1] https://lists.debian.org/debian-devel/2020/05/msg00239.html

Now the best course of action, I think, is to downgrade the severity
again to Guillem's original setting of 'important'. That will allow
the change to remain in testing. It is, after all, what the testing
distribution is for.

It would also give me more time to understand the possibly
unreasonable burden on Lintian users across Debian and the derivative
ecosystem. Simon may receive feedback from Ubuntu, a significant
derivative. If there are real problems, I am happy to discuss a
solution that reverts the default to Lintian's old setting.

Kind regards
Felix Lechner

Bug#962158: lintian: Swapped exit statuses and --fail-on default value require downstream adjustments

[Felix Lechner]

Hi

On Thu, Jun 4, 2020 at 3:21 PM Chris Lamb  wrote:
>
> I can relate to this feeling so let me do this for you. At the very
> least, this change now won't hit bullseye before being resolved.

I also agree with this bump in severity. Thanks!

> This change means that any current caller which uses lintian as part
> of its acceptance testing will now silently let broken things through

As I explained on IRC this statement is probably untrue (and you did
not have the courtesy to mention that objection here). From what I can
tell, the FTP Master (who are arguably the one "acceptance tester" who
really matters) parses the tags. [1] Please let me know if you know
otherwise.

[1] https://salsa.debian.org/ftp-team/dak/-/blob/master/daklib/lintian.py#L73-74

> If the default change made sense due to some technical rationale, this
> effort might be worthwhile

As I likewise explained on IRC, Lintian's return status was
unreliable. Some program errors exited with status 1 and others with
status 2, while detecting error tags always produced status 1. Lintian
was also unable to use Perl's 'die'. The proper remedy was to always
use status 1 for program errors. That step alone would require any
automated user to examine their scripts.

The 'fail-on' command-line option resolved a long standing problem
with the implicit behavior your so cherish (#709932). Instead of
adding more complex options, the current solution is simple, elegant,
straighforward and explicit. And again, automated users already had to
look at their scripts. It was the perfect timing to make both changes.

Kind regards,
Felix Lechner

Bug#961684: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #961684 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/db5e8f83357f4a6588f16be46c959f44345c375f


Deal gracefully with empty configuration files. (Closes: #961684)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/961684

Bug#956077: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #956077 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/-/commit/c25bdfa12f5474d5dc0f3bbd37a9c6ba92899f52


Do not look for conffiles in udebs. (Closes: #956077)

Fixes a false positive for file-in-etc-not-marked-as-conffile in
udebs, which do not declare conffiles.

The bug was introduced in commit 9d30607e, when the scope of some
checks was expanded to eliminate check descriptions.

Sorry about the inconvenience.

The problem is already present in rootskel_1.132_amd64.udeb from the
archive (no *.changes file needed). With this commit, the offending
tag is gone:

$ frontend/lintian ../bugs/udeb/rootskel_1.132_amd64.udeb
I: rootskel udeb: hardening-no-fortify-functions sbin/get-real-console-linux
I: rootskel udeb: package-contains-empty-directory dev/
I: rootskel udeb: package-contains-empty-directory initrd/
I: rootskel udeb: package-contains-empty-directory media/
I: rootskel udeb: package-contains-empty-directory ... use 
--no-tag-display-limit to see all (or pipe to a file/program)
P: rootskel udeb: executable-in-usr-lib usr/lib/finish-install.d/07rootskel

Thanks to Samuel Thibault for bringing this issue to our attention!


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/956077

Bug#954761: lintian: crashes with: coercion for "original_severity" failed: Unknown tag severity serious

[Felix Lechner]

Hi Paul,

On Sun, Mar 22, 2020 at 8:40 PM Paul Wise  wrote:
>
> Will the new Perl tests be enabled by default?

Well, that's what I did with xdeb, but it is causing #954415.

My inclination is yes, although personal profiles will soon become
very tweakable.

Kind regards

Felix Lechner

Bug#954761: lintian: crashes with: coercion for "original_severity" failed: Unknown tag severity serious

[Felix Lechner]

Hi Paul,

On Sun, Mar 22, 2020 at 7:44 PM Paul Wise  wrote:
>
> Yeah, doing with this mail.

Regarding the 'affects' setting, please know that the checks in
pkg-perl-tools will soon become part of Lintian (except perhaps the
one requiring network access). It will reduce problems like this.

Kind regards
Felix Lechner

Bug#954761: lintian: crashes with: coercion for "original_severity" failed: Unknown tag severity serious

[Felix Lechner]

Hi Paul,

On Sun, Mar 22, 2020 at 6:30 PM Paul Wise  wrote:
>
> Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x556c92ea6f30), 
> "/usr/share/lintian/tags/pkg-perl/module-build-tiny-needs-newe"...)

This is #954331 in pkg-perl-tools, which is already done.

Not sure how to best close this bug. Maybe 'forcemerge'?

Kind regards

Felix Lechner

Bug#954331: Please adjust tag severities

[Felix Lechner]

Control: reassign -1 pkg-perl-tools

Hi,

> Jonas Smedegaard wrote:
>
> Upgrading to version 2.58.0 of lintian renders it totally unusable:

That is not correct. Lintian just fails to work with pkg-perl-tools.

> Lintian::Tag::Info::original_severity(Lintian::Tag::Info=HASH(0x565295307a18),
>  "minor") called at /usr/share/perl5/Lintian/Tag/Info.pm line 182
> Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x565295307a18), 
> "/usr/share/lintian/tags/pkg-perl/nonteam-testsuite-header.desc") called at 
> /usr/share
>
> Lintian::Tag::Info::original_severity(Lintian::Tag::Info=HASH(0x55627b1c2e28),
>  "minor") called at /usr/share/perl5/Lintian/Tag/Info.pm line 182
> Lintian::Tag::Info::load(Lintian::Tag::Info=HASH(0x55627b1c2e28), 
> "/usr/share/lintian/tags/pkg-perl/nonteam-testsuite-header.desc") called at 
> /usr/share

The meaning of the Severity field in tag declarations has changed.
Please modify the tags in pkg-perl-tools accordingly. For details,
please see #935706 or this and the surrounding commits:


https://salsa.debian.org/lintian/lintian/-/commit/e1e12f7f4190ab5718e2317dd7e466d8b56d6043

Kind regards
Felix Lechner

Bug#949066: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #949066 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/commit/7975d71063bc1db65c42ef3f0448d129a5b791b5


For one i386-only test package, build only on i386. (Closes: #949066)

Unfortunately, dpkg-buildpackage cannot tell when no build is needed.
Source packages are nowadays permitted to build undeclared artifacts.
That is why a build attempt for this test package will fail even
though there is simply nothing to do.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/949066

Bug#949066: lintian: testsuite failures on arm*

[Felix Lechner]

Hi Gianfranco,

On Fri, Jan 24, 2020 at 8:39 AM Gianfranco Costamagna
 wrote:
>
> Felix gentle ping please?
> (in Ubuntu I disabled that test BTW and the result package autopkgtestsuite 
> was green on all archs)

The release took place solely to facilitate upgrading lintian.d.o,
which has been down for months. Details are in #949398; your bug is
mentioned there.

I have been working with the dpkg maintainers on a solution, which
will not happen anytime soon. The underlying problem is that
dpkg-buildpackage issues a build error when there is simply nothing to
do.

Fixing that is complicated because source packages nowadays permit the
building of undeclared artifacts. There is no longer a way to tell
from a source package if a build should be attempted. Either way, I
will triage your bug later today.

Thank you for your patience and for your help in trying to make
Lintian better for everyone.

Kind regards

Felix

Bug#949066: lintian: testsuite failures on arm*

[Felix Lechner]

Hi Gianfranco,

On Thu, Jan 16, 2020 at 8:26 AM Gianfranco Costamagna
 wrote:
>
> Hello, looks like tests regressed on arm64 and armhf

Thanks for pointing this out. It is a result of splitting the build
and test specifications. The best thing is probably to restrict the
building of affected tests with the proper wildcard in
'Package-Architecture:' in build-spec/fill-values. I will add them in
the near future.

A list of the test packages that failed to build on arm* would be helpful.

Kind regards
Felix

Bug#946396: Missing fcrypt causes Lintian test failure

[Felix Lechner]

Hi Aurelien,

On Sun, Dec 8, 2019 at 3:08 PM Aurelien Jarno  wrote:
>
> Hi,
>
> On 2019-12-07 13:42, Felix Lechner wrote:
> > Hi,
> >
> > Starting in `libc6 2.29-5`, the Lintian test
> > `t/tags/checks/binaries/binaries-obsolete-des` fails in `unstable`:
> >
> > cc -g -O2 
> > -fdebug-prefix-map=/builds/lintian/lintian/debian/test-out/packages/tags/checks/binaries/binaries-obsolete-des/binaries-obsolete-des-1.0=.
> > -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro
> > -Wl,-z,now uses-fcrypt.o -o uses-fcrypt -lcrypt
> > /usr/bin/ld: uses-fcrypt.o: in function `main':
> > ./uses-fcrypt.c:19: undefined reference to `fcrypt'
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [Makefile:34: uses-fcrypt] Error 1
>
> Sorry about breaking lintian with that change.

Your suggestion worked great for two weeks, but now the fix for
#946396 seems to have broken it again. As you can see from this build
log, libcrypt-dev is installed in unstable, but not libcrypt1-dev:

https://salsa.debian.org/lintian/lintian/-/jobs/484947/raw

> > Perhaps is it time to remove the test (and the tag
> > `obsolete-des-encryption`). Was `fcrypt` dropped entirely, or is it
> > still provided by `libcrypt`?
>
> Yes, fcrypt is still provided by libcrypt, and like libc it is
> not available to newly linked binaries, just for old binaries. That's
> why you need some tricks to link against it.
>
> > I do not understand the impact of this commit:
> >
> > 
> > https://salsa.debian.org/glibc-team/glibc/commit/e1dc23943b0a5c9e0612f8e1364a37f12b6710ef
> >
> > Here is the code that did not link:
> >
> > /* This program uses the obsolete function 'fcrypt',
> >which is an alias for 'crypt'.  */
> >
> > #include 
> > #include 
> >
> > /* The prototype may already have been removed from crypt.h.  */
> > extern char *fcrypt(const char *, const char *);
> >
> > /* It may already not be possible to link new programs that use
> >'fcrypt' without special magic.  */
> > #ifdef SYMVER
> > __asm__ (".symver fcrypt, fcrypt@" SYMVER);
> > #endif
> >
> > int
> > main(void)
> > {
> > puts(fcrypt("password", "Dn"));
> > return 0;
> > }
>
> The code itself works. However for that it needs to have SYMVER defined
> to the correct version. This is done in the Makefile, and it assumes
> that libcrypto.so is provided by libc6. The following patch makes the
> code to link correctly:
>
> --- t/tags/checks/binaries/binaries-obsolete-des/orig/Makefile.orig 
> 2019-12-08 23:05:20.520887001 +
> +++ t/tags/checks/binaries/binaries-obsolete-des/orig/Makefile  2019-12-08 
> 23:05:11.092888400 +
> @@ -5,7 +5,7 @@
>  # around, but we have to know the exact "symbol version" associated with
>  # the obsolete functions, which has to be dug out of libcrypt.so with nm.
>
> -LIBCRYPT_FILE := $(shell dpkg -L libc6-dev | grep 'libcrypt\.so$$')
> +LIBCRYPT_FILE := $(shell dpkg -L libcrypt1-dev | grep 'libcrypt\.so$$')
>  SYMVER := $(shell nm --dynamic --with-symbol-versions $(LIBCRYPT_FILE) | \
>  grep ' setkey@' | cut -d@ -f2)

Because the package libcrypt1-dev is not installed in unstable (only
libcrypt-dev is), your suggestion now errors out with:

   dh_auto_build
make -j1 "INSTALL=install --strip-program=true"
make[2]: Entering directory
'/builds/lintian/lintian/debian/test-out/packages/tags/checks/binaries/binaries-obsolete-des/binaries-obsolete-des-1.0'
dpkg-query: package 'libcrypt1-dev' is not installed
Use dpkg --contents (= dpkg-deb --contents) to list archive files contents.
nm: 'a.out': No such file
: update target 'uses-fcrypt.o' due to: uses-fcrypt.c
cc -g -O2 
-fdebug-prefix-map=/builds/lintian/lintian/debian/test-out/packages/tags/checks/binaries/binaries-obsolete-des/binaries-obsolete-des-1.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -USYMVER  -c -o uses-fcrypt.o uses-fcrypt.c
Makefile:38: update target 'uses-fcrypt' due to: uses-fcrypt.o
cc -g -O2 
-fdebug-prefix-map=/builds/lintian/lintian/debian/test-out/packages/tags/checks/binaries/binaries-obsolete-des/binaries-obsolete-des-1.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro
-Wl,-z,now uses-fcrypt.o -o uses-fcrypt -lcrypt
/usr/bin/ld: uses-fcrypt.o: in function `main':
./uses-fcrypt.c:19: undefined reference to `fcrypt'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:38: uses-fcrypt] Error 1

Is the solution to replace libcrypt1-dev in your suggestion in the
Makefile with libcrypt-dev?

Kind regards
Felix Lechner

Bug#945299: lintian: ignores all but last override of a tag

[Felix Lechner]

Fixed in:


https://salsa.debian.org/lintian/lintian/commit/cbf3f6487b19d16a99e8582e24ddc2817a5487ac

Kind regards,
Felix Lechner

Bug#945299: marked as pending in lintian

[Felix Lechner]

Control: tag -1 pending

Hello,

Bug #945299 in lintian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/lintian/lintian/commit/cbf3f6487b19d16a99e8582e24ddc2817a5487ac


Process all overrides for a particular tag and not just the last one. (Closes: 
#945276, #945299)

Thanks to Andreas Beckmann for the hint about the last override. Some
of that code was rewritten recently. Your hint really helped narrow
down the issue quickly.

Thanks to Martin Pitt, as well, for likewise bringing this problem to
our attention.

Finally, sorry about the inconvenience.


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/945299

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Felix Lechner]

Hi Chris,

On Sun, Nov 10, 2019 at 10:06 AM Chris Lamb  wrote:
>
> Felix, can you do the "honours" here?

Was this not resolved by the following?


https://salsa.debian.org/lintian/lintian/commit/33bd1434f0c160770a26bea55328e5bf7545322f

As you can see, I marked the bug as closed. The BTS never switched to
pending, presumably due to the version restriction via 'found'.

Or, do I need to backport the patch to that specific version?

Kind regards,
Felix Lechner

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Felix Lechner]

Hi Chris,

On Thu, Nov 7, 2019 at 2:07 PM Chris Lamb  wrote:
>
> I do not understand the frequency that Christoph's checks
> his email has any bearing here. Can you elaborate?

Unfortunately, I can only speculate that he meant to present a sense
of urgency. If a new release is needed, Christoph should speak up.
>From my perspective no action is required.

Kind regards,
Felix Lechner

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Felix Lechner]

Hi,

The version requirement was dropped:


https://salsa.debian.org/lintian/lintian/commit/33bd1434f0c160770a26bea55328e5bf7545322f

Since Christoph receives emails every six hours, a new release may be in order.

Thank you for your patience as we work to make Lintian better for everyone.

Kind regards,
Felix Lechner

On Thu, Nov 7, 2019 at 11:34 AM Adam D. Barratt
 wrote:
>
> On Thu, 2019-11-07 at 10:49 -0800, Felix Lechner wrote:
> > Also, as a side note, would someone please explain why someone still
> > on stretch would need lintian? I am personally on stable, but most
> > package maintainers out there seem to track testing or the bleeding
> > edge, unstable.
>
> Well, at least some debian.org infrastructure, including the ftp-master
> host, are still running stretch, for a starting point.
>
> Regards,
>
> Adam
>

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Felix Lechner]

Hi,

On Thu, Nov 7, 2019 at 10:33 AM Chris Lamb  wrote:
>
> > I'm not sure if that means that backport is really going to appear in
> > stretch-backports.
>
> That is my reading of it too. Felix, can we drop this requirement on
> coreutils for the time being? (I'm afraid I wasn't following the
> details at the time it was introduced.)

Yes, we probably can but I would like to understand, please, why
coreutils 8.30 (which, according to Andreas Beckmann, builds cleanly
in stretch) cannot find its way into stretch-bpo.

Also, as a side note, would someone please explain why someone still
on stretch would need lintian? I am personally on stable, but most
package maintainers out there seem to track testing or the bleeding
edge, unstable.

Kind regards,
Felix Lechner

Bug#944258: lintian 2.32.0~bpo9+1 in stretch-backports depends on coreutils (>= 8.30), but stretch has only 8.26-3

[Felix Lechner]

Hi Christoph,

On Wed, Nov 6, 2019 at 12:48 PM Christoph Berg  wrote:
>
> coreutils:
>   Versionstabelle:
>  *** 8.26-3 500

According to Andreas Beckmann, coreutils 8.30 is in the process of
being ported to stretch.

For details, please have a look at the PS here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943910#25

Kind regards,
Felix Lechner

CC: Andreas Beckmann

Bug#942252: lintian: No vendor given at /<>/lib/Lintian/Maintainer.pm line 33

[Felix Lechner]

Hi Sebastian,

On Sun, Oct 13, 2019 at 12:15 PM Chris Lamb  wrote:
>
> Thanks. Unfortunately, I don't quite know why this is happening. (The
> tests on Salsa appear to pass right now.)

Some test scripts appear to load old profiles. They are presumably
located in the installed location /usr/share/lintian. The errors
depend on the version difference between what is installed and what is
under test. That is probably why the reported bug does not show up in
Gitlab (anymore).

Could you please cherry-pick this commit?
https://salsa.debian.org/lintian/lintian/commit/33508343d8fde77a3d5db22863ff358dbf7a915f

This commit does two things: (1) It unambiguously uses only one
include path when finding profiles, and (2) makes sure a profile is
loaded in the test pod-synopsis.t that fails in your bug report.

I cannot test the proposed fix locally (the error does not appear
here). Which version Lintian do you have installed?

Kind regards,
Felix Lechner

Bug#918952: Bug#929468: wolfssl: NMU for wolfssl 4.1.0.

[Felix Lechner]

Hi Paul,

On Wed, Sep 11, 2019 at 6:12 AM Ying-Chun Liu (PaulLiu)
 wrote:
>
> I'm maintaining telegram-cli. I'm using wolfssl because telegram-cli is
> GPL.
>
> They are using openssl but it is actually violates the GPL license. So I
> tried to build telegram-cli with wolfssl and it just works great.

That's why I uploaded it. It only took four years for someone to think
the same way!

I'll look over your patch and update the package. Thanks for using it.

Kind regards,
Felix

Bug#918952: Bug#929468: wolfssl: NMU for wolfssl 4.1.0.

[Felix Lechner]

Hi Paul,

I am the maintainer of this library package. Are you aware of any
packages that depend on it?

Kind regards
Felix

Bug#932000: In testing

[Felix Lechner]

On Wed, Jul 24, 2019 at 6:31 AM Benjamin Kaduk  wrote:
>
> It's hard to come up with many scenarios in which they could be related.
> The only remotely plausible one that comes to mind is if the idmapd is
> somehow using a different keytab (or libkrb5) than the core NFS server, but
> I don't remember the architecture working like that.

It was caused by sssd 1.16.3 -> 2.2.0 upgrading (and apparently
invalidating) a cache database on the server. I apologize for writing.
krb5-NFSv4 is complicated to understand.

Felix

Bug#932000: In testing

[Felix Lechner]

On Tue, Jul 16, 2019 at 8:07 AM Greg Hudson  wrote:
>
> Candidate patch here:

Thank you. The update works great, although I now have problems with
idmap not working on a kerberized NFSv4 mount.

I write with hesitation. A week has passed and many other packages
were likewise updated. My idmap issue could not be related to cipher
suites in krb5, could it?

Bug#918817: lintian: Returns with exit code of 0 (zero) on failed tests

[Felix Lechner]

Please see

https://salsa.debian.org/lintian/lintian/merge_requests/121

although I cannot explain the exit code '2' right now.

Bug#917752: lintian: FTBFS: tests failed

[Felix Lechner]

This bug is fixed. It can be marked as pending when the merge requests
for the two blocking bugs are accepted.

Bug#913930: Confirmed for sbuild only

[Felix Lechner]

Hi Harlan!

On Thu, Dec 27, 2018 at 9:09 PM Harlan Lieberman-Berg
 wrote:
>
> Just as one more datapoint for you, I see the same thing with
> certbot-dns-ovh with lintian 2.5.118 and sbuild 0.77.1-2.

Thank you for writing! Your package builds much faster than lxc. The
problem was fixed in

https://salsa.debian.org/lintian/lintian/merge_requests/114

Kind regards
Felix Lechner

Bug#917844: Fixed

[Felix Lechner]

Hi,

I did not see the separate report at first and commented on #917752.
For a fix, please see:

https://salsa.debian.org/lintian/lintian/merge_requests/113

Felix Lechner

Bug#917752: lintian: FTBFS: tests failed

[Felix Lechner]

On Sun, Dec 30, 2018 at 3:06 PM Chris Lamb  wrote:
>
> > > -W: manpages-general: manpage-has-errors-from-man
> > > usr/share/man/man1/test.1p.gz 14: warning: macro `dep' not defined
> […]
> > Like you, I have not seen this one. This test was not changed recently;
> > neither was the associated check 'manpages.pm'.
>
> Mm, this appears to be caused by the recent groff 1.22.4-1 upload to
> unstable. Cloning, etc.

Please see this merge request for a solution:
https://salsa.debian.org/lintian/lintian/merge_requests/113

Bug#917752: lintian: FTBFS: tests failed

[Felix Lechner]

On Sun, Dec 30, 2018 at 3:06 PM Chris Lamb  wrote:
>
> > > +I: changes-upstream-signature-not-missing source:
> > > public-upstream-key-unusable upstream/signing-key.asc cannot be 
> > > processed
> >
> > This looks like #913930. I have only seen it in sbuild, but not otherwise.
>
> Interesting. Well, given that it is causing FTBFS I am raising the
> severity of that and marking as a blocker.

I am looking into this with some urgency.

> > > -W: manpages-general: manpage-has-errors-from-man
> > > usr/share/man/man1/test.1p.gz 14: warning: macro `dep' not defined
> […]
> > Like you, I have not seen this one. This test was not changed recently;
> > neither was the associated check 'manpages.pm'.
>
> Mm, this appears to be caused by the recent groff 1.22.4-1 upload to
> unstable. Cloning, etc.

I think you are right. I upgraded 'groff-base' this morning and then
starting seeing the error.

Bug#917752: lintian: FTBFS: tests failed

[Felix Lechner]

Chris,

On Sat, Dec 29, 2018 at 3:23 PM Chris Lamb  wrote:

>
> > > +I: changes-upstream-signature-not-missing source:
> public-upstream-key-unusable upstream/signing-key.asc cannot be processed
>
> Felix, not sure your MR/branch handles this one?
>

This looks like #913930. I have only seen it in sbuild, but not otherwise.


> > > -W: debhelper-compat-experimental source:
> package-needs-versioned-debhelper-build-depends 12
>
> I assume it addresses this one in an ongoing/sustainable manner.
>

This tag should no longer be issued. My builder automatically supplies the
correct dependency via:

desc: Dh-Compat-Level: 12
Default-Build-Depends: debhelper (>= {$dh_compat_level}~)

Because I run the test suite often, I am surprised I did not see it until
now. The tag will be removed with this merge request:

https://salsa.debian.org/lintian/lintian/merge_requests/112

> > -W: manpages-general: manpage-has-errors-from-man
> usr/share/man/man1/test.1p.gz 14: warning: macro `dep' not defined
> (possibly missing space after `de')
>
> I don't recall seeing one for these.
>

Like you, I have not seen this one. This test was not changed recently;
neither was the associated check 'manpages.pm'.

Bug#911403: Please always include a copyright notice in 'LicenseWithSummary::summary_or_text'

[Felix Lechner]

Hi Dominique,

I am fine with your suggestion. We will wait for your implementation.
Thank you for providing this package!

Kind regards,
Felix

On Mon, Oct 29, 2018 at 9:44 AM Dominique Dumont  wrote:
>
> On Monday, 29 October 2018 16:51:45 CET you wrote:
> > I am happy to provide patches and merge requests that implement your
> > idea,
>
> Thanks. But the change is trivial. I can do it on my side.
>
> We just need to find a common ground that allow fixing #905614
>
> > but are you sure there are other meaningful consumers of the
> > summary_or_text method?
>
> Absolutely not. But keeping backward compat with already published modules is
> one of the best values of the Perl community. I intend to keep that promise as
> much as possible
>
> > Your posting [1] restricts uses to Debian
>
> Debian and its 100+ derivates.
>
> > , and
> > a search on codesearch.debian.net shows no other packages that rely on
> > the current implementation that produces a copyright notice with a
> > full text but not with a summary. Why is the current implementation
> > worth keeping?
>
> Because we can't be sure that nobody will be impacted. A user may be relying
> on summary_or_text but has not (or will not) publish her or his code.
>
> > Please forgive me if I appear insistent. It's the only
> > question I have.
>
> No problem. You're right to challenge what is not clear :-)
>
> All the best
>
>
>
>

Bug#905614: Patch invalid

[Felix Lechner]

Control: tags 905614 - patch

The owner of libsoftware-licensemoreutils would like to resolve the
issue differently. (For details, please see #911403.) The patch I
submitted earlier is outdated. Thank you!

Kind regards,
Felix

Bug#911403: Please always include a copyright notice in 'LicenseWithSummary::summary_or_text'

[Felix Lechner]

Hi Dominique,

I am happy to provide patches and merge requests that implement your
idea, but are you sure there are other meaningful consumers of the
summary_or_text method? Your posting [1] restricts uses to Debian, and
a search on codesearch.debian.net shows no other packages that rely on
the current implementation that produces a copyright notice with a
full text but not with a summary. Why is the current implementation
worth keeping? Please forgive me if I appear insistent. It's the only
question I have. Thank you!

Kind regards,
Felix

[1] 
https://ddumont.wordpress.com/2018/07/07/new-softwarelicensemoreutils-perl-module/


On Mon, Oct 29, 2018 at 7:22 AM Dominique Dumont  wrote:
>
> On Sat, 27 Oct 2018 15:57:56 +0200 gregor herrmann  wrote:
> > Dominique, could you look into this patch, please?
>
> yes, sorry for the delay.
>
> I'm not thrilled at the idea of changing the behavior of summary_or_text
> method because the implementation would no longer match its behavior.
>
> Felix, how about un-deprecating debian_text method and putting your code there
> ?
>
> All the best
>
>

Bug#905614: Patch

[Felix Lechner]

Tags: patch

Hi,

The test fails because sometimes
'Software::LicenseMoreUtils::LicenseWithSummary::summary_or_text'
includes a copyright notice already. I filed a bug there to include it
always. Therefore, the copyright notice is no longer needed here. The
attached patch removes it. Thank you!

Kind regards,
Felix Lechner


remove-duplicate-copyright-notice.patch.xz
Description: application/xz

Bug#906466: Upload pending

[Felix Lechner]

Control: severity 906466 normal

Hi,

A pending upload is expected to resolve this bug report. To prevent
auto removal, I am downgrading the severity to normal. Thank you!

Felix Lechner

Bug#904711: On Mentors

[Felix Lechner]

Hi, I am waiting for a sponsor to upload the fixed version. If you are
in a hurry, please build from Mentors
(https://mentors.debian.net/package/wolfssl). Thank you!

Bug#888587: Revert to Arch:all

[Felix Lechner]

Package: golang-github-rfjakob-eme
Version: 1.1-2
Severity: serious

For a brief time, the package is being marked Arch:any to produce
detailed logs. We would like to support additional release
architectures, but the package is Golang source (and autopkgtest did
not run on the affected architectures).

The package should be marked Arch:all before being allowed into testing.

Bug#887952: Revert to Arch:all

[Felix Lechner]

Package: golang-github-jacobsa-crypto
Version: 0.0_git2016.0.293ce0c+dfsg1-5
Severity: serious

For a brief time, the package is being marked Arch:any to produce
detailed logs. We would like to support additional release
architectures, but the package is Golang source (and autopkgtest did
not run on the affected architectures).

The package should be marked Arch:all before being allowed into testing.

Bug#853672: svxlink: diff for NMU version 15.11-2.1

[Felix Lechner]

Adrian,

Thank you for doing this!

Felix


On Fri, Sep 1, 2017 at 6:20 AM, Adrian Bunk  wrote:

> Control: tags 853672 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for svxlink (versioned as 15.11-2.1) and uploaded
> it to DELAYED/10. Please feel free to tell me if I should cancel it.
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
>

Bug#860046: wolfssl: Incomplete debian/copyright?

[Felix Lechner]

Chris,

Sorry about the oversight. Please find a new upload
 on Mentors, closing two bugs.
Thank you!

Best regards,
Felix


On Mon, Apr 10, 2017 at 10:13 AM, Chris Lamb  wrote:

> Source: wolfssl
> Version: 3.10.2+dfsg-1
> Severity: serious
> Justication: Policy 12.5
>
> Hi,
>
> I just ACCEPTed wolfssl from NEW but noticed it was missing
> attribution in debian/copyright for at least the files under m4/
>
> (This is not exhaustive so please check over the entire package
> carefully and address these on your next upload.)
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>

Bug#856114: wolfssl: CVE-2017-6076

[Felix Lechner]

Hi Salvatore,

A version fixing the vulnerability is available on Mentors
<https://mentors.debian.net/package/wolfssl>. Please feel free to upload it.

With a new soname version, this upload will go through NEW. Also I am not
sure the library will make it into stretch. Currently, no packages depend
on it.

In the past, I cooperated with Clint Byrum as a sponsor and copied him on
this message. Perhaps he would prefer to upload? Thank you!

Best regards,
Felix


On Mon, Feb 27, 2017 at 5:14 AM, Salvatore Bonaccorso 
wrote:

> Hi Felix,
>
> Sorry for the late reply!
>
> On Sat, Feb 25, 2017 at 08:10:22AM -0800, Felix Lechner wrote:
> > Hi Salvatore,
> >
> > Thank you for your email. I would like to package the new version but
> > 3.10.2 was not signed on GitHub. (Upstream recently added those
> signatures
> > for us.) The more recent release actually fixes two additional
> > vulnerabilities, with one being more serious. Details are in [0] and
> > replicated in part here:
>
> To have the fixes in stretch, at this point of the release I suspect
> we will need to have them cherry-picked. Otherwise I think the release
> team will not ack it to unblock.
>
> >
> > This release of wolfSSL fixes 2 low and 1 medium level security
> > vulnerability.
> >
> > Low level fix of buffer overflow for when loading in a malformed
> temporary
> > DH file. Thanks to Yueh-Hsun Lin and Peng Li from KNOX Security, Samsung
> > Research America for the report.
> >
> > Medium level fix for processing of OCSP response. If using OCSP without
> > hard faults enforced and no alternate revocation checks like OCSP
> stapling
> > then it is recommended to update.
> >
> > Low level fix for potential cache attack on RSA operations. If using
> > wolfSSL RSA on a server that other users can have access to monitor the
> > cache, then it is recommended to update wolfSSL. Thanks to Andreas Zankl,
> > Johann Heyszl and Georg Sigl at Fraunhofer AISEC for the initial report.
> >
> > I will wait with packaging until the release is signed, which may be
> after
> > the weekend. Meanwhile, you are welcome to file reports for the other
> > vulnerabilities. Did MITRE have them too? Thank you!
>
> Alright, thanks for the information. I will check later today if I
> find if CVEs were already assigned. Will come back to you if I have
> some questions!
>
> Regards and thanks for your work!
>
> Salvatore
>

Bug#856114: wolfssl: CVE-2017-6076

[Felix Lechner]

Hi Salvatore,

Thank you for your email. I would like to package the new version but
3.10.2 was not signed on GitHub. (Upstream recently added those signatures
for us.) The more recent release actually fixes two additional
vulnerabilities, with one being more serious. Details are in [0] and
replicated in part here:

This release of wolfSSL fixes 2 low and 1 medium level security
vulnerability.

Low level fix of buffer overflow for when loading in a malformed temporary
DH file. Thanks to Yueh-Hsun Lin and Peng Li from KNOX Security, Samsung
Research America for the report.

Medium level fix for processing of OCSP response. If using OCSP without
hard faults enforced and no alternate revocation checks like OCSP stapling
then it is recommended to update.

Low level fix for potential cache attack on RSA operations. If using
wolfSSL RSA on a server that other users can have access to monitor the
cache, then it is recommended to update wolfSSL. Thanks to Andreas Zankl,
Johann Heyszl and Georg Sigl at Fraunhofer AISEC for the initial report.

I will wait with packaging until the release is signed, which may be after
the weekend. Meanwhile, you are welcome to file reports for the other
vulnerabilities. Did MITRE have them too? Thank you!

Best regards,
Felix

[0] https://github.com/wolfSSL/wolfssl/releases/tag/v3.10.2-stable


On Sat, Feb 25, 2017 at 2:27 AM, Salvatore Bonaccorso 
wrote:

> Source: wolfssl
> Version: 3.9.10+dfsg-1
> Severity: grave
> Tags: upstream security patch fixed-upstream
>
> Hi,
>
> the following vulnerability was published for wolfssl.
>
> CVE-2017-6076[0]:
> | In versions of wolfSSL before 3.10.2 the function fp_mul_comba makes
> | it easier to extract RSA key information for a malicious user who has
> | access to view cache on a machine.
>
> From the release notes:
>
> Low level fix for potential cache attack on RSA operations. If using
> wolfSSL RSA on a server that other users can have access to monitor
> the cache, then it is recommended to update wolfSSL. Thanks to Andreas
> Zankl, Johann Heyszl and Georg Sigl at Fraunhofer AISEC for the
> initial report.
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2017-6076
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6076
> [1] https://github.com/wolfSSL/wolfssl/commit/
> 345df93978c41da1ac8047a37f1fed5286883d8d
> [2] https://github.com/wolfSSL/wolfssl/pull/674
>
> Regards,
> Salvatore
>

Bug#793134: Packaging of newest upstream version in progress

[Felix Lechner]

Uploaded and pending in NEW.


On Fri, Dec 2, 2016 at 12:11 AM, Nobuhiro Iwamatsu 
wrote:

> Hi,
>
> > Newest version will be uploaded soon. Upstream is reviewing configured
> > ciphers and options.
>
> ping?
>
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org}
>GPG ID: 40AD1FA6
>

Bug#793134: Packaging of newest upstream version in progress

[Felix Lechner]

Newest version will be uploaded soon. Upstream is reviewing configured
ciphers and options.

Bug#801265: Build problem has been fixed upstream

[Felix Lechner]

A recent upload to Mentors fixes this issue. It should be in the archive
shortly.

Should Britney remove the package from testing on Nov 5, you can still get
it from unstable. Just download it from https://packages.debian.org or via
apt.


On Mon, Nov 2, 2015 at 2:25 PM, SM0SVX  wrote:

> Hi!
>
> I'm the original author of the SvxLink software.
>
> The C++11 problem appeared because libsigc++ in Debian was upgraded to a
> version that require C++11 support to be turned on in the compiler.
> However,
> if C++11 support was turned on, SvxLink would not compile since some
> existing
> static const declations seemed to be illegal in C++11.
>
> The problem has now been fixed upstream in the 14.08.2 release:
>
> https://github.com/sm0svx/svxlink/releases/tag/14.08.2
>
> Best regards,
> Tobias
>