Bug#966904: pfstools: FTBFS: array2d.h:173:9: error: ‘__assert_fail’ was not declared in this scope; did you mean ‘MagickCore::__assert_fail’?

[peter green]

On 24/09/2020 06:25, Andreas Metzler wrote:

On 2020-08-28 peter green  wrote:

Tags 966904 +patch
thanks



The issue is that Magick++.h (indirectly) includes assert.h inside a namespace.

[...]

I would argue that is a bug in imagemagick and have filed bugs in both Debian 
and upstream as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969128 and 
https://github.com/ImageMagick/ImageMagick6/issues/95

[...]

Hello Peter,

thanks for your help.

Did you note that the ImageMagick6 issue 95 has an comment ("We compiled
your source under Fedora and Centos without complaint [...]  Perhaps
there is a problem in the Debian tool chains.")

I did see it, but not sure how best to respond (and I don't really want to get 
deeply involved in this).

I still think it's imagemagick's fault for including assert.h inside a 
namespace and hence breaking other users of the
header, even if it happens to work on some other distros (which presumably have 
slightly different header interdependencies).

Bug#970833: libapache2-mod-security2: Segfault when using SecRemoteRules

[David Robb]

Package: libapache2-mod-security2
Version: 2.9.3-2
Severity: normal

Dear Maintainer,

When SecRemoteRules are configured, Apache segfaults.

Removing the SecRemoteRules configuration lines resolves the problem.

This appears to be a known issue in modsecurity 2.9.3 - 
https://github.com/SpiderLabs/ModSecurity/issues/1982 with an available patch 
there to fix this.

https://github.com/SpiderLabs/ModSecurity/commit/52532a1bce0b705c0aa4365fecf727b836d37f00

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

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

Versions of packages libapache2-mod-security2 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.46-1~bpo10+1
ii  libapr1 1.6.5-1+b1
ii  libaprutil1 1.6.1-4
ii  libc6   2.28-10
ii  libcurl3-gnutls 7.64.0-4+deb10u1
ii  liblua5.1-0 5.1.5-8.1+b2
ii  libpcre32:8.39-12
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libyajl22.1.0-3

Versions of packages libapache2-mod-security2 recommends:
ii  modsecurity-crs  3.1.0-1+deb10u1

libapache2-mod-security2 suggests no packages.

-- no debconf information

Bug#966904: pfstools: FTBFS: array2d.h:173:9: error: ‘__assert_fail’ was not declared in this scope; did you mean ‘MagickCore::__assert_fail’?

[Andreas Metzler]

On 2020-08-28 peter green  wrote:
> Tags 966904 +patch
> thanks

> The issue is that Magick++.h (indirectly) includes assert.h inside a 
> namespace.
[...]
> I would argue that is a bug in imagemagick and have filed bugs in both Debian 
> and upstream as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969128 and 
> https://github.com/ImageMagick/ImageMagick6/issues/95
[...]

Hello Peter,

thanks for your help. 

Did you note that the ImageMagick6 issue 95 has an comment ("We compiled
your source under Fedora and Centos without complaint [...]  Perhaps
there is a problem in the Debian tool chains.")

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#970832: highwayhash FTCBFS: multiple reasons

[Helmut Grohne]

Source: highwayhash
Version: 0~git20191002.0aaf66b-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

highwayhash fails to cross build from source for multiple reasons. One
reason is confusing the terms build and host as defined in man
dpkg-architecture. Thus it issues inappropriate compiler flags during
cross builds. Beyond that, libhighwayhash.so is not part of the default
target, so it only gets built during dh_auto_install where no cross
tools are passed. The attached patch fixes both aspects. Please consider
applying it.

Helmut
diff --minimal -Nru highwayhash-0~git20191002.0aaf66b/debian/changelog 
highwayhash-0~git20191002.0aaf66b/debian/changelog
--- highwayhash-0~git20191002.0aaf66b/debian/changelog  2019-10-04 
09:48:51.0 +0200
+++ highwayhash-0~git20191002.0aaf66b/debian/changelog  2020-09-24 
06:13:24.0 +0200
@@ -1,3 +1,12 @@
+highwayhash (0~git20191002.0aaf66b-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Fix build vs host confusion.
++ Build libhighwayhash.so during dh_auto_build.
+
+ -- Helmut Grohne   Thu, 24 Sep 2020 06:13:24 +0200
+
 highwayhash (0~git20191002.0aaf66b-1) unstable; urgency=medium
 
   * New upstream version 0~git20191002.0aaf66b
diff --minimal -Nru highwayhash-0~git20191002.0aaf66b/debian/rules 
highwayhash-0~git20191002.0aaf66b/debian/rules
--- highwayhash-0~git20191002.0aaf66b/debian/rules  2019-10-04 
09:48:51.0 +0200
+++ highwayhash-0~git20191002.0aaf66b/debian/rules  2020-09-24 
06:13:24.0 +0200
@@ -1,26 +1,25 @@
 #!/usr/bin/make -f
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-BUILD_ARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH)
-MULTIARCH=$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
 export DESTDIR=/usr
-export LIBDIR=$(DESTDIR)/lib/$(MULTIARCH)/
+export LIBDIR=$(DESTDIR)/lib/$(DEB_HOST_MULTIARCH)/
 export INCDIR=$(DESTDIR)/include/
 TESTBINS = highwayhash_test nanobenchmark_example profiler_example 
sip_hash_test vector_test
 
-ifeq (arm64,$(BUILD_ARCH))
+ifeq (arm64,$(DEB_HOST_ARCH_CPU))
 export HH_AARCH64=1
 endif
-ifeq (ppc64,$(BUILD_ARCH))
-export HH_POWER=1
-endif
-ifeq (ppc64el,$(BUILD_ARCH))
+ifneq (,$(filter $(DEB_HOST_ARCH_CPU),ppc64 ppc64el))
 export HH_POWER=1
 endif
 
 %:
dh $@
 
+override_dh_auto_build:
+   dh_auto_build -- all lib/libhighwayhash.so
+
 override_dh_auto_clean:
dh_auto_clean
-$(RM) deps.mk
@@ -35,12 +34,12 @@
 
 override_dh_auto_install:
dh_auto_install
-   mkdir -p debian/libhighwayhash0/usr/lib/$(MULTIARCH)
-   rename 's/.so/.so.0/' debian/tmp/usr/lib/$(MULTIARCH)/*.so
-   install -m0755 debian/tmp/usr/lib/$(MULTIARCH)/*.so.0 \
-   debian/libhighwayhash0/usr/lib/$(MULTIARCH)/
-   mkdir -p debian/libhighwayhash-dev/usr/lib/$(MULTIARCH)
-   install -m0755 debian/tmp/usr/lib/$(MULTIARCH)/*.a \
-   debian/libhighwayhash-dev/usr/lib/$(MULTIARCH)/
-   set -e; cd debian/libhighwayhash-dev/usr/lib/$(MULTIARCH)/; \
+   mkdir -p debian/libhighwayhash0/usr/lib/$(DEB_HOST_MULTIARCH)
+   rename 's/.so/.so.0/' debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/*.so
+   install -m0755 debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/*.so.0 \
+   debian/libhighwayhash0/usr/lib/$(DEB_HOST_MULTIARCH)/
+   mkdir -p debian/libhighwayhash-dev/usr/lib/$(DEB_HOST_MULTIARCH)
+   install -m0755 debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/*.a \
+   debian/libhighwayhash-dev/usr/lib/$(DEB_HOST_MULTIARCH)/
+   set -e; cd debian/libhighwayhash-dev/usr/lib/$(DEB_HOST_MULTIARCH)/; \
ln -s libhighwayhash.so.0 libhighwayhash.so

Bug#970831: php7.4-fpm: please include a config snippet for nginx that includes the fpm unix socket

[Andres Salomon]

Package: php7.4-fpm
Version: 7.4.10-1

In the php*-fpm packages, there's an apache snippet (eg,
/etc/apache2/conf-available/php7.4-fpm.conf) that tells apache where 
the fpm's

unix socket is. This is useful because the default sock has a name like
'php7.4-fpm.sock', and when upgrading to the next major php version the
httpd's configuration will break.

Unfortunately, there's no similar file for nginx. On redhat, their 
php-fpm
package sticks a config file into /etc/nginx/conf.d/php-fpm.conf that 
contains
the following (note that the path may be edited, as I'm taking this 
from a live

server):


upstream php-fpm {
   server unix:/var/run/php-fpm/www.sock;
}


They also do some /etc/alternative stuff with php-fpm.conf being a 
symlink
to php-fpm.conf-7.3, but that seems unnecessary. It would be good to 
have

something like that in Debian, but pointing to /run/php/php7.4-fpm.sock.
When I upgrade my stable servers from php7.3-fpm to php7.4-fpm, the 
nginx
config is going to break unless I modify 
/etc/php/7.3/fpm/pool.d/www.conf

to not listen on /run/php/php7.3-fpm.sock.

Bug#970830: Firefox 78 ESR: Can't hear other participants in Google Meet

[Job Ryan C. Bautista]

Package: firefox-esr
Version: 78.3.0esr-2
Severity: important

In an ALSA-only system, I can't hear the voices of the other participants in a
meeting in Google Meet, even though it says that the participant is
talking. This
is weird, because audio playback works fine in sites like YouTube, and
Google Meet
even detects my microphone. The only workaround to make audio work in
Google Meet
is wrapping Firefox around apulse. I tested Firefox without apulse in safe mode,
and I can confirm that it's not the add-ons causing this problem.

Job Bautista


-- 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: user-disabled

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: eBay
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Facebook Container
Location: ${PROFILE_EXTENSIONS}/@contain-facebook.xpi
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: Good Old YouTube
Location: ${PROFILE_EXTENSIONS}/{482060de-6804-4020-a1b9-16dc012a3c93}.xpi
Status: enabled

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

Name: Google Container
Location: ${PROFILE_EXTENSIONS}/@contain-google.xpi
Status: enabled

Name: HTTPS Everywhere
Location: /usr/share/webext/https-everywhere
Package: webext-https-everywhere
Status: enabled

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

Name: uBlock Origin
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net
Package: webext-ublock-origin-firefox
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-esr  78.3.0esr-2   amd64Mozilla
Firefox web browser - Extended Support Release (ESR)
ii  webext-https-everywhere  2020.8.13-1   all  Extension
to force the use of HTTPS on many sites
ii  webext-ublock-origin-firefox 1.29.0+dfsg-2 all
lightweight and efficient ads, malware, trackers blocker (Firefox)

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera/ceres)
Release:testing/unstable
Codename:   n/a
Architecture: x86_64

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8),
LANGUAGE=en_PH:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils 4.9.1
ii  fontconfig  2.13.1-4.2
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-3
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.20-1+devuan1
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.12-stable-1
ii  libffi7 3.3-4
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-3
ii  libgcc-s1   10.2.0-9
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libglib2.0-02.66.0-2
ii  libgtk-3-0  3.24.23-1
ii  libnspr42:4.28-1
ii  libnss3 2:3.56-1
ii  libpango-1.0-0  1.46.1-1
ii  libstdc++6  10.2.0-9
ii  libvpx6 1.8.2-1
ii  libx11-62:1.6.12-1
ii  libx11-xcb1 2:1.6.12-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  libxext62: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+devuan1
ii  zlib1g  1:1.2.11.dfsg-2

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

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
pn  fonts-stix | otf-stix  
ii  

Bug#970768: torbrowser-launcher: error while checking version number after TorBrowser 10.0 release

[Lev Lamberov]

Hi Roger,

Чт 24 сен 2020 @ 01:43 Roger Shimizu :

> Dear Lev,
>
> Thanks for your report!
>
> On Wed, Sep 23, 2020 at 4:00 PM Lev Lamberov  wrote:
>>
>> Package: torbrowser-launcher
>> Version: 0.3.2-13
>> Severity: grave
>> Tags: upstream
>> Justification: renders package unusable
>>
>> Dear Maintainer,
>>
>> because of faulty version number check, torbrowser-launcher cannot
>> correctly handle TorBrowser 10.0 release. Now it shows the following
>> error message:
>>
>> The version of Tor Browser you have installed is earlier than it
>> should be, which could be a sign of an attack!
>>
>> Seems that because of this error it is not possible to install the new
>> release of TorBrowser, and installation of it is run everytime when
>> running torbrowser-launcher. So, torbrowser-launcher simply doesn't do
>> what it should (install and run TorBrowser), which make it unusable.
>>
>> There is an upstream issued already reported, see #498 [#498], and
>> merge request submitted.
>>
>> [#498] https://github.com/micahflee/torbrowser-launcher/issues/498
>
> I just uploaded 0.3.2-14~exp1 to experimental.
> Since I cannot launch TBB after downloading it.
> (I'm using buster + backports)
> Can you kindly help to confirm it works on your side? Thanks!

I've installed torbrowser-launcher from experimental and can confirm
that it works properly for me. Thanks for you work on it!

Cheers!
Lev

Bug#970829: covtobed FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: covtobed
Version: 1.1.2+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

covtobed fails to cross build from source, because debian/rules uses the
build architecture compiler as a make default. Please consider letting
dpkg's buildtools.mk set up the CXX variable to make covtobed cross
buildable. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru covtobed-1.1.2+dfsg/debian/changelog 
covtobed-1.1.2+dfsg/debian/changelog
--- covtobed-1.1.2+dfsg/debian/changelog2020-07-20 13:52:38.0 
+0200
+++ covtobed-1.1.2+dfsg/debian/changelog2020-09-24 06:09:37.0 
+0200
@@ -1,3 +1,10 @@
+covtobed (1.1.2+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk setup cross tools. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 24 Sep 2020 06:09:37 +0200
+
 covtobed (1.1.2+dfsg-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru covtobed-1.1.2+dfsg/debian/rules 
covtobed-1.1.2+dfsg/debian/rules
--- covtobed-1.1.2+dfsg/debian/rules2020-07-20 13:52:38.0 +0200
+++ covtobed-1.1.2+dfsg/debian/rules2020-09-24 06:09:36.0 +0200
@@ -4,6 +4,7 @@
 export LC_ALL=C.UTF-8
 
 include /usr/share/dpkg/default.mk
+-include /usr/share/dpkg/buildtools.mk
 
 # for hardening you might like to uncomment this:
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all

Bug#963630: Aparapi license has changed to a more liberal license

[Jeffrey Freeman]

Hi I noticed you had a conversation sometime back here:
https://github.com/aparapi/aparapi/issues/50

I wanted to mention that Aparapi is no longer maintained at the address you
specified and all developers, including the founder, have moved onto the
new repository which is now active and well funded here:
https://git.qoto.org/aparapi/aparapi

During that port back in 2016 the license was reviewed by a paid lawyer
hired by the new foundation and the license was legally changed. As our
lawyer had assured us the original additional verbiage in the license for
the original release of Aparapi did not functionally change the license in
any way, it simply allowed AMD to protect themselves against any liability
should the software be misused. The original added verbiage basically
amounted to "You can not break the law when you exercise your rights under
this license", which is already implied with an MIT license but not
explicitly stated.

As such we were able to legally and effectively relicense the software
under the apache license and the new software is licensed wholly under the
Apache license with no additional restrictions of any kind. You are free to
repackage and redistribute the license exactly as you would under the
Apache license.

Let me know if you have any questions.

Bug#963630: Aparapi license has changed to a more liberal license

[Jeffrey Freeman]

Glad to hear it. If you have any questions at all reach out to me anytime.
I've been the package maintainer for some time. While I am not the founder
I handle most of the day to day coding and project management and am in
close contact with the original founder who is still a contributor and
active participant but not as active as myself these days. So I try to
handle any of the day to day issues that come up. Always happy to answer
any questions if you need anything.

On Wed, Sep 23, 2020 at 3:38 PM Andreas Tille  wrote:

> Dear Jeffrey,
>
> thanks a lot for the good news.  We will package from the new location
> for Debian then.
>
> Kind regards
>
> Andreas.
>
> On Wed, Sep 23, 2020 at 12:03:12PM -0400, Jeffrey Freeman wrote:
> > Hi I noticed you had a conversation sometime back here:
> > https://github.com/aparapi/aparapi/issues/50
> >
> > I wanted to mention that Aparapi is no longer maintained at the address
> you
> > specified and all developers, including the founder, have moved onto the
> > new repository which is now active and well funded here:
> > https://git.qoto.org/aparapi/aparapi
> >
> > During that port back in 2016 the license was reviewed by a paid lawyer
> > hired by the new foundation and the license was legally changed. As our
> > lawyer had assured us the original additional verbiage in the license for
> > the original release of Aparapi did not functionally change the license
> in
> > any way, it simply allowed AMD to protect themselves against any
> liability
> > should the software be misused. The original added verbiage basically
> > amounted to "You can not break the law when you exercise your rights
> under
> > this license", which is already implied with an MIT license but not
> > explicitly stated.
> >
> > As such we were able to legally and effectively relicense the software
> > under the apache license and the new software is licensed wholly under
> the
> > Apache license with no additional restrictions of any kind. You are free
> to
> > repackage and redistribute the license exactly as you would under the
> > Apache license.
> >
> > Let me know if you have any questions.
>
> --
> http://fam-tille.de
>

Bug#893745: python-cffi: FTBFS on ia64: several test failures

[Stefano Rivera]

Hi Aaron (2018.03.21_16:02:21_-0700)
> testing/cffi0/test_ownlib.py:296: AssertionError
> ___ test_no_unknown_exported_symbols 
> ___
> 
> def test_no_unknown_exported_symbols():
> if not hasattr(_cffi_backend, '__file__'):
> py.test.skip("_cffi_backend module is built-in")
> if not sys.platform.startswith('linux'):
> py.test.skip("linux-only")
> g = os.popen("objdump -T '%s'" % _cffi_backend.__file__, 'r')
> for line in g:
> if not line.startswith('0'):
> continue
> if '*UND*' in line:
> continue
> name = line.split()[-1]
> if name.startswith('_') or name.startswith('.'):
> continue
> if name not in ('init_cffi_backend', 'PyInit__cffi_backend'):
> >   raise Exception("Unexpected exported name %r" % (name,))
> E   Exception: Unexpected exported name 'ctypedescr_clear'

Looks like this is the only remaining failure.

So, the rest were presumably libffi bugs.

Not sure exactly what's going on there. I can't seem to access the
atlantis porterbox ATM.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#970664: libvte-2.91-0: Terminal not displaying correctly

[Fabián Inostroza]

Thanks!.

El mié., 23 sept. 2020 a las 6:02, Simon McVittie () escribió:
>
> Control: forwarded -1 https://gitlab.gnome.org/GNOME/vte/-/issues/284
>
> On Wed, 23 Sep 2020 at 08:22:48 +0100, Simon McVittie wrote:
> > I think it's caused by
> > the change made for .
>
> Yes, it is. I've contacted upstream and suggested a change that seems to
> do approximately the right thing.
>
> I'll see what response we get; if it takes a while, we can revert the
> problematic change instead.
>
> smcv

Bug#968991: openjdk-14: diff for NMU version 14.0.2+12-1.1

[tony mancill]

Control: tags 968991 + pending

Hi Matthias,

I've prepared an NMU for openjdk-14 (versioned as 14.0.2+12-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I should
delay it longer, or if you would prefer that I remove the upload.

Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944738 for
discussion regarding the patch.

Cheers,
tony
diff -Nru openjdk-14-14.0.2+12/debian/changelog openjdk-14-14.0.2+12/debian/changelog
--- openjdk-14-14.0.2+12/debian/changelog	2020-07-17 09:20:10.0 -0700
+++ openjdk-14-14.0.2+12/debian/changelog	2020-09-23 11:13:13.0 -0700
@@ -1,3 +1,12 @@
+openjdk-14 (14.0.2+12-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch to strip nondeterminism before computing jmod hash.
+Thank you to Julian Gilbey for the patch.  (Closes: #968991)
+Add Build-Depends on strip-nondeterminism.
+
+ -- tony mancill   Wed, 23 Sep 2020 11:13:13 -0700
+
 openjdk-14 (14.0.2+12-1) unstable; urgency=medium
 
   * OpenJDK 14.0.2 release, build 12 (release build).
diff -Nru openjdk-14-14.0.2+12/debian/control openjdk-14-14.0.2+12/debian/control
--- openjdk-14-14.0.2+12/debian/control	2020-07-17 07:51:00.0 -0700
+++ openjdk-14-14.0.2+12/debian/control	2020-09-19 12:57:12.0 -0700
@@ -15,6 +15,7 @@
   zlib1g-dev:native, zlib1g-dev, libattr1-dev, libpng-dev, libjpeg-dev, libgif-dev, 
   libnss3-dev (>= 2:3.17.1),
   openjdk-14-jdk-headless ,
+  strip-nondeterminism,
 Build-Depends-Indep: graphviz, pandoc,
 Standards-Version: 4.5.0
 Homepage: http://openjdk.java.net/
diff -Nru openjdk-14-14.0.2+12/debian/patches/reproducible-build-jmod.diff openjdk-14-14.0.2+12/debian/patches/reproducible-build-jmod.diff
--- openjdk-14-14.0.2+12/debian/patches/reproducible-build-jmod.diff	1969-12-31 16:00:00.0 -0800
+++ openjdk-14-14.0.2+12/debian/patches/reproducible-build-jmod.diff	2020-09-23 11:11:16.0 -0700
@@ -0,0 +1,33 @@
+Description: jlink: Hash of module differs to expected hash recorded in java.base
+ The cause is the use of dh_strip_nondeterminism late in the build
+ process.  This reorganises the jmod files, which in turn changes their
+ SHA256 checksums.  This would not be a problem, except that the
+ checksums are saved in java.base.jmod *before* the use of
+ dh_strip_nondeterminism.  Performing this stripping immediately after
+ each jmod file is created results in the checksums being consistent
+ throughout.
+Author: Julian Gilbey 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944738
+Forwarded: not-needed
+
+--- a/make/CreateJmods.gmk
 b/make/CreateJmods.gmk
+@@ -218,6 +218,9 @@
+ 
+ # Create jmods in the support dir and then move them into place to keep the
+ # module path in $(IMAGES_OUTPUTDIR)/jmods valid at all times.
++# strip-nondeterminism requires the same timestamp as
++# dh_strip_nondeterminism uses, so we determine this first.
++DSN_TIMESTAMP := $(shell perl -MDebian::Debhelper::Dh_Lib -e 'print get_source_date_epoch()')
+ $(eval $(call SetupExecute, create_$(JMOD_FILE), \
+ WARN := Creating $(INTERIM_MSG)$(JMOD_FILE), \
+ DEPS := $(DEPS), \
+@@ -228,7 +231,7 @@
+ --target-platform '$(OPENJDK_MODULE_TARGET_PLATFORM)' \
+ --module-path $(JMODS_DIR) $(JMOD_FLAGS) \
+ $(JMODS_SUPPORT_DIR)/$(JMOD_FILE), \
+-POST_COMMAND := $(MV) $(JMODS_SUPPORT_DIR)/$(JMOD_FILE) $(JMODS_DIR)/$(JMOD_FILE), \
++POST_COMMAND := strip-nondeterminism --timestamp $(DSN_TIMESTAMP) $(JMODS_SUPPORT_DIR)/$(JMOD_FILE) && $(MV) $(JMODS_SUPPORT_DIR)/$(JMOD_FILE) $(JMODS_DIR)/$(JMOD_FILE), \
+ ))
+ 
+ TARGETS += $(create_$(JMOD_FILE))
diff -Nru openjdk-14-14.0.2+12/debian/patches/series openjdk-14-14.0.2+12/debian/patches/series
--- openjdk-14-14.0.2+12/debian/patches/series	2020-04-15 00:11:57.0 -0700
+++ openjdk-14-14.0.2+12/debian/patches/series	2020-09-23 11:11:33.0 -0700
@@ -42,3 +42,4 @@
 reproducible-module-info.diff
 reproducible-copyright-headers.diff
 reproducible-build-user.diff
+reproducible-build-jmod.diff


signature.asc
Description: PGP signature

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

[tony mancill]

On Wed, Sep 23, 2020 at 08:55:11PM +0100, Julian Gilbey wrote:
> On Wed, Sep 23, 2020 at 11:09:28AM -0700, tony mancill wrote:
> > > dh_strip_nondeterminism gets its timestamp from the debian/changelog
> > > file, while strip-nondeterminism strips the timestamps.
> > > 
> > > So here's a replacement patch which fixes everything except
> > > java.naming.jmod.  I have to run now, but will try to figure out
> > > tomorrow why that one still breaks.
> > 
> > I rebuilt with this patch (and also my NONPARALLEL patch) and am able to
> > call jlink against all of the modules shipped with the resulting JDK
> > binary package.  So this is looking good.
> > 
> > I'm rebuilding now (without nonparallel) what should be the NMU candidate.
> 
> Super!  I wonder, though, why it didn't work for me first time round?
> I rebuilt it and it worked the second time, though.  So maybe I
> changed something.

The rebuild of openjdk-14, including tests and the ad-hoc jlink tests
was successful, so I think this is ready.  I have uploaded it to
DELAYED/15, closing #968991 [1], since there was a bug there for just
openjdk-14.

> Obviously, similar builds will be needed for openjdk-{11,13,14,15}.

Yes, I will start working on the others.

Thank you for all of help.
tony

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968991)

Bug#743835: xlbiff: `nmh is not installed'

[Paul Wise]

On Mon, 07 Apr 2014 15:14:27 +0800 積丹尼 Dan Jacobson wrote:

> We see a message 'it doesn't look like nmh is installed' (but in fact it
> is.) We also see Warning: Cannot convert string
> "-*-clean-bold-r-normal--13-130-75-75-c-80-iso8859-1" to type FontStruct

Do you still have the same problem with xlbiff since version 4.3-1 was
reintroduced into Debian unstable?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress

[Noah Meyerhans]

Control: severity -1 minor

> 1) ping is working
> 2) start apt dist-upgrade
> 3) at some point new ping stops working with ping: socket: Operation not 
> permited
>   for minutes.
> 4) apt dist-upgrade finishes
> 5) ping works again

The ping process requires the ability to open a raw network socket,
which is a privileged operation.  The ping binary contained within the
package is completely unprivileged, so when it's initially installed it
can only be executed by the root user or some other user that has
retained the cap_net_raw capability.  Later in the installation process,
the package's post-install script tries to add the cap_net_raw
file-based capability to the binary as that's the safest (least
privileged) way to grant users the ability to run ping.  If that fails,
probably because the system is configured with some unusual filesystem
that doesn't support file-based capabilities, then the script sets the
suid bit on the binary, granting unprivileged users the ability to run
ping with a slight reduction in the security posture.

I'm not sure of a practical way to avoid this situation.  If .deb files
could contain files with capabilities set on them, then this would
likely improve the situation for most users, but I believe it's still
the case that this isn't possible.

You can see the script in question at
https://salsa.debian.org/debian/iputils/-/blob/master/debian/iputils-ping.postinst

noah

Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress

[Witold Baryluk]

Package: iputils-ping
Version: 3:20200821-2
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com


I noticed this weird thing:

1) ping is working
2) start apt dist-upgrade
3) at some point new ping stops working with ping: socket: Operation not 
permited
  for minutes.
4) apt dist-upgrade finishes
5) ping works again


That is not nice.

Looking at dpkg.log I see this:

2020-09-24 01:34:40 upgrade iputils-ping:amd64 3:20190709-3 3:20200821-2
2020-09-24 01:34:40 status half-configured iputils-ping:amd64 3:20190709-3
2020-09-24 01:34:40 status unpacked iputils-ping:amd64 3:20190709-3
2020-09-24 01:34:40 status half-installed iputils-ping:amd64 3:20190709-3
2020-09-24 01:34:40 status unpacked iputils-ping:amd64 3:20200821-2
...
...
2020-09-24 01:45:28 configure iputils-ping:amd64 3:20200821-2 
2020-09-24 01:45:28 status unpacked iputils-ping:amd64 3:20200821-2
2020-09-24 01:45:28 status half-configured iputils-ping:amd64 3:20200821-2
2020-09-24 01:45:28 status installed iputils-ping:amd64 3:20200821-2



So I suspect there is something critical in configure that prevent ping
from working during this intermitent period.


Wish it could be fixed somehow.


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/32 CPU threads)
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 iputils-ping depends on:
ii  libc62.31-3
ii  libcap2  1:2.43-1
ii  libcap2-bin  1:2.43-1
ii  libidn2-02.3.0-1

iputils-ping recommends no packages.

iputils-ping suggests no packages.

-- no debconf information

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Paul Wise]

Control: retitle -1 firefox: FF80 broke webext-* add-ons on existing profiles 
and new profiles after three restarts

On Wed, 2020-09-23 at 19:44 +0900, Yuya Nishihara wrote:

> If I restarted firefox 3 times, the problem came back.

I noticed that this 3 restart thing also applies to new profiles, so it
should be easily reproducible for everyone. This occurs both when using
a new HOME directory and when passing the -profile option to firefox.

I see that Yuya discovered that too and posted some logs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969174#70

Mike, could you try reproducing it on a new profile with 3 restarts?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#970826: ITP: dosage -- comic strip downloader and archive

[Fabio Junior]

Package: wnpp
Severity: wishlist
Owner: Fabio Junior 
X-Debbugs-Cc: debian-de...@lists.debian.org, fabio.jun...@digitalcomics.com.br

* Package name: dosage
  Version : 2.15-5.1
  Upstream Author : Fabio Junior 
* URL : https://dosage.rocks/
* License : MIT
  Programming Lang: Python
  Description : comic strip downloader and archive

Dosage is designed to keep a local copy of specific webcomics and other 
picture-based content such as Picture of the Day sites. With the dosage 
commandline script you can get the latest strip of a webcomic, or catch-up to 
the last strip downloaded, or download a strip for a particular date/index (if 
the webcomic's site layout allows this).
Multiple webcomics can be downloaded in parallel, making the update of comic 
strips faster.

Bug#970825: ITP: golang-github-petermattis-goid -- Programatically retrieve the current goroutine's ID

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: golang-github-petermattis-goid
  Version : 0.0~git20180202.b0b1615-1
  Upstream Author : Peter Mattis
* URL : https://github.com/petermattis/goid
* License : Apache-2.0
  Programming Lang: Go
  Description :

 goid Build Status (https://travis-ci.org/petermattis/goid)
 Programatically retrieve the current goroutine's ID. See the CI
 configuration (.travis.yml) for supported Go versions. In addition,
 gccgo 7.2.1 (Go 1.8.3) is supported.

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Paul Wise]

On Wed, 2020-09-23 at 19:44 +0900, Yuya Nishihara wrote:

> Not for me. If I restarted firefox 3 times, the problem came back.

Arghh, me too now :(

I think this issue needs to be fixed before it reaches the ESR series.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#953875: Debian FTP Masters

[Felix Freeman]

It's not solved on my end with Debian 10... here is what I see when I 
try to install git-all.


```
root:/home/admin# apt update && apt install git-all
...
The following packages will be REMOVED:
  libpam-systemd systemd-sysv
```

Please check my previous message for context.

Bug#970823: RFP: git-hours -- Tool for count the time spent on code via git.

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: git-hours
  Version : ...
  Upstream Author : multiple
* URL : https://github.com/kimmobrunfeldt/git-hours
* License : various
  Programming Lang: C or Javascript or Python
  Description : Tool for count the time spent on code via git.

Those tools analyse your git history, look at commit dates and try to
guess how much time it took to make those commits...

There's actually three such tools...

The javascript version:

https://github.com/kimmobrunfeldt/git-hours

A rewrite in C:

https://github.com/ceigh/git-hours

A pastebin in Python:

https://gist.github.com/leandropls/6db26df3939b094dd321

I actually found the latter the most useful because it allows you to
restrict your search to a path within the repository.

Bug#970822: python-whiteboard: Correct GPL-2 in copyright to GPL-2+

[Bastian Germann]

Source: python-whiteboard
Severity: normal

Please correct the copyright file to say GPL-2+ (which is the package's
license) instead of GPL-2 (only). This has an impact on the package
because it is a derivative work of pyqt5, which is GPL-3 licensed and
thus incompatible with GPL-2 only.

Bug#962102: Fwd: ltunify_0.3-1 in NEW

[Geert Stappers]

- Forwarded message from Debian FTP Masters 
 -

Date: Tue, 22 Sep 2020 17:34:00 +
From: Debian FTP Masters 
To: Anthony Perkins , stapp...@debian.org
Subject: ltunify_0.3-1_amd64.changes is NEW

binary:ltunify is NEW.
binary:ltunify is NEW.
source:ltunify is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports

- End forwarded message -

Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#961371: due_2.0.0-1_amd64.changes ACCEPTED into unstable

[Geert Stappers]

On Tue, Sep 22, 2020 at 07:39:23AM -0700, Alex Doyle wrote:
> Hi Geert,
>  That's excellent! Thanks so much for your help with this.
> 
> I expect it will be a while ( like, months ) until I have a new version
> ready to release. From reading the mentor's faq, it looks like I should
> contact you?

Yes, feel free to contact me.

FWIW  Incase "upstream" releases v2.0.1 ( git tag v2.0.1 ; git push --tags )
or whatever the next version number might be.  I'm happy to sponsor the upload.

 
> I'd imagine that from here on out it would be a  lot less work involved to
> approve new versions since there is a known good baseline to compare
> against.
> 
> And thanks again - if we're ever at the same DebConf, I definitely owe you
> a beverage of your choice :)

:-)   We will find a way to celebrate what did together.


> -Alex
> 
> On Tue, Sep 22, 2020 at 5:57 AM Geert Stappers wrote:
> 
> > - Forwarded message from Debian FTP Masters <
> > ftpmas...@ftp-master.debian.org> -
> >
> > Date: Tue, 22 Sep 2020 12:00:09 +
> > From: Debian FTP Masters 
> > To: Alex Doyle , stapp...@debian.org
> > Subject: due_2.0.0-1_amd64.changes ACCEPTED into unstable, unstable
> >
> >
> >
> > Accepted:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Format: 1.8
> > Date: Sat, 19 Sep 2020 22:39:58 +0200
> > Source: due
> > Binary: due
> > Architecture: source all
> > Version: 2.0.0-1
> > Distribution: unstable
> > Urgency: medium
> > Maintainer: Alex Doyle 
> > Changed-By: Alex Doyle 
> > Description:
> >  due- Dedicated User Environment: manage build environments in 
> > Docker c
> > Closes: 931617
} }  ^
> > Changes:
> >  due (2.0.0-1) unstable; urgency=medium
> >  .
> >[ Alex Doyle ]
> >* Initial upload. Closes: #931617
> >  .
> >[ Geert Stappers ]
> >* Uploader
> > Checksums-Sha1:
> >  88e1e57205188ce920e74d13a00025ba94aef04a 1852 due_2.0.0-1.dsc
> >  b37ff0b79c5e26760c5bc170c70889570e127d14 105376 due_2.0.0.orig.tar.gz
> >  2ff9c89b48952cf4dc36b1089d50b48160f3fcc7 2996 due_2.0.0-1.debian.tar.xz
> >  fbcab6e758a3c4c3436dc27006cfd7b0d690dcdb 74120 due_2.0.0-1_all.deb
> >  739d14896bed173ac0e728f21505bd897bc10ef3 6428 due_2.0.0-1_amd64.buildinfo
> > Files:
> >  4fb5cff6346482839b5fbc6b4a18dc3b 1852 devel optional due_2.0.0-1.dsc
> >  2475a84a68ff837854caa1c607eab862 105376 devel optional 
> > due_2.0.0.orig.tar.gz
> >  4ae14448019b16133ff25009a56d1a61 2996 devel optional 
> > due_2.0.0-1.debian.tar.xz
> >  27b8b03bc1bc88215bf834b268e7b2fd 74120 devel optional due_2.0.0-1_all.deb
> >  620d5bea2ced8f41fa3923a594784bf7 6428 devel optional 
> > due_2.0.0-1_amd64.buildinfo
> >
> >
> > Thank you for your contribution to Debian.
> >
> > - End forwarded message -

Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#970802: gcc-10: armhf: false positive when using -O2 and -Werror=format-truncation

[Hans van Kranenburg]

On 9/23/20 4:59 PM, Julien Grall wrote:
> X-Debbugs-CC: i...@xenproject.org
> X-Debbugs-CC: h...@knorrie.org
> Package: gcc-10
> Version: 10.2.0-9
> Severity: important
> 
> Dear Maintainer,
> 
> There was an FTBFS for Xen when building using GCC 10 on armhf (see
> bug #9689645 [1]).

FYI [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968965#22

> After investigation, it looks a problem when with the optimizer in GCC 
> for armhf.
> 
> [...]

Thanks,
Hans

Bug#970798: [Pkg-net-snmp-devel] Bug#970798: net-snmp: Not built on buildd: arch all binaries, source-only upload required

[Craig Small]

On Thu, 24 Sep 2020 at 01:27, Chris Hofstaedtler  wrote:

> * Not built on buildd: arch amd64 binaries uploaded by csmall
> * Not built on buildd: arch all binaries uploaded by csmall, a new
> source-only upload is needed to allow migration
>
> While the first one could be fixed by a binNMU, the second one
> cannot. This also prevents your reverse dependencies from migrating
> to testing.
>
> Please do a new source-only, possibly no-change, upload to unstable.
>
Hi Chris,
  Thanks for pointing out its not migrating.

Seriously this source-only upload stuff is broken.

source-only uploads fail because libsnmptrapd40 is new
binary uploads fail because they wont go into testing

So apparently, I need to:
* first upload a binary set to get libsnmptrapd40 through the gate
* upload a source-only for no other reason other than.. reasons

 - Craig

Bug#913781: reprozip: Script accesses internal dpkg database

[Rémi Rampin]

2018-11-15 23:33:30 UTC-0500, Remi Rampin :
> I have gone ahead and implemented what you describe, it should be in
> the next minor release of ReproZip. It also turns out to be faster.

This is present in reprozip/1.0.16-1 that was just uploaded so I
believe it can be closed too (see
https://github.com/VIDA-NYU/reprozip/pull/330).

-- 
Rémi Rampin

Bug#970821: RFS: dbacl/1.14.1-3 [QA] [RC] -- digramic Bayesian text classifier

[Bastian Germann]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: dbacl
   Version : 1.14.1-3
   Upstream Author : Laird Breyer 
 * URL : https://www.lbreyer.com/gpl.html
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/dbacl
   Section : text

It builds those binary packages:

  dbacl - digramic Bayesian text classifier

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/dbacl/dbacl_1.14.1-3.dsc

Changes since the last upload:

 dbacl (1.14.1-3) unstable; urgency=medium
 .
   * QA upload.
 .
   [ Bastian Germann ]
   * Use current libreadline (Closes: #953006)
   * Fix duplicate definitions (Closes: #957121)
 .
   [ Debian Janitor ]
   * Use secure URI in debian/watch.
   * Use secure URI in Homepage field.
   * Update standards version to 4.4.1, no changes needed.
   * Set upstream metadata fields: Archive, Bug-Submit.

Regards,
Bastian

Bug#953060: ImportError when trying to import OpenImageIO

[Matteo F. Vescovi]

Hi!

On 2020-03-03 at 16:58 (-05), James Dietrich wrote:

[...]

> I am getting an ImportError when trying to import OpenImageIO:
> jdietrch@saturn:~$ python3
> Python 3.7.6 (default, Jan 19 2020, 22:34:52)
> [GCC 9.2.1 20200117] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 import OpenImageIO
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: /lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate
> memory in static TLS block

Sorry for the late reply.

It was figured out that the problem resides in memory allocation in
jemalloc; please see https://github.com/jemalloc/jemalloc/issues/937 for
more detailed information on that.

It's now fixed upstream but Debian package is not built with a
particular configuration parameter to avoid this behavior.

I'm wondering if the issue should then be reassigned to jemalloc itself.

Cheers.


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


signature.asc
Description: PGP signature

Bug#970803: lighttpd: appliation segfaults on start

[Glenn Strauss]

Did you have a prior version of lighttpd running successfully?
Which version?

Please share your current lighttpd config
$ lighttpd -f /etc/lighttpd/lighttpd.conf -p
$ lighttpd -f /etc/lighttpd/lighttpd.conf -tt
If you have strace installed:
$ strace -s 1024 lighttpd -f /etc/lighttpd/lighttpd.conf -D

Bug#970820: missing bid_functions.h header

[Sébastien Villemot]

Package: libintelrdfpmath-dev
Version: 2.0u2-2
Severity: serious

Dear Maintainer,

The bid_functions.h header is not included in the package.

This header is required when compiling a program against the library. In
particular, it defines the BID_UINT32, BID_UINT64 and BID_UINT128 types, and
declares the prototypes of most functions.

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org

Bug#969739: Segmentation fault on startup

[Bernhard Übelacker]

Dear Maintainer,
I could not reproduce the crash, but I could modify the process under
gdb to reach a point of execution, which prints a similar backtrace.

Therefore I guess the crash described in Christophe's first message
is really located in [1], caused by "xf86_platform_devices[i].pdev"
containing a null pointer.

[1] 
https://sources.debian.org/src/xorg-server/2:1.20.9-1/hw/xfree86/common/xf86platformBus.c/#L367


But second and more fundamentally, I guess too that the backtrace
generating function in Xorg seems not to be reliable.

If I am right the following backtraces should show the same addresses, but for
some reason the Xorg output seems to be kind of misleading on some frames.
Would that be worth to track in a separate bug?

Kind regards,
Bernhard

With debug symbols:
#0  0x5560ae10 in xf86MergeOutputClassOptions () at 
../../../../../../hw/xfree86/common/xf86platformBus.c:367
#1  0x555ee197 in xf86CollectOptions () at 
../../../../../../hw/xfree86/common/xf86Option.c:83
#2  0x76993d2e in PreInit () at 
../../../../../../../hw/xfree86/drivers/modesetting/driver.c:972
#3  0x555f185e in InitOutput () at 
../../../../../../hw/xfree86/common/xf86Init.c:522
#4  0x555b331c in dix_main () at ../../../../dix/main.c:193
#5  0x772dbcca in __libc_start_main () at ../csu/libc-start.c:308
#6  0x5559cc9a in _start ()

Without debug symbols:
#0  0x5560ae10 in ?? ()
#1  0x555ee197 in xf86CollectOptions ()
#2  0x76993d2e in ?? () from 
/usr/lib/xorg/modules/drivers/modesetting_drv.so
#3  0x555f185e in InitOutput ()
#4  0x555b331c in ?? ()
#5  0x772dbcca in __libc_start_main () at ../csu/libc-start.c:308
#6  0x5559cc9a in _start ()

>From Xorg:
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x135) [0x55712f35]
(EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) 
[0x7749018f]
(EE) 2: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x5c0) [0x5560b2b0]
(EE) 3: /usr/lib/xorg/Xorg (xf86CollectOptions+0x77) [0x555ee197]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 4: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) 
[0x76993940]
(EE) 5: /usr/lib/xorg/Xorg (InitOutput+0x9ae) [0x555f185e]
(EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x1cc) [0x555b335c]
(EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xea) 
[0x772dbcca]
(EE) 8: /usr/lib/xorg/Xorg (_start+0x2a) [0x5559cc9a]
(EE) 
(EE) Segmentation fault at address 0x124

# Unstable amd64 qemu VM 2020-09-23

apt update
apt dist-upgrade


apt install systemd-coredump gdb xserver-xorg xterm openbox


/usr/bin/Xorg








root@debian:~# gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'display/i 
$pc' -ex 'b *xf86MergeOutputClassOptions+31' -ex 'run' -ex 'print/x $edx' -ex 
'set $edx = 1' -ex 'b *xf86MergeOutputClassOptions+288' -ex 'cont' -ex 'print/x 
$rdx' -ex 'set $rdx=0' -ex 'generate-core /tmp/xorg-core' -ex 'bt' -ex 'detach' 
-ex 'quit' --args /usr/lib/xorg/Xorg 
Reading symbols from /usr/lib/xorg/Xorg...
Reading symbols from 
/usr/lib/debug/.build-id/86/86f2627d86f090b258bc6477b49359b2475a83.debug...
1: x/i $pc

Breakpoint 1 at 0xb6d0f: file 
../../../../../../hw/xfree86/common/xf86platformBus.c, line 361.
Starting program: /usr/lib/xorg/Xorg 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

X.Org X Server 1.20.9
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.19.0-10-amd64 x86_64 Debian
Current Operating System: Linux debian 5.8.0-1-amd64 #1 SMP Debian 5.8.7-1 
(2020-09-05) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.8.0-1-amd64 
root=UUID=c9e90f0f-a043-45af-bda9-4a7fb7b42490 ro quiet
Build Date: 31 August 2020  03:49:48PM
xorg-server 2:1.20.9-1 (https://www.debian.org/support) 
Current version of pixman: 0.36.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Sep 23 22:02:12 2020
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

Breakpoint 1, 0x5560ad0f in xf86MergeOutputClassOptions (entityIndex=0, 
options=options@entry=0x55800f90) at 
../../../../../../hw/xfree86/common/xf86platformBus.c:361
361 ../../../../../../hw/xfree86/common/xf86platformBus.c: Datei oder 
Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x5560ad0f : cmp$0x1,%edx
$1 = 0x3
Breakpoint 2 at 0x5560ae10: file 
../../../../../../hw/xfree86/common/xf86platformBus.c, line 367.
Continuing.

Breakpoint 2, 0x5560ae10 in 

Bug#958520: lighttpd: remove usage of 'su' in crontab

[Glenn Strauss]

Thanks for the report and suggestion.

As you know, a patch has been pending since May
https://salsa.debian.org/debian/lighttpd/-/commit/744b38fd5c4c4c11123733d1a5f1239a5a9b5a0d

Bug#964115: Web browser video playback broken in bullseye

[Chris Hofstaedtler]

Hello Ryan Goodfellow,

thank you for your report. However, please see below.

* Ryan Goodfellow :
> Video playback does not seem to be working in any browser in Debian
> Bullseye.
> 
>* What led up to the situation?
> apt update
> apt dist-upgrade
[..]
>- Chromium crashes, which seems to be related to ffmpeg 4.3
>  (https://bugs.chromium.org/p/chromium/issues/detail?id=1095962)
>- Chrome and Firefox play video at an infinitesimal rate
[..]

> Debian Release: bullseye/sid
> Kernel: Linux 5.7.0-1-amd64 (SMP w/128 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE

You are running Debian "testing" in a quite advanced configuration.
In such cases, we really need more specific bug reports; you
mentioned a Chromium bug - is it relevant? Did you try the patches
suggested there? What is a likely cause on the Firefox side?

If needed, please find help - also with further diagnosing - at more
appropiate user help venues first. We have list a here:
   https://www.debian.org/support
Especially helpful tend to be: IRC, the mailing lists or 
   http://forums.debian.net/ .

Thank you for your understanding,
Chris

Bug#970819: linux-image-4.19.0-10-amd64: Suspend and hibernate fail to work

[Cameron DeCoster]

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

Dear Maintainer,

I'm running Debian 10 on by Dell Latitude 7490. It recently updated to kernel
4.19.0-10 and the suspend and hibernate functions stopped working. I noticed
this when I opened my laptop after closing it previously to engage suspend. The
screen stayed off and the system was non-responsive. I had to do a hard reboot
to get things working again. Upon testing, I also found that this happens when
suspending or hibernating from the power off menu. I tried booting with the
previous kernel, 4.19.0-9, and suspend and hibernate started working again. I
did some searching online and found this report that could be caused by a
similar problem:
https://www.dell.com/community/Latitude/Latitude-7490-CPU-failure-occurs-after-
sleep/td-p/7316847

I'm happy to provide more information if it's needed. Thank you.

Cam



-- Package-specific info:
** Version:
Linux version 4.19.0-10-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-amd64 
root=UUID=fb6ca44e-dd7c-4ed6-b141-e25c6e73aa4d ro quiet

** Not tainted

** Kernel log:
[5.019467] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[5.025504] input: Dell WMI hotkeys as 
/devices/platform/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input20
[5.142083] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: 
(null)
[5.149233] Intel(R) Wireless WiFi driver for Linux
[5.149234] Copyright(c) 2003- 2015 Intel Corporation
[5.149642] iwlwifi :02:00.0: enabling device ( -> 0002)
[5.167691] iwlwifi :02:00.0: firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[5.168374] iwlwifi :02:00.0: loaded firmware version 36.9f0a2d68.0 
op_mode iwlmvm
[5.182289] input: DELL081C:00 044E:121F Mouse as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-DELL081C:00/0018:044E:121F.0002/input/input21
[5.182408] input: DELL081C:00 044E:121F Touchpad as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-DELL081C:00/0018:044E:121F.0002/input/input22
[5.182500] input: DELL081C:00 044E:121F UNKNOWN as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-DELL081C:00/0018:044E:121F.0002/input/input23
[5.182564] hid-multitouch 0018:044E:121F.0002: input,hidraw1: I2C HID v1.00 
Mouse [DELL081C:00 044E:121F] on i2c-DELL081C:00
[5.191966] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3246: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[5.191969] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[5.191971] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[5.191972] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[5.191973] snd_hda_codec_realtek hdaudioC0D0:inputs:
[5.191975] snd_hda_codec_realtek hdaudioC0D0:  Headset Mic=0x19
[5.191977] snd_hda_codec_realtek hdaudioC0D0:  Headphone Mic=0x1a
[5.191979] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[5.209749] audit: type=1400 audit(1600891583.780:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=685 comm="apparmor_parser"
[5.210251] audit: type=1400 audit(1600891583.780:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=684 
comm="apparmor_parser"
[5.210255] audit: type=1400 audit(1600891583.780:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=684 comm="apparmor_parser"
[5.210580] audit: type=1400 audit(1600891583.780:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/snapd/snap-confine" pid=686 comm="apparmor_parser"
[5.210583] audit: type=1400 audit(1600891583.780:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=686 
comm="apparmor_parser"
[5.212372] audit: type=1400 audit(1600891583.784:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=689 comm="apparmor_parser"
[5.212603] audit: type=1400 audit(1600891583.784:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=698 comm="apparmor_parser"
[5.213170] audit: type=1400 audit(1600891583.784:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=683 comm="apparmor_parser"
[5.213992] audit: type=1400 audit(1600891583.784:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=700 
comm="apparmor_parser"
[5.295762] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 
8265, REV=0x230
[5.357424] intel_rapl: Found 

Bug#970386: dovecot-imapd: assertion failure in message_part_finish when searching large folder

[Noah Meyerhans]

Control: tags -1 + upstream fixed-upstream buster stretch

On Wed, Sep 23, 2020 at 08:41:19AM -0700, Noah Meyerhans wrote:
> >  Sep 21 14:04:00 hostname dovecot:
> >  imap(username)<29488>: Panic: file message-parser.c:
> >  line 174 (message_part_finish): assertion failed:
> >  (ctx->nested_parts_count > 0)
> > 
> >Oh, right, this is fixed
> >by: 
> > [2]https://github.com/dovecot/core/commit/a668d767a710ca18ab6e7177d8e8be22a6b024fb
> 
> Well this looks promising.  Thanks!  Will look into cherry-picking this 
> change.

Confirmed that this fixes the crash in both stretch and buster.  I'll
prepare an update targeting buster for the 10.7 release.  The stretch
release will go through the LTS process.

noah

Bug#947833: Emergency shell unusable with root login disabled

[Benjamin Moody]

In bug #802211, Michael Biebl writes:
> Systemd now provides a mechanism to set the desired behaviour.
> It is now up to the installer or admin to set this up accordingly.

I think the mechanism he's referring to is to set an environment
variable SYSTEMD_SULOGIN_FORCE=1, which will cause systemd to
invoke sulogin with the --force option (i.e., if the root account
is locked or has no password, then log in without asking for a
password.)  See .

Personally I'm not sure this is the best idea - it'd be better to ask
for the username and password of somebody allowed to use sudo.  But if
that's too complicated/fragile to implement easily, then falling back
to root access on the console without a password is probably better
than making the system completely unusable (unless you can boot from
an alternate device or modify the bootloader arguments.)

So in the absence of a better solution, the installer probably ought
to enable SYSTEMD_SULOGIN_FORCE=1 if the administrator chooses not to
set a root password.

Bug#963846: bugs.debian.org: usb-audio : Lexicon Omega only 2 analog inputs in Debian 10, while showing 4 analog inputs in Debian 9

[Chris Hofstaedtler]

Control: reassign -1 jackd

Reassigning to jackd (metapackage), as it's not clear (to me) which
version of jack is involved, and further details are likely needed.
Hopefully the jack / Debian Multimedia maintainers can figure
something out from here.

Please do not reassign this bug back to general, as bugs only rot
there until "expiration".

Chris

Bug#941745: Tomb 2.6 provides an important fix

[Sven Geuer]

Hello Dominik,

I agree with you that the situation with tomb in stable is
not satisfactory.

Unfortunately the bug was detected to late to get the fix into buster
as buster was already in deep freeze at that time. So, in the end, the
release process led to the current situation.

> I use stable because I expect the chance to things working with
> default

That's understandable but regrettably not fully achievable. I cite from
the buster release notes [1]:

» Contrary to our wishes, there may be some problems that exist in the
release, even though it is declared stable. We've made a list of the
major known problems, and you can always report other issues to us. «

[1]: https://www.debian.org/releases/buster/index.en.html

It is always a good idea to check backports in case a packet in stable
does not work as expected.

Best,
Sven

Am Montag, den 21.09.2020, 17:08 +0200 schrieb Dominik Schmidt-Philipp:
> reached here with the same intention as Joerg Bornemann.
> 
> apparently it is against Debian philosophy to include a version that
> is
> compatible with Debian 10 cryptsetup version. What document do I need
> to
> read to understand the reasoning behind that?
> 
> I use stable because I expect the chance to things working with
> default
> settings to be highest there. tomb in Debian 10 is not usable without
> reading discussions about bugreports. The workaround is both
> difficult to
> remember, and hard to find. Easiest workaround for me was just
> installing
> from source, not using APT. ok for me, but not possible to recommend
> to
> those I usually help out.
> 
> thank you for inclusion in backports though. Hadn't thought of that,
> since
> usually I have no need to use newest version of system-tools.
> 
> kind regards,
> Dom


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

Bug#970510: why3: does not work with current version of cvc4

[Ralf Treinen]

Hello,

On Wed, Sep 23, 2020 at 02:04:24PM +0200, Fabian Wolff wrote:
> And while we're at it, even though this is technically an unrelated
> problem, it also has something to do with SMT solver versions: In the
> autopkgtests control file [0], you have the following code:
> 
>   Tests: why3+z3
>   Depends:why3, z3 (<< 4.8.7)
>   Restrictions: skip-not-installable
> 
> This is not a big issue, because it doesn't block migration of z3
> (unlike the cvc4 failure [1]), you might still want to adjust this
> version restriction, given that the current z3 version in unstable is
> 4.8.9 (unless, of course, there is a reason why why3 won't work with
> more recent versions of z3).

this version constraint is coming from share/provers-detection-data.conf,
so why3 will refuse to work with newer versions of z3, and I am on
myself not able to attest that it is safe to override this check.

-Ralf.

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

[Julian Gilbey]

On Wed, Sep 23, 2020 at 11:09:28AM -0700, tony mancill wrote:
> > dh_strip_nondeterminism gets its timestamp from the debian/changelog
> > file, while strip-nondeterminism strips the timestamps.
> > 
> > So here's a replacement patch which fixes everything except
> > java.naming.jmod.  I have to run now, but will try to figure out
> > tomorrow why that one still breaks.
> 
> I rebuilt with this patch (and also my NONPARALLEL patch) and am able to
> call jlink against all of the modules shipped with the resulting JDK
> binary package.  So this is looking good.
> 
> I'm rebuilding now (without nonparallel) what should be the NMU candidate.

Super!  I wonder, though, why it didn't work for me first time round?
I rebuilt it and it worked the second time, though.  So maybe I
changed something.

Obviously, similar builds will be needed for openjdk-{11,13,14,15}.

Best wishes,

   Julian

Bug#970818: mrpt: FTBFS on mipse64el: E: Build killed with signal TERM after 150 minutes of inactivity

[Sebastian Ramacher]

Source: mrpt
Version: 1:2.1.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: 

Builds of mrpt on mips64el run into a timeout:
| [ 84%] Building CXX object 
libs/slam/CMakeFiles/slam.dir/src/registerAllClasses.cpp.o
| cd /<>/obj-mips64el-linux-gnuabi64/libs/slam && /usr/bin/c++ 
-Dslam_EXPORTS -I/usr/include/suitesparse -I/<>/libs/slam/src 
-I/<>/libs/slam/include -I/<>/libs/vision/include 
-I/<>/libs/obs/include -I/<>/libs/opengl/include 
-I/<>/libs/poses/include -I/<>/libs/bayes/include 
-I/<>/libs/math/include -I/<>/libs/core/include 
-I/<>/obj-mips64el-linux-gnuabi64/include/mrpt-configuration 
-I/<>/libs/containers/include 
-I/<>/libs/typemeta/include 
-I/<>/libs/serialization/include 
-I/<>/libs/rtti/include -I/<>/libs/random/include 
-I/<>/libs/system/include 
-I/<>/libs/nanoflann/include 
-I/<>/libs/config/include -I/<>/libs/expr/include 
-I/<>/libs/img/include -I/<>/libs/io/include 
-I/<>/libs/tfest/include -I/<>/libs/maps/include 
-I/<>/libs/graphs/include -isystem /usr/include/eigen3 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -O3 -DNDEBUG -fPIC 
-Wall -Wabi=11 -Wno-long-long -Wno-variadic-macros -Wshadow -Wreturn-local-addr 
-Werror=return-local-addr -Wno-ignored-attributes -Wno-int-in-bool-context 
-Wno-write-strings -Wreturn-type -Werror=return-type -Wformat 
-Werror=format-security -Wextra -Wtype-limits -Wcast-align -Wparentheses 
-Wno-unused-parameter -mtune=native -O3 -fPIC -std=gnu++17 -o 
CMakeFiles/slam.dir/src/registerAllClasses.cpp.o -c 
/<>/libs/slam/src/registerAllClasses.cpp
| [ 84%] Building CXX object 
libs/slam/CMakeFiles/slam.dir/src/slam-precomp.cpp.o
| cd /<>/obj-mips64el-linux-gnuabi64/libs/slam && /usr/bin/c++ 
-Dslam_EXPORTS -I/usr/include/suitesparse -I/<>/libs/slam/src 
-I/<>/libs/slam/include -I/<>/libs/vision/include 
-I/<>/libs/obs/include -I/<>/libs/opengl/include 
-I/<>/libs/poses/include -I/<>/libs/bayes/include 
-I/<>/libs/math/include -I/<>/libs/core/include 
-I/<>/obj-mips64el-linux-gnuabi64/include/mrpt-configuration 
-I/<>/libs/containers/include 
-I/<>/libs/typemeta/include 
-I/<>/libs/serialization/include 
-I/<>/libs/rtti/include -I/<>/libs/random/include 
-I/<>/libs/system/include 
-I/<>/libs/nanoflann/include 
-I/<>/libs/config/include -I/<>/libs/expr/include 
-I/<>/libs/img/include -I/<>/libs/io/include 
-I/<>/libs/tfest/include -I/<>/libs/maps/include 
-I/<>/libs/graphs/include -isystem /usr/include/eigen3 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -O3 -DNDEBUG -fPIC 
-Wall -Wabi=11 -Wno-long-long -Wno-variadic-macros -Wshadow -Wreturn-local-addr 
-Werror=return-local-addr -Wno-ignored-attributes -Wno-int-in-bool-context 
-Wno-write-strings -Wreturn-type -Werror=return-type -Wformat 
-Werror=format-security -Wextra -Wtype-limits -Wcast-align -Wparentheses 
-Wno-unused-parameter -mtune=native -O3 -fPIC -std=gnu++17 -o 
CMakeFiles/slam.dir/src/slam-precomp.cpp.o -c 
/<>/libs/slam/src/slam-precomp.cpp
| E: Build killed with signal TERM after 150 minutes of inactivity

See
https://buildd.debian.org/status/fetch.php?pkg=mrpt=mips64el=1%3A2.1.0-1=1600889689=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#970817: ITP: python-html-sanitizer - HTML sanitizer with more HTML fragment transforms

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python-html-sanitizer
  Version  : 1.9.1
  Upstream Author  : Matthias Kestenholz 
* Url  : https://github.com/matthiask/html-sanitizer
* Licenses : BSD-3-Clause~Feinheit
  Programming Lang : Python
  Section  : python

 This is an allowlist-based and very opinionated HTML sanitizer
 that can be used both for untrusted and trusted sources.
 It attempts to clean up the mess
 made by various rich text editors and or copy-pasting
 to make styling of webpages simpler and more consistent.
 It builds on the excellent HTML cleaner in lxml
 to make the result both valid and safe.
 .
 HTML sanitizer goes further than e.g. bleach
 in that it not only ensures that content is safe
 and tags and attributes conform to a given allowlist,
 but also applies additional transforms to HTML fragments.

This package is needed by matrix-mirage.

I plan to maintain this package myself,
keeping debianization in following Git repository:

 https://salsa.debian.org/debian/python-html-sanitizer.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#970744: ben: please provide machine-parseable version of transition status

[Sebastian Ramacher]

On 2020-09-23 20:52:03 +0200, Sebastian Ramacher wrote:
> Hi Stéphane
> 
> On 2020-09-23 09:42:27 +0200, Stéphane Glondu wrote:
> > Le 22/09/2020 à 22:12, Sebastian Ramacher a écrit :
> > > thanks for maintaining ben. In additiona to the HTML output, it would be
> > > great to have the same information as machine-parseable file. With such
> > > a file one could feed other tools to further process the info produced
> > > by ben, e.g., to produce a list of binNMUs.
> > 
> > Did you know that there were a text output? Probably not what you mean
> > by "machine-parseable", but maybe easier to parse than the HTML output.
> 
> No, I didn't. I work with the HTML output on release.debian.org most of
> the time.
> 
> > I'm willing to implement another output format. What would you like?
> > Could you provide an example?
> 
> A YAML file with a list of the packages including versions, their
> dependency lievel, and the state on the architectures would suffice.
> Additionally, info on whether they are only in sid and if they produce
> MA: same binaries would be helpful.
> 
> It could look like the following:
> 
> packages:
> - dependency_level: 3
>   ma_same: true
>   package: vlc
>   sid_only: false
>   state:
> amd64: good
> arm64: partial
> i386: bad
>   version: 3.0.11.1-2
> - dependency_level: 2
>   ma_same: false
>   package: ffmpeg
>   sid_only: true
>   state:
> amd64: good
> arm64: good
> armel: good
> armhf: good
> i386: good
> mips64el: bad
> mipsel: partial
> ppc64el: good
> s390x: good
>   version: 7:4.3.1-3
> transition: auto-test

Oh, and also a flag for Architecture: all packages (e.g., arch_all: true or 
false).

Cheers

> 
> Architectures were the sate is unknown could be skipped. Thanks for
> considering.
> 
> Cheers
> -- 
> Sebastian Ramacher



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#970816: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2+deb10u1

[Yves-Alexis Perez]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,
would it be possible to allow a new libimobiledevice version in Buster?

[ Reason ]

the recently released iOS (and ipadOS) 14 updates some protocols version
used for communication between a host and a device, especially debug,
backup and snapshot services. Upstream has updated the library, I've
already uploaded a fixed version in stable (and it has migrated to
testing).

I backported some of the changes to stable (the snapshot and backup
protocols versions, unfortunately the debug part would require
backporting others commits).

[ Impact ]
Backup, snapshot and debug services are broken. I think backup is the
most problematic one.

[ Tests ]
I've checked the backup part is fixed with iOS 14 on stable.

[ Risks ]
Code is rather simple (just protocol version change actually). I wasn't
able to test it on previous iOS version yet but an user did test on iOS
5 and reported success on github:
https://github.com/libimobiledevice/libimobiledevice/commit/b5d575c118ecfc2afcb12739433e916527182327#commitcomment-42388557

[ 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 (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Two patches are added, updating the protocol version number in the
source.

Regards,
-- 
Yves-Alexis

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (450, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Differences in libimobiledevice between 1.2.1~git20181030.92c5462-2 and 
1.2.1~git20181030.92c5462-2+deb10u1
diff -Nru libimobiledevice-1.2.1~git20181030.92c5462/debian/changelog 
libimobiledevice-1.2.1~git20181030.92c5462/debian/changelog
--- libimobiledevice-1.2.1~git20181030.92c5462/debian/changelog 2019-09-29 
18:48:58.0 +0200
+++ libimobiledevice-1.2.1~git20181030.92c5462/debian/changelog 2020-09-23 
20:24:18.0 +0200
@@ -1,3 +1,9 @@
+libimobiledevice (1.2.1~git20181030.92c5462-2+deb10u1) buster; urgency=medium
+
+  * d/patches: partial support for iOS 14
+
+ -- Yves-Alexis Perez   Wed, 23 Sep 2020 20:24:18 +0200
+
 libimobiledevice (1.2.1~git20181030.92c5462-2) stable; urgency=medium
 
   * d/patches: properly handle partial SSL writes
diff -Nru 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0004-mobilebackup2-Set-DeviceLink-version-to-400-to-suppo.patch
 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0004-mobilebackup2-Set-DeviceLink-version-to-400-to-suppo.patch
--- 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0004-mobilebackup2-Set-DeviceLink-version-to-400-to-suppo.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0004-mobilebackup2-Set-DeviceLink-version-to-400-to-suppo.patch
   2020-09-23 20:24:18.0 +0200
@@ -0,0 +1,21 @@
+From: Nikias Bassen 
+Date: Fri, 7 Aug 2020 00:50:46 +0200
+Subject: mobilebackup2: Set DeviceLink version to 400 to support iOS 14b4+
+
+---
+ src/mobilebackup2.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/mobilebackup2.c b/src/mobilebackup2.c
+index 08ce22b..5b3b4fb 100644
+--- a/src/mobilebackup2.c
 b/src/mobilebackup2.c
+@@ -27,7 +27,7 @@
+ #include "device_link_service.h"
+ #include "common/debug.h"
+ 
+-#define MBACKUP2_VERSION_INT1 300
++#define MBACKUP2_VERSION_INT1 400
+ #define MBACKUP2_VERSION_INT2 0
+ 
+ #define IS_FLAG_SET(x, y) ((x & y) == y)
diff -Nru 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0005-screenshotr-Set-DeviceLink-version-to-400-to-support.patch
 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0005-screenshotr-Set-DeviceLink-version-to-400-to-support.patch
--- 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0005-screenshotr-Set-DeviceLink-version-to-400-to-support.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libimobiledevice-1.2.1~git20181030.92c5462/debian/patches/0005-screenshotr-Set-DeviceLink-version-to-400-to-support.patch
   2020-09-23 20:24:18.0 +0200
@@ -0,0 +1,21 @@
+From: Nikias Bassen 
+Date: Mon, 10 Aug 2020 15:39:56 +0200
+Subject: screenshotr: Set DeviceLink version to 400 to support iOS 14b4+
+
+---
+ src/screenshotr.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/screenshotr.c b/src/screenshotr.c
+index 5c4a53f..bfefdee 100644
+--- a/src/screenshotr.c
 b/src/screenshotr.c
+@@ -27,7 +27,7 @@
+ #include "device_link_service.h"
+ #include "common/debug.h"
+ 

Bug#961373: slic3r-prusa FTBFS on armhf: cc1plus: out of memory

[Gregor Riepl]

> cc1plus: out of memory allocating 9048820 bytes after a total of 77602816 
> bytes

How about increasing the memory on the build machine or preventing a
parallel make?

90MB memory usage doesn't sound dramatic to me.

Bug#774995: dosage -- comic strip downloader and archive

[Fábio Junior - Digital Comics]

retitle 774995 dosage -- comic strip downloader and archive
owner 774995 fabio.jun...@digitalcomics.com.br

Bug#966701: Driverless printing in buster via ipp-usb

[Brian Potkin]

I would like the following version to replace previous offering:


USB connected printers and driverless printing
--

The Release Notes for Debian 10 briefly describe the driverless printing
situation implemented via CUPS and cups-filters. [1] The changes apply to
modern printers connected by ethernet or wireless. [2]

The release of Debian 11 sees the inclusion of ipp-usb in the stable
archive. ipp-usb is recommended by cups-daemon and utilises the
vendor-neutral IPP-over-USB protocol that is supported by many modern
printers. ipp-usb allows a USB device to be seen and treated as a network
device. The outcome is that driverless printing is extended to include USB
connected printers. The specifics are outlined on the wiki. [3]

The systemd service file included in the ipp-usb package starts the
ipp-usb daemon when a printer is plugged in. A USB connected printer now
becomes available to print to, either by being auto-setup by cups-browsed,
which is the default technique, or being manually installed [4] with a
local driverless print queue.

The use of vendor printer drivers, free and non-free, becomes unnecessary
with networked and USB connected printers.


[1] 
https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#driverless-printing
[2] https://wiki.debian.org/CUPSQuickPrintQueues
[3] https://wiki.debian.org/CUPSDriverlessPrinting.
[4] https://wiki.debian.org/SystemPrinting

Cheers,

Brian.

Bug#970744: ben: please provide machine-parseable version of transition status

[Sebastian Ramacher]

Hi Stéphane

On 2020-09-23 09:42:27 +0200, Stéphane Glondu wrote:
> Le 22/09/2020 à 22:12, Sebastian Ramacher a écrit :
> > thanks for maintaining ben. In additiona to the HTML output, it would be
> > great to have the same information as machine-parseable file. With such
> > a file one could feed other tools to further process the info produced
> > by ben, e.g., to produce a list of binNMUs.
> 
> Did you know that there were a text output? Probably not what you mean
> by "machine-parseable", but maybe easier to parse than the HTML output.

No, I didn't. I work with the HTML output on release.debian.org most of
the time.

> I'm willing to implement another output format. What would you like?
> Could you provide an example?

A YAML file with a list of the packages including versions, their
dependency lievel, and the state on the architectures would suffice.
Additionally, info on whether they are only in sid and if they produce
MA: same binaries would be helpful.

It could look like the following:

packages:
- dependency_level: 3
  ma_same: true
  package: vlc
  sid_only: false
  state:
amd64: good
arm64: partial
i386: bad
  version: 3.0.11.1-2
- dependency_level: 2
  ma_same: false
  package: ffmpeg
  sid_only: true
  state:
amd64: good
arm64: good
armel: good
armhf: good
i386: good
mips64el: bad
mipsel: partial
ppc64el: good
s390x: good
  version: 7:4.3.1-3
transition: auto-test

Architectures were the sate is unknown could be skipped. Thanks for
considering.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#963392: [Help] Re: r-cran-rstanarm: FTBFS: error: (converted from warning) TBB library not found.

[Shayan Doust]

Hello again Andreas,

This [commit] now rectifies the build issue for r-cran-prophet.

I can build r-cran-prophet successfully after re-building r-cran-rstan with the
new patch.

Within r-cran-prophet:
$ autopkgtest . -- null

[TRUNCATED]

/usr/bin/ld: cannot find -lStanHeaders
collect2: error: ld returned 1 exit status
make: *** [/usr/share/R/share/make/shlib.mk:6: sourceCpp_2.so] Error 1
-- 2. Error: (unknown) (@test_stan_functions.R#9)  -
$ operator is invalid for atomic vectors
Backtrace:
 1. base::tryCatch(...)
 2. base:::tryCatchList(expr, classes, parentenv, handlers)
 3. base:::tryCatchOne(expr, names, parentenv, handlers[[1L]])
 4. value[[3L]](cond)
 5. rstan::expose_stan_functions(...)

== testthat results  ===
[ OK: 160 | SKIPPED: 0 | WARNINGS: 3 | FAILED: 2 ]
1. Error: (unknown) (@test_prophet.R#9)
2. Error: (unknown) (@test_stan_functions.R#9)

There exists some failed tests, however 160 pass!

Kind regards,
Shayan Doust


[commit]:
https://salsa.debian.org/r-pkg-team/r-cran-rstan/-/commit/7351289242ba080c112b1c15784e57f154a79076


0x6D7D441919D02395.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#969436: Fixing wrong changelog entry

[Paul Gevers]

Hi Keith,

On 23-09-2020 15:17, Keith Max wrote:
> This small mess has been existing couple of days now. Is it possible to
> fix this package please? There are a bunch of packages stuck in unstable
> because of this situation this package is in.
>  
> If I'm correct, the changelog of -2 closed the wrong bug number. Then
> the wrong changelog entry was fixed on the source repo, but no new
> upload was made to unstable with the actual corrected changelog. So
> based on the previous upload inlcuding the wrong changelog the BTS has
> determined that this serious bug is still applicable to current upload.

The bug number issue has been fixed in the bts correctly and no action
is required regarding that.

> Is it possible to do a corrected upload please to correct the changelog
> also in the actual package, not just in the source repo?

It's bug 970798 that's blocking net-snmp, or rather, the issue it's
reporting. In other words, the source doesn't need any change, the only
issue is that the binaries need to be built on the build daemons and
that requires an upload (without changes is good enough). I'll do that
if Craig doesn't respond in one or two days.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#774995: ITA: dosage -- comic strip downloader and archive

[Fábio Junior - Digital Comics]

I want to adopt this package.

Thanks in advance.

Bug#970815: provide .desktop file so fstl could be added as an application to open files in Files GUI

[Yaroslav Halchenko]

Package: fstl
Version: 0.9.3-1+b1
Severity: wishlist

Subject

Thanks! ;)

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable-updates'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/12 CPU cores)
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=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fstl depends on:
ii  libc62.30-4
ii  libgcc-s1 [libgcc1]  10-20200418-1
ii  libgcc1  1:10-20200418-1
ii  libgl1   1.3.0-7
ii  libgl1-mesa-dri  20.1.5-1
ii  libqt5core5a 5.14.2+dfsg-4
ii  libqt5gui5   5.14.2+dfsg-4
ii  libqt5opengl55.14.2+dfsg-4
ii  libqt5widgets5   5.14.2+dfsg-4
ii  libstdc++6   10-20200418-1

fstl recommends no packages.

fstl suggests no packages.

-- debconf-show failed

Bug#970814: ITP: Mirage -- desktop IM client for the Matrix protocol

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : matrix-mirage
  Version  : 0.6.4
  Upstream Author  : miruka 
* Url  : https://github.com/mirukana/mirage
* Licenses : Apache-2.0,Expat,LGPL-3+ (Effective: GPL-3+)
  Programming Lang : C++, Python
  Section  : net

 Mirage is a fancy, customizable, keyboard-operable chat client
 for the Matrix protocol,
 written in Qt/QML and Python.
 .
 Notable Matrix features supported:
  * Markdown parsing when sending messages
  * End-to-end encryption
  * Multiple concurrent accounts
  * Session administration
  * Room administration
 .
 Notable Matrix features missing:
  * Communities (a.k.a. groups of rooms)
  * Audio/video chat
 .
 Matrix is an open, federated communications protocol.

I plan to maintain this package in the Matrix team,
keeping debianization in following Git repository:

 https://salsa.debian.org/matrix-team/matrix-mirage.git

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#970813: ITA: dosage -- comic strip downloader and archiver

[Fabio Junior]

Package: dosage
Version: 2.15-4
Severity: normal
X-Debbugs-Cc: fabio.jun...@digitalcomics.com.br

Dear Maintainer,

I want to adopt this package.

Thanks in advance.

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

Kernel: Linux 5.8.0-1-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 dosage depends on:
ii  python3   3.8.2-3
ii  python3-requests  2.23.0+dfsg-2

dosage recommends no packages.

Versions of packages dosage suggests:
pn  python3-argcomplete  

-- no debconf information

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

[tony mancill]

On Wed, Sep 23, 2020 at 01:45:23PM +0100, Julian Gilbey wrote:
> On Mon, Sep 21, 2020 at 10:49:24PM -0700, tony mancill wrote:
> > > * Run the sha256sum command (protected with a '-' in case it fails!)
> > >   at several points in the build-arch and install targets to see when
> > >   the hashes change, if at all.
> > 
> > Good idea.  I am doing that now, and also building without parallelism,
> > since I'd like to see the build logs for a single jmod being built
> > without those being interspersed with others.  Specifically, I'd like to
> > see the order in which the jmods are built and the hashes recorded.
> > Somewhere along the line, we must be invoking jmod hash / --hash-modules
> > on a jmod before strip-nondeterminism was invoked. 
> > [...]
> > Thank you for the ideas.  I will keep working on it.
> 
> Aargh, I've found what I did that was different from what I *said* I
> did: I left in the dh_strip_nondeterminism -Xjmods option.  Leaving
> that option out breaks it: it turns out that dh_strip_nondeterminism
> sets a different timestamp from strip-nondeterminism.
> 
> dh_strip_nondeterminism gets its timestamp from the debian/changelog
> file, while strip-nondeterminism strips the timestamps.
> 
> So here's a replacement patch which fixes everything except
> java.naming.jmod.  I have to run now, but will try to figure out
> tomorrow why that one still breaks.

I rebuilt with this patch (and also my NONPARALLEL patch) and am able to
call jlink against all of the modules shipped with the resulting JDK
binary package.  So this is looking good.

I'm rebuilding now (without nonparallel) what should be the NMU candidate.

Thanks!
tony

Bug#970743: marked as pending in lintian

[Louis-Philippe Véronneau]

On Wed, 23 Sep 2020 19:07:27 +0200 Mattia Rizzolo  wrote:
> On Wed, Sep 23, 2020 at 04:53:00PM +, Chris Lamb wrote:
> > Control: tag -1 pending
> > 
> > https://salsa.debian.org/lintian/lintian/-/commit/5080c0068ffc4a9ddee92022a91d0c2ff53e56d1
> > 
> > 
> > Update the expected Vcs-{Browser,Git} location of modules and applications 
> > maintained by the Python module team. (Closes: #970743)
> > 
> 
> However it has to be noted that together with the VCS location, also the
> email and maintainer address changed.
> That now should be
> Debian Python Team 
> 
> So I wonder if instead those 2 tags should be replaced by a bunch of
> old-papt-maintainer/old-papt-vcs/old-dpmt-vcs/old-dpmt-maintainer that
> should all point toward the new name and new VCS location.

I've set aside some time to have a look at this today :)

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#970812: glances: systemd service starting unrestricted listener on 0.0.0.0:61209 by default

[compositiv GmbH]

Package: glances
Version: 3.1.0-1
Severity: important

Dear Maintainer,

when changing the service file structure from SysVinit to systemd on Debian 10 
(Buster), a security issue was introduced:
The service unit file is enabled by default without explicitly defining the 
bind address as localhost or implementing any other form of access control.  
Thus, the service is exposed to the whole network and any compatible client can 
connect and gather an extensive amount of data from the system.

This behaviour was not given in previous Debian releases, where execution of 
the listener was disabled through /etc/default/glances by default (RUN="false").

The issue is known since Fri, 11 Oct 2019 and has been fixed with upstream 
release 3.1.3-1 on Fri, 17 Jan 2020 in testing/unstable (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942162), but has never been 
backported to stable ever since, hence the renewed bug report.

Any of the following would be an acceptable solution:
- disable the service by default (previous behaviour, service is not required 
for connection to localhost anyway)
- configure the bind address to 127.0.0.1
- implement another restriction like setting a random password on installation

Kind regards,
  David Winterstein

compositiv GmbH
Hammer Deich 30
20537 Hamburg
Tel: +49 40 6094349 0
Fax: +49 40 6094349 40
Web: www.compositiv.com
Mail: i...@compositiv.com

Geschäftsführer Matthias Krawen
Amtsgericht Hamburg - HRB 122540
USt.-IdNr: DE282432834



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

Kernel: Linux 4.19.0-10-amd64 (SMP w/48 CPU cores)
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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages glances depends on:
ii  adduser3.118
ii  lsb-base   10.2019051400
ii  node-normalize.css 8.0.1-3
ii  python33.7.3-1
ii  python3-pkg-resources  40.8.0-1
ii  python3-psutil 5.5.1-1

Versions of packages glances recommends:
ii  hddtemp 0.3-beta15-53
ii  lm-sensors  1:3.5.0-3
ii  python3-bottle  0.12.15-2
ii  python3-docker  3.4.1-4
ii  python3-influxdb5.2.0-1
ii  python3-matplotlib  3.0.2-2
ii  python3-netifaces   0.10.4-1+b1
ii  python3-pysnmp4 4.4.6+repack1-1
ii  python3-pystache0.5.4-6

Versions of packages glances suggests:
pn  glances-doc  

-- no debconf information

Bug#970811: RFP: python3-sphinx-sitemap -- sphinx sitemap generator extension

[Drew Parsons]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: block 962440 by -1

* Package name: python3-sphinx-sitemap
  Version : 2.2.0
  Upstream Author : Jared Dillard 
* URL : https://github.com/jdillard/sphinx-sitemap
* License : MIT
  Programming Lang: Python
  Description : sphinx sitemap generator extension

A Sphinx extension to generate multiversion and multilanguage
sitemaps.org compliant sitemaps for the HTML version of your Sphinx
documentation.


This package is required in order to build the docs for MDAnalysis.


To be maintained under the Python Package Team alonside other sphinx
extensions.

Bug#963688: neovim-qt: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> Source: neovim-qt
> Version: 0.2.7-3
> Tags: patch

Gentle ping on the above?


Regards,

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

Bug#335925:

[Françoise AGBOBLI-SEMONDZI]

Hi, I have emailed you before but there is no reply
from you, answer when you receive my message ??
FRANÇOISE AGBOBLI SEMONDZI (ESQ).

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Antoine Le Gonidec]

On Wed, 23 Sep 2020 15:54:06 +0800 Paul Wise  wrote:
> This appears to be fixed for me in 81.0-1, can anyone else confirm?

Here it looked like it was fixed right after the update.

But very quickly after that (3 browser restarts), the add-ons are disabled once 
again. Now I’m back to the previous behaviour, with add-ons silently disabled 
on launch.

I get the same behaviour on two distinct Debian Bullseye/Sid, on each one the 
add-ons disabling is back on the third Firefox restart.

Bug#970743: marked as pending in lintian

[Mattia Rizzolo]

On Wed, Sep 23, 2020 at 04:53:00PM +, Chris Lamb wrote:
> Control: tag -1 pending
> 
> https://salsa.debian.org/lintian/lintian/-/commit/5080c0068ffc4a9ddee92022a91d0c2ff53e56d1
> 
> 
> Update the expected Vcs-{Browser,Git} location of modules and applications 
> maintained by the Python module team. (Closes: #970743)
> 

However it has to be noted that together with the VCS location, also the
email and maintainer address changed.
That now should be
Debian Python Team 

So I wonder if instead those 2 tags should be replaced by a bunch of
old-papt-maintainer/old-papt-vcs/old-dpmt-vcs/old-dpmt-maintainer that
should all point toward the new name and new VCS location.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#970773: More info: it works with fakeroot

[Raúl Sánchez Siles]

  Hello:

  I've tried again using the unsquash command under a fakeroot environment. 
In this case uncompression works correctly. So does when done as root. In 
this case this may be a minor bug then.

  Regards,
-- 
Rául Sánchez Siles

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

Bug#970768: torbrowser-launcher: error while checking version number after TorBrowser 10.0 release

[Roger Shimizu]

Dear Lev,

Thanks for your report!

On Wed, Sep 23, 2020 at 4:00 PM Lev Lamberov  wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.2-13
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
>
> Dear Maintainer,
>
> because of faulty version number check, torbrowser-launcher cannot
> correctly handle TorBrowser 10.0 release. Now it shows the following
> error message:
>
> The version of Tor Browser you have installed is earlier than it
> should be, which could be a sign of an attack!
>
> Seems that because of this error it is not possible to install the new
> release of TorBrowser, and installation of it is run everytime when
> running torbrowser-launcher. So, torbrowser-launcher simply doesn't do
> what it should (install and run TorBrowser), which make it unusable.
>
> There is an upstream issued already reported, see #498 [#498], and
> merge request submitted.
>
> [#498] https://github.com/micahflee/torbrowser-launcher/issues/498

I just uploaded 0.3.2-14~exp1 to experimental.
Since I cannot launch TBB after downloading it.
(I'm using buster + backports)
Can you kindly help to confirm it works on your side? Thanks!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#970807: python3-venv is gone

[Matthias Klose]

Package: xonsh
Version: 0.9.20+dfsg-1
Severity: serious
Tags: sid bullseye

This package depends or build-depends on python3-venv, which is gone upstream.
Please remove or re-implement that usage.

Bug#970808: python3-venv is gone

[Matthias Klose]

Package: thonny
Version: 3.2.7-1
Severity: serious
Tags: sid bullseye

This package depends or build-depends on python3-venv, which is gone upstream.
Please remove or re-implement that usage.

Bug#970806: python3-venv is gone

[Matthias Klose]

Package: yubikey-manager
Version: 3.1.1-1
Severity: serious
Tags: sid bullseye

This package depends or build-depends on python3-venv, which is gone upstream.
Please remove or re-implement that usage.

Bug#970809: python3-venv is gone

[Matthias Klose]

Package: pipx
Version: 0.12.3.1-3
Severity: serious
Tags: sid bullseye

This package depends or build-depends on python3-venv, which is gone upstream.
Please remove or re-implement that usage.

Bug#919350: hyperv-daemons: hv_get_dhcp_info, hv_get_dns_info not found

[Noël Köthe]

Package: hyperv-daemons
Version: 4.19.132-1
Followup-For: Bug #919350

Dear Maintainer,

installed hyperv-daemons on a HyperV Debian Buster guest and the log gets
repeated lines about the missing hv_get_dhcp_info and hv_get_dns_info
scripts at the not existing path /usr/libexec/hypervkvpd/

Bug #927384 is a similar problem with the path.

Installing the Buster Backport Package 5.7.10-1~bpo10+1 fixes the problem.

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 hyperv-daemons depends on:
ii  init-system-helpers  1.58
ii  libc62.31-3
ii  lsb-base 11.1.0

hyperv-daemons recommends no packages.

hyperv-daemons suggests no packages.

Bug#970810: python3-venv is gone

[Matthias Klose]

Package: dh-virtualenv
Version: 1.2.1-1
Severity: serious
Tags: sid bullseye

This package depends or build-depends on python3-venv, which is gone upstream.
Please remove or re-implement that usage.

Bug#970805: Unable to mount after burning a CD with wodim

[Bernard, Guy (GE Healthcare)]

Package:cdrkit

Hello,
On Scientific Linux 7.8, I have an issue with wodim-1.1.11.
After burning a CD, it's not possible to mount the media.
I am obliged to eject the media and then reload it manually in order to check 
the content.
Is this issue known? Are there some actions to execute so that I can mount and 
check the content of the burnt media without a manual intervention?

Best Regards
Guy

Bug#968046: Workaround

[Petr Menšík]

I hit this error when just upgrading unstable container some months old.
It as not obvious to me.

Recommended workaround is:
apt-get upgrade python
apt-get upgrade

Is there reason it is not yet fixed?
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

Bug#966846: Kernel panic (4.19.0-10): RIP __cgroup_bpf_run_filter_skb

[Ben Hutchings]

On Tue, 2020-09-22 at 23:52 +0200, Michel Le Bihan wrote:
> Hello,
> 
> I'm a bit late but I also have this issue and it occurs every several
> hours on my server. Here is the trace if anybody is still interested: 
> https://lebihan.pl/files/trace.txt
> 
> When can I expect the new package to be uploaded into stable?

In the point release, at the weekend.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou




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

Bug#970804: awscli: Please package AWS CLI 2.0

[Gregor Riepl]

Package: awscli
Version: 1.18.135-1
Severity: wishlist
X-Debbugs-Cc: onit...@gmail.com

Dear Maintainer,

Please consider packaging version 2.0.x of the AWS CLI.

It contains a few crucial new features that aren't available in version 1.x.

Note that v2 is maintained in a separate branch: https://github.com/aws/aws-
cli/tree/v2
Perhaps these can also be packaged in parallel.

Thanks!



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

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

Versions of packages awscli depends on:
ii  groff   1.22.4-5
ii  python3 3.8.2-3
ii  python3-botocore1.17.22+repack-1
ii  python3-colorama0.4.3-1
ii  python3-docutils0.16+dfsg-3
ii  python3-pyasn1  0.4.8-1
ii  python3-rsa 4.0-4
ii  python3-s3transfer  0.3.3-1
ii  python3-yaml5.3.1-2

awscli recommends no packages.

awscli suggests no packages.

-- no debconf information

Bug#970803: lighttpd: appliation segfaults on start

[Jeff]

Package: lighttpd
Version: 1.4.55-1~bpo10+1
Severity: normal

Dear Maintainer,

  I am running the current version of Raspbian using DietPI on a RPI Zero.
  Installed lighttpd from the Buster-Backports.
  Segfault on start/restart/command line.
  Pretty simple.

-- System Information:
Debian Release: 10.4
Architecture: armhf (armv6l)

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

Versions of packages lighttpd depends on:
ii  libattr1  1:2.4.48-4
ii  libbz2-1.01.0.6-9.2~deb10u1
ii  libc6 2.28-10+rpi1
ii  libfam0   2.7.0-17.3
ii  libpcre3  2:8.39-12
ii  libssl1.1 1.1.1d-0+deb10u3+rpt1
ii  lsb-base  10.2019051400+rpi1
ii  mime-support  3.62
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages lighttpd recommends:
ii  perl5.28.1-6
pn  spawn-fcgi  

Versions of packages lighttpd suggests:
pn  apache2-utils   
pn  lighttpd-doc
pn  lighttpd-mod-authn-gssapi   
pn  lighttpd-mod-authn-pam  
pn  lighttpd-mod-authn-sasl 
pn  lighttpd-mod-cml
pn  lighttpd-mod-geoip  
pn  lighttpd-mod-magnet 
pn  lighttpd-mod-maxminddb  
pn  lighttpd-mod-trigger-b4-dl  
pn  lighttpd-mod-vhostdb-dbi
pn  lighttpd-mod-vhostdb-pgsql  
pn  lighttpd-mod-webdav 
pn  lighttpd-modules-ldap   
pn  lighttpd-modules-mysql  
ii  openssl 1.1.1d-0+deb10u3+rpt1
pn  php-cgi 
pn  rrdtool 

-- no debconf information

Bug#666743: draft implementation for a Multi-Arch: foreign interface to gcc

[Matthias Klose]

On 9/23/20 1:26 PM, Helmut Grohne wrote:
> Hi Matthias,
> 
> thank you for reviewing my patch!
> 
> On Wed, Sep 23, 2020 at 12:48:10PM +0200, Matthias Klose wrote:
>> looking at this patch:
>>
>> -dh_installdocs -p$(p_gdc)
>> -dh_installchangelogs -p$(p_gdc) src/gcc/d/ChangeLog
>> +debian/dh_doclink -p$(p_gdc_n) $(p_xbase)
>>
>> doesn't work, replacing the doc directory with a symlink.
> 
> Please elaborate.
> 
> p_gdc_n is a new package. Nothing is replaced here.
> 
> The calls for p_gdc are not removed. They're moved lower. The docs stay
> right there where they are now.
> 
> The new p_gdc_n package uses a symlink for its doc directory. That
> should be fine.

... which then doesn't work with a separate gdc build.

Bug#963392: [Help] Re: r-cran-rstanarm: FTBFS: error: (converted from warning) TBB library not found.

[Shayan Doust]

Hello Andreas,

I see the error within r-cran-prophet's build.

It seems like this issue stems from r-cran-rstan (as the call stack shows).

Specifically:

$ grep -r "system.file(\"lib\""
R/plugin.R:RcppParallel_pkg_libs <- system.file("lib", .Platform$r_arch,
R/plugin.R:rstan_StanServices <- system.file("lib", .Platform$r_arch,
"libStanServices.a",

I believe the first line (regarding RcppParallel_pkg_libs) is of concern and the
cause as again, the library location assumption is wrong.

I will write a patch for this too, and I'll test anymore findings.

Kind regards,
Shayan Doust


0x6D7D441919D02395.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#970014: [Pkg-pascal-devel] Bug#970014: Workaround proposal

[Frédéric Bonnard]

On Wed, 23 Sep 2020 15:01:55 +0200, Graham Inggs  wrote:
> Hi Frédéric
> 
> On Wed, 23 Sep 2020 at 10:47, Frédéric Bonnard  wrote:
> > Debug info type's recommended setting seems to be dwarf anyway (32/64b).
> > So I've replaced -gs with -gw in components/chmhelp/lhelp/Makefile.fpc.
> > It builds on amd64, i386 and ppc64el at least.
> > I'll send another merge request.
> 
> Works for me!  (on plummer and ubuntu)
> Also ddrescueview now builds on ppc64el as well.  I can't build
> doublecmd yet, because lcl-qt5 wasn't built from src:lazarus on
> ppc64el,  I'm going to see now if I can enable that.

oh right, I didn't realize not all binary packages are built on "any". 2
needs to be enabled (lcl-qt5-2.0 and lazarus-ide-qt5-2.0). And I tested
and they build well on ppc64el.
I'll also tested on ppc64 and provided pie is disabled too, it works
too.
So I'll send another MR for those 2 improvements.

> 
> Regards
> Graham


signature.asc
Description: PGP signature

Bug#970802: gcc-10: armhf: false positive when using -O2 and -Werror=format-truncation

[Julien Grall]

X-Debbugs-CC: i...@xenproject.org
X-Debbugs-CC: h...@knorrie.org
Package: gcc-10
Version: 10.2.0-9
Severity: important

Dear Maintainer,

There was an FTBFS for Xen when building using GCC 10 on armhf (see
bug #9689645 [1]).

After investigation, it looks a problem when with the optimizer in GCC 
for armhf.


The issue was narrowed down to the following code:

42sh> cat test.c
#include 
#include 
#include 

char *tmp(struct dirent *dir_entry)
{
static char file_name[284];

if ( strlen(dir_entry->d_name) < 4 )
return NULL;

snprintf(file_name, sizeof(file_name), "%s",
 dir_entry->d_name);

return file_name;
}

42sh> gcc -Wall -Werror -O2 -c test.c
test.c: In function 'tmp':
test.c:12:45: error: '%s' directive output may be truncated writing 
between 4 and 2147483645 bytes into a region of size 284 
[-Werror=format-truncation=]

   12 | snprintf(file_name, sizeof(file_name), "%s",
  | ^~
test.c:12:5: note: 'snprintf' output between 5 and 2147483646 bytes into 
a destination of size 284

   12 | snprintf(file_name, sizeof(file_name), "%s",
  | ^~~~
   13 |  dir_entry->d_name);
  |  ~~
cc1: all warnings being treated as errors

Removing the length check will allow GCC to compile the object
sucessfully.

Would it be possible to investigate the root cause in GCC?

Cheers,

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: armhf (armv7l)

--
Julien Grall

Bug#970386: dovecot-imapd: assertion failure in message_part_finish when searching large folder

[Noah Meyerhans]

On Wed, Sep 23, 2020 at 01:34:26PM +0300, Timo Sirainen wrote:
>  Sep 21 14:04:00 hostname dovecot:
>  imap(username)<29488>: Panic: file message-parser.c:
>  line 174 (message_part_finish): assertion failed:
>  (ctx->nested_parts_count > 0)
> 
>Oh, right, this is fixed
>by: 
> [2]https://github.com/dovecot/core/commit/a668d767a710ca18ab6e7177d8e8be22a6b024fb

Well this looks promising.  Thanks!  Will look into cherry-picking this change.

noah

Bug#970796: cloud-init: Please add gnupg to Recommends

[Noah Meyerhans]

On Wed, Sep 23, 2020 at 10:57:50AM -0400, Daniel Watkins wrote:
> cloud-init uses gnupg in two ways: directly, to fetch and export keys
> (when specified by ID, see [0]), and via apt-key to add keys to the system
> (whether specified via ID or in full, see [1]).  (Even once we remove
> apt-key usage[2], we will still need it for the former use case.)
> 
> I've just opened a PR[3] to add this to our Ubuntu packaging, and would
> request that you do the same so that Debian users are able to configure
> custom apt sources using cloud-init configuration.
> 
> (My assumption here is that Debian cloud images are built with
> --install-recommends; if not, then you may want to consider ensuring
> that gnupg is present in Debian cloud images via other means.)

This was previously discussed in the context of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910654

Unfortunately, most of the discussion occurred in person at the 2018
cloud team sprint, and wasn't captured in the bug report.  IIRC, at the
time, most of the discussion focused on the apt-key use-case, and there
were enough people who felt strongly that using gpg to fetch keys from a
key server was a sufficiently bad idea, and the same functionality could
be provided by passing a complete public key directly via cloud-config
userdata, that we should support this functionality.  This opinion
wasn't universally held, but it was held strongly enough by enough
people to overrule any dissenting opionions.

Maybe it's worth revisiting this discussion for bullseye?

noah

Bug#666743: draft implementation for a Multi-Arch: foreign interface to gcc

[Helmut Grohne]

Hi Matthias,

thank you for reviewing my patch!

On Wed, Sep 23, 2020 at 12:48:10PM +0200, Matthias Klose wrote:
> looking at this patch:
> 
> - dh_installdocs -p$(p_gdc)
> - dh_installchangelogs -p$(p_gdc) src/gcc/d/ChangeLog
> + debian/dh_doclink -p$(p_gdc_n) $(p_xbase)
> 
> doesn't work, replacing the doc directory with a symlink.

Please elaborate.

p_gdc_n is a new package. Nothing is replaced here.

The calls for p_gdc are not removed. They're moved lower. The docs stay
right there where they are now.

The new p_gdc_n package uses a symlink for its doc directory. That
should be fine.

Helmut

Bug#970801: mtd-utils FTBFS with the nocheck build profile

[Helmut Grohne]

Source: mtd-utils
Version: 1:2.1.1-1.1
Severity: important
Tags: patch ftbfs
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mtd-utils fails to build from source in unstable when building with the
nocheck build profile. The profile drops the cmocka dependency, but
tests remain enabled so configure gives up. That also causes cross
builds to fail. Please consider applying the attached patch.

Helmut
diff --minimal -Nru mtd-utils-2.1.2/debian/changelog 
mtd-utils-2.1.2/debian/changelog
--- mtd-utils-2.1.2/debian/changelog2020-09-08 20:52:53.0 +0200
+++ mtd-utils-2.1.2/debian/changelog2020-09-23 15:12:05.0 +0200
@@ -1,3 +1,10 @@
+mtd-utils (1:2.1.2-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS with nocheck build profile. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 23 Sep 2020 15:12:05 +0200
+
 mtd-utils (1:2.1.2-0.1) unstable; urgency=medium
 
   [ Bastian Germann ]
diff --minimal -Nru mtd-utils-2.1.2/debian/rules mtd-utils-2.1.2/debian/rules
--- mtd-utils-2.1.2/debian/rules2020-09-08 20:52:53.0 +0200
+++ mtd-utils-2.1.2/debian/rules2020-09-23 15:12:05.0 +0200
@@ -2,8 +2,14 @@
 %:
dh $@
 
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+CONFIGURE_ARGS = --enable-test --enable-unit-tests
+else
+CONFIGURE_ARGS = --disable-test --disable-unit-tests
+endif
+
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-test --enable-unit-tests
+   dh_auto_configure -- $(CONFIGURE_ARGS)
 
 # tests are known to pass only on the listed architectures
 ifeq (,$(filter amd64 armel armhf arm64 i386 mipsel s390x 
x32,$(DEB_HOST_ARCH)))

Bug#666743: wrong dependencies

[Matthias Klose]

$ dpkg -I ../gdc-10_10.2.0-9.1_amd64.deb |grep Depends
 Depends: gdc-10-x86-64-linux-gnu (= 10), gcc-10-base (>= 10), g++-10 (>= 10)


this is wrong: gdc-10-x86-64-linux-gnu (= 10)

why are you using these loose versions?

Bug#666743: dpkg-genchanges warnings

[Helmut Grohne]

Hi Matthias,

thank you for reviewing my patch stack.

On Wed, Sep 23, 2020 at 05:26:56PM +0200, Matthias Klose wrote:
> you'll see warnings when dpkg-genchanges runs. looks like you want the
> architecture file to list the one architecture explicitly, not list "any".

Yes. I got this wrong. It's correct for cpp, gcc, and gccgo, but wrong for
gfortran, gdc, gobjc, and gobjc++.

Instead of `Architecture: any`, the correct line is:

Architecture: ifdef(`TARGET',`any',arch_deb)

Thank you for catching this. The next iteration shall fix it.

Helmut

Bug#892058: debian-keyring: please automatically send reminder emails to people whose keys will expire soon

[Gunnar Wolf]

David Prévot dijo [Wed, Sep 23, 2020 at 10:49:33AM -0400]:
> > And we would have everything in place to notify people whose key is
> > to expire soon.
> 
> Wonderful, thank you for working into making (part of) our lives easier!

:-]

I will add this, but not to this script (thinking during
breakfast... The script I modified is part of our test suite, and it'd
be wrong to mark soon-to-expire keys as failing). But I think I will
modify in this same way the mail_expired script - making it not
consume from the no-expired test, but asking directly from gpg.

I also just (!) took notice of this bug report and its history;
although we informally discussed this a long time ago, I'd like to
give _my_ answer to Jonathan's questions¹. Note that they are _my_
take on that, just as ⅓ of the relevant team (where Jonathan is
another ⅓).

¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892058#10

- What email to notify from? I think it can be keyring-maint@d.o. Why
  not? It's not going to be so massive, and if we get bounces... Well,
  they will not be hundreds of them.

- Which mail to notify? I think just the @debian.org address should
  suffice. Yes, we know of some DDs that disable this address, but I
  don't think they are significative enough for us to even notice.

- How often? I often do a mail every time I push out a keyring (which
  is, approximately, one out of three months). I think we could do
  this run on a monthly basis, notifying people that are to expire in
  two or three months time.

- Why is it keyring-maint's responsibility? It is not, but it is a
  service we can perform, much like any other person can. It just
  happens that we have all of the data in our hands.

- How long to care for long expired keys? I often mail everybody with
  an expired key, but it'd be quite easy to have some different mails
  -- Could be along the lines of "Key about to expire, please act now"
  (-2 to 0 months), "Key recently expired" (0 to 3 months), "Do note
  your key has expired" (3 to 12 months), "Key long expired" (12 to 24
  months), and... "Radio silence, please call in MIA".


signature.asc
Description: PGP signature

Bug#970800: lacme: allow direct use challenge-directory .well-known/acme-challenge

[Benjamin Tietz]

Package: lacme
Version: 0.5-1
Severity: wishlist
Tags: patch upstream

Dear Maintainer,

in our setup multiple http-servers can be used to serve a random file.
For the static files, the storage is syncronized filesystem replication.

When lacme creates a challenge-response for a new certificate, it is
unclear, which of the external servers will serve that request. Due to
the replication, all of the servers could have access to the challenge
file, but currently lacme only creates a symlink into a temporary
directory.

The attached patch adds a new configuration option 
`hard-copy-challenge-directory`,
which will drop the temporary file and handles the acme-challenge
directory directly.

best regards

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

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

Versions of packages lacme depends on:
ii  libconfig-tiny-perl   2.23-1
ii  libjson-perl  4.02000-1
ii  libnet-ssleay-perl1.85-2+b1
ii  libtypes-serialiser-perl  1.0-1
ii  libwww-perl   6.36-2
ii  openssl   1.1.1d-1+0~20191009.15+debian9~1.gbpd6badf
ii  perl  5.28.1-6+deb10u1

Versions of packages lacme recommends:
ii  lacme-accountd  0.6-1
ii  liblwp-protocol-https-perl  6.07-2

lacme suggests no packages.

-- Configuration Files:
/etc/lacme/lacme.conf changed [not included]

-- no debconf information

--- a/config/lacme.conf 2020-09-23 14:14:46.274311863 +0200
+++ b/config/lacme.conf 2020-09-23 14:16:19.324643678 +0200
@@ -86,6 +86,10 @@
 #
 #challenge-directory =
 
+# Do not symlink the challenge-directory, but copy the challenge-files
+# explictly
+#hard-copy-challenge-directory = Yes
+
 # username to drop privileges to (setting both effective and real uid).
 # Preserve root privileges if the value is empty (not recommended).
 #
--- a/lacme 2020-09-23 14:16:28.124864204 +0200
+++ b/lacme 2020-09-23 16:14:21.456006087 +0200
@@ -28,6 +28,7 @@
 use Errno 'EINTR';
 use Fcntl qw/F_GETFD F_SETFD FD_CLOEXEC SEEK_SET/;
 use File::Temp ();
+use File::Path 'remove_tree';
 use Getopt::Long qw/:config posix_default no_ignore_case gnu_getopt 
auto_version/;
 use List::Util 'first';
 use POSIX ();
@@ -100,6 +101,7 @@
 webserver => {
 listen=> '/var/run/lacme-www.socket',
 'challenge-directory' => undef,
+'hard-copy-challenge-directory' => 'No',
 user  => 'www-data',
 group => 'www-data',
 command   => '/usr/lib/lacme/webserver',
@@ -315,10 +317,26 @@
 # serve ACME challenge reponses).
 if (defined (my $dir = $conf->{'challenge-directory'})) {
 print STDERR "[$$] Using existing webserver on $dir\n" if $OPTS{debug};
-symlink $tmpdir, $dir or die "Can't symlink $dir -> $tmpdir: $!";
-push @CLEANUP, sub() {
-print STDERR "Unlinking $dir\n" if $OPTS{debug};
-unlink $dir or warn "Warning: Can't unlink $dir: $!";
+if (lc ($conf->{'hard-copy-challenge-directory'} // 'No') eq 'yes') {
+mkdir $dir or die "Can't create directory $dir: $!";
+$tmpdir = $dir;
+push @CLEANUP, sub() {
+my $error = undef;
+   remove_tree($dir, { safe => 1, error => \$error });
+if($error && @$error) {
+for(@$error) {
+my ($file, $message) = %$_;
+   my $msghead = $file?"Error removing $file in":"Error 
while removing";
+warn "$msghead challenge dir $dir: $message\n";
+}
+}
+}
+   } else {
+symlink $tmpdir, $dir or die "Can't symlink $dir -> $tmpdir: $!";
+push @CLEANUP, sub() {
+print STDERR "Unlinking $dir\n" if $OPTS{debug};
+unlink $dir or warn "Warning: Can't unlink $dir: $!";
+}
 }
 }
 elsif (!@sockaddr) {
--- a/config/lacme.conf 2020-09-23 14:14:46.274311863 +0200
+++ b/config/lacme.conf 2020-09-23 14:16:19.324643678 +0200
@@ -86,6 +86,10 @@
 #
 #challenge-directory =
 
+# Do not symlink the challenge-directory, but copy the challenge-files
+# explictly
+#hard-copy-challenge-directory = Yes
+
 # username to drop privileges to (setting both effective and real uid).
 # Preserve root privileges if the value is empty (not recommended).
 #
--- a/lacme 2020-09-23 14:16:28.124864204 +0200
+++ b/lacme 2020-09-23 16:14:21.456006087 +0200
@@ -28,6 +28,7 @@
 use Errno 'EINTR';
 use Fcntl qw/F_GETFD F_SETFD FD_CLOEXEC SEEK_SET/;
 use File::Temp ();
+use File::Path 'remove_tree';
 use 

Bug#666743: dpkg-genchanges warnings

[Matthias Klose]

you'll see warnings when dpkg-genchanges runs. looks like you want the
architecture file to list the one architecture explicitly, not list "any".


dpkg-genchanges: warning: package gdc-10-alpha-linux-gnu in control file but not
in files list
dpkg-genchanges: warning: package gdc-10-arm-linux-gnueabi in control file but
not in files list
dpkg-genchanges: warning: package gdc-10-arm-linux-gnueabihf in control file but
not in files list
dpkg-genchanges: warning: package gdc-10-aarch64-linux-gnu in control file but
not in files list
dpkg-genchanges: warning: package gdc-10-i686-linux-gnu in control file but not
in files list
dpkg-genchanges: warning: package gdc-10-mipsel-linux-gnu in control file but
not in files list
dpkg-genchanges: warning: package gdc-10-mips64-linux-gnuabi64 in control file
but not in files list
dpkg-genchanges: warning: package gdc-10-mips64el-linux-gnuabi64 in control file
but not in files list
dpkg-genchanges: warning: package gdc-10-mips64-linux-gnuabin32 in control file
but not in files list
dpkg-genchanges: warning: package gdc-10-powerpc-linux-gnu in control file but
not in files list
dpkg-genchanges: warning: package gdc-10-powerpc64-linux-gnu in control file but
not in files list
dpkg-genchanges: warning: package gdc-10-powerpc64le-linux-gnu in control file
but not in files list
dpkg-genchanges: warning: package gdc-10-m68k-linux-gnu in control file but not
in files list
dpkg-genchanges: warning: package gdc-10-riscv64-linux-gnu in control file but
not in files list
dpkg-genchanges: warning: package gdc-10-sh4-linux-gnu in control file but not
in files list
dpkg-genchanges: warning: package gdc-10-sparc64-linux-gnu in control file but
not in files list
dpkg-genchanges: warning: package gdc-10-s390x-linux-gnu in control file but not
in files list
dpkg-genchanges: warning: package gdc-10-x86-64-linux-gnux32 in control file but
not in files list
dpkg-genchanges: warning: package gdc-10-mips64el-linux-gnuabin32 in control
file but not in files list
dpkg-genchanges: warning: package gdc-10-mipsisa32r6-linux-gnu in control file
but not in files list
dpkg-genchanges: warning: package gdc-10-mipsisa32r6el-linux-gnu in control file
but not in files list
dpkg-genchanges: warning: package gdc-10-mipsisa64r6-linux-gnuabi64 in control
file but not in files list
dpkg-genchanges: warning: package gdc-10-mipsisa64r6el-linux-gnuabi64 in control
file but not in files list
dpkg-genchanges: warning: package gdc-10-mipsisa64r6-linux-gnuabin32 in control
file but not in files list
dpkg-genchanges: warning: package gdc-10-mipsisa64r6el-linux-gnuabin32 in
control file but not in files list

Bug#970798: net-snmp: Not built on buildd: arch all binaries, source-only upload required

[Chris Hofstaedtler]

Package: net-snmp
Version: 5.9+dfsg-2
Severity: serious
Justification: testing migration blocked

Dear Maintainer,

your package is prohibited from migrating to testing for these
reasons:

* Not built on buildd: arch amd64 binaries uploaded by csmall
* Not built on buildd: arch all binaries uploaded by csmall, a new
source-only upload is needed to allow migration

While the first one could be fixed by a binNMU, the second one
cannot. This also prevents your reverse dependencies from migrating
to testing.

Please do a new source-only, possibly no-change, upload to unstable.

Thanks,
Chris

Bug#970799: torbrowser-launcher: i cant launch tor browser 10.0 after updating - possibly apparmor issue

[p]

Package: torbrowser-launcher
Version: 0.3.2-13~bpo10+1
Severity: important
Tags: newcomer

Dear Maintainer,

I cant lauch Tor Browser after yesterday's update to 10.0 version. I have it
installed using torbrowser-launcher. I managed to fix the bug mentioned here
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970768

however Browser still doesn't launch. When i typed dmesg, I got following
error:

Sep 23 17:05:34 m kernel: [ 1944.819317] audit: type=1400
audit(1600873534.409:24): apparmor="DENIED" operation="file_mmap"
profile="torbrowser_firefox"
name="/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_en-
US/Browser/TorBrowser/Tor/libstdc++/libstdc++.so.6" pid=5121
comm="firefox.real" requested_mask="m" denied_mask="m" fsuid=1000 ouid=1000

When I disabled app armor, by typing
sudo aa-disable /etc/apparmor.d/torbrowser.Browser.firefox

Tor browser launched. I am new user of Debian and I don't know how to have TB
working with apparmor again. I also checked that this error exists with Debian
Live USB Image.
Thanks in advance for fixing.



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

Kernel: Linux 4.19.0-10-amd64 (SMP w/6 CPU cores)
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=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20200601~deb10u1
ii  gnupg 2.2.12-1+deb10u1
ii  libdbus-glib-1-2  0.110-4
ii  python3   3.7.3-1
ii  python3-gpg   1.12.0-6
ii  python3-pyqt5 5.11.3+dfsg-1+b3
ii  python3-requests  2.21.0-1
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.5.10-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.2-10

-- no debconf information

Bug#937234: pam-python/libpam-mklocaluser/debian-edu-config python3 migration.

[Mike Gabriel]

Hi,

Am Samstag, 19. September 2020 schrieb peter green:
> The debian python maintainers are trying to phase out python 2.
> 
> python 2 has been granted a stay of execution as some important software 
> requires it to build. However we should still
> be attempting to get rid of use at runtime if at all possible. Also the 
> "unversioned python" packages have been dropped.
> Software that requires python 2 must depend on the explicit python2 packages 
> and use the python2 binary name in /bin.
> 
> The absolute minimum required to get pam-python and it's reverse dependencies 
> in releasable shape for bullseye would be
> to switch away from the versioned python packages to the explicit python2 
> packages. However that is just kicking
> the can down the road.
> 
> What needs to happen long-term is for pam-python to move to python 3. I 
> suspect this will involve renaming the binary
> package and adjusting the reverse dependencies to depend on the new binary 
> package and use python 3 compatible code.
> 

I was pretty sure that pam-python.so and mklocaluser already operate on 
Python3. This mail makes me unsure about this, now.

I'll take a closer look at this. Thanks for letting us know.

Mike
-- 
Sent from my Fairphone powered by SailfishOS

Bug#970797: ITP: jiconfont-google-material-design-icons -- jIconFont - Google Material Design Icons

[KITAGAWA Masahiro]

Package: wnpp
Severity: wishlist
Owner: Masahiro Kitagawa 

* Package name: jiconfont-google-material-design-icons
  Version : 2.2.0.2
  Upstream Author : jIcomFont
* URL :
https://github.com/jIconFont/jiconfontgoogle_material_design_icons
* License : Expat
  Programming Lang: Java
  Description :  jIconFont - Google Material Design Icons

 jIconFont is an API to provide icons generated from any IconFont. These
 icons can be used in Java GUI toolkits, such as Swing and JavaFX.

 This package provides support for the Google Material Design Icons.

Bug#970796: cloud-init: Please add gnupg to Recommends

[Daniel Watkins]

Package: cloud-init
Version: 20.2-2
Severity: normal

Dear Maintainer,

cloud-init uses gnupg in two ways: directly, to fetch and export keys
(when specified by ID, see [0]), and via apt-key to add keys to the system
(whether specified via ID or in full, see [1]).  (Even once we remove
apt-key usage[2], we will still need it for the former use case.)

I've just opened a PR[3] to add this to our Ubuntu packaging, and would
request that you do the same so that Debian users are able to configure
custom apt sources using cloud-init configuration.

(My assumption here is that Debian cloud images are built with
--install-recommends; if not, then you may want to consider ensuring
that gnupg is present in Debian cloud images via other means.)


Thanks!

Dan

[0] https://github.com/canonical/cloud-init/blob/master/cloudinit/gpg.py
[1] 
https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_apt_configure.py#L698
[2] https://bugs.launchpad.net/cloud-init/+bug/1836336
[3] https://github.com/canonical/cloud-init/pull/583

Bug#892058: debian-keyring: please automatically send reminder emails to people whose keys will expire soon

[David Prévot]

On Wed, Sep 23, 2020 at 08:26:05AM -0500, Gunnar Wolf wrote:

[…Technical stuff…]

> And we would have everything in place to notify people whose key is
> to expire soon.

Wonderful, thank you for working into making (part of) our lives easier!

Regards

David


signature.asc
Description: PGP signature

Bug#970520: The same bug

[Max Minenko]

My situation is identical:


minemax@maxPC:~$ wesnoth
Battle for Wesnoth v1.14.13
Started on Wed Sep 23 17:44:51 2020


Data directory:   /usr/share/games/wesnoth/1.14
User configuration directory: /home/USER/.config/wesnoth-1.14
User data directory:  /home/USER/.config/wesnoth-1.14
Cache directory:  /home/USER/.config/wesnoth-1.14/cache

Setting mode to 1920x1080
*** stack smashing detected ***: terminated
Aborted

Bug#632438: [Popcon-developers] Bug#681721: #632438:

[Bill Allombert]

On Wed, Sep 23, 2020 at 09:23:13PM +0900, Kentaro Hayashi wrote:
> On Sun, 20 Sep 2020 13:41:53 +0200 Bill Allombert  wrote:
> > On Sun, Sep 20, 2020 at 08:08:35PM +0900, Kentaro Hayashi wrote:
> > > I want to exclude installed packages from 3rd party vendor
> > > such as /etc/apt/sources.list.d/*.list. (some may be proprietary software)
> > 
> > OK, but what is your purpose in excluding them from popcon ?
> 
> Personally, I think that popcon data from 3rd party packages
> is just a noise because there is nothing to do with Debian.

Not always. Sometimes that points to packages that are missing in Debian
and should be packaged.

> Therefore, I think that it seems better to exclude.
> 
> But this is my personal opinion, so I don't mean to force others
> to do so. I'm happy if I have an option to exclude them.

But as soon as a single system report a package name, it appears in the
statistics. So unless everyone set up popcon to discard it, there is the
same amount of noise with less accurate statistics.

One other option would be for popularity-contest to detect third-party 
packages, but
this is difficult to do client-side. However this is done server-side,
see 

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#970795: Current linux-headers-amd64 disables many kernel modules

[Abit Gray]

Package: linux-headers-5.8.0-2-amd64
Version: 5.8.0-2 (amd64)

Had to switch to 5.7 kernel as 5.8 does not run VirtualBox, my ethernet card 
and front audio panel on my case.

I have got no messages as the Ethernet card was nowhere to be found and dmesg 
had no errors.

Do not have the knowledge (or time) to try to find out what was wrong. Just 
here to report that something was wrong.
Motherboard: MSI X570-A PRO (with AMD CPU)