Bug#620146: This bug is already fixed

[alex]

The problem is caused by the Incscape EPS file that places the userdict 
on top of the dictionary stack and brings in all the context it has. In 
particular, it brings an unwanted definition of /showpage.


Patching the EPS file solves the problem.

--- cc_by_sa.eps 2021-06-02 23:49:29.426574732 -0400
+++ cc_by_sa-fixed.eps 2021-06-02 23:50:11.731325295 -0400
@@ -11,7 +11,7 @@
 /cairo_eps_state save def
 /dict_count countdictstack def
 /op_count count 1 sub def
-userdict begin
+100 dict begin
 /q { gsave } bind def
 /Q { grestore } bind def
 /cm { 6 array astore concat } bind def

My copy of Incscape, Inkscape 0.92.5 (2060ec1f9f, 2020-04-08) already 
has a similar fix. I believe that this bug can be closed as fixed.

Bug#964511: Tests are failing, need to depends on the svg loader

[Paul Wise]

On Wed, 8 Jul 2020 21:29:07 +0200 Ondřej Tůma wrote:

> thank's for report. I'm working now on version 1.4.3, which is last
> upstream stable version. So I apply patch to new version too.

It is now too late to get 1.4.3 into bullseye and the bug is now going
to cause formiko to be removed from bullseye unless it is fixed soon.

https://tracker.debian.org/pkg/formiko

Will you be able to fix this issue or should Sebastien upload his NMU?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#989409: nss-pam-ldapd's autopkgtest fails with OpenLDAP 2.5

[Sergio Durigan Junior]

Source: nss-pam-ldapd
Version: 0.9.11-1
Severity: medium

Hi there!

We're currently working on getting OpenLDAP 2.5 into experimental, so
that we can start slowly working on its migration.  As a side note,
Ubuntu is already planning to ship OpenLDAP 2.5 in the next release
(Impish, 21.10).

While running autopkgtests against openldap's rdeps, I noticed that
nss-pam-ldapd is failing with the following error:

  Creating blank /tmp/slapd.g4Wq6n slapd environment... done.
  Loading cn=config...
  added: "cn=config" (0001)
  lt_dlopenext failed: (back_bdb) file not found
  slapadd: could not add entry dn="cn=module{0},cn=config" (line=10): 
 handler exited with 1
   FAILED
  testsuite: cleaning up...
  Failed to stop pynslcd.service: Unit pynslcd.service not loaded.
  Cleaning /tmp/slapd.g4Wq6n... done.
  testsuite: restoring configuration...
  autopkgtest [23:55:51]: test testsuite: ---]
  autopkgtest [23:55:51]: test testsuite:  - - - - - - - - - - results - - - - 
- - - - - -
  testsuiteFAIL non-zero exit status 1

You can find the full log here if you're interested:

https://autopkgtest.ubuntu.com/results/autopkgtest-impish-ci-train-ppa-service-4572/impish/amd64/n/nss-pam-ldapd/20210602_235938_b5f64@/log.gz

The reason this fails is because OpenLDAP 2.5 has dropped the BDB
backend.  I believe that the test will need to be ported to LMDB.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#989408: python-motor: Skip autopkgtest if deps not installable

[Logan Rosen]

Package: python-motor
Version: 2.3.0-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Hi,

python-motor's autopkgtest currently fails because it depends on
mongodb-server, which is not available in Debian.

In Ubuntu, the attached patch was applied to achieve the following:

- d/t/control: Skip test if deps not installable.

Thanks for considering the patch.

Logan
diff -Nru python-motor-2.3.0/debian/tests/control 
python-motor-2.3.0/debian/tests/control
--- python-motor-2.3.0/debian/tests/control 2020-10-27 05:09:12.0 
-0400
+++ python-motor-2.3.0/debian/tests/control 2020-10-27 11:17:29.0 
-0400
@@ -5,5 +5,6 @@
  python3-tornado,
  mongodb-server (>= 3.4),
 Restrictions: allow-stderr,
+  skip-not-installable,
   isolation-container,
 Test-Command: set -e ; for py in $(py3versions -r 2>/dev/null) ; do echo 
"Testing with $py:" ; $py setup.py test ; done

Bug#989223: vim: unavailable URL in README.Debian

[James McCoy]

On Sat, May 29, 2021 at 12:10:31PM +0200, Reiner Herrmann wrote:
> README.Debian contains a link to 
> http://pkg-vim.alioth.debian.org/vim-policy.html/
> which is no longer available (does not resolve).
> Please update it with its new location.

I've made it available at , but
it's rather outdated.  New packages should use dh-vim-addon.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#988148: initscripts: Can not umount /usr at shutdown

[lorenzo]

Hi Hans,
thank you for reporting this.

On Thu, 06 May 2021 18:49:00 +0200
"Hans-J. Ullrich"  wrote:

> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

This report is from a machine that runs systemd as init, so
just to be sure: is the "can not unmount /usr" message happening on
another machine that runs Sysv as init?

Regards,
Lorenzo

Bug#974678: Bug#988484: ITP: openh264 -- H.264 encoding and decoding

[Paul Wise]

On Wed, Jun 2, 2021 at 3:36 PM Tobias Frost wrote:

> Has this been discussed on e.g debian-legal or with the ftp masters 
> beforehand?

FTR, Debian's patent policy is to only discuss them with lawyers,
never in public:

https://www.debian.org/legal/patent
https://www.debian.org/reports/patent-faq

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#989407: tpm-tss: CVE-2020-24455 not in buster

[Bastian Germann]

Source: tpm2-tss
Version: 2.1.0-4

The fapi feature was introduced in 2.4.0. Therefore, buster version is not affected by 
CVE-2020-24455. Please adjust the security tracker accordingly.

Bug#983175: tpm2-tss: Provide buster-backports

[Bastian Germann]

On Sat, 20 Feb 2021 17:23:14 +0100 Bastian Germann wrote:
Please provide a version >= 2.4 and < 3.0.2 (without the #974837 change) 
as buster-backports.


Please use one of the 3.0.1 versions as that is not affected by CVE-2020-24455.

Bug#981794: RFS: gftools/0.5.2+dfsg-1 [ITP] -- Google Fonts Tools

[Romain Porte]

Hi tobi,

On Wed, 02 Jun 2021 17:02:06 +0200 Tobias Frost  wrote:

> Control: tags -1 moreinfo
>
> The package fails to build; there is no package named
python3-opentype-sanitizer

> in Debian.

I have fixed this issue by renaming the dependency to the correct name
(python3-ots instead of python3-opentype-sanitizer). New package version
has just been signed and uploaded to mentors [1]. The commit that
provides the fix was also pushed to the Salsa repository [2].

[1] https://mentors.debian.net/package/gftools/ see upload #6

[2]
https://salsa.debian.org/fonts-team/gftools/-/commit/7fa7395834e36281796744540b1d461ef526bc70

Can you check again for other issues?

Thanks in advance,

Romain.

Bug#980963: dpkg: Please add ARC architecture

[Vineet Gupta]

Hi Guillem,

On 5/27/21 8:50 PM, Guillem Jover wrote:
> I discussed this today with Vineet on IRC in #debian-bootstrap, to try
> to clarify some things, and this is the summary I think:
>
> * ARCv2 32-bit little-endian
>
>- The arch based on ARCv2 32-bit is going to be little-endian, and
>  ideally will be hard-float, but that's pending on a patch for gcc,
>  to flip the default from soft-float. From what I understand while
>  hard and soft-float are ABI compatible in the ISA and calling
>  convention sense, they are not ABI compatible in the object
>  linking sense, and while I guess this could also perhaps be lifted,
>  it's not currently the case. My concern is that adding the support
>  before the default has been switched might mean "ABI incompatible"
>  architectures if we cannot link objects. Vineet, mentioned that
>  they might be fine settling with soft-float in that case, even
>  with the performance penalty implied (in that case, personally I
>  think adding the -gnuhf triplet would be better, but I'd not be
>  going to be doing the work, so… :). The patch is supposed to be
>  sent upstream around next week or so. I'd prefer to wait what
>  ends up happening there, TBH, before committing the support to
>  dpkg. As I've mentioned I'm fine with committing it once it hits
>  upstream git though.
>- The triplet would be «arc-linux-gnu», the Debian architecture
>  would be «arc».

FWIW gcc patch is now in mainline (I've requested Claudiu for backport)

2021-06-02 46d04271a498 ARC: gcc driver default to hs38_linux

Thx,
-Vineet

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Andreas Beckmann]

On 03/06/2021 01.41, Andreas Beckmann wrote:

BUT: This would still only solve the co-installability mess of hdf5,
the gdal problem is still there.


gdal could rename gdal-data to gdal3-data, build with 
--datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
Thus libgdal20 + gdal-data from buster should be co-installable with 
libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.


(or we could reintroduce gdal 2.4.x into bullseye as src:gdal2 building 
only libgdal20 and (the renamed) gdal2-data)


Andreas

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Andreas Beckmann]

On 02/06/2021 22.22, Sebastian Ramacher wrote:

So, what if we use the free versions between 103 and 200 to transition
to a Debian-specific version? Attached is a patch that does that. It's
not an optimal solution as we would have a release with a
Debian-specific SOVERSIONs. For good reason, we usually try to avoid
those. So, it would be good for someone more familiar with the users of
hdf5 to check if that would be an issue in this specific case.


Can we be even more explicit about that and use a SOVERSION like "106deb" ?
That might be a bit tricky with libtool, though.

I think you should only remove Conflicts/Replaces on libhdf5*-103 and
leave all other there. (Have they been in buster already?)

You definitively want to have a
  Breaks: libhdf5-foo-10x(-1)
in each libhdf5-foo-106 package as we don't want to mix the current
bullseye packages with your proposed packages

Wouldn't it be sufficient to rename only the packages where the
soversion is the same in buster and bullseye?

I'll try to make a table:

library buster  bullseye
proposed soversion

libhdf5_serial.so.103   libhdf5-103 libhdf5-103-1   
103deb or 106
libhdf5_serial_fortran.so.100   libhdf5-103 n/a 
-
libhdf5_serial_fortran.so.102   n/a 
libhdf5-fortran-102 keep
libhdf5_serial_hl.so.100libhdf5-103 libhdf5-hl-100  
100deb or 106
libhdf5_serialhl_fortran.so.100 libhdf5-103 
libhdf5-hl-fortran-100  100deb or 106

libhdf5_cpp.so.103  libhdf5-cpp-103 
libhdf5-cpp-103-1   103deb or 106
libhdf5_hl_cpp.so.100   libhdf5-cpp-103 
libhdf5-hl-cpp-100  100deb or 106

libhdf5_mpich.so.103libhdf5-mpich-103   
libhdf5-mpich-103-1 103deb or 106
libhdf5_mpich_fortran.so.100libhdf5-mpich-103   n/a 
-
libhdf5_mpich_fortran.so.102n/a 
libhdf5-mpich-fortran-102   keep
libhdf5_mpich_hl.so.100 libhdf5-mpich-103   
libhdf5-mpich-hl-100100deb or 106
libhdf5_mpichhl_fortran.so.100  libhdf5-mpich-103   
libhdf5-mpich-hl-cpp-100100deb or 106

libhdf5_mpich_cpp.so.103n/a 
libhdf5-mpich-cpp-103-1 keep or 103
libhdf5_mpich_hl_cpp.so.100 n/a 
libhdf5-mpich-hl-cpp-100keep

libhdf5_openmpi.so.103  libhdf5-openmpi-103 
libhdf5-openmpi-103-1   103deb or 106
libhdf5_openmpi_fortran.so.100  libhdf5-openmpi-103 n/a 
-
libhdf5_openmpi_fortran.so.102  n/a 
libhdf5-openmpi-fortran-102 keep
libhdf5_openmpi_hl.so.100   libhdf5-openmpi-103 
libhdf5-openmpi-hl-100  100deb
libhdf5_openmpihl_fortran.so.100libhdf5-openmpi-103 
libhdf5-openmpi-hl-fortran-100  100deb

libhdf5_openmpi_cpp.so.103  n/a 
libhdf5-openmpi-cpp-103-1   keep or 103
libhdf5_openmpi_hl_cpp.so.100   n/a 
libhdf5-openmpi-hl-cpp-100  keep


Well, having different sonames for libhdf5_cpp.so and libhdf5_*mpi*_cpp.so
might be difficult and non-intuitive.
But at least you don't have to touch libhdf5*-fortran-102 ;-)


BUT: This would still only solve the co-installability mess of hdf5,
the gdal problem is still there.

Andreas

Bug#974678: ITP: openh264 -- H.264 encoding and decoding

[Walter Landry]

Bastian Germann writes:
> Am 02.06.21 um 17:33 schrieb Tobias Frost:
>> Is this RFS package now a downloader or the library itself?
>
> It's both. The -dev package is created from the source files and
> resides in main. The library package contains the downloader as a
> postinst script, which checks the known SHA256 hashes.
> There are some example userspace tools available in the package which
> could potentially be packaged in an additional package. I left this
> for a later version.
>
> There is also a chance that reproducible build might be implemented:
> https://github.com/cisco/openh264/issues/893
> When that works, the package could build the lib, verify the resulting
> hashes, and throw away the built binary. That way we could be sure not
> to have any additions to the downloaded library that are not available
> as source.
>
> I think, as Cisco provides the patent license, having the downloader
> in contrib (for some architectures) is better than having the built
> library in main (for all compiling architectures). We could also
> provide both. Any thoughts?

As I understand Debian Policy, downloading anything during postinst is
discouraged, if not banned.  So it would be best to avoid it.

In terms of the patent license, I do not think that x264 has any special
dispensation.  So just directly building and packaging openh264 should
not open Debian to any significant additional liability.  But as always,
the FTP masters will be the final arbiter of that.

Cheers,
Walter

Bug#989406: wireguard-dkms makes little sense with the bullseye kernel

[Adrian Bunk]

Package: wireguard-dkms
Severity: serious

The only kernel shipped in bullseye is 5.10, and dkms.conf
already inhits building the module for it.

There is not much benefit shipping a package that cannot
do anything useful in the release in question.

Running the buster kernel at least temporarily is possible,
but in that case the user already has to have the package
installed for any benefit.

For using wireguard in buster today, the buster-backports
kernel would anyway the best solution.

Overall it feels like a package with high CVE risk and 0 users
in bullseye.

Bug#989405: unblock: qtdeclarative-opensource-src/5.15.2+dfsg-5

[Lisandro Damián Nicanor Pérez Meyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Please unblock package qtdeclarative-opensource-src

[ Reason ]
Upstream warned us of this simple patch in order to support  in
translations.

[ Impact ]
Translations are not being show as expected, and that makes us look bad
;-)

[ Risks ]
Code is trivial, it only affectes proper presentation of translated
text.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
No.

unblock qtdeclarative-opensource-src/5.15.2+dfsg-5
diff -Nru qtdeclarative-opensource-src-5.15.2+dfsg/debian/changelog 
qtdeclarative-opensource-src-5.15.2+dfsg/debian/changelog
--- qtdeclarative-opensource-src-5.15.2+dfsg/debian/changelog   2021-03-19 
14:46:16.0 -0300
+++ qtdeclarative-opensource-src-5.15.2+dfsg/debian/changelog   2021-06-01 
18:37:21.0 -0300
@@ -1,3 +1,10 @@
+qtdeclarative-opensource-src (5.15.2+dfsg-6) unstable; urgency=medium
+
+  * Backport patch to support  in styled text, along with it's
+documentation.
+
+ -- Lisandro Damián Nicanor Pérez Meyer   Tue, 01 Jun 
2021 18:37:21 -0300
+
 qtdeclarative-opensource-src (5.15.2+dfsg-5) unstable; urgency=medium
 
   * Add a patch to make tst_qmldiskcache::regenerateAfterChange() pass on
diff -Nru qtdeclarative-opensource-src-5.15.2+dfsg/debian/patches/series 
qtdeclarative-opensource-src-5.15.2+dfsg/debian/patches/series
--- qtdeclarative-opensource-src-5.15.2+dfsg/debian/patches/series  
2021-03-19 14:46:16.0 -0300
+++ qtdeclarative-opensource-src-5.15.2+dfsg/debian/patches/series  
2021-06-01 18:36:28.0 -0300
@@ -3,6 +3,7 @@
 fix_qml_property_cache_leaks.patch
 gcc_11.patch
 tst_qmldiskcache_big_endian.patch
+support_apos_in_styled_text.patch
 
 # Debian patches
 disableopengltests.patch
diff -Nru 
qtdeclarative-opensource-src-5.15.2+dfsg/debian/patches/support_apos_in_styled_text.patch
 
qtdeclarative-opensource-src-5.15.2+dfsg/debian/patches/support_apos_in_styled_text.patch
--- 
qtdeclarative-opensource-src-5.15.2+dfsg/debian/patches/support_apos_in_styled_text.patch
   1969-12-31 21:00:00.0 -0300
+++ 
qtdeclarative-opensource-src-5.15.2+dfsg/debian/patches/support_apos_in_styled_text.patch
   2021-06-01 18:36:28.0 -0300
@@ -0,0 +1,33 @@
+Description: Support  in styled text and document it
+ This ensures that some translations really look ok.
+Origin: https://invent.kde.org/qt/qt/qtdeclarative/-/merge_requests/3/diffs
+Forwarded: not-needed
+Author: Albert Astals Cid
+Applied-Upstream: 
https://invent.kde.org/qt/qt/qtdeclarative/-/commit/0dda47d9f1a22567ad8f1266be2f0cd8a9226c7f
+
+diff --git a/src/quick/items/qquicktext.cpp b/src/quick/items/qquicktext.cpp
+index 
581ab9f76a41b731126eb53aa7069a21d7c96c76..4ddd2a41bc9290d09412b7904c3561ccfb65a6a8
 100644
+--- a/src/quick/items/qquicktext.cpp
 b/src/quick/items/qquicktext.cpp
+@@ -2168,7 +2168,7 @@ void QQuickText::resetMaximumLineCount()
+  - inline images
+ ,  and  - ordered and unordered lists
+  - preformatted
+-  
++ 
+ \endcode
+ 
+ \c Text.StyledText parser is strict, requiring tags to be correctly 
nested.
+diff --git a/src/quick/util/qquickstyledtext.cpp 
b/src/quick/util/qquickstyledtext.cpp
+index 
d531fc92051b4a966a29ea4c463c7d5ca79a7ab3..a25af90414bc4e29efe02c773bf19645a272b93c
 100644
+--- a/src/quick/util/qquickstyledtext.cpp
 b/src/quick/util/qquickstyledtext.cpp
+@@ -564,6 +564,8 @@ void QQuickStyledTextPrivate::parseEntity(const QChar 
*, const QString 
+ textOut += QChar(60);
+ else if (entity == QLatin1String("amp"))
+ textOut += QChar(38);
++else if (entity == QLatin1String("apos"))
++textOut += QChar(39);
+ else if (entity == QLatin1String("quot"))
+ textOut += QChar(34);
+ else if (entity == QLatin1String("nbsp"))

Bug#989404: wtf: Very outdated; missing entries such as LGTM

[Alejandro Colomar]

Package: bsdgames
Version: 2.17-28
Severity: important
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear Maintainer,

I see the last sync with upstream was many years ago (9?).

Today I wanted to know what LGTM means.  I didn't find it with wtf(1),
so I went looking for the upstream source code to try to patch it.
However, I found out that the upstream source code does contain the definition,
which BTW is "looks good to me", and that the latest upstream release
(of bsdwtf, not bsdgames, which I don't know where to find) is from a
month ago or so:




Could you please package a new version of it?

Thanks,

Alex

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bsdgames depends on:
ii  libc6 2.31-11
ii  libfl22.6.4-8
ii  libgcc-s1 [libgcc1]   10.2.1-6
ii  libncurses6   6.2+20201114-2
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  wamerican [wordlist]  2019.10.06-1

bsdgames recommends no packages.

bsdgames suggests no packages.

-- no debconf information

Bug#974678: ITP: openh264 -- H.264 encoding and decoding

[Bastian Germann]

Am 02.06.21 um 17:33 schrieb Tobias Frost:

On Fri, 14 May 2021 00:04:52 +0200 Bastian Germann wrote:

This is fine. The package must not reside in main. If you plan to
release the package (the downloader) under a DFSG-compatible license,
please submit it to contrib rather than non-free.


I am currently packaging openh264.


(I was checking the RFS, thats why I came accross this ITP)

I'm confused; is there now a legal patent problem with the library that could
affect/hurt Debian?


There are H.264 patents that are applicable. I do not know how the existing H.264 implementations in 
Debian handle this, e.g. x264 or ffmpeg. According to the legal FAQ, these seem to be ignored.


For the OpenH264 binaries, Cisco actually pays a license fee so that it can be used by the general 
public at no cost. The exact license terms are included in the package:

https://salsa.debian.org/bage/openh264/-/blob/debian/2.1.1-1/debian/libopenh264-6.copyright

The key point for having the library package in contrib and download the library is: "The 
Cisco-provided binary is separately downloaded to an end user's device, and not integrated into or 
combined with third party software prior to being downloaded to the end user's device;"



Has this been discussed on e.g debian-legal or with the ftp masters beforehand?


Not for OpenH264 specifically, but I am including debian-legal now. For the H.264 patents, there is 
an old thread at https://lists.debian.org/debian-legal/2006/04/msg00286.html



Is this RFS package now a downloader or the library itself?


It's both. The -dev package is created from the source files and resides in main. The library 
package contains the downloader as a postinst script, which checks the known SHA256 hashes.
There are some example userspace tools available in the package which could potentially be packaged 
in an additional package. I left this for a later version.


There is also a chance that reproducible build might be implemented:
https://github.com/cisco/openh264/issues/893
When that works, the package could build the lib, verify the resulting hashes, and throw away the 
built binary. That way we could be sure not to have any additions to the downloaded library that are 
not available as source.


I think, as Cisco provides the patent license, having the downloader in contrib (for some 
architectures) is better than having the built library in main (for all compiling architectures). We 
could also provide both. Any thoughts?

Bug#989403: O: inotify-tools -- utility wrapper around inotify

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of inotify-tools has retired.  Therefore, I orphan this 
package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

https://tracker.debian.org/pkg/inotify-tools


Package: inotify-tools
Binary: libinotifytools0, libinotifytools0-dev, inotify-tools
Version: 3.14-8.1
Maintainer: Dmitry Bogatov 
Build-Depends: debhelper-compat (= 12), doxygen
Architecture: linux-any
Standards-Version: 4.4.0
Format: 3.0 (quilt)
Files:
 2c62e61fea51354a145cb65a104f645d 1839 inotify-tools_3.14-8.1.dsc
 b43d95a0fa8c45f8bab3aec9672cf30c 358772 inotify-tools_3.14.orig.tar.gz
 158b696421e383f3c025d2d4c158deb0 8584 inotify-tools_3.14-8.1.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/inotify-tools
Vcs-Git: https://salsa.debian.org/debian/inotify-tools.git
Checksums-Sha256:
 fc8d453d902f7f311a18420b20523a3ec1234400396bfe8e41a314d1e424959c 1839 
inotify-tools_3.14-8.1.dsc
 222bcca8893d7bf8a1ce207fb39ceead5233b5015623d099392e95197676c92f 358772 
inotify-tools_3.14.orig.tar.gz
 963363e6a6aae933a141e092f2e7271555632bbfb3d2729a871b0aaf1dd33a8c 8584 
inotify-tools_3.14-8.1.debian.tar.xz
Homepage: https://github.com/rvoicilas/inotify-tools/wiki/
Dgit: 04914f242fa6d5a797a44e4ad0799dc520ad1816 debian archive/debian/3.14-8.1 
https://git.dgit.debian.org/inotify-tools
Package-List: 
 inotify-tools deb misc optional arch=linux-any
 libinotifytools0 deb libs optional arch=linux-any
 libinotifytools0-dev deb libdevel optional arch=linux-any
Directory: pool/main/i/inotify-tools
Priority: source
Section: misc

Package: libinotifytools0
Source: inotify-tools
Version: 3.14-8.1
Installed-Size: 61
Maintainer: Dmitry Bogatov 
Architecture: amd64
Replaces: inotify-tools (<< 3.10-2)
Depends: libc6 (>= 2.15)
Description-en: utility wrapper around inotify
 Inotify is a Linux kernel feature enabling user space programs to
 monitor parts of the filesystem in a efficient way. libinotifytools
 is a thin layer on top of the kernel interface which makes it easy
 to set up watches on many files at once, read events without having
 to deal with low-level I/O, and several utility functions for inotify-
 related string formatting
Description-md5: a71513de41931b25a4024cda6dc521a4
Multi-Arch: same
Homepage: https://github.com/rvoicilas/inotify-tools/wiki/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/i/inotify-tools/libinotifytools0_3.14-8.1_amd64.deb
Size: 18932
MD5sum: 71db8af802e06ce542450d94ae860b1d
SHA256: 722dd49ca724e68935374bf6721a54731c20a2f718d775804f65401c77d48c6d

Package: libinotifytools0-dev
Source: inotify-tools
Version: 3.14-8.1
Installed-Size: 679
Maintainer: Dmitry Bogatov 
Architecture: amd64
Replaces: inotify-tools (<< 3.10-2)
Provides: libinotifytools-dev
Depends: libinotifytools0 (= 3.14-8.1)
Conflicts: libinotifytools-dev
Description-en: Development library and header files for libinotifytools0
 Headers, static libraries, and documentation for the libinotifytools
 library.
 .
 libinotifytools is a thin layer on top of the kernel interface which makes it
 easy to set up watches on many files at once, read events without having to
 deal with low-level I/O, and several utility functions for inotify-related
 string formatting
Description-md5: de409149937acda109beb6ac4968f84d
Homepage: https://github.com/rvoicilas/inotify-tools/wiki/
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/i/inotify-tools/libinotifytools0-dev_3.14-8.1_amd64.deb
Size: 116136
MD5sum: a6db8f6c2e99b56b83bdf0b371d6daa2
SHA256: b0d8a5d27c9e43881a15b3bfa3eac3631535dc87941a1e84d9bc36375265cc7e

Package: inotify-tools
Version: 3.14-8.1
Installed-Size: 85
Maintainer: Dmitry Bogatov 
Architecture: amd64
Depends: libc6 (>= 2.14), libinotifytools0 (>= 3.11)
Description-en: command-line programs providing a simple interface to inotify
 inotify-tools is a set of command-line programs for Linux providing a
 simple interface to inotify. These programs can be used to monitor and
 act upon filesystem events. inotify-tools consists of two utilities:
 .
 inotifywait simply blocks for inotify events, making it appropriate
 for use in shell scripts.
 .
 inotifywatch collects filesystem usage statistics and outputs counts
 of each inotify event.
Description-md5: 75b00fa82511a5bdec777dcd118c2a99
Multi-Arch: foreign
Homepage: https://github.com/rvoicilas/inotify-tools/wiki/
Tag: admin::monitoring, implemented-in::c, interface::commandline,
 role::program, scope::utility, works-with::file
Section: misc
Priority: optional
Filename: pool/main/i/inotify-tools/inotify-tools_3.14-8.1_amd64.deb
Size: 25884
MD5sum: a48c6f4ff06e68b17a7cd68da75040db
SHA256: 

Bug#989288: CVE-2021-29629

[Christoph Berg]

Control: clone -1 -2
Control: severity -2 normal
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: dacs -- RoM; unmaintained and security-buggy

Re: Salvatore Bonaccorso
> > Fair enough, unless anyone steps forward, can you file an RM bug
> > in time of the freeze?
> 
> Agreed, if there is not anymore much use of it (and popcon is very low
> as well, indicating this might be the case in general), then removal
> would be good. In fact is it as well possible:
> 
> carnil@coccia:~$ dak rm --suite=testing -n -R dacs
> Will remove the following packages from testing:
> 
>   dacs |   1.4.40-2 | source
>   dacs | 1.4.40-2+b1 | amd64, arm64, armel, armhf, i386, mips64el, 
> mipsel, ppc64el, s390x
> dacs-examples |   1.4.40-2 | all
> libapache2-mod-dacs | 1.4.40-2+b1 | amd64, arm64, armel, armhf, i386, 
> mips64el, mipsel, ppc64el, s390x
> libdacs-dev | 1.4.40-2+b1 | amd64, arm64, armel, armhf, i386, mips64el, 
> mipsel, ppc64el, s390x
>   libdacs1 | 1.4.40-2+b1 | amd64, arm64, armel, armhf, i386, mips64el, 
> mipsel, ppc64el, s390x

Let's do that then.

Christoph

Bug#984761: dcraw: buffer-overflow caused by integer-overflow in foveon_load_camf()

[Salvatore Bonaccorso]

Hi Filip, Wooseok

On Tue, Mar 09, 2021 at 05:41:51PM +0100, Filip Hroch wrote:
> Dear Wooseok,
> 
> I'll look on this.
> 
> Note, that I'm maintaining only Debian packaging.
> I am not upstream autor; I can fix only the bugs
> which does not induce extensive changes in whole
> structure of the source code.

Can you please report the issue upstream? Or was this reported
upstream?

Regards,
Salvatore

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Sebastian Ramacher]

Hi Gilles, hi Andreas,

On 2021-06-01 14:15:52 +0200, Andreas Beckmann wrote:
> On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder  wrote:
> > One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
> > Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
> > and postgresql-11-postgis-2.5 depends on that.  libgdal28 depends on
> > gdal-data (>=3.2.1+dfsg-1).  To me it looks like there's no way to
> > keep postgresql-11-postgis-2.5 around if anything that depends on
> > libgdal28 (postgis, libopencv-imgcodecs4.5, ...) gets installed.
> 
> What would be needed to reintroduce postgresql-11-postgis-2.5 (i.e.
> src:postgis-2.5) (built against bullseye libraries) into bullseye? Probably
> libraries and -dev packages from postgresql-11, too.
> Here I assume that src:postgis-2.5 could be built against gdal 3.2.x and
> that can be used to perform the upgrade to postgis 3.x - is that true?

So here is a different view. At least the hdf5 part of this upgrade
issue could have been avoided if we transitationed to hdf5 1.12 (which
bumps all the SOVERSIONs to 200) for bullseye. Alas, we didn't and it's
too late for that.

So, what if we use the free versions between 103 and 200 to transition
to a Debian-specific version? Attached is a patch that does that. It's
not an optimal solution as we would have a release with a
Debian-specific SOVERSIONs. For good reason, we usually try to avoid
those. So, it would be good for someone more familiar with the users of
hdf5 to check if that would be an issue in this specific case.

I've done a rebuild of the reverse dependencies and they built fine.
Only pbseqlib requires a patch due to its use of d-shlibs. If we want to
do that, we need to act fast as it would require a trip through NEW.

Cheers
-- 
Sebastian Ramacher
diff -Nru hdf5-1.10.6+repack/debian/changelog 
hdf5-1.10.6+repack/debian/changelog
--- hdf5-1.10.6+repack/debian/changelog 2020-04-24 20:00:42.0 +0200
+++ hdf5-1.10.6+repack/debian/changelog 2021-06-02 21:33:00.0 +0200
@@ -1,3 +1,12 @@
+hdf5 (1.10.6+repack-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump SONAME to Debian specific version (106)
+This is a workaround for upgrade issues caused by libhdf5-103 (in buster)
+and libhdf5-103-1 (in bullseye) not being co-installable. (Closes: #988722)
+
+ -- Sebastian Ramacher   Wed, 02 Jun 2021 21:33:00 +0200
+
 hdf5 (1.10.6+repack-2) unstable; urgency=medium
 
   * Default plugindir per flavor
diff -Nru hdf5-1.10.6+repack/debian/control hdf5-1.10.6+repack/debian/control
--- hdf5-1.10.6+repack/debian/control   2020-04-24 20:00:42.0 +0200
+++ hdf5-1.10.6+repack/debian/control   2021-06-02 21:33:00.0 +0200
@@ -21,15 +21,13 @@
 Vcs-Git: https://salsa.debian.org/debian/hdf5.git
 Homepage: http://hdfgroup.org/HDF5/
 
-Package: libhdf5-103-1
+Package: libhdf5-106
 Architecture: any
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
-Breaks: libhdf5-103
-Replaces: libhdf5-103
 Description: HDF5 C runtime files - serial version
  Hierarchical Data Format 5 (HDF5) is a file format and library for
  storing scientific data.  HDF5 was designed and implemented to address
@@ -38,7 +36,7 @@
  .
  This package contains the C runtime files for serial platforms.
 
-Package: libhdf5-fortran-102
+Package: libhdf5-fortran-106
 Architecture: any
 Multi-Arch: same
 Section: libs
@@ -53,15 +51,13 @@
  .
  This package contains the Fortran runtime files for serial platforms.
 
-Package: libhdf5-hl-100
+Package: libhdf5-hl-106
 Architecture: any
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
-Conflicts: libhdf5-100, libhdf5-101, libhdf5-102, libhdf5-103 (<< 1.10.5)
-replaces: libhdf5-100, libhdf5-101, libhdf5-102, libhdf5-103 (<< 1.10.5)
 Description: HDF5 High Level runtime files - serial version
  Hierarchical Data Format 5 (HDF5) is a file format and library for
  storing scientific data.  HDF5 was designed and implemented to address
@@ -70,15 +66,13 @@
  .
  This package contains the high level C API runtime files for serial platforms.
 
-Package: libhdf5-hl-fortran-100
+Package: libhdf5-hl-fortran-106
 Architecture: any
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
-Conflicts: libhdf5-100, libhdf5-101, libhdf5-102, libhdf5-103 (<< 1.10.5)
-replaces: libhdf5-100, libhdf5-101, libhdf5-102, libhdf5-103 (<< 1.10.5)
 Description: HDF5 High Level Fortran runtime files - serial version
  Hierarchical Data Format 5 (HDF5) is a file format and library for
  storing scientific data.  HDF5 was designed and implemented to address
@@ -88,14 +82,12 @@
  This package contains the high level Fortran API runtime files for serial
  platforms.
 
-Package: libhdf5-cpp-103-1
+Package: libhdf5-cpp-106
 Architecture: any
 Multi-Arch: same
 Section: libs
 Depends: 

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Wed, Jun 02, 2021 at 09:21:54PM +0200, Jose wrote:
> Berto,
> 
> Thanks.
> 
> Here is the full gdb bt after installing the debug symbols.
> 
> Please tell me if you'd like me to do any additional tests
> or debugging.
> 
> --josé

> #0  0x7f707b64e7bb in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x7f707b639535 in __GI_abort () at abort.c:79
> #2  0x7f7080746085 in CRASH_WITH_INFO(...) () at 
> DerivedSources/ForwardingHeaders/wtf/Assertions.h:713
> #3  0x7f7080746085 in 
> WebCore::MediaPlayerPrivateGStreamer::createAudioSink() ()
> at 
> ../Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:1322

Can you install gstreamer1.0-plugins-good and try again?

Berto

Bug#989288: CVE-2021-29629

[Salvatore Bonaccorso]

Hi Christoph, hi Jonas,

On Tue, Jun 01, 2021 at 09:41:25PM +0200, Moritz Mühlenhoff wrote:
> Am Mon, May 31, 2021 at 04:31:13PM +0200 schrieb Christoph Berg:
> > Re: Moritz Muehlenhoff
> > > Package: dacs
> > > Severity: important
> > > Tags: security
> > > X-Debbugs-Cc: Debian Security Team 
> > > 
> > > dacs bundles a copy in src/libradius/src/radlib.c:
> > > https://www.freebsd.org/security/advisories/FreeBSD-SA-21:12.libradius.asc
> > 
> > Fwiw, the package is orphaned, I do not intend to fix this personally.
> > 
> > I am not aware of anyone using the package (the company for which we
> > were packaging it has moved to something else, and iirc Jonas who was
> > interested in it some time ago has also said he went for something
> > else), so removal from bullseye is certainly an option.
> 
> Fair enough, unless anyone steps forward, can you file an RM bug
> in time of the freeze?

Agreed, if there is not anymore much use of it (and popcon is very low
as well, indicating this might be the case in general), then removal
would be good. In fact is it as well possible:

carnil@coccia:~$ dak rm --suite=testing -n -R dacs
Will remove the following packages from testing:

  dacs |   1.4.40-2 | source
  dacs | 1.4.40-2+b1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, 
ppc64el, s390x
dacs-examples |   1.4.40-2 | all
libapache2-mod-dacs | 1.4.40-2+b1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
libdacs-dev | 1.4.40-2+b1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, 
ppc64el, s390x
  libdacs1 | 1.4.40-2+b1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, 
ppc64el, s390x

Maintainer: Christoph Berg 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

carnil@coccia:~$

but time is getting tight, so this needs to be done quite soon.

Regards,
Salvatore

Bug#989306: cups-filters: parallel port modules force included on ARM kernels

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Hello Jonathan, and thanks for your bugreport,

It might be very old, but it was apparently never properly reported to Debian; 
so thanks for that!

Le lundi, 31 mai 2021, 20.28:39 h CEST Jonathan Lane a écrit :
> The file /etc/modules-load.d/cups.conf contains invocations to load
> modules lp, ppdev, and parport_pc, which are unavailable on the latest
> arm64 kernels in Debian 10, and will likely remain so forever, at least
> parport_pc, because ARM systems do not have PC parallel ports.  This
> results in systemd-load-modules.service reporting failure every boot.
> The fix is only including this file on architectures where those kernel
> modules are meaningful.  This is a very old bug and appears to be a
> regression, since it was known at least as far back as 2015 by the
> Ubuntu maintainers.

Would the attached patch solve this bug meaningfully? It seems to work as-is 
on amd64; could you confirm it's working on arm*?

Best,
OdyX>From 9a629787fd476efceb1885bc6fe9c9df336c689b Mon Sep 17 00:00:00 2001
From: Didier Raboud 
Date: Wed, 2 Jun 2021 20:33:19 +0200
Subject: [PATCH] Only install /etc/modules-load.d/cups-filters.conf in amd64
 i386 mips64el mipsel alpha hppa ia64 sparc64

Closes: #989306
---
 debian/rules | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 30b23d06d..7246a2fe1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo "yes") || echo "no")
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
@@ -48,8 +50,11 @@ else
 	rsvg-convert debian/local/default-testpage-debian.svg -f pdf > debian/cups-filters/usr/share/cups/data/default-testpage.pdf
 endif
 
-	# Install the modules loader for lp, ppdev and parport_pc
+# Known not-present: m68k hurd-i386 kfreebsd-{amd64,i386}
+ifneq ($(filter $(DEB_HOST_ARCH),amd64 i386 mips64el mipsel alpha hppa ia64 sparc64),)
+	# Install the modules loader for lp, ppdev and parport_pc, only on allow-listed architectures where these are known-present
 	install -D -m 644 debian/local/modules-load.conf debian/cups-filters/etc/modules-load.d/cups-filters.conf
+endif
 
 	dh_apparmor -pcups-browsed --profile-name=usr.sbin.cups-browsed
 
-- 
2.32.0.rc2

Bug#989053: debdelta: Problems with signatures

[A Mennucc]

you have to download and install a later version of debdelta, for
example from

https://packages.debian.org/bullseye/debdelta

a.

Il 24/05/21 20:58, Ilari Halminen ha scritto:
> Package: debdelta
> Version: 0.62
> Severity: normal
>
> Dear Maintainer,
>
> I cannot use debdelta at all, because it complains of missing
> signatures. I do not know if the problems has something to do with my
> systems special options like still using inittab. I have included a
> file with all messages so you may see the problem. I do not know not
> often report any bug, so at least wanted to send that raport just for you.
>
> With best wishes
> Ilari Halminen (from Finland)
>
> -- System Information:
> Debian Release: 10.9
> APT prefers proposed-updates
> APT policy: (500, 'proposed-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8),
> LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages debdelta depends on:
> ii binutils 2.31.1-16
> ii bzip2 1.0.6-9.2~deb10u1
> ii libbz2-1.0 1.0.6-9.2~deb10u1
> ii libc6 2.28-10
> ii python 2.7.16-1
> ii zlib1g 1:1.2.11.dfsg-1
>
> Versions of packages debdelta recommends:
> ii bsdiff 4.3-21
> ii gnupg-agent 2.2.12-1+deb10u1
> ii gnupg2 2.2.12-1+deb10u1
> ii gpg-agent [gnupg-agent] 2.2.12-1+deb10u1
> ii lzma 9.22-2.1
> ii python-apt 1.8.4.3
> ii python-debian 0.1.35
> ii xdelta 1.1.3-9.2
> ii xdelta3 3.0.11-dfsg-1+b1
> ii xz-utils [lzma] 5.2.4-1
>
> Versions of packages debdelta suggests:
> ii debdelta-doc 0.62
>
> -- no debconf information

Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool

[Tobias Frost]

Control: tags -1 moreinfo

Hi Clay,

here's a review:
- The patch: The dep3 header, the field Bug-Debian is wrong, the ITP is not
  related to the patch
- The patch looks strange to me: Why do you patch the Makefile? What do you
  want to archieve? Parts of the patching seems ok (like avoiding stomping over
CFLAGS, but other parts seems excessive, removing sane parts to me…
  - Upstream seems to support arm, you patch that out?
  - There is no LDCFLAGS -> did you mean LDFLAGS?

- (not a blocker) Please send the manpage upstream for inclusion.


Waiting for your reply…

Cheers,
tobi

Bug#989401: mathtex FTCBFS: compiles for the build architecture

[Helmut Grohne]

Source: mathtex
Version: 1.03-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mathtex fails to cross build from source, because it uses the build
architecture compiler. It neither passes cross tools to make nor does
the Makefile use a substitution variable. Both needs to be fixed. To
make matters worse, it actually compiles during make install. Long story
short, the attached patch makes mathtex cross buildable. Please consider
applying it.

Helmut
diff -u mathtex-1.03/Makefile mathtex-1.03/Makefile
--- mathtex-1.03/Makefile
+++ mathtex-1.03/Makefile
@@ -5,7 +5,7 @@
 
 install:
mkdir -p debian/mathtex/usr/bin
-   gcc -DLATEX=\"/usr/bin/latex\" -DDVIPNG=\"/usr/bin/dvipng\" mathtex.c 
-o ${TARGET}
+   $(CC) -DLATEX=\"/usr/bin/latex\" -DDVIPNG=\"/usr/bin/dvipng\" mathtex.c 
-o ${TARGET}
 
 clean:
mkdir -p debian/mathtex/usr/bin
diff -u mathtex-1.03/debian/changelog mathtex-1.03/debian/changelog
--- mathtex-1.03/debian/changelog
+++ mathtex-1.03/debian/changelog
@@ -1,3 +1,12 @@
+mathtex (1.03-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Make gcc substitutable.
+
+ -- Helmut Grohne   Wed, 02 Jun 2021 19:15:45 +0200
+
 mathtex (1.03-1) unstable; urgency=high
 
   * New upstream release.
diff -u mathtex-1.03/debian/rules mathtex-1.03/debian/rules
--- mathtex-1.03/debian/rules
+++ mathtex-1.03/debian/rules
@@ -25,9 +25,6 @@
 
 build-stamp: configure-stamp  
dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE)
docbook-to-man debian/mathtex.sgml > mathtex.1
 
touch $@
@@ -47,9 +44,7 @@
dh_testroot
dh_prep
dh_installdirs
-
-   # Add here commands to install the package into debian/mathtex.
-   $(MAKE) DESTDIR=$(CURDIR)/debian/mathtex install
+   dh_auto_build -- DESTDIR=$(CURDIR)/debian/mathtex install
 
 
 # Build architecture-independent files here.

Bug#989399: nauty FTCBFS -- multiple reasons

[Helmut Grohne]

Control: retitle -1 nauty: i386 baseline violation by using popcnt
Control: severity -1 serious
Control: tags -1 - patch

On Wed, Jun 02, 2021 at 09:59:23PM +0530, Nilesh Patra wrote:
> Nauty fails to cross build due to two reasons:
> 
> 1. It uses AC_RUN_IFELSE testing which cannot heppen during cross build
>Simply replacing it by AC_LINK_IFELSE does the trick. Please find the
>patch for this below, and consider applying

I'm sorry, but this is wrong on so many levels...

Replacing AC_RUN_IFELSE with AC_LINK_IFELSE only makes sense if the
result of the execution is not important. For this check however, it
really is. The check does not want to know whether the compiler supports
popcnt (which could be determined using AC_LINK_IFELSE), but whether the
CPU does and AC_LINK_IFELSE does not suffice here.

Unfortunately such opportunistic use of the popcnt instruction violates
the i386 baseline as it does not include SSE4 at this time. This is a
serious bug. For Debian, such detection is not appropriate. Debian
builds must pass --disable-popcnt for any-i386. If the package is deemed
unusable without such performance optimizations, it should at least
depend on the appropriate isa-support package likely sse4.2-support.

Since replacing AC_RUN_IFELSE with AC_LINK_IFELSE is not reasonable
here, another solution is required. The problem can be narrowed: The
check can be split into a compile and a separate run check. If the
popcnt instruction cannot be compiled (which likely happens for any !x86
system), the run check can be skipped. For x86 architectures there are
two reasonable approaches. One is providing explicit options for
instruction-selection. There already is --disable-popcnt. Skipping the
run check when either --disable-popcnt or --enable-popcnt is given would
be reasonable. Another option is introducing a cache variable using
AC_CACHE_CHECK.

I hope it's ok if I repurpose this bug for the i386 baseline violation.
Nilesh, can you file a new bug for the FTCBFS with a better patch?

Helmut

Bug#903937: /etc/reader.conf.d/libtowitoko2 causes driver failure

[Ondrej Zary]

This is really an annoying bug. Just installed libtowitoko2 2.0.7-9+b1 to
test a serial CHIPDRIVE card reader only to find this old bug again.

The original /etc/reader.conf.d/libtowitoko2 file is:
FRIENDLYNAME  "Towitoko Chipdrive Reader"
DEVICENAME/dev/ttyS0
LIBPATH   /usr/lib/libtowitoko.so.2.0.0
CHANNELID 0x0103F8

It causes very weird behavior of pcscd:
readerfactory.c:1106:RFInitializeReader() Open Port 0x0 Failed (/dev/ttyS0)

The strace is very "interesting", first stat()ing /dev/ttyS0 and then trying
to open() /dev/ttyUSB32767:
openat(AT_FDCWD, "/etc/reader.conf.d/libtowitoko2", O_RDONLY) = 7
ioctl(7, TCGETS, 0xbff8d8c8)= -1 ENOTTY (Inappropriate ioctl for 
device)
fstat64(7, {st_mode=S_IFREG|0644, st_size=171, ...}) = 0
read(7, "FRIENDLYNAME  \"Towitoko Chip"..., 8192) = 171
read(7, "", 4096)   = 0
stat64("/dev/ttyS0", {st_mode=S_IFCHR|0660, st_rdev=makedev(0x4, 0x40), ...}) = 0
stat64("/usr/lib/libtowitoko.so.2.0.0", {st_mode=S_IFREG|0644, st_size=88472, 
...}) = 0
read(7, "", 8192)   = 0
ioctl(7, TCGETS, 0xbff8d8c8)= -1 ENOTTY (Inappropriate ioctl for 
device)
close(7)= 0
getdents64(6, /* 0 entries */, 32768)   = 0
close(6)= 0
futex(0xb7e4404c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/usr/lib/libtowitoko.so.2.0.0", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 6
read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340>\0\0004\0\0\0"..., 
512) = 512
fstat64(6, {st_mode=S_IFREG|0644, st_size=88472, ...}) = 0
mmap2(NULL, 91344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 
0xb7f1
mmap2(0xb7f25000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x14000) = 0xb7f25000
close(6)= 0
mprotect(0xb7f25000, 4096, PROT_READ)   = 0
openat(AT_FDCWD, "/dev/ttyUSB32767", O_RDWR|O_NOCTTY) = -1 ENOENT (No such file 
or directory)


Where comes the weird CHANNELID 0x0103F8 from? Maybe 0x3f8 as I/O address of PC 
COM1 port?

The working /etc/reader.conf.d/libtowitoko2 file is:
FRIENDLYNAME  "Towitoko Chipdrive Reader"
LIBPATH   /usr/lib/libtowitoko.so.2.0.0
CHANNELID 1

However, it should probably be commented-out by default (as in 
/etc/reader.conf.d/libccidtwin)

-- 
Ondrej Zary

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Wed, Jun 02, 2021 at 06:11:56PM +0200, Jose wrote:
> Hi Berto,
> 
> Sorry for the delay. Yopmail went down a little bit after I sent my
> initial report.
> 
> Discord still crashes for me. I'm attaching the gdb trace you
> requested. I opened epiphany with a blank home screen, then went
> to the discord site and clicked on "open discord in the browser"
> 
> As you can see, I have the same version of epiphany that you used
> in your own test:
> 
>   Installed: 3.32.1.2-3~deb10u1
>   Candidate: 3.32.1.2-3~deb10u1
> 
> I may be able to reproduce the error due to my using discord and belonging
> to some servers. This may make epiphany/webkit or the associated 
> javascript do some rendering or something I don't know that used to work
> and stopped after the libwebkit patch. It's just normal discord servers,
> nothing hacked or fancy afaik.

Yes, I guess the reason is the servers you belong to because I really
cannot reproduce the problem.

If you run Epiphany from the command line, does it show any error
message when it crashes? There's an abort() there which might give us
a clue (the rest of the backtrace if unfortunately not very useful
without the symbols).

Also, can you try with the Minibrowser?

$ /usr/lib/*/webkit2gtk-4.0/MiniBrowser https://discord.com

One more thing, you can also try without the JIT:

$ JavaScriptCoreUseJIT=0 epiphany

If this last one doesn't crash, can you tell me what CPU model does
your computer have?

> If you'd like me to download the debug symbols and generate another
> bt, please tell me so.

Unfortunately they don't seem to be available yet for your build:

http://debug.mirrors.debian.org/debian-debug/pool/main/w/webkit2gtk/

You would need to build them yourself (or I can also provide the debug
packages for you if you prefer).

Berto

Bug#987244: RFS: nbsdgames/4.0-1 [ITP] -- text based mini games for your terminal

[Tobias Frost]

Control: tags -1 moreinfo

The current package on mentors from May 11th has still the collisions mentioned
earlier in #12*. Until that is not resolved, the sponsoring cannot proceed.

Tagging moreinfo to reduce the noise in sponsorship-requests…

* sos -> pkg sosreport has /usr/bin/sos
  sudoku -> pkg sudoko /usr/games/sudoku

Cheers, 
--
tobi

Bug#987794: RFS: budgie-screensaver/4.0-1 [ITP] -- Screensaver and screen lock for the Budgie Desktop

[Tobias Frost]

Control: tags -1 moreinfo

Hi David,

- d/copyright:
  - its incomplete; at least the entry for git.mk is missing.
  - There are files in src/ that are NOT GPL (e.g. setuid.h)
  - (NOTE: I stopped here doing the copyright review. Please make sure to review
  it again in depth and fix any issues _before_ the next sponsorship iteration.)

  - (optional, but very appreciated): you can tidy up the file a bit by not
repeating the License Texts…
  I mean, for example, it's ok to says "License: GPL-2" in the files section and
  then have a stand-aline "License: GPL-2" section with the text. This would   
  improve readability/reviewability a lot…
  A small IRL example:
https://tracker.debian.org/media/packages/d/darkradiant/copyright-2.11.0-1
(look for the GPL-2+ and GPL-3+ sections)
 

- d/docs: the NEWS file should probably be installed as upstream changelog, not
as doc.

- d/rules (optional) I'd prefer to use d/clean instead of overriding dh_clean

- d/control why control.in ? A diff with control shows no dynamic parts in that
file beside the "do not change me" header.


  ( something to ask upstream): Upstream says "this is GPL-2-only" but this
  is contradicted by the headers in e.g src/, which say "GPL-2+". Possibly 
  upstream might want to rectify that. (Not needed for this upload)


Package needs updating; please remove the moreinfo tag when ready.

--

Cheers,
tobi

Bug#989399: nauty FTCBFS -- multiple reasons

[Nilesh Patra]

Package: nauty
Version: 2.7r1+ds-2
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

Nauty fails to cross build due to two reasons:

1. It uses AC_RUN_IFELSE testing which cannot heppen during cross build
   Simply replacing it by AC_LINK_IFELSE does the trick. Please find the
   patch for this below, and consider applying

2. It uses help2man during build, and the same has also been
   autotoolised - this isn't allowed during build. It looks like there's 
particularly
   no good way to fix it, and probably compiling twice once for build
   arch, and once for host is un-needed extra work.
   I'd suggest removing the help2man invocations from autotools, not
   generate this during build, but simply maintain maintainer manpage,
   using for example createmanpages script[1]
   Talking to upstream and asking them to vendor their own manpages from
   next release can also be a nice option.

   If it is too much hassle for you, I'm willing to do so myself and
   even maintain the package

[1]: 
https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages

--- a/configure.ac
+++ b/configure.ac
@@ -295,7 +295,7 @@

 dnl --check if popcnt instruction is available and desired
 AC_MSG_CHECKING(if popcnt instruction is available and requested)
-AC_RUN_IFELSE([AC_LANG_PROGRAM([],[[if (__builtin_cpu_supports("popcnt")) 
return 0; else return 1;]])],
+AC_LINK_IFELSE([AC_LANG_PROGRAM([],[[if (__builtin_cpu_supports("popcnt")) 
return 0; else return 1;]])],
   popsup=1,popsup=0)

 AS_IF([test "$allow_popcnt" -eq 1],


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

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

Versions of packages nauty depends on:
ii  libc6  2.31-3
ii  libgmp10   2:6.2.0+dfsg-6
pn  libnauty2  
ii  zlib1g 1:1.2.11.dfsg-2

nauty recommends no packages.

Versions of packages nauty suggests:
ii  graphviz   2.42.2-4
pn  nauty-doc  

Bug#989400: mariadb-server-10.5: MariaDB fail to execute CONVERT TO CHARACTER

[Dmitriy Rabotyagov]

Package: mariadb-server-10.5
Version: 1:10.5.10-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: noonedeadp...@ya.ru

Dear Maintainer,

MariaDB 10.5.10 package has introduced a "floating" bug, when server may fail 
to execute like
`ALTER TABLE tablename CONVERT TO CHARACTER SET utf8`

This results in failing migrations, for example, of the OpenStack Cinder:
https://bf8b3683a4d2b36abe64-1877198ef7d2100f38eb37f99c1c7298.ssl.cf1.rackcdn.com/783606/20/check/openstack-ansible-deploy-aio_lxc-debian-bullseye/aa42a18/logs/ara-report/results/2512.html

More logs can be found: 
https://zuul.opendev.org/t/openstack/build/aa42a18e3f9b417e91ee6470afb5ecbb/logs

Downgrading mariadb-server for buster and ubuntu distributions to 10.5.9 
allowed us not to face this issue,
while it have another issue with loosing root permissions after upgrade (but it 
could be easily worked around with
`UPDATE mysql.global_priv SET Priv = '549755813887' where User = 'root' and 
Host = 'localhost'`)

Related bug report has been submitted to mariadb maintainers: 
https://jira.mariadb.org/browse/MDEV-25673

What makes things worse, that mariadb does not provide bullseye packages yet, 
so there's no option to pick up from
buggy version you're ok with.

Would be great to have some options in upstream repo to pick from, then apt 
pinning might be used by users to pick up
from appropriate version until 10.5.11 will be relased, that hopefully fixes 
both issues and won't bring anything too
breaking again.


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

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

Versions of packages mariadb-server-10.5 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.75
ii  galera-4  26.4.7-3
ii  gawk  1:5.1.0-1
ii  iproute2  5.10.0-4
ii  libc6 2.31-12
ii  libdbi-perl   1.643-3+b1
ii  libpam0g  1.4.0-7
ii  libssl1.1 1.1.1k-1
ii  libstdc++610.2.1-6
ii  lsb-base  11.1.0
ii  lsof  4.93.2+dfsg-1.1
ii  mariadb-client-10.5   1:10.5.10-2
ii  mariadb-common1:10.5.10-2
ii  mariadb-server-core-10.5  1:10.5.10-2
ii  passwd1:4.8.1-1
ii  perl  5.32.1-4
ii  procps2:3.3.17-5
ii  psmisc23.4-2
ii  rsync 3.2.3-4
ii  socat 1.7.4.1-3
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages mariadb-server-10.5 recommends:
pn  libhtml-template-perl  

Versions of packages mariadb-server-10.5 suggests:
pn  mailx   
pn  mariadb-test
pn  netcat-openbsd  

-- debconf information:
  mariadb-server-10.5/nis_warning:
* mysql-server/root_password: 9816a835ad4129d0460500ff66aa4ff
  mariadb-server-10.5/old_data_directory_saved:
  mariadb-server-10.5/postrm_remove_databases: false
* mysql-server/root_password_again: 9816a835ad4129d0460500ff66aa4ff

Bug#987996: RFS: hipercontracer/1.6.0~rc1-1 [ITP]

[Tobias Frost]

Control: tags -1 moreinfo

Hi Thomas,

Mentors says:

"Package closes bugs in a wrong way
Errors:

Bug #987996 is a RFS bug

hipercontracer:
#987996 (Normal, RFS): RFS: hipercontracer/1.6.0~rc1-1 [ITP]"

--> you need to close the ITP bug in the changelog.
Possibly after filing one; I couldnt find it at least…

- On a new package, the _only_ changelog entry is that one that closes the ITP.
(in your case delete the new upstream version line and *all* older entries.

- There are lots of versioned Build-Depends which are already fulfilled in
oldstable. drop those.
  - There is no cmake3 package in Debian, drop that alternative to cmake.
  - It should be sufficient for the boost B-D to just specify the version
agnostic one. Or do I miss the point what you want to archive here?
(beside, oldstable has already 1.62, so no need to say >1.58)

- Pendantic lintian has this, easy to fix:
P: hipercontracer source: uses-debhelper-compat-file


- The examples should be installed using dh_installexamples (not using
*.install)

- Please add comments to lintian overrides. Did you override because you
  checked them or just overode them?

- I think the user/group handling in postinst is wrong in several ways.
  - hardcoded id of 888. 
  - names should be "invalid names" so that it cannot cause collisions.
  - setting the hoemdirectory to /tmp/ is certainly a bad idea and I
guess insecure. Especially when setting /bin/bash as shell…
  - IOW, Read the Debian Policy on this topic.


Package needs work; therefore tagging moreinfo. Please remove for the next
iteration. I did not do a copyright review.
  
--  
cheers
tobi

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Salvatore Bonaccorso]

Hi,

On Tue, Jun 01, 2021 at 07:46:34PM -0700, Rick Thomas wrote:
> Hi!
> Is there any estimate of when the assumed fix (linux/5.10.40-1) will
> show up in the installer at [1] ?  I'd love to test it!

Should be "soon", cf. #988442.

Regards,
Salvatore

Bug#989398: can not find itkVTKImageToImageFilter.h

[Picca Frédéric-Emmanuel]

Package: libinsighttoolkit4-dev
Version: 4.13.3withdata-dfsg1-4.1
Severity: important
X-Debbugs-Cc: pi...@debian.org

Hello, I am building a paraview extension but it ends up with this error

 CMakeFiles/FacetAnalyserTest.dir/FacetAnalyser.cxx.o -c 
"/<>/code/FacetAnalyser.cxx"
/<>/code/FacetAnalyser.cxx:33:10: fatal error: 
itkVTKImageToImageFilter.h: No such file or directory
   33 | #include 
  |  ^~~~


it seems that you did not provide these headers in the -dev package of the 4.x 
version.
This file was available in the 3.x version of itk.

Could you considere re-adding the Bridge modules

thanks

Frederic



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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libinsighttoolkit4-dev depends on:
ii  libc6 2.31-12
ii  libdcmtk-dev  3.6.5-1
ii  libdouble-conversion-dev  3.1.5-6.1
ii  libexpat1-dev [libexpat-dev]  2.2.10-2
ii  libgcc-s1 10.2.1-6
ii  libgdcm-dev   3.0.8-1
ii  libhdf5-dev   1.10.6+repack-2
ii  libinsighttoolkit4.13 4.13.3withdata-dfsg1-4.1
ii  libminc-dev   2.4.03-3
ii  libnifti-dev  3.0.1-8
ii  libnifti2-dev [libnifti-dev]  3.0.1-8
ii  libstdc++610.2.1-6

Versions of packages libinsighttoolkit4-dev recommends:
pn  libfftw3-dev  
ii  uuid-dev  2.36.1-7

Versions of packages libinsighttoolkit4-dev suggests:
pn  insighttoolkit4-examples  

-- no debconf information

Bug#974678: ITP: openh264 -- H.264 encoding and decoding

[Tobias Frost]

On Fri, 14 May 2021 00:04:52 +0200 Bastian Germann  wrote:
> Control: retitle -1 ITP: openh264 -- H.264 encoding and decoding
> 
> On Sat, 8 May 2021 18:28:35 +0200 Bastian Germann 
wrote:
> > This is fine. The package must not reside in main. If you plan to 
> > release the package (the downloader) under a DFSG-compatible license, 
> > please submit it to contrib rather than non-free.
> 
> I am currently packaging openh264.
> 
(I was checking the RFS, thats why I came accross this ITP)

I'm confused; is there now a legal patent problem with the library that could
affect/hurt Debian? 
Has this been discussed on e.g debian-legal or with the ftp masters beforehand?
Is this RFS package now a downloader or the library itself?

--
tobi

Bug#989365: RFS: recastnavigation

[Tobias Frost]

On Tue, 1 Jun 2021 22:02:57 +0200 bret curtis  wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Hello Debian,
> 
> I've prepared the packaging of recastnavigation. It is lintian clean
> and tested with pbuilder. Further information about this package can
> be accessed from the URL :
> https://salsa.debian.org/games-team/recastnavigation
> 
> it's been put into use here, as it is a build dependency for the upcoming
> OpenMW release.
> https://launchpad.net/~openmw/+archive/ubuntu/openmw/+packages
> 
> Please consider it for review and possible upload for 'experimental', at
> least until Bullseye has been released. :)

New packages (ITPs) can go to unstable; (they don't interfere with the freeze)

Would you mind to upload a package to mentors for easier consumption?
(Sponsors like me are lazy and have some automation in place for mentors, but
not for git as working from git makes them often need to guess what exactly
wants to be sponsored)

-- 
Cheers,
tobi

Bug#757356: Apple keyboard: Scan code event (EV_MSC) not generated when the EV_KEY event is generated by hid-apple.c

[Salvatore Bonaccorso]

Hi Vincent,

On Wed, May 26, 2021 at 12:02:12PM +0200, Vincent Lefevre wrote:
> Control: retitle -1 Apple keyboard: Scan code event (EV_MSC) not generated 
> when the EV_KEY event is generated by hid-apple.c
> Control: tags -1 patch
> 
> On 2021-05-26 10:39:11 +0200, Vincent Lefevre wrote:
> > And the cursor keys. Actually, all the keys corresponding to
> > 
> > static const struct applespi_key_translation applespi_fn_codes[] = {
> > { KEY_BACKSPACE, KEY_DELETE },
> > { KEY_ENTER,KEY_INSERT },
> > { KEY_F1,   KEY_BRIGHTNESSDOWN, APPLE_FLAG_FKEY },
> > { KEY_F2,   KEY_BRIGHTNESSUP,   APPLE_FLAG_FKEY },
> > { KEY_F3,   KEY_SCALE,  APPLE_FLAG_FKEY },
> > { KEY_F4,   KEY_DASHBOARD,  APPLE_FLAG_FKEY },
> > { KEY_F5,   KEY_KBDILLUMDOWN,   APPLE_FLAG_FKEY },
> > { KEY_F6,   KEY_KBDILLUMUP, APPLE_FLAG_FKEY },
> > { KEY_F7,   KEY_PREVIOUSSONG,   APPLE_FLAG_FKEY },
> > { KEY_F8,   KEY_PLAYPAUSE,  APPLE_FLAG_FKEY },
> > { KEY_F9,   KEY_NEXTSONG,   APPLE_FLAG_FKEY },
> > { KEY_F10,  KEY_MUTE,   APPLE_FLAG_FKEY },
> > { KEY_F11,  KEY_VOLUMEDOWN, APPLE_FLAG_FKEY },
> > { KEY_F12,  KEY_VOLUMEUP,   APPLE_FLAG_FKEY },
> > { KEY_RIGHT,KEY_END },
> > { KEY_LEFT, KEY_HOME },
> > { KEY_DOWN, KEY_PAGEDOWN },
> > { KEY_UP,   KEY_PAGEUP },
> > { }
> > };
> > 
> > in drivers/input/keyboard/applespi.c.
> > 
> > Just in case, in /etc/modprobe.d/hid_apple.conf, I have
> > 
> > options hid_apple fnmode=2
> > options hid_apple iso_layout=0
> 
> But since I'm using hid_apple, I should have taken
> drivers/hid/hid-apple.c, which has the same kind of code:
> 
> static const struct apple_key_translation apple_fn_keys[] = {
> { KEY_BACKSPACE, KEY_DELETE },
> { KEY_ENTER,KEY_INSERT },
> { KEY_F1,   KEY_BRIGHTNESSDOWN, APPLE_FLAG_FKEY },
> { KEY_F2,   KEY_BRIGHTNESSUP,   APPLE_FLAG_FKEY },
> { KEY_F3,   KEY_SCALE,  APPLE_FLAG_FKEY },
> { KEY_F4,   KEY_DASHBOARD,  APPLE_FLAG_FKEY },
> { KEY_F5,   KEY_KBDILLUMDOWN,   APPLE_FLAG_FKEY },
> { KEY_F6,   KEY_KBDILLUMUP, APPLE_FLAG_FKEY },
> { KEY_F7,   KEY_PREVIOUSSONG,   APPLE_FLAG_FKEY },
> { KEY_F8,   KEY_PLAYPAUSE,  APPLE_FLAG_FKEY },
> { KEY_F9,   KEY_NEXTSONG,   APPLE_FLAG_FKEY },
> { KEY_F10,  KEY_MUTE,   APPLE_FLAG_FKEY },
> { KEY_F11,  KEY_VOLUMEDOWN, APPLE_FLAG_FKEY },
> { KEY_F12,  KEY_VOLUMEUP,   APPLE_FLAG_FKEY },
> { KEY_UP,   KEY_PAGEUP },
> { KEY_DOWN, KEY_PAGEDOWN },
> { KEY_LEFT, KEY_HOME },
> { KEY_RIGHT,KEY_END },
> { }
> };
> 
> In the conditions from hidinput_apple_event(), the only ones that
> should match according to my settings are
> 
> if (usage->code == fn_keycode) {
> 
> and
> 
> if (fnmode) {
> 
> and these are the keys (when trans is true, for fnmode) for which I do
> not get a scan code event. Said otherwise, if hidinput_apple_event()
> returns 1, I do not get a scan code event. There are input_event()
> calls, but I suppose that they will just generate an EV_KEY event,
> and EV_MSC is the one that is missing.
> 
> Note: in hid-apple.c, apple_event() calls hidinput_apple_event(), and
> one has
> 
> static struct hid_driver apple_driver = {
> [...]
> .event = apple_event,
> [...]
> };
> module_hid_driver(apple_driver);
> 
> I forgot that there was
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757356#35
> 
> from Daniel Lin, with a patch, in 2017. I've looked at this patch
> (but have not tried it), and it adds an additional EV_MSC event
> when hidinput_apple_event() has to generate an EV_KEY event. So
> I confirm that should solve this issue and I'm adding the patch
> tag (I don't know whether the patch needs an update, though).

Can you, time permitting, starting from there (and needed refreshes)
try to confirm if the patch solves the issue on top of 5.10.40? If so,
next step would be to propose the change/report the bug at least, to
upstream, get_maintainers.pl would suggest to report it to:

Jiri Kosina  (maintainer:HID CORE LAYER)
Benjamin Tissoires  (maintainer:HID CORE LAYER)
linux-in...@vger.kernel.org (open list:HID CORE LAYER)
linux-ker...@vger.kernel.org (open list)

Regards,
Salvatore

Bug#989386: RFS: gifsicle/1.92-3 [ITA] -- Tool for manipulating GIF images

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #989386

Uploaded. Thanks for the package!

-- 
tobi

Bug#989397: gifsicle: watchfile does not work

[Tobias Frost]

Package: gifsicle
Severity: normal
Control: found -1 1.92-2

The watch file is broken

tobi@isildor:~/workspace/deb/mentors/GürkanMyczko/gifsicle/archive/gifsicle-1.92$
 uscan
uscan warn: In debian/watch no matching files for watch line
  https://github.com/kohler/gifsicle/releases 
.*/archive/v?(\d\S+)\.(?:tar.gz|zip)

The file is already broken in 1.92-2, did not test older versions.

-- 
Cheers,
tobi

Bug#989396: linux-image-4.19.0-16-amd64: The machine reboots after kernbel selecting on grub screen one or two times on 3

[rpnpif]

Package: src:linux
Version: 4.19.181-1
Severity: important

Dear Maintainer,

Starting the machine powering on, Grub screen is normally displayed.
I press the Enter key to select the first kernel (4.9.0-16) to start.
The machine reboots often randomly (1 or 2 times on 3).

After some reboots, the kernel is starting normally but the usb mouse does not 
work.
When the starting is normal after powering on, the usb mouse works fine. 

Regards.

-- Package-specific info:
** Version:
Linux version 4.19.0-16-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.181-1 (2021-03-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-16-amd64 
root=UUID=5ebf0513-8146-4896-b3bc-9a9923f0cf81 ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   12.349975] input: HDA ATI HDMI HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.1/sound/card1/input7
[   12.370811] saa7134: saa7130/34: v4l2 driver version 0, 2, 17 loaded
[   12.370918] saa7134 :05:05.0: enabling device ( -> 0002)
[   12.371015] saa7134: saa7134[0]: found at :05:05.0, rev: 1, irq: 20, 
latency: 32, mmio: 0xfe80
[   12.371022] saa7134: saa7134[0]: subsystem: 11bd:002b, board: Medion 7134 
[card=12,insmod option]
[   12.371048] saa7134: saa7134[0]: board init: gpio is 0
[   12.371516] EDAC amd64: Node 0: DRAM ECC disabled.
[   12.371517] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[   12.475407] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC887-VD: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[   12.475410] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   12.475411] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[   12.475412] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   12.475413] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   12.475414] snd_hda_codec_realtek hdaudioC0D0:  Front Mic=0x19
[   12.475416] snd_hda_codec_realtek hdaudioC0D0:  Rear Mic=0x18
[   12.475416] snd_hda_codec_realtek hdaudioC0D0:  Line=0x1a
[   12.492917] input: HD-Audio Generic Front Mic as 
/devices/pci:00/:00:14.2/sound/card0/input8
[   12.492987] input: HD-Audio Generic Rear Mic as 
/devices/pci:00/:00:14.2/sound/card0/input9
[   12.493051] input: HD-Audio Generic Line as 
/devices/pci:00/:00:14.2/sound/card0/input10
[   12.493111] input: HD-Audio Generic Line Out as 
/devices/pci:00/:00:14.2/sound/card0/input11
[   12.493173] input: HD-Audio Generic Front Headphone as 
/devices/pci:00/:00:14.2/sound/card0/input12
[   12.532903] saa7134: i2c eeprom 00: bd 11 2b 00 f8 f8 1c 00 43 43 a9 1c 55 
d2 b2 92
[   12.532906] saa7134: i2c eeprom 10: 00 00 19 0e ff 20 ff ff ff ff ff ff ff 
ff ff ff
[   12.532907] saa7134: i2c eeprom 20: 01 40 01 03 03 ff 03 01 08 ff 00 53 ff 
ff ff ff
[   12.532908] saa7134: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532909] saa7134: i2c eeprom 40: ff 07 00 c0 86 ff 01 03 ff ff ff ff ff 
ff ff ff
[   12.532910] saa7134: i2c eeprom 50: 0c 22 17 36 03 0b df bb ff ff ff ff ff 
ff ff ff
[   12.532911] saa7134: i2c eeprom 60: 03 03 19 71 fb ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532911] saa7134: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532912] saa7134: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532913] saa7134: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532913] saa7134: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532914] saa7134: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532915] saa7134: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532915] saa7134: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532916] saa7134: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.532917] saa7134: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff
[   12.568942] saa7134: saa7134[0] Can't determine tuner type 7 from EEPROM
[   12.569002] saa7134: saa7134[0] Tuner type is 63
[   12.569158] saa7134[0]: Unable to enable IF of the tuner.
[   12.597351] saa7134: saa7134[0]: registered device video1 [v4l2]
[   12.597431] saa7134: saa7134[0]: registered device vbi1
[   12.597500] saa7134: saa7134[0]: registered device radio1
[   12.975583] Adding 1615868k swap on /dev/sda2.  Priority:-2 extents:1 
across:1615868k FS
[   13.029643] Adding 2047996k swap on /dev/sdb1.  Priority:-3 extents:1 
across:2047996k FS
[   13.082259] saa7134_dvb: dvb_init() allocating 1 frontend
[   13.136046] DVB: Unable to find symbol tda10046_attach()
[   13.136117] saa7134_dvb: saa7134[0]/dvb: 

Bug#989393: perl: Reporting with reportbug

[Daniele Primon]

Package: perl
Version: 5.28.1-6+deb10u1
Followup-For: Bug #989393


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

Kernel: Linux 5.10.24-matsui (PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), 
LANGUAGE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages perl depends on:
ii  dpkg   1.19.7
ii  libperl5.285.28.1-6+deb10u1
ii  perl-base  5.28.1-6+deb10u1
ii  perl-modules-5.28  5.28.1-6+deb10u1

Versions of packages perl recommends:
ii  netbase  5.6

Versions of packages perl suggests:
pn  libb-debug-perl 
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
ii  make4.2.1-1.2
pn  perl-doc
ii  perl-modules-5.24 [liblocale-codes-perl]5.24.1-3+deb9u7

-- no debconf information

Bug#981794: RFS: gftools/0.5.2+dfsg-1 [ITP] -- Google Fonts Tools

[Tobias Frost]

Control: tags -1 moreinfo

Hi Romain Porte,

The package fails to build; there is no package named python3-opentype-sanitizer
in Debian.

$ pbuilder build gftools_0.5.2+dfsg-1.dsc
(...)

The following packages have unmet dependencies:
 pbuilder-satisfydepends-dummy : Depends: python3-opentype-sanitizer which is a
virtual package and is not provided by any available package

Unable to resolve dependencies!  Giving up...


Cheers,
tobi

Bug#989395: wmcpu FTCBFS -- uses the build architecture compiler

[Nilesh Patra]

Package: wmcpu
Version: 1.4-4
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, nil...@debian.org, 
debian-cr...@lists.debian.org

Dear Maintainer,

Dear Maintainer,

wmcpu Fails to cross build because it hardcodes gcc as build
compiler in CC=gcc.
Simply removing this line would do the trick for us, however I've
replaced this with CC ?= gcc
Although this is a no-op for us, but this will help getting this
upstreamed.
Please consider applying the attched patch

PS: Since this package hasn't been uploaded for more than 13 years,
which is a *really really* long time, I intend to NMU it post bullseye
release, with this patch applied - if not uploaded on time ofcourse.

--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-CC = gcc
+CC ?= gcc
 CFLAGS = -O3 -Wall
 #DEBUG FLAGS HERE:
 #CFLAGS+= -g -ggdb

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

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

Versions of packages wmcpu depends on:
ii  libc6 2.31-3
ii  libx11-6  2:1.7.0-2
ii  libxext6  2:1.3.3-1+b2
ii  libxpm4   1:3.5.12-1

wmcpu recommends no packages.

wmcpu suggests no packages.

Bug#989394: python-django: CVE-2021-33203 & CVE-2021-33571

[Chris Lamb]

Package: python-django
Version: 1:1.11.29-1~deb10u1
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for python-django.

  * CVE-2021-33203: Potential directory traversal via admindocs

Staff members could use the admindocs TemplateDetailView view to
check the existence of arbitrary files. Additionally, if (and only
if) the default admindocs templates have been customized by the
developers to also expose the file contents, then not only the
existence but also the file contents would have been exposed.

As a mitigation, path sanitation is now applied and only files
within the template root directories can be loaded.

This issue has low severity, according to the Django security
policy.

Thanks to Rasmus Lerchedahl Petersen and Rasmus Wriedt Larsen from
the CodeQL Python team for the report.

  * CVE-2021-33571: Possible indeterminate SSRF, RFI, and LFI attacks
since validators accepted leading zeros in IPv4 addresses

URLValidator, validate_ipv4_address(), and
validate_ipv46_address() didn't prohibit leading zeros in octal
literals. If you used such values you could suffer from
indeterminate SSRF, RFI, and LFI attacks.

validate_ipv4_address() and validate_ipv46_address() validators
were not affected on Python 3.9.5+.

This issue has medium severity, according to the Django security
policy.

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

  https://www.djangoproject.com/weblog/2021/jun/02/security-releases/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#989393: h2ph wrong destination directory

[Daniele Primon]

Package: perl
Version: 5.28.1-6+deb10u1

h2ph fails with the following message.

$ h2ph
Destination directory /usr/local/lib/x86_64-linux-gnu/perl/5.28.1  
doesn't exist or isn't a directory


$ /usr/bin/h2ph
Destination directory /usr/local/lib/x86_64-linux-gnu/perl/5.28.1  
doesn't exist or isn't a directory


$


I'm using Debian GNU/Linux buster 10.9, self compiled kernel  
5.10.24-matsui-1, libc6 2.28-10

--
Daniele Primon 
Web: http://www.reteimprese.it/danieleprimon
 http://web.cheapnet.it/signup/

Bug#989392: wmmatrix FTCBFS -- uses the build architecture compiler

[Nilesh Patra]

Package: wmmatrix
Version: 0.2-12.1
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

wmmatrix Fails to cross build because it hardcodes gcc as build
compiler in CC=gcc.
Simply removing this line would do the trick for us, however I've
replaced this with CC ?= gcc
Although this is a no-op for us, but this will help getting this
upstreamed.
Please consider applying the attched patch

PS: Since a _maintainer upload_ for this package hasn't happened for more than 
12 years,
which is a *really really* long time, I intend to NMU it post bullseye
release, with this patch applied - if not uploaded on time ofcourse.

--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-CC = gcc
+CC ?= gcc
 CFLAGS = -O2 -Wall 
 INCDIR = -I/usr/X11R6/include/X11 -I/usr/X11R6/include
 DESTDIR= /usr/X11R6

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

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

Versions of packages wmmatrix depends on:
ii  libc6 2.31-3
ii  libx11-6  2:1.7.0-2
ii  libxext6  2:1.3.3-1+b2
ii  libxpm4   1:3.5.12-1

wmmatrix recommends no packages.

wmmatrix suggests no packages.

Bug#986801: CVE-2021-30184 patch for GNU Chess 6.2.7 and 6.2.8

[Sebastian Pipping]

Hi Debian,


just a quick note that GNU Chess 6.2.8 is vulnerable too (and that I'm
in touch with NVD to mark 8.2.8 as vulnerable in NVD).

This is the patch for CVE-2021-30184 for both GNU Chess 6.2.7 and 6.2.8
that I derived from Michael Vaughan's prior work for Gentoo, earlier today:
https://github.com/gentoo/gentoo/blob/master/games-board/gnuchess/files/gnuchess-6.2.8-cve-2021-30184.patch

Additional review is welcome.

Best



Sebastian

Bug#981184: firefox-esr: doesn't load pages over internet

[Abhijith PA]

Package: firefox-esr
Version: 78.11.0esr-1
Followup-For: Bug #981184

Hello, 

I updated from firefox-esr:amd64 (78.5.0esr-1, 78.10.0esr-1) and now
to 78.11.0esr-1. I can confirm issue still exist. As suggested above
updating libnss3 to 2:3.61-1 fixed the issue.


-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Default theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: Web Compat
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

-- Plugins information

-- Addons package information
ii  firefox-esr78.11.0esr-1 amd64Mozilla Firefox web browser - 
Extended Support Release (ESR)

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-5
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.20-1
ii  libdbus-glib-1-2 0.110-5
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-5
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-4
ii  libgcc-s110.2.0-19
ii  libgdk-pixbuf-2.0-0  2.40.0+dfsg-8
ii  libglib2.0-0 2.66.3-2
ii  libgtk-3-0   3.24.23-3
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.0-19
ii  libvpx6  1.8.2-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-2
ii  libxcb1  1.14-2
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.16-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.1-5

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-4
ii  libgtk2.0-02.24.32-5
ii  pulseaudio 13.0-5

-- no debconf information

Bug#989391: phnxdeco FTCBFS -- uses the build architecture compiler

[Nilesh Patra]

Package: phnxdeco
Version: 0.33-3
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

phnxdeco Fails to cross build because it hardcodes gcc as build
compiler,
Simply replacing such invocations with $(CC) fixes it. Please consider
applying the patch attached.

PS: Since this package hasn't been uploaded for more than 13 years,
which is a *really really* long time, I intend to NMU it post bullseye
release, with this patch applied - if not uploaded on time ofcourse.

Nilesh

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

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

Versions of packages phnxdeco depends on:
ii  libc6  2.31-3

phnxdeco recommends no packages.

phnxdeco suggests no packages.
diff -Nur -x '*.orig' -x '*~' phnxdeco-0.33/src/Makefile 
phnxdeco-0.33.new/src/Makefile
--- phnxdeco-0.33/src/Makefile  2021-06-02 19:32:33.394649634 +0530
+++ phnxdeco-0.33.new/src/Makefile  2021-06-02 19:33:24.941634732 +0530
@@ -9,17 +9,17 @@
 
 phnxdeco: phnxfunc kernel
DEMO=""
-   gcc -DDEBUG $(DEMO) phnxdeco.c phnxfunc.o kernel.o -fpack-struct -o 
phnxdeco
+   $(CC) -DDEBUG $(DEMO) phnxdeco.c phnxfunc.o kernel.o -fpack-struct -o 
phnxdeco
 
 phnxdeco-demo:
DEMO=1
-   gcc -DDEBUG=$(DEMO) phnxdeco.c phnxfunc.o kernel.o -fpack-struct -o 
phnxdeco-demo
+   $(CC) -DDEBUG=$(DEMO) phnxdeco.c phnxfunc.o kernel.o -fpack-struct -o 
phnxdeco-demo
 
 phnxfunc:
-   gcc phnxfunc.c -c -o phnxfunc.o -fpack-struct
+   $(CC) phnxfunc.c -c -o phnxfunc.o -fpack-struct
 
 kernel:
-   gcc kernel.c -c -o kernel.o -fpack-struct
+   $(CC) kernel.c -c -o kernel.o -fpack-struct
 
 clean: 
rm -f *.o

Bug#988869: libqhull-doc: broken symlinks: /usr/share/doc/libqhull-dev/qhull/src/libqhull_r/*.h -> ../../../../../../include/libqhull_r/*.h

[Timo Röhling]

Hi Andreas,

* Andreas Beckmann  [2021-05-20 17:20]:

Should libqhull-doc have a Depends/Recommends/Suggests: libqhull-dev ?

Probably yes. Those symlinks are used to make some hyperlinks to the
source code files work in the HTML documentation.

I'm on the fence between Recommends and Suggests. What do you think?

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#989390: etherpuppet FTCBFS -- uses the build architecture compiler

[Nilesh Patra]

Package: etherpuppet
Version: 0.3-4
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

etherpuppet Fails to cross build because it uses the build compiler
rather than the host compiler for compilation.
Simply using dpkg's buildtools.mk fixes the problem. Please consider
applying the attached patch.

Nilesh

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

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

Versions of packages etherpuppet depends on:
ii  libc6  2.31-3

etherpuppet recommends no packages.

etherpuppet suggests no packages.
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #! /usr/bin/make -f
 
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 

Bug#989324: Bug#989243: RFS: opendmarc/1.4.0~beta1+dfsg-4 -- Milter implementation of DMARC

[David Bürgin]

Adam Borowski:

On Wed, Jun 02, 2021 at 11:45:23AM +0200, David Bürgin wrote:

The release team have asked for a change
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989324

Can I upload a new package with version 1.4.0~beta1+dfsg-4 to mentors,
or do I have to use version 1.4.0~beta1+dfsg-5 with new changelog entry?


1.4.0~beta1+dfsg-4 is already in unstable, there's no way to reuse that
version number ever.  You need to upload -5.


All right, thank you. Would you recommend that I file a new RFS bug for
1.4.0~beta1+dfsg-5 (now on mentors)?

Sorry for any breach of protocol, I’m doing this for the first time. I
hope this version will be acceptable to the release team (CC, final
debdiff attached).


--
David
diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/changelog opendmarc-1.4.0~beta1+dfsg/debian/changelog
--- opendmarc-1.4.0~beta1+dfsg/debian/changelog	2020-09-19 08:40:47.0 +0200
+++ opendmarc-1.4.0~beta1+dfsg/debian/changelog	2021-06-02 14:17:33.0 +0200
@@ -1,3 +1,18 @@
+opendmarc (1.4.0~beta1+dfsg-5) unstable; urgency=high
+
+  * Amend cve-2020-12272.patch to keep libopendmarc2 public ABI unchanged
+
+ -- David Bürgin   Wed, 02 Jun 2021 14:17:33 +0200
+
+opendmarc (1.4.0~beta1+dfsg-4) unstable; urgency=high
+
+  * Backport patches from upstream version 1.4.1.1 (Closes: #977766, #977767):
+- CVE-2019-16378: Fix handling of multi-valued From headers
+- CVE-2019-20790: Validate incoming SPF headers
+- CVE-2020-12272: Check DKIM and SPF domain syntax
+
+ -- David Bürgin   Sat, 29 May 2021 16:22:50 +0200
+
 opendmarc (1.4.0~beta1+dfsg-3) unstable; urgency=high
 
   * Cherry-pick patch for CVE-2020-12460 from upstream:
diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2019-16378.patch opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2019-16378.patch
--- opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2019-16378.patch	1970-01-01 01:00:00.0 +0100
+++ opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2019-16378.patch	2021-06-02 12:14:59.0 +0200
@@ -0,0 +1,321 @@
+Description: CVE-2019-16378: Handle multi-valued From header, add RejectMultiValueFrom parameter
+Author: Murray S. Kucherawy 
+Origin: backport, https://github.com/trusteddomainproject/OpenDMARC/releases/tag/rel-opendmarc-1-4-1-1
+
+--- a/opendmarc/parse.c
 b/opendmarc/parse.c
+@@ -12,10 +12,18 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ /* opendmarc includes */
+ #include "util.h"
+ 
++#ifndef FALSE
++# define FALSE	0
++#endif /* ! FALSE */
++#ifndef TRUE
++# define TRUE	1
++#endif /* ! TRUE */
++
+ /* types */
+ typedef unsigned long cmap_elem_type;
+ 
+@@ -24,6 +32,7 @@
+ #define MAILPARSE_ERR_PUNBALANCED	1	/* unbalanced parentheses */
+ #define MAILPARSE_ERR_QUNBALANCED	2	/* unbalanced quotes */
+ #define MAILPARSE_ERR_SUNBALANCED	3	/* unbalanced sq. brackets */
++#define MAILPARSE_ERR_MULTIVALUE	4	/* multiple possible values */
+ 
+ /* a bitmap for the "specials" character class */
+ #define	CMAP_NBITS	 	(sizeof(cmap_elem_type) * CHAR_BIT)
+@@ -466,6 +475,160 @@
+ 	}
+ }
+ 
++/*
++**  DMARCF_MAIL_PARSE_MULTI -- extract the local-part and hostname from a mail
++** header field that might contain multiple
++** values, e.g. "To:", "Cc:"
++**
++**  Parameters:
++**  	line -- input line
++**  	users_out -- array of pointers to "local-part" (returned)
++**  	domains_out -- array of pointers to hostname (returned)
++**
++**  Return value:
++**  	0 on success, or an DKIM_MAILPARSE_ERR_* on failure.
++**
++**  Notes:
++**  	Input string is modified.
++*/
++
++int
++dmarcf_mail_parse_multi(unsigned char *line, unsigned char ***users_out,
++unsigned char ***domains_out)
++{
++	_Bool escaped = FALSE;
++	_Bool quoted = FALSE;
++	_Bool done = FALSE;
++	int a = 0;
++	int n = 0;
++	int status;
++	int parens = 0;
++	char *p;
++	char *addr;
++	unsigned char **uout = NULL;
++	unsigned char **dout = NULL;
++	unsigned char *u;
++	unsigned char *d;
++
++	/* walk the input string looking for unenclosed commas */
++	addr = line;
++	for (p = line; !done; p++)
++	{
++		if (escaped)
++		{
++			escaped = FALSE;
++			continue;
++		}
++
++		switch (*p)
++		{
++		  case '\\':
++			escaped = TRUE;
++			continue;
++
++		  case '"':
++			quoted = !quoted;
++			continue;
++
++		  case '(':
++			parens++;
++			continue;
++
++		  case ')':
++			parens--;
++			continue;
++
++		  case ',':
++			/* skip it if it's quoted or in a comment */
++			if (parens != 0 || quoted)
++continue;
++			/* FALLTHROUGH */
++
++		  case '\0':
++			if (*p == '\0')
++done = TRUE;
++			else
++*p = '\0';
++
++			status = dmarcf_mail_parse(addr, , );
++			if (status != 0)
++			{
++if (uout != NULL)
++{
++	free(uout);
++	free(dout);
++}
++
++return status;
++			}
++
++			if (n == 0)
++			{
++size_t newsize = 2 * sizeof(unsigned char *);
++
++uout = (unsigned char **) malloc(newsize);
++if (uout == NULL)
++	return -1;
++

Bug#989389: python3-apt's InstallProgress is not being used as a context manager

[Samuel Mannehed]

Package: python3-apt
Version: 2.2.0

As can be seen in the constructor, InstallProgress is designed to be
used in a 'with' in order to properly close write_stream and
status_stream:

https://git.launchpad.net/python-apt/tree/apt/progress/base.py#n163

This commit added support for using InstallProgress as a context
manager:

https://git.launchpad.net/python-apt/commit/?id=462c05b39eae5a0fa2270d329b03d4711742f20d

It also modified a test, but didn't change the way InstallProgress is
used by cache.py.

This causes Python 3 to complain that InstallProgress's constructor
leaves unclosed files:

> /usr/lib/python3.9/glob.py:123: ResourceWarning: unclosed file 
> <_io.TextIOWrapper name=4 mode='r' encoding='UTF-8'>
>   with os.scandir(dirname) as it:
> Object allocated at (most recent call last):
>   File "/opt/thinlinc/modules/thinlinc/packageinstaller/__init__.py", lineno 
> 33
> OOO0o000 = globals ( ) [ IIi1i111IiII ] . Backend ( )
>   File "/opt/thinlinc/modules/thinlinc/packageinstaller/aptbackend.py", 
> lineno 88
> self . _aptcallback = i1Ii1i ( self )
>   File "/opt/thinlinc/modules/thinlinc/packageinstaller/aptbackend.py", 
> lineno 31
> super ( ) . __init__ ( )
>   File "/usr/lib/python3/dist-packages/apt/progress/base.py", lineno 164
> self.status_stream = os.fdopen(self.statusfd, "r")  # type: io.TextIOBase 
> # noqa
>   File "/usr/lib/python3.9/os.py", lineno 1023
> return io.open(fd, *args, **kwargs)
> /usr/lib/python3.9/glob.py:123: ResourceWarning: unclosed file 
> <_io.TextIOWrapper name=5 mode='w' encoding='UTF-8'>
>   with os.scandir(dirname) as it:
> Object allocated at (most recent call last):
>   File "/opt/thinlinc/modules/thinlinc/packageinstaller/__init__.py", lineno 
> 33
> OOO0o000 = globals ( ) [ IIi1i111IiII ] . Backend ( )
>   File "/opt/thinlinc/modules/thinlinc/packageinstaller/aptbackend.py", 
> lineno 88
> self . _aptcallback = i1Ii1i ( self )
>   File "/opt/thinlinc/modules/thinlinc/packageinstaller/aptbackend.py", 
> lineno 31
> super ( ) . __init__ ( )
>   File "/usr/lib/python3/dist-packages/apt/progress/base.py", lineno 163
> self.write_stream = os.fdopen(self.writefd, "w")  # type: io.TextIOBase
>   File "/usr/lib/python3.9/os.py", lineno 1023
> return io.open(fd, *args, **kwargs)


The issue was identified on Ubuntu 21.04:

> Linux ubuntu2104 5.11.0-17-generic #18-Ubuntu SMP Thu May 6 20:10:11
> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux



-- 
Samuel Mannehed Software Development
Cendio AB   https://cendio.com
Teknikringen 8  https://twitter.com/ThinLinc
583 30 Linköpinghttps://facebook.com/ThinLinc
Phone: +46 13 214 600

Bug#989388: bareos-filedaemon: Failure to mount NFS directory prefents FD startup, but FD doesn't need it

[James Youngman]

Package: bareos-filedaemon
Version: 16.2.6-5
Severity: normal

If an NFS mount fails, the Bareos FD won't start.  But (at least by
default) the LinuxAll fileset excludes NFS-mounted directories anyway,
so such directories would not be backed up anyway.

IOW, there's no actual reason for the FD not to start in this situation.

Here are the relevant error messages from the systemd journal:

  -- The unit mnt-kerberised\x2dnfs\x2dtesting.mount has entered the
   'failed' state with result 'exit-code'.
   Jun 02 13:45:04 Big-in-Japan systemd[1]: Failed to mount
   /mnt/kerberised-nfs-testing.
   -- Subject: A start job for unit
   mnt-kerberised\x2dnfs\x2dtesting.mount has failed
   -- Defined-By: systemd
   -- Support: https://www.debian.org/support
   --
   -- A start job for unit mnt-kerberised\x2dnfs\x2dtesting.mount has
   finished with a failure.
   --
   -- The job identifier is 79015 and the job result is failed.
   Jun 02 13:45:04 Big-in-Japan systemd[1]: Dependency failed for
   Remote File Systems.
   -- Subject: A start job for unit remote-fs.target has failed
   -- Defined-By: systemd
   -- Support: https://www.debian.org/support
   --
   -- A start job for unit remote-fs.target has finished with a
   failure.
   --
   -- The job identifier is 78995 and the job result is dependency.
   Jun 02 13:45:04 Big-in-Japan systemd[1]: Dependency failed for
   Bareos File Daemon service.
   -- Subject: A start job for unit bareos-filedaemon.service has
   failed
   -- Defined-By: systemd
   -- Support: https://www.debian.org/support
   --


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bareos-filedaemon depends on:
ii  adduser3.118
ii  bareos-common  16.2.6-5
ii  debconf [debconf-2.0]  1.5.71
ii  libacl12.2.53-4
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libgcc11:8.3.0-6
ii  libgnutls303.6.7-4+deb10u6
ii  libjansson42.12-1
ii  liblzo2-2  2.10-0.1
ii  libstdc++6 8.3.0-6
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  lsof   4.91+dfsg-1
ii  zlib1g 1:1.2.11.dfsg-1

bareos-filedaemon recommends no packages.

bareos-filedaemon suggests no packages.

-- no debconf information

Bug#989386: RFS: gifsicle/1.92-3 [ITA] -- Tool for manipulating GIF images

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gifsicle":

 * Package name: gifsicle
   Version : 1.92-3
   Upstream Author : Eddie Kohler 
 * URL : http://www.lcdf.org/gifsicle/
 * License : GPL-2 or CLICK or special, GPL-2 or special
 * Vcs : https://salsa.debian.org/debian/gifsicle
   Section : graphics

It builds those binary packages:

  gifsicle - Tool for manipulating GIF images

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/gifsicle/

Alternatively, one can download the package with dget using this 
command:


  dget -x 
https://mentors.debian.net/debian/pool/main/g/gifsicle/gifsicle_1.92-3.dsc


Changes since the last upload:

 gifsicle (1.92-3) experimental; urgency=medium
 .
   * New Maintainer. Thanks Herbert Parentes Fortes Neto for the nice 
work.

 (Closes: #986934)
   * d/upstream/metadata: added.
   * Bump standards version to 4.5.1.
   * Bump debhelper version to 13.
   * d/control: added Rules-Requires-Root.

Regards,
--
  Gürkan Myczko

Bug#989385: redisearch.so needs executable permissions

[Andreas Gerstmayr]

Package: redis-redisearch
Version: 1.2.2-3

The /usr/lib/redis/modules/redisearch.so file needs executable 
permissions, otherwise Redis won't start.



Quick reproducer in a container:

root@c47b056bcc1f:/# apt-get update && apt-get install -y sudo 
redis-redisearch

[...]

root@c47b056bcc1f:/# sudo -u redis redis-server --loadmodule 
/usr/lib/redis/modules/redisearch.so
290:C 02 Jun 2021 12:10:34.530 # oO0OoO0OoO0Oo Redis is starting 
oO0OoO0OoO0Oo
290:C 02 Jun 2021 12:10:34.530 # Redis version=6.0.14, bits=64, 
commit=, modified=0, pid=290, just started

290:C 02 Jun 2021 12:10:34.530 # Configuration loaded
_._
   _.-``__ ''-._
  _.-```.  `_.  ''-._   Redis 6.0.14 (/0) 64 bit
  .-`` .-```.  ```\/_.,_ ''-._
 ('  ,   .-`  | `,) Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
 |`-._   `._/ _.-'| PID: 290
  `-._`-._  `-./  _.-'_.-'
 |`-._`-._`-.__.-'_.-'_.-'|
 |`-._`-.__.-'_.-'|   http://redis.io
  `-._`-._`-.__.-'_.-'_.-'
 |`-._`-._`-.__.-'_.-'_.-'|
 |`-._`-.__.-'_.-'|
  `-._`-._`-.__.-'_.-'_.-'
  `-._`-.__.-'_.-'
  `-.__.-'
  `-.__.-'

290:M 02 Jun 2021 12:10:34.534 # Server initialized
290:M 02 Jun 2021 12:10:34.534 # WARNING overcommit_memory is set to 0! 
Background save may fail under low memory condition. To fix this issue 
add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or 
run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
290:M 02 Jun 2021 12:10:34.534 # Module 
/usr/lib/redis/modules/redisearch.so failed to load: It does not have 
execute permissions.
290:M 02 Jun 2021 12:10:34.534 # Can't load module from 
/usr/lib/redis/modules/redisearch.so: server aborting


root@c47b056bcc1f:/# ls -lh /usr/lib/redis/modules/redisearch.so
-rw-r--r--. 1 root root 2.0M Apr 23  2020 
/usr/lib/redis/modules/redisearch.so


root@c47b056bcc1f:/# chmod +x /usr/lib/redis/modules/redisearch.so

root@c47b056bcc1f:/# sudo -u redis redis-server --loadmodule 
/usr/lib/redis/modules/redisearch.so
294:C 02 Jun 2021 12:10:53.581 # oO0OoO0OoO0Oo Redis is starting 
oO0OoO0OoO0Oo
294:C 02 Jun 2021 12:10:53.581 # Redis version=6.0.14, bits=64, 
commit=, modified=0, pid=294, just started

294:C 02 Jun 2021 12:10:53.581 # Configuration loaded
_._
   _.-``__ ''-._
  _.-```.  `_.  ''-._   Redis 6.0.14 (/0) 64 bit
  .-`` .-```.  ```\/_.,_ ''-._
 ('  ,   .-`  | `,) Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
 |`-._   `._/ _.-'| PID: 294
  `-._`-._  `-./  _.-'_.-'
 |`-._`-._`-.__.-'_.-'_.-'|
 |`-._`-.__.-'_.-'|   http://redis.io
  `-._`-._`-.__.-'_.-'_.-'
 |`-._`-._`-.__.-'_.-'_.-'|
 |`-._`-.__.-'_.-'|
  `-._`-._`-.__.-'_.-'_.-'
  `-._`-.__.-'_.-'
  `-.__.-'
  `-.__.-'

294:M 02 Jun 2021 12:10:53.584 # Server initialized
294:M 02 Jun 2021 12:10:53.585 # WARNING overcommit_memory is set to 0! 
Background save may fail under low memory condition. To fix this issue 
add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or 
run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

294:M 02 Jun 2021 12:10:53.587 *  RediSearch version 1.2.0 (Git=)
294:M 02 Jun 2021 12:10:53.587 *  concurrency: ON, gc: ON, prefix 
min length: 2, prefix max expansions: 200, query timeout (ms): 500, 
timeout policy: return, cursor read size: 1000, cursor max idle (ms): 
30, max doctable size: 100, search pool size: 20, index pool 
size: 8,

294:M 02 Jun 2021 12:10:53.588 *  Initialized thread pool!
294:M 02 Jun 2021 12:10:53.588 * Module 'ft' loaded from 
/usr/lib/redis/modules/redisearch.so

294:M 02 Jun 2021 12:10:53.588 * Ready to accept connections
^C294:signal-handler (1622635855) Received SIGINT scheduling shutdown...
294:M 02 Jun 2021 12:10:55.999 # User requested shutdown...
294:M 02 Jun 2021 12:10:55.999 # Redis is now ready to exit, bye bye...


Problem occurs with Debian bullseye and sid, it works fine on buster. I 
guess it's a change in Redis version 6.



Cheers,
Andreas

Bug#989274: Sway does not restore SIGPIPE

[Daniel Eklof]

Hi (author of foot here),

I happened to see this bug, and it caught my interest. What I found is this:

SIGPIPE is Sway's doing. It configures it to be ignored (by setting its signal 
handler to SIG_IGN). Now, normally signal dispositions are restored to their 
defaults after an exec(). The exception is ignored signals, which _do_ get 
inherited.

The combination of foot+bash is important too, because neither foot, nor bash 
restore signals they don't touch. In other words, SIGPIPE being ignored is 
inherited from Sway, through foot, through bash, and finally into dgit. Both 
zsh and fish appear to reset all signals, and are not affected.

Now, foot _could_ also restore all signals, just like zsh and fish. For the 
time being I think it's better not to do so, since it would just have hidden 
the bug in Sway.

There was also a bug in foot, where an ignored SIGHUP could "leak" into spawned 
processes.

I'll try to put together a patch for sway.

Bug#989384: acpi-call-dkms: new version of linux-call-dkms in https://github.com/nix-community/acpi_call

[Colin Ian King]

Package: acpi-call-dkms
Version: 1.1.0-6
Severity: important

Dear Maintainer,

the acpi-call project has been moved to a newer git repository that contains
more fixes and feature improvements.  I found a NULL pointer issue with the
current packaged version and found these have been fixed in the new upstream
supported git reposititory:

https://github.com/nix-community/acpi_call

Is it possible to use this repo as the main source repository for the packaged
version to pick up the new fixes and features?

here is an example of a bug that is fixed in the new upstream repo:

236 buf = (u8*) kmalloc(arg->buffer.length, GFP_KERNEL);
237 memcpy(buf, temporary_buffer, arg->buffer.length);

Regards,

Colin King

Bug#989383: unblock: remmina/1.4.11+dfsg-3

[Matteo F. Vescovi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package remmina

On May 27, fellow DD Michael Biebl filed #989163 reporting that RDP
support under Wayland was badly broken, while perfectly functional under
Xorg.

[ Reason ]
The management of the alpha channel on RDP rendering changed on FreeRDP
and it messed up the rendering of output in remmina.

[ Impact ]
Mainly, unusable desktop remote sessions since the output is so blurry
that it becomes hard to manage anything.

[ Tests ]
Upstream developers and Michael as well provided extensive tests on the
patched revision and it works just fine.

[ Risks ]
The change is trivial (see debdiff for it) and touches only a file in
the code.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock remmina/1.4.11+dfsg-3

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A

diff -Nru remmina-1.4.11+dfsg/debian/changelog remmina-1.4.11+dfsg/debian/changelog
--- remmina-1.4.11+dfsg/debian/changelog	2021-02-10 22:46:17.0 +0100
+++ remmina-1.4.11+dfsg/debian/changelog	2021-06-01 20:40:12.0 +0200
@@ -1,3 +1,10 @@
+remmina (1.4.11+dfsg-3) unstable; urgency=medium
+
+  * debian/patches/: patchset updated (Closes: #989163)
+- 0002-Fix_alpha_channel_issue.patch added
+
+ -- Matteo F. Vescovi   Tue, 01 Jun 2021 20:40:12 +0200
+
 remmina (1.4.11+dfsg-2) unstable; urgency=medium
 
   * debian/patches/: patchset updated
diff -Nru remmina-1.4.11+dfsg/debian/patches/0002-Fix_alpha_channel_issue.patch remmina-1.4.11+dfsg/debian/patches/0002-Fix_alpha_channel_issue.patch
--- remmina-1.4.11+dfsg/debian/patches/0002-Fix_alpha_channel_issue.patch	1970-01-01 01:00:00.0 +0100
+++ remmina-1.4.11+dfsg/debian/patches/0002-Fix_alpha_channel_issue.patch	2021-06-01 20:30:53.0 +0200
@@ -0,0 +1,22 @@
+From: "Matteo F. Vescovi" 
+Date: Tue, 1 Jun 2021 20:30:08 +0200
+Subject: Fix_alpha_channel_issue
+
+Closes: #989163
+---
+ plugins/rdp/rdp_plugin.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plugins/rdp/rdp_plugin.c b/plugins/rdp/rdp_plugin.c
+index ca937ad..dfad02b 100644
+--- a/plugins/rdp/rdp_plugin.c
 b/plugins/rdp/rdp_plugin.c
+@@ -602,7 +602,7 @@ static BOOL remmina_rdp_post_connect(freerdp *instance)
+ 
+ 	if (rfi->bpp == 32) {
+ 		freerdp_local_color_format = PIXEL_FORMAT_BGRA32;
+-		rfi->cairo_format = CAIRO_FORMAT_ARGB32;
++		rfi->cairo_format = CAIRO_FORMAT_RGB24;
+ 	} else if (rfi->bpp == 24) {
+ 		/* CAIRO_FORMAT_RGB24 is 32bit aligned, so we map it to libfreerdp’s PIXEL_FORMAT_BGRX32 */
+ 		freerdp_local_color_format = PIXEL_FORMAT_BGRX32;
diff -Nru remmina-1.4.11+dfsg/debian/patches/series remmina-1.4.11+dfsg/debian/patches/series
--- remmina-1.4.11+dfsg/debian/patches/series	2021-02-10 22:44:05.0 +0100
+++ remmina-1.4.11+dfsg/debian/patches/series	2021-06-01 20:30:53.0 +0200
@@ -1 +1,2 @@
 0001-Revert-rdp-event-Fix-wheel-value-for-GDK_SCROLL_DOWN.patch
+0002-Fix_alpha_channel_issue.patch


signature.asc
Description: PGP signature

Bug#963987: buster-pu: package libtool/2.4.6-9

[Wang Shanker]

Hi, all

I meet the same problem when building the latest qemu package 
on buster. The output of the failed build log is :

```
.
powerpc64-linux-gnu-ar cru libfs.a  xxx.o xxx.o (a lot of .o's omitted); 
powerpc64-linux-gnu-ranlib libfs.a
powerpc64-linux-gnu-ar: `u' modifier ignored since `D' is the default (see `U')
cc1: all warnings being treated as errors
make[1]: *** [rules.mak:233: target/drivers/usbohci.o] Error 1
make[1]: *** Waiting for unfinished jobs
```

It seems that the problem is related to the option `cru` to ar
at first look. However, it's not the case. Rhe cause of the 
build failure is actually in usbohci.c: 

```
/home//qemu/qemu/qemu-6.0+dfsg/roms/openbios/drivers/usbohci.c:46:32: 
error: unknown option after '#pragma GCC diagnostic' kind [-Werror=pragmas]
 #pragma GCC diagnostic warning "-Waddress-of-packed-member"
^~~~
```

That's because the option `-Waddress-of-packed-member` is introduced
in gcc 9, and we only have gcc 8 on buster.

I'm posting this information here, in case anyone should reach this
bug report via search engine.

Cheers,

Miao Wang

Bug#989382: bareos-director: Broken link in auth error message from director

[James Youngman]

Package: bareos-director
Version: 16.2.6-5
Severity: minor
Tags: upstream

Here's an example error message from a failed job:

02-Jun 09:03 bareos-dir JobId 15: Fatal error: Authorization key
rejected by File Daemon terminator-fd.
Please see
http://doc.bareos.org/master/html/bareos-manual-main-reference.html#AuthorizationErrors
for help.


There are other similar error messages too:

02-Jun 09:03 bareos-dir JobId 15: Fatal error: Unable to authenticate
with File daemon at "terminator.spiral-arm.org:9102". Possible causes:
Passwords or names not the same or
TLS negotiation failed or
Maximum Concurrent Jobs exceeded on the FD or
FD networking messed up (restart daemon).
Please see
http://doc.bareos.org/master/html/bareos-manual-main-reference.html#AuthorizationErrors
for help.
02-Jun 09:03 bareos-dir JobId 15: Error: getmsg.c:212 Malformed
message: Authorization key rejected by Director bareos-dir.
Please see
http://doc.bareos.org/master/html/bareos-manual-main-reference.html#AuthorizationErrors
for help.


The problem is that there is no #AuthorizationErrors anchor on the
specified page, so the link to the help information doesn't work.

Additionally, the Bareos web page does feature versioned documentation
(for example, https://docs.bareos.org/bareos-19.2/index.html) but the
error messages don't include the version number.   Hence released
versions  of the software will have their links broken as the
documentation is updated.

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bareos-director depends on:
ii  adduser 3.118
ii  bareos-common   16.2.6-5
ii  bareos-database-common  16.2.6-5
ii  bareos-database-tools   16.2.6-5
ii  bsd-mailx [mailx]   8.1.2-0.20180807cvs-1
ii  debconf [debconf-2.0]   1.5.71
ii  libacl1 2.2.53-4
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4+deb10u6
ii  libjansson4 2.12-1
ii  liblzo2-2   2.10-0.1
ii  libstdc++6  8.3.0-6
ii  libwrap07.6.q-28
ii  lsb-base10.2019051400
ii  lsof4.91+dfsg-1
ii  mailutils [mailx]   1:3.5-4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages bareos-director recommends:
ii  logrotate  3.14.0-4

bareos-director suggests no packages.

-- no debconf information

Bug#989355: transition: tinyxml2

[Sebastian Ramacher]

On 2021-06-02 02:45:56, Chow Loong Jin wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> There's been an ABI break without an upstream soname bump in
> libtinyxml2-8, between upstream versions 8.0.0 and 8.1.0, see [1] and
> [2]. To remedy this, I have uploaded version 8.1.0+dfsg-2 to
> experimental with the library package renamed from libtinyxml2-8 to
> libtinyxml2-8a. It is waiting in the NEW queue now.

Please revert tinyxml2 in unstable to the state of 8.0.0+dfsg-2 to
avoid uploads of reverse dependencies that are targetted for bullseye to
be built against the broken version.

Cheers

> 
> The following packages are impacted, and I have successfully rebuilt all
> of them locally without sourceful changes, so binNMUs are all that are
> necessary for this transition.
> 
>  - basilisk2
>  - bullet
>  - caveexpress
>  - cppcheck
>  - dart
>  - encfs
>  - fastdds
>  - gazebo
>  - ignition-common
>  - ignition-fuel-tools
>  - ignition-msgs
>  - kodi-pvr-dvblink
>  - kodi-pvr-nextpvr
>  - kodi-pvr-vbox
>  - kodi-pvr-zattoo
>  - lgogdownloader
>  - libexadrums
>  - libmediainfo
>  - mrpt
>  - ros-image-pipeline
>  - ros-kdl-parser
>  - ros-pluginlib
>  - ros-ros
>  - ros-rospack
>  - ros-urdf
>  - sdpb
>  - trigger-rally
> 
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988986
> [2] https://github.com/leethomason/tinyxml2/issues/867
> 
> Ben file:
> 
> title = "tinyxml2";
> is_affected = .depends ~ "libtinyxml2-8" | .depends ~ "libtinyxml2-8a";
> is_good = .depends ~ "libtinyxml2-8a";
> is_bad = .depends ~ "libtinyxml2-8";
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers groovy-updates
>   APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500, 
> 'groovy'), (400, 'groovy-proposed'), (100, 'groovy-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.12.1-hyper1 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_SG.utf8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_SG:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



-- 
Sebastian Ramacher

Bug#989381: lintian: spelling-error-in-copyright is triggering on names

[Gard Spreemann]

Package: lintian
Version: 2.104.0
Severity: normal
X-Debbugs-Cc: g...@nonempty.org

Dear Maintainer,

Lintian is triggering spelling-error-in-copyright upon seeing my first
name (Gard) in the copyright field of some packages (example: [1]). It
suggests that I should be named Guard instead. A bug filed with my
parents was closed with wontfix, so I'll try the second best thing.

I do not know how one would go about exempting names from such
spellchecks, but could one perhaps at least whitelist the known
quantity that is the maintainer's name?

The bug seems at least superficially similar to #922233.


[1] https://lintian.debian.org/sources/python-cdsapi

 Best,
 Gard


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian depends on:
ii  binutils2.35.2-2
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.39
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.26-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-2
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012001-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.22-3
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.1-4
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

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

-- no debconf information

Bug#989287: libcivetweb1: build with websockets support

[Andreas Tille]

On Wed, Jun 02, 2021 at 09:44:27AM +0100, Claude Heiland-Allen wrote:
> I could not get debdiff to work for me (I couldn't figure out how to create
> a new .dsc file, I'm very out of practice with Debian packaging), so I
> attach a regular diff between two directories.  I hope it's not too
> inconvenient.

Regular diff is perfectly fine (=basically the same).
Thanks a lot, Andreas.
 

> diff -ruw civetweb-1.13+dfsg.old/debian/changelog 
> civetweb-1.13+dfsg.new/debian/changelog
> --- civetweb-1.13+dfsg.old/debian/changelog   2021-01-21 14:30:38.0 
> +
> +++ civetweb-1.13+dfsg.new/debian/changelog   2021-06-02 09:34:33.738622818 
> +0100
> @@ -1,3 +1,10 @@
> +civetweb (1.13+dfsg-5.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Enable websockets support.
> +
> + -- Claude Heiland-Allen   Wed, 02 Jun 2021 09:34:18 
> +0100
> +
>  civetweb (1.13+dfsg-5) unstable; urgency=medium
>  
>* Team Upload.
> diff -ruw civetweb-1.13+dfsg.old/debian/libcivetweb1.symbols 
> civetweb-1.13+dfsg.new/debian/libcivetweb1.symbols
> --- civetweb-1.13+dfsg.old/debian/libcivetweb1.symbols2021-01-21 
> 14:14:50.0 +
> +++ civetweb-1.13+dfsg.new/debian/libcivetweb1.symbols2021-06-02 
> 09:32:55.214672544 +0100
> @@ -144,4 +144,6 @@
>   mg_url_decode@Base 1
>   mg_url_encode@Base 1
>   mg_version@Base 1
> + mg_websocket_client_write@Base 1.13+dfsg-5
> + mg_websocket_write@Base 1.13+dfsg-5
>   mg_write@Base 1
> diff -ruw civetweb-1.13+dfsg.old/debian/rules 
> civetweb-1.13+dfsg.new/debian/rules
> --- civetweb-1.13+dfsg.old/debian/rules   2021-01-21 14:29:18.0 
> +
> +++ civetweb-1.13+dfsg.new/debian/rules   2021-06-02 09:31:08.019109852 
> +0100
> @@ -12,6 +12,7 @@
>  -DCIVETWEB_BUILD_TESTING=OFF \
>  -DCIVETWEB_SOVERSION=1 \
>   -DCIVETWEB_ENABLE_CXX=ON \
> + -DCIVETWEB_ENABLE_WEBSOCKETS=ON \
>  -DBUILD_SHARED_LIBS=ON
>  
>  %:


-- 
http://fam-tille.de

Bug#988442: unblock: linux/5.10.40-1

[Cyril Brulebois]

Hi,

Paul Gevers  (2021-06-01):
> On 01-06-2021 08:06, Salvatore Bonaccorso wrote:
> > The version is not 4 days in unstable, looks good to me to let it
> > migrate to testing (unless Cyril spotted issues in recent d-i tests).
> 
> I'm still good to go.

Tests look good, please let it migrate. :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#989380: unblock: golang-1.15/1.15.9-4

[Shengjing Zhu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: z...@debian.org

Please unblock package golang-1.15

[ Reason ]
Backport patch for CVE-2021-33196

[ Impact ]
Security issue

[ Tests ]
Upstream has its own unit tests, and a new test is added in patch as
well.

[ Risks ]
+ Key package
+ Diff is small

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]

unblock golang-1.15/1.15.9-4

diff -Nru golang-1.15-1.15.9/debian/changelog 
golang-1.15-1.15.9/debian/changelog
--- golang-1.15-1.15.9/debian/changelog 2021-05-08 14:22:26.0 +0800
+++ golang-1.15-1.15.9/debian/changelog 2021-06-02 10:56:03.0 +0800
@@ -1,3 +1,12 @@
+golang-1.15 (1.15.9-4) unstable; urgency=medium
+
+  * Team upload.
+  * Backport patch for CVE-2021-33196
+archive/zip: malformed archive may cause panic or memory exhaustion
+https://github.com/golang/go/issues/46396
+
+ -- Shengjing Zhu   Wed, 02 Jun 2021 10:56:03 +0800
+
 golang-1.15 (1.15.9-3) unstable; urgency=medium
 
   * Fix failed TestDependencyVersionsConsistent test.
diff -Nru golang-1.15-1.15.9/debian/patches/0008-CVE-2021-33196.patch 
golang-1.15-1.15.9/debian/patches/0008-CVE-2021-33196.patch
--- golang-1.15-1.15.9/debian/patches/0008-CVE-2021-33196.patch 1970-01-01 
08:00:00.0 +0800
+++ golang-1.15-1.15.9/debian/patches/0008-CVE-2021-33196.patch 2021-06-02 
10:56:03.0 +0800
@@ -0,0 +1,124 @@
+From: Roland Shoemaker 
+Date: Tue, 11 May 2021 11:31:31 -0700
+Subject: archive/zip: only preallocate File slice if reasonably sized
+
+Since the number of files in the EOCD record isn't validated, it isn't
+safe to preallocate Reader.Files using that field. A malformed archive
+can indicate it contains up to 1 << 128 - 1 files. We can still safely
+preallocate the slice by checking if the specified number of files in
+the archive is reasonable, given the size of the archive.
+
+Thanks to the OSS-Fuzz project for discovering this issue and to
+Emmanuel Odeke for reporting it.
+
+Updates #46242
+Fixes #46396
+Fixes CVE-2021-33196
+
+Change-Id: I3c76d8eec178468b380d87fdb4a3f2cb06f0ee76
+Reviewed-on: https://go-review.googlesource.com/c/go/+/318909
+Trust: Roland Shoemaker 
+Trust: Katie Hockman 
+Trust: Joe Tsai 
+Run-TryBot: Roland Shoemaker 
+TryBot-Result: Go Bot 
+Reviewed-by: Katie Hockman 
+Reviewed-by: Joe Tsai 
+(cherry picked from commit 74242baa4136c7a9132a8ccd9881354442788c8c)
+Reviewed-on: https://go-review.googlesource.com/c/go/+/322949
+Reviewed-by: Filippo Valsorda 
+
+Origin: backport, 
https://github.com/golang/go/commit/c92adf420a3d9a5510f9aea382d826f0c9216a10
+---
+ src/archive/zip/reader.go  | 10 ++-
+ src/archive/zip/reader_test.go | 59 ++
+ 2 files changed, 68 insertions(+), 1 deletion(-)
+
+diff --git a/src/archive/zip/reader.go b/src/archive/zip/reader.go
+index 13ff9dd..2d5151a 100644
+--- a/src/archive/zip/reader.go
 b/src/archive/zip/reader.go
+@@ -84,7 +84,15 @@ func (z *Reader) init(r io.ReaderAt, size int64) error {
+   return err
+   }
+   z.r = r
+-  z.File = make([]*File, 0, end.directoryRecords)
++  // Since the number of directory records is not validated, it is not
++  // safe to preallocate z.File without first checking that the specified
++  // number of files is reasonable, since a malformed archive may
++  // indicate it contains up to 1 << 128 - 1 files. Since each file has a
++  // header which will be _at least_ 30 bytes we can safely preallocate
++  // if (data size / 30) >= end.directoryRecords.
++  if (uint64(size)-end.directorySize)/30 >= end.directoryRecords {
++  z.File = make([]*File, 0, end.directoryRecords)
++  }
+   z.Comment = end.comment
+   rs := io.NewSectionReader(r, 0, size)
+   if _, err = rs.Seek(int64(end.directoryOffset), io.SeekStart); err != 
nil {
+diff --git a/src/archive/zip/reader_test.go b/src/archive/zip/reader_test.go
+index adca87a..6f67d2e 100644
+--- a/src/archive/zip/reader_test.go
 b/src/archive/zip/reader_test.go
+@@ -1070,3 +1070,62 @@ func TestIssue12449(t *testing.T) {
+   t.Errorf("Error reading the archive: %v", err)
+   }
+ }
++
++func TestCVE202133196(t *testing.T) {
++  // Archive that indicates it has 1 << 128 -1 files,
++  // this would previously cause a panic due to attempting
++  // to allocate a slice with 1 << 128 -1 elements.
++  data := []byte{
++  0x50, 0x4b, 0x03, 0x04, 0x14, 0x00, 0x08, 0x08,
++  0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
++  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
++  0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x01, 0x02,
++  0x03, 0x62, 0x61, 0x65, 0x03, 0x04, 0x00, 0x00,
++  0xff, 0xff, 0x50, 

Bug#989287: libcivetweb1: build with websockets support

[Claude Heiland-Allen]

Hi Andreas,

On 02/06/2021 07:16, Andreas Tille wrote:

Hi Claude,

On Mon, May 31, 2021 at 09:51:33AM +0100, Claude Heiland-Allen wrote:

I managed to rebuild the package locally with websockets support by adding
-DCIVETWEB_ENABLE_WEBSOCKETS=ON to CMAKE_EXTRA_FLAGS in debian/rules, adding
extra lines to debian/libcivetweb1.symbols like
  mg_websocket_client_write@Base 1.13+dfsg-5
  mg_websocket_write@Base 1.13+dfsg-5

Thank you for the bug report.  It seems to be easy to accomplish.
However, due to the current freeze policy we can not upload to unstable
and thus I prefer to leave this bug open until after the freeze.

Sure that's perfectly fine for me.

It would be great if you could meanwhile post a complete patch (by
for instance using debdiff) to save us the work to do what you just
have done.
I could not get debdiff to work for me (I couldn't figure out how to 
create a new .dsc file, I'm very out of practice with Debian packaging), 
so I attach a regular diff between two directories.  I hope it's not too 
inconvenient.


Thanks,


Claude

diff -ruw civetweb-1.13+dfsg.old/debian/changelog civetweb-1.13+dfsg.new/debian/changelog
--- civetweb-1.13+dfsg.old/debian/changelog	2021-01-21 14:30:38.0 +
+++ civetweb-1.13+dfsg.new/debian/changelog	2021-06-02 09:34:33.738622818 +0100
@@ -1,3 +1,10 @@
+civetweb (1.13+dfsg-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Enable websockets support.
+
+ -- Claude Heiland-Allen   Wed, 02 Jun 2021 09:34:18 +0100
+
 civetweb (1.13+dfsg-5) unstable; urgency=medium
 
   * Team Upload.
diff -ruw civetweb-1.13+dfsg.old/debian/libcivetweb1.symbols civetweb-1.13+dfsg.new/debian/libcivetweb1.symbols
--- civetweb-1.13+dfsg.old/debian/libcivetweb1.symbols	2021-01-21 14:14:50.0 +
+++ civetweb-1.13+dfsg.new/debian/libcivetweb1.symbols	2021-06-02 09:32:55.214672544 +0100
@@ -144,4 +144,6 @@
  mg_url_decode@Base 1
  mg_url_encode@Base 1
  mg_version@Base 1
+ mg_websocket_client_write@Base 1.13+dfsg-5
+ mg_websocket_write@Base 1.13+dfsg-5
  mg_write@Base 1
diff -ruw civetweb-1.13+dfsg.old/debian/rules civetweb-1.13+dfsg.new/debian/rules
--- civetweb-1.13+dfsg.old/debian/rules	2021-01-21 14:29:18.0 +
+++ civetweb-1.13+dfsg.new/debian/rules	2021-06-02 09:31:08.019109852 +0100
@@ -12,6 +12,7 @@
 -DCIVETWEB_BUILD_TESTING=OFF \
 -DCIVETWEB_SOVERSION=1 \
 	-DCIVETWEB_ENABLE_CXX=ON \
+	-DCIVETWEB_ENABLE_WEBSOCKETS=ON \
 -DBUILD_SHARED_LIBS=ON
 
 %:

Bug#989324: unblock: opendmarc/1.4.0~beta1+dfsg-4

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-06-01 10:34:59, David Bürgin wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package opendmarc
> 
> Fixes for three CVEs have recently been released by the OpenDMARC
> developers. The fixes themselves are spread over more than a dozen
> commits, so I referred to the final code from upstream version 1.4.1.1.
> Detailed description of the CVEs and their resolution can be found at:
> https://github.com/trusteddomainproject/OpenDMARC/tree/rel-opendmarc-1-4-1-1/SECURITY
> 
> [ Reason ]
> Fixes for several CVEs have been released in OpenDMARC 1.4.1.1.
> 
> [ Impact ]
> Current opendmarc 1.4.0~beta1+dfsg-3 contains vulnerabilities that need
> patching.
> 
> [ Tests ]
> Version 1.4.0~beta1+dfsg-4 is running ‘in production’ (on my small
> personal mail server), rudimentary manual testing.
> 
> [ Risks ]
> The patches are not small but relatively self-contained and easy to
> read.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> unblock opendmarc/1.4.0~beta1+dfsg-4

> diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/changelog 
> opendmarc-1.4.0~beta1+dfsg/debian/changelog
> --- opendmarc-1.4.0~beta1+dfsg/debian/changelog   2020-09-19 
> 08:40:47.0 +0200
> +++ opendmarc-1.4.0~beta1+dfsg/debian/changelog   2021-05-29 
> 16:22:50.0 +0200
> @@ -1,3 +1,12 @@
> +opendmarc (1.4.0~beta1+dfsg-4) unstable; urgency=high
> +
> +  * Backport patches from upstream version 1.4.1.1 (Closes: #977766, 
> #977767):
> +- CVE-2019-16378: Fix handling of multi-valued From headers
> +- CVE-2019-20790: Validate incoming SPF headers
> +- CVE-2020-12272: Check DKIM and SPF domain syntax
> +
> + -- David Bürgin   Sat, 29 May 2021 16:22:50 +0200
> +
>  opendmarc (1.4.0~beta1+dfsg-3) unstable; urgency=high
>  
>* Cherry-pick patch for CVE-2020-12460 from upstream:
> diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/libopendmarc2.symbols 
> opendmarc-1.4.0~beta1+dfsg/debian/libopendmarc2.symbols
> --- opendmarc-1.4.0~beta1+dfsg/debian/libopendmarc2.symbols   2020-06-16 
> 20:41:13.0 +0200
> +++ opendmarc-1.4.0~beta1+dfsg/debian/libopendmarc2.symbols   2021-05-29 
> 15:03:47.0 +0200
> @@ -1,5 +1,6 @@
>  libopendmarc.so.2 libopendmarc2 #MINVER#
>  * Build-Depends-Package: libopendmarc-dev
> + check_domain@Base 1.4.0~beta1+dfsg

If check_domain is really supposed to be part of the public ABI, then
this should by versioned as 1.4.0~beta1+dfsg-4~ as it is introduced in a
patch. Since check_domain is an overly generic name and it is not
exposed in any header, I suspect that it is not intended to be public.
In that case, sticking a static to the definition of check_domain will
remove the symbol from the public ABI. It's only used inside
libopendmarc/opendmarc_policy.c anyway.

Please remove it from the public ABI or fix the version in the symbols
file.

Cheers

>   dmarc_dns_get_record@Base 1.1.0~beta2
>   dmarc_strlcat@Base 1.1.0~beta2
>   dmarc_strlcpy@Base 1.1.0~beta2
> diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2019-16378.patch 
> opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2019-16378.patch
> --- opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2019-16378.patch
> 1970-01-01 01:00:00.0 +0100
> +++ opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2019-16378.patch
> 2021-05-29 16:22:50.0 +0200
> @@ -0,0 +1,321 @@
> +Description: CVE-2019-16378: Handle multi-valued From header, add 
> RejectMultiValueFrom parameter
> +Author: Murray S. Kucherawy 
> +Origin: backport, 
> https://github.com/trusteddomainproject/OpenDMARC/releases/tag/rel-opendmarc-1-4-1-1
> +
> +--- a/opendmarc/parse.c
>  b/opendmarc/parse.c
> +@@ -12,10 +12,18 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + 
> + /* opendmarc includes */
> + #include "util.h"
> + 
> ++#ifndef FALSE
> ++# define FALSE  0
> ++#endif /* ! FALSE */
> ++#ifndef TRUE
> ++# define TRUE   1
> ++#endif /* ! TRUE */
> ++
> + /* types */
> + typedef unsigned long cmap_elem_type;
> + 
> +@@ -24,6 +32,7 @@
> + #define MAILPARSE_ERR_PUNBALANCED   1   /* unbalanced parentheses */
> + #define MAILPARSE_ERR_QUNBALANCED   2   /* unbalanced quotes */
> + #define MAILPARSE_ERR_SUNBALANCED   3   /* unbalanced sq. brackets */
> ++#define MAILPARSE_ERR_MULTIVALUE4   /* multiple possible values */
> + 
> + /* a bitmap for the "specials" character class */
> + #define CMAP_NBITS  (sizeof(cmap_elem_type) * CHAR_BIT)
> +@@ -466,6 +475,160 @@
> + }
> + }
> + 
> ++/*
> ++**  DMARCF_MAIL_PARSE_MULTI -- extract the local-part and hostname from a 
> mail
> ++** header field that might contain multiple
> ++** values, e.g. "To:", "Cc:"
> ++**
> ++**  Parameters:
> ++**  

Bug#989163: Acknowledgement (RDP broken under Wayland)

[Michael Biebl]

Hi Matteo

Am 01.06.21 um 15:55 schrieb Matteo F. Vescovi:
Actually, upstream already provided me a patch to fix the issue but I'm 
lacking time these days to prepare a revision with the fix.


I can confirm that 1.4.11+dfsg-3 fixes the issue. Thanks!

I'll try to upload a fixed source package tonight and file an unblock 
bug report, eventually.


That would be great!

Regards,
Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989379: unblock: redis/5:6.0.14-1

[Chris Lamb]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Dear Release Team,

Please consider unblocking redis 5:6.0.14-1 in order to a) incorporate
a number of security issues, and b) to harmonise with the upstream's
stable branch. This latter change will greatly help the maintenance of
this package over the lifetime of bullseye.

'b' does involve incorporating a "New upstream release." (5:6.0.12-1).
However, this is actually a release containing a single bugfix related
to the build system.

  redis (5:6.0.14-1) unstable; urgency=medium

* CVE-2021-32625: Fix a vulnerability in the STRALGO LCS command.
  (Closes: #989351)

  redis (5:6.0.14-1) unstable; urgency=medium

* CVE-2021-32625: Fix a vulnerability in the STRALGO LCS command.
  (Closes: #989351)

   -- Chris Lamb   Tue, 01 Jun 2021 17:35:19 +0100

  redis (5:6.0.13-1) unstable; urgency=medium

* New upstream security release:
  - CVE-2021-29477: Vulnerability in the STRALGO LCS command.
  - CVE-2021-29478: Vulnerability in the COPY command for large intsets.
  (Closes: #988045)
* Refresh patches.

   -- Chris Lamb   Tue, 04 May 2021 11:06:14 +0100

  redis (5:6.0.12-1) unstable; urgency=medium

* New upstream release.

   -- Chris Lamb   Sat, 06 Mar 2021 11:03:47 +


The full debdiff is attached.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

debdiff
Description: Binary data

Bug#989378: Avoid leases to be issued forever when not set

[Christian Ehrhardt]

Package: dnsmasq
Version: 2.85-1

Hi,

This isn't a new topic at all, but I wonder what else I could do to raise
awareness.

It was initially submitted and discussed:
 https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014341.html
I pinged about the case whenever I touched dnsmasq in Ubuntu:
 https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014387.html
 https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014639.html

The discussion was abit back and forth but I thought that eventually the
change suggested by Dominik dl6er at dl6er.de seemed to be simple and working.
Since then Ubuntu carries this as:

diff --git a/src/radv.c b/src/radv.c
index 3255904b..d10f2b6b 100644
--- a/src/radv.c
+++ b/src/radv.c
@@ -628,8 +628,9 @@ static int add_prefixes(struct in6_addr *local,  int prefix,

  /* find floor time, don't reduce below 3 * RA interval.
 If the lease time has been left as default, don't
-use that as a floor. */
- if ((context->flags & CONTEXT_SETLEASE) &&
+use that as a floor.
+Always set lease time if requested to do so. */
+ if ((context->flags & CONTEXT_SETLEASE) ||
  time > context->lease_time)
{
  time = context->lease_time;

Any chance to apply that upstream and/or in Debian?
Or did I miss a part of the dsicussion that identified this as being wrong?

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@gmail.com

I came accross these 2 threads on r/debian and I am now thinking that my
problem too may not be related to debian packaging/patching/configuration but
to some upstream flaw(s) of 5.10.
The guy in the second thread has done some very extensive testing that prove
it.

https://old.reddit.com/r/debian/comments/npvzyt/intel_nuc_8_freezing_when_idle_on_most_kernels/
https://old.reddit.com/r/debian/comments/mrxx76/irritating_problem_with_the_bullseyes_kernel/

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'),
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash

Bug#989344: rviz: error while loading shared libraries: libOgreOverlay.so.1.12.5: cannot open shared object file: No such file or directory

[Leopold Palomo-Avellaneda]

Hi Jochen!


first, thanks for the test. I was guessing but I do no pretend that you did it. 
In any case, it is great that you have done it because now, we have real 
information.


OTOH I like very much your summary. I take it as a reference for the future.

Thanks for all,

Cheers,

Leo


--
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Bug#989193: [pkg-apparmor] Bug#989193: breaks apt-cacher-ng by blocking link operation

[intrigeri]

Control: tag -1 + upstream
Control: forwarded -1 
https://gitlab.com/apparmor/apparmor-profiles/-/merge_requests/51
Control: tag -1 + moreinfo

Hi,

Eduard Bloch (2021-05-28):
> see attachment, your config which doesn't allow link calls, which
> sporadically breaks operation of apt-cacher-ng in unexpected ways.

Thanks! I've turned this patch into an upstream merge request.

I see you've made this bug RC. I'd like to better understand the
severity, so I can figure out what I should do for Bullseye.
I'm wondering because I'm using this AppArmor policy on sid with
apt-cacher-ng myself, and I can't find traces of such denials in
my logs.

Could you please help me understand what kind of apt-cacher-ng
operations (or configuration) trigger these denials and are broken by
the current AppArmor policy?

Thanks in advance,
cheers!
-- 
intrigeri

Bug#989344: rviz: error while loading shared libraries: libOgreOverlay.so.1.12.5: cannot open shared object file: No such file or directory

[Jochen Sprickerhof]

Hi Leo,

* Leopold Palomo-Avellaneda  [2021-06-02 08:43]:
It's strange and I think that it's more a misunderstanding from 
upstream than a packaging name error.


I agree with Jochen that for Bullseye with just a binNMU should be 
enough. However, I would like to know if it's binary incompatible 
1.12.5 and 1.12.10. Because, if the are compatible, maybe with just 
patch Ogre to have soversion with major.minor instead complete version 
should be more appropriated.


For that the ABI would need to be the same, let's test:

$ sudo apt install abigail-tools wget

$ wget 
http://snapshot.debian.org/archive/debian/20201120T031928Z/pool/main/o/ogre-1.12/libogre-1.12_1.12.5%2Bdfsg1-1%2Bb1_amd64.deb
$ wget 
http://snapshot.debian.org/archive/debian-debug/20201120T030320Z/pool/main/o/ogre-1.12/libogre-1.12-dbgsym_1.12.5%2Bdfsg1-1%2Bb1_amd64.deb
$ wget 
http://snapshot.debian.org/archive/debian/20200419T033910Z/pool/main/o/ogre-1.12/libogre-1.12-dev_1.12.5%2Bdfsg1-1_amd64.deb
$ wget 
https://deb.debian.org/debian/pool/main/o/ogre-1.12/libogre-1.12_1.12.10+dfsg2-1_amd64.deb
$ wget 
https://deb.debian.org/debian-debug/pool/main/o/ogre-1.12/libogre-1.12-dbgsym_1.12.10+dfsg2-1_arm64.deb
$ wget 
https://deb.debian.org/debian/pool/main/o/ogre-1.12/libogre-1.12-dev_1.12.10+dfsg2-1_amd64.deb

$ dpkg-deb -x libogre-1.12_1.12.5+dfsg1-1+b1_amd64.deb 5
$ dpkg-deb -x libogre-1.12-dbgsym_1.12.5+dfsg1-1+b1_amd64.deb 5
$ dpkg-deb -x libogre-1.12-dev_1.12.5+dfsg1-1_amd64.deb 5
$ dpkg-deb -x libogre-1.12_1.12.10+dfsg2-1_amd64.deb 10
$ dpkg-deb -x libogre-1.12-dbgsym_1.12.10+dfsg2-1_arm64.deb 10
$ dpkg-deb -x libogre-1.12-dev_1.12.10+dfsg2-1_amd64.deb 10

$ abidiff --stat --debug-info-dir1 5/usr/lib/debug/ --debug-info-dir2 
10/usr/lib/debug/ --headers-dir1 5/usr/include/OGRE/ --headers-dir2 
10/usr/include/OGRE/ 5/usr/lib/x86_64-linux-gnu/libOgreMain.so.1.12.5 
10/usr/lib/x86_64-linux-gnu/libOgreMain.so.1.12.10
ELF SONAME changed
Functions changes summary: 214 Removed (5 filtered out), 0 Changed, 0 Added 
functions
Variables changes summary: 3 Removed, 0 Changed, 0 Added variables
Function symbols changes summary: 1 Removed, 170 Added function symbols not 
referenced by debug info
Variable symbols changes summary: 11 Removed, 40 Added variable symbols not 
referenced by debug info

(we can't use abipkgdiff due to the Soname bump.)

So yes, the Soname bump was correct and we should not patch Ogre.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#989362: closed by Gilles Filippini (Re: Bug#989362: navit: Multiple security issues in ezxml)

[Moritz Muehlenhoff]

On Tue, Jun 01, 2021 at 09:51:05PM +, Debian Bug Tracking System wrote:
> The ezxml support module is not built for any of our architectures. Here is
> the related build log excerpt:

Ack, I've updated the meta data on the embedded code copy in the Debian
Security Tracker.

Cheers,
Moritz

Bug#989377: chromium: keymap changes with xmodmap after chromium launches cause problems

[Jason Woofenden]

Package: chromium
Version: 90.0.4430.212-1
Severity: normal

Dear Maintainer,

Thanks for all your work on packaging chromium, I imagine that this
is a big job!

My keyboard lacks an AltGr key, so I use xmodmap to turn my useless
Menu key into an AltGr like so:

setxkbmap dvorak
xmodmap -e 'keycode 135 = Mode_switch' \
-e 'remove mod5 = Mode_switch'
xmodmap -e 'add mod3 = Mode_switch'

I have a script containing the above lines, though sometimes it's
"us" instead of "dvorak".

This worked well for about 5 years.

I'm not sure if it's the setxkbmap or the xmodmap, but when I run
that script _after_ chromium starts, then chromium starts ignoring
my keybinding for the menu key, and I can no longer type accented
characters, because I get a weird menu instead.

If I close chromium and open it up again, it's fixed (I can again
use that key as Mode_switch) until next time I switch to qwerty and
back (and run those xmodmap commands.)

When chromium is bugging, other programs are functioning correctly,
eg I can still type my accented characters with my menu key
remapped to alt-gr in other programs (I tested lowriter, st, atril,
and filezilla).

Thanks!

  - Jason


-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common 90.0.4430.212-1
ii  libasound2  1.2.4-1.1
ii  libatk-bridge2.0-0  2.38.0-1
ii  libatk1.0-0 2.36.0-2
ii  libatomic1  10.2.1-6
ii  libatspi2.0-0   2.38.0-4
ii  libavcodec587:4.3.2-0+deb11u1
ii  libavformat58   7:4.3.2-0+deb11u1
ii  libavutil56 7:4.3.2-0+deb11u1
ii  libc6   2.31-12
ii  libcairo2   1.16.0-5
ii  libcups22.3.3op2-3+deb11u1
ii  libdbus-1-3 1.12.20-2
ii  libdrm2 2.4.104-1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libexpat1   2.2.10-2
ii  libflac81.3.3-2
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libgbm1 20.3.5-1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libgtk-3-0  3.24.24-4
ii  libharfbuzz0b   2.7.4-1
ii  libicu6767.1-6
ii  libjpeg62-turbo 1:2.0.6-4
ii  libjsoncpp241.9.4-4
ii  liblcms2-2  2.12~rc1-2
ii  libminizip1 1.1-8+b1
ii  libnspr42:4.29-1
ii  libnss3 2:3.63-1
ii  libopenjp2-72.4.0-3
ii  libopus01.3.1-0.1
ii  libpango-1.0-0  1.46.2-3
ii  libpng16-16 1.6.37-3
ii  libpulse0   14.2-2
ii  libre2-920210201+dfsg-1
ii  libsnappy1v51.1.8-1
ii  libstdc++6  10.2.1-6
ii  libvpx6 1.9.0-1
ii  libwebp60.6.1-2+b1
ii  libwebpdemux2   0.6.1-2+b1
ii  libwebpmux3 0.6.1-2+b1
ii  libx11-62:1.7.1-1
ii  libxcb1 1.14-3
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.3-1.1
ii  libxfixes3  1:5.0.3-2
ii  libxml2 2.9.10+dfsg-6.7
ii  libxrandr2  2:1.5.1-1
ii  libxshmfence1   1.3-1
ii  libxslt1.1  1.1.34-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  90.0.4430.212-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6   2.31-12
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.1-1
ii  libxext62:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4.1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox 90.0.4430.212-1
ii  dunst [notification-daemon]  1.5.0-1
ii  fonts-liberation 1:1.07.4-11
ii  libgl1-mesa-dri  20.3.5-1
pn  libu2f-udev  
ii  system-config-printer1.5.14-1
ii  upower   0.99.11-2

Versions of packages chromium-sandbox depends on:
ii  libc6  2.31-12

-- no debconf information

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Rick Thomas]

On Tue, Jun 1, 2021, at 11:06 PM, Vagrant Cascadian wrote:
> On 2021-06-01, Rick Thomas wrote:
> > Is there any estimate of when the assumed fix (linux/5.10.40-1) will
> > show up in the installer at [1] ?  I'd love to test it!
> ...
> > [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
> 
> It should already be there kernel version 5.10.38-1 had it, 5.10.40-1
> should also have it.
> 
> I only tested it outside of debian-installer (e.g. upgrading kernel on
> an already installed system), so it is also possible that more modules
> are needed in one of the kernel udebs used by the installer, or that
> you're experiencing a different issue from the one that was fixed. I'll
> try to test debian-installer on Cubox-i4pro to see if I still have an
> issue.

Hmmm... Here's a log from the serial console while trying to use the above card 
image.  Best way to read it is with "less -r".
It does appear that the 5.10.40-1 kernel is being used by the installer.  But 
it still has the problem... 

Hope it helps!
Let me know if there's anything else I can provide that might help!

Rick


screenlog
Description: Binary data

Bug#989376: unblock: glusterfs/9.2-1

[Patrick Matthäi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package glusterfs

Hi,

sadly I need again an unblock of an upstream release. It is again a bugfix
only release (also one important [0] bug introduced with 9.1, sic...).
The upstream changelog could be found here [1].

The filtered diffstat:

$ diff -Naur glusterfs-9.1/ glusterfs-9.2/ -x tests -x .pc -x ChangeLog -x 
VERSION -x glusterfs.spec |diffstat
 api/src/glfs-fops.c   |3
 cli/src/cli-rpc-ops.c |6
 configure |   20 -
 contrib/umountd/Makefile  |8
 debian/changelog  |6
 extras/group-distributed-virt |1
 extras/group-gluster-block|1
 extras/group-virt.example |1
 rpc/rpc-lib/src/protocol-common.h |3
 xlators/cluster/afr/src/afr-dir-read.c|   11
 xlators/cluster/afr/src/afr-inode-read.c  |  254 +-
 xlators/features/index/src/index.c|   79 +-
 xlators/features/locks/src/posix.c|   25 +-
 xlators/mgmt/glusterd/src/glusterd-mgmt-handler.c |6
 xlators/mgmt/glusterd/src/glusterd-store.c|   12 +
 xlators/mount/fuse/src/fuse-bridge.c  |3
 xlators/mount/fuse/src/fuse-bridge.h  |   21 +
 xlators/protocol/client/src/client-helpers.c  |   10
 xlators/protocol/client/src/client-lk.c   |   85 ---
 xlators/protocol/client/src/client.h  |8
 xlators/storage/posix/src/posix-inode-fd-ops.c|   10
 21 files changed, 337 insertions(+), 236 deletions(-)

I have attached the full diff.


[0]: https://github.com/gluster/glusterfs/issues/2351
[1]: https://docs.gluster.org/en/latest/release-notes/9.2/


unblock glusterfs/9.2-1

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


glusterfs92.diff.gz
Description: application/gzip

Bug#989373: zfs-linux: Extra iov_iter_advance may lead to memory corruption

[Antonio Russo]

Source: zfs-linux
Version: 2.0.1-1
Severity: grave
Tags: upstream
Justification: causes data loss
X-Debbugs-Cc: aeru...@aerusso.net

See Brian Behlendof's comment at [1], in the merge request for commit
3f81aba76, referencing the analysis of the bug report [2].

In summary: a kernel buffer iterator can be advanced beyond its end.
On kernels 5.12 and later, a safety mechanism has been created that
detects this error, but as of 5.10, this mechanism is not present
(AFAICT).

The aforementioned commit addresses the issue, and has also been
applied to 2.0.5-staging (as 3e0bc63e1).  As of now, no released
version of ZFS addresses this issue.

There is a suggestion that this could lead to memory corruption,
which seems plausible.  The lack of widespread data loss under ZFS
2.0 to date suggests that any corruption is relatively minor.

[1] https://github.com/openzfs/zfs/pull/12155#issuecomment-850935748
[2] https://github.com/openzfs/zfs/issues/12041


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989375: courier-pop: CVE-2011-0411 equivalent vulnerability - fix not implemented

[Sysadmin HTL Leonding]

Package: courier-pop
Severity: important

Dear Maintainer,

Uni Münster did a vulnerability scan on the Internet and reported a Debian 
server running 
courier-pop to be vulnerable to the equivalent of CVE-2011-0411. The system 
information
is from another system, but the issue exists in the upstream source, so it 
doesn't matter.

The suggested fixes from
www.postfix.org/CVE-2011-0411.html
have never been implemented in courier-pop (according to the researchers only 
in the IMAP
implementation).

There has been a very old bug report for Ubuntu (Debian security team asked me 
to open a ticket
in Debian BTS for this):
https://bugs.launchpad.net/ubuntu/+source/courier/+bug/1194892

In the meanwhile I got the information from a courier developer that while 
courier-pop 
is vulnerable to the same issue as the other programs (where fixes have been 
implemented)
according to him there has never been an practically exploit given the 
limitations of the 
POP3 protocol. The only possibility for an attacker would be to cause the 
server to send back
errors or failures to the login request and as the attacker is already MITM 
he/she could do 
that anyway.

As a measure of defense in depth and to prevent Internet scans to cause 
"noise", it might
be still a good idea to implement the suggested fixes in the POP3 
implementation too.

Or someone could declare STARTTLS as anyway broken (then it should be disabled 
in config
and documented there) and users should use the TLS-only ports as researchers 
recommended
as workaround.


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages courier-pop depends on:
pn  courier-authlib 
pn  courier-base
ii  debconf [debconf-2.0]   1.5.71
pn  default-mta | mail-transport-agent  
ii  libc6   2.28-10
pn  libcourier-unicode4 
ii  libidn111.33-2.2
ii  sysvinit-utils  2.93-8

courier-pop recommends no packages.

Versions of packages courier-pop suggests:
pn  courier-doc  
pn  mail-reader  

Bug#989344: rviz: error while loading shared libraries: libOgreOverlay.so.1.12.5: cannot open shared object file: No such file or directory

[Leopold Palomo-Avellaneda]

It's strange and I think that it's more a misunderstanding from upstream than a 
packaging name error.


I agree with Jochen that for Bullseye with just a binNMU should be enough. 
However, I would like to know if it's binary incompatible 1.12.5 and 1.12.10. 
Because, if the are compatible, maybe with just patch Ogre to have soversion 
with major.minor instead complete version should be more appropriated.


Leo

Bug#989372: sddm-theme-debian-maui: sddm-greeter returns warning about Implicitly defined onFoo properties

[Tia]

Package: sddm-theme-debian-maui
Version: 0.19.0-3
Severity: normal
X-Debbugs-Cc: tia3...@protonmail.com

Dear Maintainer,

Sddm-greeter returns warning to journal

sddm-greeter[20366]: file:///usr/share/sddm/themes/debian-maui/Main.qml:41:5: 
QML Connections: Implicitly defined onFoo properties in Connections are 
deprecated.  Use this syntax instead: function onFoo() { ... }

Seems it is a change in QT in change of syntax for connections.
https://stackoverflow.com/questions/62297192/qml-connections-implicitly-defined-onfoo-properties-in-connections-are-deprecat

Simmilary in qt-5 manual
https://doc.qt.io/qt-5/qml-qtqml-connections.html

It doesn't seem to impact the functionality of the theme.

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sddm-theme-debian-maui depends on:
ii  desktop-base  11.0.3

Versions of packages sddm-theme-debian-maui recommends:
ii  sddm  0.19.0-3

sddm-theme-debian-maui suggests no packages.

-- no debconf information

Bug#989287: libcivetweb1: build with websockets support

[Andreas Tille]

Hi Claude,

On Mon, May 31, 2021 at 09:51:33AM +0100, Claude Heiland-Allen wrote:
> 
> I managed to rebuild the package locally with websockets support by adding
> -DCIVETWEB_ENABLE_WEBSOCKETS=ON to CMAKE_EXTRA_FLAGS in debian/rules, adding
> extra lines to debian/libcivetweb1.symbols like
>  mg_websocket_client_write@Base 1.13+dfsg-5
>  mg_websocket_write@Base 1.13+dfsg-5

Thank you for the bug report.  It seems to be easy to accomplish.
However, due to the current freeze policy we can not upload to unstable
and thus I prefer to leave this bug open until after the freeze.
It would be great if you could meanwhile post a complete patch (by
for instance using debdiff) to save us the work to do what you just
have done.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Vagrant Cascadian]

On 2021-06-01, Rick Thomas wrote:
> Is there any estimate of when the assumed fix (linux/5.10.40-1) will
> show up in the installer at [1] ?  I'd love to test it!
...
> [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/

It should already be there kernel version 5.10.38-1 had it, 5.10.40-1
should also have it.

I only tested it outside of debian-installer (e.g. upgrading kernel on
an already installed system), so it is also possible that more modules
are needed in one of the kernel udebs used by the installer, or that
you're experiencing a different issue from the one that was fixed. I'll
try to test debian-installer on Cubox-i4pro to see if I still have an
issue.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#989374: lvm2: Activation of logical volume is prohibited while logical volume is active.

[Johnny Strom]

Package: lvm2
Version: 2.03.11-2.1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Uppgrade from debian 10 to debian 11.0.
Or creating an complete new thinpool and using snaphosts on debian 11.0

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 After an reboot and when thin_check has finnished so are the LVs inactive.

 They can't be activated with vgchange -ya it shows the following error:
 Activation of logical volume hemma/hemma-thinpool is prohibited while 
logical volume hemma/hemma-thinpool_tmeta is active.


   * What was the outcome of this action?

 vgchange -ya hemma
  0 logical volume(s) in volume group "hemma" now active
  Activation of logical volume hemma/hemma-thinpool is prohibited while logical 
volume hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/backup is prohibited while logical volume 
hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/home is prohibited while logical volume 
hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/stuff is prohibited while logical volume 
hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/Monday is prohibited while logical volume 
hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/Tuesday is prohibited while logical volume 
hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/Wednesday is prohibited while logical 
volume hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/Thursday is prohibited while logical 
volume hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/Friday is prohibited while logical volume 
hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/Saturday is prohibited while logical 
volume hemma/hemma-thinpool_tmeta is active.
  Activation of logical volume hemma/Sunday is prohibited while logical volume 
hemma/hemma-thinpool_tmeta is active.
  0 logical volume(s) in volume group "hemma" now active

lvs -a

  LV VGAttr   LSizePool   Origin Data%  
Meta%  Move Log Cpy%Sync Convert
  Friday hemma Vwi---tz--   <3.91t hemma-thinpool backup

  Monday hemma Vwi---tz--   <3.91t hemma-thinpool backup

  Saturday   hemma Vwi---tz--   <3.91t hemma-thinpool backup

  Sunday hemma Vwi---tz--   <3.91t hemma-thinpool backup

  Thursday   hemma Vwi---tz--   <3.91t hemma-thinpool backup

  Tuesdayhemma Vwi---tz--   <3.91t hemma-thinpool backup

  Wednesday  hemma Vwi---tz--   <3.91t hemma-thinpool backup

  backup hemma Vwi---tz--   <3.91t hemma-thinpool   

  hemma-thinpool hemma twi---tz--   <7.25t  

  [hemma-thinpool_tdata] hemma Twi-a-   <7.25t  

  [hemma-thinpool_tmeta] hemma ewi-a-   15.00g  

  home   hemma Vwi---tz-- 1000.00g hemma-thinpool   

  [lvol0_pmspare]hemma ewi---   15.00g  

  stuff  hemma Vwi---tz--   10.00g hemma-thinpool




   * What outcome did you expect instead?

 First they would be active after an reboot and when thin_check has 
finnished.
 and second it should be possible to activate with vgchange -ya.



 An work arround is to first run: lvchange -an hemma

 Then thin_check starts and after that has finnished:

 And then run: vgchange -ay hemma

 And now the VG is active again.

lvs -a
  LV VGAttr   LSizePool   Origin Data%  
Meta%  Move Log Cpy%Sync Convert
  Friday hemma Vwi-a-tz--   <3.91t hemma-thinpool backup 45.19  

  Monday hemma Vwi-a-tz--   <3.91t hemma-thinpool backup 45.19  

  Saturday   hemma Vwi-a-tz--   <3.91t hemma-thinpool backup 45.19  

  Sunday hemma Vwi-a-tz--   <3.91t hemma-thinpool backup 45.19  

  Thursday   hemma Vwi-a-tz--   <3.91t hemma-thinpool backup 45.07  

  Tuesdayhemma Vwi-a-tz--   <3.91t