Bug#400681:

[Ludriche Guillaume]

Oo

Bug#949332: apparmor profile for fwknop

[Luca Filipozzi]

debian/patches/001_apparmor_profile.patch already adds

+  @{PROC}/@{pid}/net/ip_tables_names r,
+   /usr/sbin/xtables-nft-multi rix,

so 002_apparmor_profile.patch that adds the following

+  /etc/host.conf r,
+  /etc/resolv.conf r,
+  /etc/services r,
+  /run/resolvconf/resolv.conf r,
+  /sbin/ipset rix,
+  /usr/sbin/ipset rix,

should work for the ipset use case

-- 
Luca Filipozzi

Bug#949331: why nfq over pcap

[Luca Filipozzi]

> Is there any advantage to migrating users to NFQ?

With PCAP:
* fwknopd dies if interface is brought down / up

With NFQ:
* fwknopd does not die if the interface is brought down / up

-- 
Luca Filipozzi

Bug#962777: RFS: jsonlab/2.0 [RFS] -- a native JSON/UBJSON/MassagePack encoder/decoder for MATLAB/Octave

[Qianqian Fang]

it looks like if I use jsonlab as the main package main, the octave 
packaging script seems to place all .m files under the jsonlab package 
instead of the octave-jsonlab package, so I had to rename the package 
name to octave-jsonlab to correctly build all subpackages.


The mentor package URL has also changed to

https://mentors.debian.net/package/octave-jsonlab

dget -x 
https://mentors.debian.net/debian/pool/main/o/octave-jsonlab/octave-jsonlab_2.0-1.dsc


do I need to create a new RFS if I change the package's name?

Bug#838392: dpkg: should build-depend on hurd-dev

[Guillem Jover]

Hi!

On Wed, 2016-09-21 at 08:58:11 +0200, Samuel Thibault wrote:
> Control: reassign -1 hurd
> Control: block -1 by 818618
> 
> Helmut Grohne, on Wed 21 Sep 2016 06:09:22 +0200, wrote:
> > Thus I suggest to close this bug or turn it into wishlist bugs for the
> > above.
> 
> Right. Also adding the bug dependency. I didn't remember that we still
> hadn't fixed that part. So we're waiting for dpkg-genchanges' 818618 :)
> Guillem had concerns which he raised on
> 
> https://lists.debian.org/debian-devel/2016/04/msg00326.html
> 
> I answered that what we actually need here is way less invasive than
> what Guillem raised:
> 
> https://lists.debian.org/debian-devel/2016/04/msg00327.html

Bug 818618 was fixed in dpkg 1.19.3, is there still something else
missing from the dpkg side? AFAIR there was a problem with DAK, but
cannot recall if it was related to this problem.

Thanks,
Guillem

Bug#962849: alsa-lib: failed to build twice

[Francisco]

Dear Maintainer,

the bug can be closed with the attached patch.

Regards.

-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
diff -Nru alsa-lib-1.2.2/debian/changelog alsa-lib-1.2.2/debian/changelog
--- alsa-lib-1.2.2/debian/changelog 2020-06-10 06:26:40.0 +
+++ alsa-lib-1.2.2/debian/changelog 2020-06-15 02:02:50.0 +
@@ -1,3 +1,12 @@
+alsa-lib (1.2.2-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules:
+  - Fixed dh_clean target to allow the package build twice.
+(Closes: #962849)
+
+ -- Francisco Vilmar Cardoso Ruviaro   Mon, 15 
Jun 2020 02:02:50 +
+
 alsa-lib (1.2.2-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru alsa-lib-1.2.2/debian/rules alsa-lib-1.2.2/debian/rules
--- alsa-lib-1.2.2/debian/rules 2020-02-29 15:51:16.0 +
+++ alsa-lib-1.2.2/debian/rules 2020-06-15 00:23:05.0 +
@@ -38,3 +38,17 @@
 
 override_dh_makeshlibs:
dh_makeshlibs -- -c4
+
+override_dh_auto_clean:
+   rm -rf doc/doxygen
+   rm -f src/control/ctl_symbols_list.c \
+  src/control/libcontrol.la \
+  src/hwdep/libhwdep.la \
+  src/mixer/libmixer.la \
+  src/pcm/libpcm.la \
+  src/pcm/pcm_symbols_list.c \
+  src/rawmidi/librawmidi.la \
+  src/seq/libseq.la \
+  src/timer/libtimer.la \
+  src/ucm/libucm.la
+   dh_auto_clean

Bug#936757: jackd2: Python2 removal in sid/bullseye

[Sandro Tosi]

Hello everyone,

On Mon, 21 Oct 2019 14:46:54 +0200 Reiner Herrmann  wrote:
> Control: tags -1 + fixed-upstream
> Control: forwarded -1 https://github.com/jackaudio/jack2/pull/352
>
> The new upstream release 1.9.13 has support for Python 3.

can someone look at this bug soon, please? along with #959177 it seems
that the newer releases of jack have been ported to python3, so we
"just" need to upgrade to it. Porting jack to python3 will clear one
of the only 2 remaining reverse dependencies of python-dbus

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#962850: haskell-platform: New upstream version

[Shayan Doust]

Package: haskell-platform
Version: 2014.2.0.0.debian8
Severity: wishlist

Hello,

I am not too informed on Haskell but I'm not sure if haskell-platform[1] still 
(or if it did) follow Stackage
LTS, however the latest version is now available labelled as Haskell
16.0 featuring the newer ghc-8.8.3[2].

Kind regards,
Shayan Doust

[1]: https://downloads.haskell.org/~platform/
[2]: https://www.stackage.org/lts-16.0

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 haskell-platform depends on:
ii  alex 3.2.4-4
ii  cabal-install2.2.0.0-2
ii  ghc [libghc-xhtml-dev]   8.4.4+dfsg1-3
pn  ghc-haddock  
ii  happy1.19.9-6
ii  hscolour 1.24.4-2+b2
ii  libghc-async-dev 2.2.1-2+b2
ii  libghc-attoparsec-dev0.13.2.2-6+b1
ii  libghc-case-insensitive-dev  1.2.0.11-3+b2
ii  libghc-fgl-dev   5.6.0.0-4+b1
ii  libghc-gluraw-dev2.0.0.4-2+b2
ii  libghc-glut-dev  2.7.0.14-2+b2
ii  libghc-hashable-dev  1.2.7.0-5+b1
ii  libghc-haskell-src-dev   1.0.3.0-2+b2
ii  libghc-html-dev  1.0.1.2-15+b2
ii  libghc-http-dev  1:4000.3.12-4+b2
ii  libghc-hunit-dev 1.6.0.0-2+b2
ii  libghc-network-dev   2.6.3.6-1+b2
ii  libghc-opengl-dev3.0.2.2-2+b2
ii  libghc-openglraw-dev 3.3.1.0-2+b2
ii  libghc-parallel-dev  3.2.2.0-1+b2
ii  libghc-primitive-dev 0.6.4.0-2+b2
ii  libghc-quickcheck2-dev   2.11.3-1+b2
ii  libghc-random-dev1.1-7+b2
ii  libghc-regex-base-dev0.93.2-13+b2
ii  libghc-regex-compat-dev  0.95.1-12+b2
ii  libghc-regex-posix-dev   0.95.2-11+b2
ii  libghc-split-dev 0.2.3.3-2+b2
ii  libghc-syb-dev   0.7-3+b2
pn  libghc-transformers-dev  
ii  libghc-unordered-containers-dev  0.2.9.0-2+b2
ii  libghc-vector-dev0.12.0.1-8+b2
ii  libghc-zlib-dev  0.6.2-2+b2

haskell-platform recommends no packages.

Versions of packages haskell-platform suggests:
pn  haskell-platform-doc   
pn  haskell-platform-prof  

-- debconf-show failed

Bug#962849: alsa-lib: failed to build twice

[Francisco Vilmar Cardoso Ruviaro]

Source: alsa-lib
Version: 1.2.2-2.2
Severity: normal

Dear Maintainer,

please fix dh_clean target to allow the package to be compiled twice.

Regards,

Francisco Vilmar

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Just wanted to do a quick follow up:

Is there anything else you would like me to do to prepare this package
for submission?

Thanks,
Antonio

On 2020-06-10 18:30, Antonio Russo wrote:
> On 2020-06-10 08:53, Boyuan Yang wrote:
>> Signed tags/tarballs don't matter; they are totally optional. Your
>> debian/watch file is using mode=git, which is totally fine; however,
>> you may also opt to monitor the github releases page like other Debian
>> packages.
> 
> Understood. I've left it untouched, in the hope that upstream will
> sign their git tags.
> 
>> Just one last issue: you did not document the license information of
>> textext/texoutparse.py; this file is licensed under the MIT License
>> (seems to be the Expat variant), not BSD-3-Clause. Please update this
>> information accordingly. After that, I think I can help to upload this
>> package.
> 
> Whoops. I've fixed that, and uploaded the changes to mentors and salsa.
> 
> Thanks for your time,
> Antonio
> 

Bug#962848: dpkg-architecture: please add aliases for 32-bit 64-bit bad-endian

[Adam Borowski]

Package: dpkg-dev
Version: 1.20.0
Severity: wishlist

Hi!
More and more software has dropped (or never implemented) support for
32-bit.  Likewise, the endian wars have been decisively won by LE,
leaving s390x as the only BE release architecture -- and it doesn't
exactly have many users.

Declaring the list of architectures by mentioning every one of them
is tedious, error-prone and incomplete.  Thus: could you please add
the following for aliases?:
* 32-bit
* 64-bit
* big-endian
* little-endian

dpkg-architecture already has some code for that (-B, -E), but that's
not usable in Architecture: fields nor in {Build-,}{Depends,...} []
stanzas.

Of course, being actually usable requires waiting a release cycle or two,
but the only way to get that is to have support before Bullseye's freeze.


Meow!

Bug#962141: docker.io: CVE-2020-13401

[Dmitry Smirnov]

On Monday, 15 June 2020 7:23:41 AM AEST Felix Geyer wrote:
> I've prepared an update for buster-security (debdiff attached).
> With the update accept_ra is correctly set to 0 for bridges Docker creates.

Many thanks for your help, Felix.


> @Maintainers:
> Do you want me push the patch to the Git repo for unstable or are you
> planning to update to 19.03.11 anyway?

Please go ahead and push. I'm not working on a new release but I'm not sure 
about Arnaud.

-- 
All the best,
 Dmitry Smirnov.

---

In times of universal deceit, telling the truth becomes a revolucionary
act.
-- George Orwell


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

Bug#962847: exim4: takes forever to send a mail after sleeping

[Rémi Letot]

Package: exim4
Version: 4.94-2
Severity: normal

Dear Maintainer,

I'm using exim4 on a laptop to send email through a smarthost. 

Up to 4.93-16, everything went well. 

Since upgrading to 4.94 (4.94-1 and 4.94-2 display the problem), I have 
noticed delays when trying to send email after the laptop has been sleeping. 

My mail client (emacs) simply gets stuck until I cancel the message, or 
wait long enough.

At first I thought that it simply got stuck, but while testing i noticed 
that the delay is exactly the time that the laptop has been sleeping. 

Here the laptop has been asleep 1 minute and 11 seconds:
2020-06-15 01:17:44 1jkbsm-000Stl-SK <= r...@lybrafox.be H=(sphax) [::1] 
P=esmtps X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no 
S=664 id=87y2ops0do.fsf@sphax
2020-06-15 01:18:55 1jkbsm-000Stl-SK => r...@lybrafox.be R=smarthost 
T=remote_smtp_smarthost H=mail2.lybrafox.be [37.59.240.190] 
X=TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256 CV=no 
DN="CN=mail2.lybrafox.be" A=plain C="250 2.0.0 Ok: queued as 394FB419A4"
2020-06-15 01:18:55 1jkbsm-000Stl-SK Completed

And here it has been asleep exactly 4 minutes 2 seconds:

2020-06-15 01:51:07 1jkcP5-000V8E-MS <= r...@lybrafox.be H=(sphax) [::1] 
P=esmtps X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no 
S=664 id=875zbtqk9i.fsf@sphax
2020-06-15 01:55:09 1jkcP5-000V8E-MS => r...@lybrafox.be R=smarthost 
T=remote_smtp_smarthost H=mail2.lybrafox.be [37.59.240.190] 
X=TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256 CV=no 
DN="CN=mail2.lybrafox.be" A=plain C="250 2.0.0 Ok: queued as 8E27141DEE"
2020-06-15 01:55:09 1jkcP5-000V8E-MS Completed

I didn't test for longer delays, but when I leave the laptop asleep for 
the night, my mail client just stays stuck.

Restarting the exim4 service makes it work again without delay, but does 
not make the stuck messages get delivered. For that I need to manually kill 
the stuck daemons and restart the service.

I reverted to 4.93 for the time being, but it's easy to get back to 4.94 if
you need some testing.

Thanks for your work, 
-- 
Rémi

-- Package-specific info:
Exim version 4.94 #2 built 07-Jun-2020 07:55:58
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC 
Event I18N OCSP PIPE_CONNECT PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='satellite'
dc_other_hostnames='sphax'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost='sphax'
dc_relay_domains=''
dc_minimaldns='true'
dc_relay_nets=''
dc_smarthost='mail2.lybrafox.be::587'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
mailname:sphax
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -   one daemon running queue and listening on SMTP port
# 'no'   -   no daemon running the queue
# 'separate' -   two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# Options for the SMTP listener daemon. By default, it is listening on
# port 25 only. To listen on more 

Bug#962813: does not build with ghc 8.8

[Mike Gabriel]

Hi,

On  So 14 Jun 2020 16:41:31 CEST, Picca Frédéric-Emmanuel wrote:


Source: haskell-tree-monad
Severity: critical

Hello,

this package does not build with the up-comming ghc 8.8 version.
It is not part of stackage LTS, and it was not updated by upstream  
since 2009.

It means that there is few chance to see the upstream fix this issue.

so it is considere to remove it from Debian.

Someone can salvage it by providing a patch (prefereably to the  
upstream first).


Cheers


I have pinged upstream (off-list, off-bts) on this issue and will  
provide feedback once I hear from them.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpBxjskrIlfd.pgp
Description: Digitale PGP-Signatur

Bug#962779: djview4 color PDF export results in a blank page

[Adam Richter]

Thank you for your prompt and thoughtful response, Barak.

When I submitted that bug report to the Debian list, I mistakenly
assumed that the latest upstream was the latest djview4 tar
file release, which has the older tiff2pdf.c, which does not have
that problem.  However, I see now that there is a much newer
central git tree at https://sourceforge.net/p/djvu/djview-git/ci/master/tree/
and see that you are apparently actively involved with it.  I confirm
that I can reproduce the problem with the git master branch version
of that code, so my belief that the bug was from a Debian
packaging change was wrong.

As you recommended, I have submitted my bug report upstream.
It should be accessible at https://sourceforge.net/p/djvu/patches/41/ .
I submitted it as a "patch" because I include that proposed possible
fix, but please let me know if you think I should resubmit it another way
or change anything.  Also, please feel free to close or otherwise
change the status of my bug report on the Debian bug tracking system
as you believe appropriate.

Thanks for your help, and thanks for your work in packaging and maintaining
such useful software as djview for so many people to use.

Adam


Adam

On Sun, Jun 14, 2020 at 2:34 PM Barak A. Pearlmutter
 wrote:
>
> Thanks for your very thorough bug report.
>
> The changes to tiff2pdf.c in the Debian package are actually inherited
> from upstream, because we're tracking upstream development as that's
> the easiest way to deal with bugs etc, and upstream is very
> cooperative.
>
> So I'd suggest filing this on upstream, because as you say, I'm not
> sure it's a good idea for me to patch the Debian package with this
> kind of might-break-something-else fix.
>
> Cheers,
>
> --Barak.

Bug#962766: autotools-dev: New versions upstream

[Jessica Clarke]

As mentioned elsewhere, I had forgotten my patch got reverted upstream.
I've now submitted a new one[0] that's hopefully acceptable to upstream
and should also be sufficient for Debian (and tg's case my previous
patch broke) given build-essential includes a compiler for the build
architecture. It's a shame that x32 gets treated as a second-class
citizen, but at least it's somewhat supported (and I'm not sure the
fallback (heuristic, given you _can_ mix and match userspace programs) I
mention in the patch is worth bothering with).

Jess

[0] https://lists.gnu.org/archive/html/config-patches/2020-06/msg5.html

Bug#962811: calibre: ebook-viewer crash on start

[Harlan Lieberman-Berg]

severity grave
tags 962811 +confirmed
clone 962811 -1 -2
reassign -1 pyqt5webengine 5.14.0-2+b1
retitle -1 pyqt5webengine: fails to block pyqt5 update
reassign -2 pyqt5 5.15.0+dfsg-1
retitle -2 pyqt5: update breaks pyqt5webengine and deps
affects -1 calibre
thanks

On Sun, 14 Jun 2020 15:31:47 +0200 Davide Prina  wrote:
> in this bug report the prolem is a python2 library, I have see that the
> corresponding python3 library has been updated today:
> python3-pyqt5
>
> but I cant try to install the previews version, elsewhere it will remove
> calibre and so I cannot test if this is the problem.

I've done a bit of digging, and this problem is solved by manually
updating pyqt5webengine to 5.15 from unstable.  The root cause is that
there is an unstated strict version dependency between these two
packages, and/or some symbols were changed without being handled
properly.

Reassigning the bug to the correct packages.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

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

[Colin Fowler]

Package: mdadm
Version: 4.1-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I created a RAID 5 volume over 4 disks using the BIOS support for Intel
RST. Install proceeded correctly, however after a reboot in to the
installed system, the root device was not found. Investigation in the
init shell found that the mdamd device had not been assembled correctly

The following error was encountered when looking for imsm capabilies on
the controller. 

mdadm --detail-platform
mdadm: imsm capabilities not found for controller: 
/sys/devices/pci:00/:00:1f.2 (type SATA)

I found that this occurred when mdadm could not read from 
/sys/firmware/efi/efivars/ due to it not being mounted. The efivarfs module was 
not found in the initrd

To resolve this, I booted in to a rescue CD and added efivarfs and
efivars to /etc/initramfs.conf/modules and ran an update-initramfs

This allowed the system to boot correctly

I suggest that mdadm ensures that these modules are added to the initrd
when the RAID array is using IMSM.


-- Package-specific info:
--- mdadm.conf
ARRAY metadata=imsm UUID=56bed0cd:2b07c313:c4651474:3a6b990c
ARRAY /dev/md/Volume0 container=56bed0cd:2b07c313:c4651474:3a6b990c member=0 
UUID=d0f942e0:fb69f9d0:bca65978:774a6c88
MAILADDR root

--- /etc/default/mdadm
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] 
[raid10] 
md126 : active raid5 sda[3] sdb[2] sdc[1] sdd[0]
  5567516672 blocks super external:/md127/0 level 5, 64k chunk, algorithm 0 
[4/4] []
  
md127 : inactive sdb[3](S) sdd[2](S) sdc[1](S) sda[0](S)
  20804 blocks super external:imsm
   
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

   8   48 1953514584 sdd
   8   32 1953514584 sdc
   8   16 1953514584 sdb
   80 1953514584 sda
   9  126 5567516672 md126
 2590 525391 md126p1
 2591 5533714844 md126p2
 2592   33276403 md126p3

--- LVM physical volumes:
LVM does not seem to be used.
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=16317648k,nr_inodes=4079412,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266568k,mode=755)
/dev/md126p2 on / type ext4 (rw,relatime,errors=remount-ro,stripe=48)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs 
(rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/memory type cgroup 
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12482)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
/dev/md126p1 on /boot/efi type vfat 
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=3266564k,mode=700,uid=1000,gid=1000)

--- initrd.img-4.19.0-9-amd64:
178049 blocks
192ccafcfe38eabf0f5184786764c4a9  ./scripts/local-bottom/mdadm
f3b648ca1c912da30940f0b821b7e9e6  ./scripts/local-block/mdadm
371839b6f84393a2c8d2988933b99f80  ./etc/mdadm/mdadm.conf
d3be82c0f275d6c25b04d388baf9e836  

Bug#962843: please package new upstream version 1.0.0 or later

[Nicholas D Steeves]

Package: go-mtpfs
Severity: normal

Hi,

Upstream released v1.0.0 several months ago.  Please package this version or 
newer.

Thanks!
Nicholas

P.S. My old died, and the replacement doesn't support MSC, which is why I'm 
reviewing the available options for MTP support in Debian.

Bug#962842: selinux-policy-default: SElinux prevents apache2 access to the mysql (mariadb) socket

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Severity: important

Dear Maintainer,

I 've configured my server as LAMP server for wordpress hosting.
I installed ex versions of packages:
***
root@vps:~# dpkg -l | grep "apache\|mysql\|mariadb\|php\|wordpress"
ii  apache2 2.4.25-3+deb9u9  amd64  
  Apache HTTP Server
ii  apache2-bin 2.4.25-3+deb9u9  amd64  
  Apache HTTP Server (modules and other binary files)
ii  apache2-data2.4.25-3+deb9u9  all
  Apache HTTP Server (common files)
ii  apache2-doc 2.4.25-3+deb9u9  all
  Apache HTTP Server (on-site documentation)
ii  apache2-utils   2.4.25-3+deb9u9  amd64  
  Apache HTTP Server (utility programs for web servers)
ii  libapache2-mod-php  1:7.0+49 all
  server-side, HTML-embedded scripting language (Apache 2 module) (default)
ii  libapache2-mod-php7.0   7.0.33-0+deb9u7  amd64  
  server-side, HTML-embedded scripting language (Apache 2 module)
ii  libdbd-mysql-perl   4.041-2  amd64  
  Perl5 database interface to the MariaDB/MySQL database
ii  libmariadbclient18:amd6410.1.44-0+deb9u1 amd64  
  MariaDB database client library
ii  libphp-phpmailer5.2.14+dfsg-2.3+deb9u1   all
  full featured email transfer class for PHP
ii  mariadb-client-10.1 10.1.44-0+deb9u1 amd64  
  MariaDB database client binaries
ii  mariadb-client-core-10.110.1.44-0+deb9u1 amd64  
  MariaDB database core client binaries
ii  mariadb-common  10.1.44-0+deb9u1 all
  MariaDB common metapackage
ii  mariadb-server  10.1.44-0+deb9u1 all
  MariaDB database server (metapackage depending on the latest version)
ii  mariadb-server-10.1 10.1.44-0+deb9u1 amd64  
  MariaDB database server binaries
ii  mariadb-server-core-10.110.1.44-0+deb9u1 amd64  
  MariaDB database core server files
ii  mysql-common5.8+1.0.2all
  MySQL database common files, e.g. /etc/mysql/my.cnf
ii  php-common  1:49 all
  Common files for PHP packages
ii  php-gd  1:7.0+49 all
  GD module for PHP [default]
ii  php-getid3  1.9.12+dfsg-1all
  scripts to extract information from multimedia files
ii  php-mysql   1:7.0+49 all
  MySQL module for PHP [default]
ii  php7.0-cli  7.0.33-0+deb9u7  amd64  
  command-line interpreter for the PHP scripting language
ii  php7.0-common   7.0.33-0+deb9u7  amd64  
  documentation, examples and common module for PHP
ii  php7.0-gd   7.0.33-0+deb9u7  amd64  
  GD module for PHP
ii  php7.0-json 7.0.33-0+deb9u7  amd64  
  JSON module for PHP
ii  php7.0-mysql7.0.33-0+deb9u7  amd64  
  MySQL module for PHP
ii  php7.0-opcache  7.0.33-0+deb9u7  amd64  
  Zend OpCache module for PHP
ii  php7.0-readline 7.0.33-0+deb9u7  amd64  
  readline module for PHP
ii  python3-pymysql 0.7.10-1 all
  Pure-Python MySQL Driver - Python 3.x
ii  wordpress   4.7.5+dfsg-2+deb9u6  all
  weblog manager
ii  wordpress-l10n  4.7.5+dfsg-2+deb9u6  all
  weblog manager - language files
ii  wordpress-theme-twentyseventeen 4.7.5+dfsg-2+deb9u6  all
  weblog manager - twentyseventeen theme files
***

I endabled next systemd units:
***
root@vps:~# systemctl list-units | grep "apache\|mysql\|mariadb\|php"
apache2.serviceloaded 
active running   The Apache HTTP Server
mariadb.serviceloaded 
active running   MariaDB 10.1.44 database server
phpsessionclean.timer  loaded 
active waiting   Clean PHP session files every 30 mins
***

So, by default mariaDB configured to interact by unix socked.
After start MariaDB, it creates expected socket:
***
root@vps:~# ls -la /var/run/mysqld/
total 0
drwxr-xr-x.  2 mysql root  40 Jun 15 01:52 .

Bug#962323: python-django: CVE-2020-13254 CVE-2020-13596

[Chris Lamb]

Chris Lamb wrote:

> I will wait a few days to see what upstream says. I will also have to
> re-release for jessie LTS, alas.

Okay, this is now fixed in the following versions (without and with
the regression fix):

  DistributionUpload with regressionUpload with regression fixed
  
  jessie  1.7.11-1+deb8u9   1.7.11-1+deb8u10
  stretch n/a   1:1.10.7-2+deb9u9 (pending)
  buster  n/a   1:1.11.29-1~deb10u1 (pending)
  unstable2:2.2.13-12:2.2.13-2
  experimental2:3.0.7-1 2:3.0.7-2
  


The two pending uploads (ie. needing your approval) to upload are:

  python-django (1:1.10.7-2+deb9u9) stretch-security; urgency=high

* CVE-2020-13254: Potential a data leakage via malformed memcached keys.

  In cases where a memcached backend does not perform key validation, 
passing
  malformed cache keys could result in a key collision, and potential data
  leakage. In order to avoid this vulnerability, key validation is added to
  the memcached cache backends.

* CVE-2020-13596: Possible XSS via admin ForeignKeyRawIdWidget.

  Query parameters to the admin ForeignKeyRawIdWidget were not properly URL
  encoded, posing an XSS attack vector. ForeignKeyRawIdWidget now ensures
  query parameters are correctly URL encoded.

   -- Chris Lamb   Sat, 13 Jun 2020 15:47:14 +0100


and

python-django (1:1.11.29-1~deb10u1) buster-security; urgency=high

  * New upstream security release (postponed from March 2020):

- CVE-2020-9402: Potential SQL injection via tolerance parameter in GIS
  functions and aggregates on Oracle

Note that Django 1.11.x left upstream's extended security support on 
April
1st 2020. For more information, please see:

  https://www.djangoproject.com/download/

  * This upload also fixes the following security issues:

- CVE-2020-13254: Potential a data leakage via malformed memcached keys.

  In cases where a memcached backend does not perform key validation,
  passing malformed cache keys could result in a key collision, and
  potential data leakage. In order to avoid this vulnerability, key
  validation is added to the memcached cache backends.

- CVE-2020-13596: Possible XSS via admin ForeignKeyRawIdWidget.

  Query parameters to the admin ForeignKeyRawIdWidget were not properly 
URL
  encoded, posing an XSS attack vector. ForeignKeyRawIdWidget now 
ensures
  query parameters are correctly URL encoded.

 -- Chris Lamb   Sun, 14 Jun 2020 12:15:26 +0100


The full debdiffs are attached. Can you especially check the
versioning scheme and distribution fields for me? I often get this
wrong and end up confusing myself. Really appreciated.


Regards,

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

Bug#962841: python3-nanomath: ships /usr/LICENSE

[Andreas Beckmann]

Package: python3-nanomath
Version: 0.23.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files ... but a file like
/usr/LICENSE should be shipped by *no* package at all.


cheers,

Andreas

Bug#962840: python3-nanoget: ships /usr/LICENSE

[Andreas Beckmann]

Package: python3-nanoget
Version: 1.12.2-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files ... but a file like
/usr/LICENSE should be shipped by *no* package at all.


cheers,

Andreas

Bug#962839: syslog-ng-core: Conflicting help messages, bad control socket location

[Elliott Mitchell]

Package: syslog-ng-core
Version: 3.19.1-5
Severity: important

`man syslog-ng` =>

   --control   or -c 
   Set the location of the syslog-ng control socket. Default value:
   /var/run/syslog-ng.ctl


`/usr/sbin/syslog-ng -h` =>

  -c, --control=Set syslog-ng 
control socket, default=${localstatedir}/syslog-ng.ctl


Then one observes AppArmor's audit log and discovers it is using
/var/lib/syslog-ng/syslog-ng.ctl instead.  That "${localstatedir}" looks
suspiciously like an incorrect build.

There is another example of that in the help message:

  --module-path=   Set the list of 
colon separated directories to search for modules, 
default=${exec_prefix}/lib/syslog-ng/3.19


The syslog-ng-core package seems to have some trouble.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#879037: refpolicy: SELinux prevents systemctl from listing units durring tab completion.

[Maksim K.]

Package: selinux-policy-default
Version: 2:2.20161023.1-9
Followup-For: Bug #879037

Hi,
I have the same issue, but I could provide audit.log.
When I am trying to Tab-Tab after (for example) 'systemctl status a' 

I've got next messages in audit.log
***
type=USER_AVC msg=audit(1592171060.677:242): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } 
for auid=0 uid=0 gid=0 path="/proc/self/mountinfo" cmdline="systemctl --system 
--full --no-legend show --property CanStop -- mnt-maks.automount 
proc-sys-fs-binfmt_misc.automount 
sys-devices-pci:00-:00:02.0-virtio0-net-ens2.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda-vda1.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda-vda15.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda.device 
sys-devices-platform-serial8250-tty-ttyS1.device 
sys-devices-platform-serial8250-tty-ttyS2.device 
sys-devices-platform-serial8250-tty-ttyS3.device 
sys-devices-pnp0-00:04-tty-ttyS0.device sys-devices-virtual-net-tun0.device 
sys-devices-virtual-net-tun1.device sys-subsystem-net-devices-ens2.device 
sys-subsystem-net-devices-tun0.device sys-subsystem-net-devices-tun1.device 
-.mount boot-efi.mount dev-hugepages.mount
  dev-mqueue.mount run-user-0.mount sys-kernel-debug.mount 
systemd-ask-password-console.path systemd-ask-password-wall.path init.scope 
session-1.scope s exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? 
terminal=?'
type=USER_AVC msg=audit(1592171894.511:255): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } 
for auid=0 uid=0 gid=0 path="/proc/self/mountinfo" cmdline="systemctl --system 
--full --no-legend show --property CanStop -- mnt-maks.automount 
proc-sys-fs-binfmt_misc.automount 
sys-devices-pci:00-:00:02.0-virtio0-net-ens2.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda-vda1.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda-vda15.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda.device 
sys-devices-platform-serial8250-tty-ttyS1.device 
sys-devices-platform-serial8250-tty-ttyS2.device 
sys-devices-platform-serial8250-tty-ttyS3.device 
sys-devices-pnp0-00:04-tty-ttyS0.device sys-devices-virtual-net-tun0.device 
sys-devices-virtual-net-tun1.device sys-subsystem-net-devices-ens2.device 
sys-subsystem-net-devices-tun0.device sys-subsystem-net-devices-tun1.device 
-.mount boot-efi.mount dev-hugepages.mount
  dev-mqueue.mount run-user-0.mount sys-kernel-debug.mount 
systemd-ask-password-console.path systemd-ask-password-wall.path init.scope 
session-1.scope s exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? 
terminal=?'
type=USER_AVC msg=audit(1592171902.891:257): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } 
for auid=0 uid=0 gid=0 path="/proc/self/mountinfo" cmdline="systemctl --system 
--full --no-legend show --property CanStop -- mnt-maks.automount 
proc-sys-fs-binfmt_misc.automount 
sys-devices-pci:00-:00:02.0-virtio0-net-ens2.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda-vda1.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda-vda15.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda.device 
sys-devices-platform-serial8250-tty-ttyS1.device 
sys-devices-platform-serial8250-tty-ttyS2.device 
sys-devices-platform-serial8250-tty-ttyS3.device 
sys-devices-pnp0-00:04-tty-ttyS0.device sys-devices-virtual-net-tun0.device 
sys-devices-virtual-net-tun1.device sys-subsystem-net-devices-ens2.device 
sys-subsystem-net-devices-tun0.device sys-subsystem-net-devices-tun1.device 
-.mount boot-efi.mount dev-hugepages.mount
  dev-mqueue.mount run-user-0.mount sys-kernel-debug.mount 
systemd-ask-password-console.path systemd-ask-password-wall.path init.scope 
session-1.scope s exe="/lib/systemd/systemd" sauid=0 hostname=? addr=? 
terminal=?'
type=USER_AVC msg=audit(1592172046.089:277): pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { status } 
for auid=0 uid=0 gid=0 path="/proc/self/mountinfo" cmdline="systemctl --system 
--full --no-legend show --property CanStop -- mnt-maks.automount 
proc-sys-fs-binfmt_misc.automount 
sys-devices-pci:00-:00:02.0-virtio0-net-ens2.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda-vda1.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda-vda15.device 
sys-devices-pci:00-:00:03.0-virtio1-block-vda.device 
sys-devices-platform-serial8250-tty-ttyS1.device 
sys-devices-platform-serial8250-tty-ttyS2.device 
sys-devices-platform-serial8250-tty-ttyS3.device 
sys-devices-pnp0-00:04-tty-ttyS0.device sys-devices-virtual-net-tun0.device 
sys-devices-virtual-net-tun1.device sys-subsystem-net-devices-ens2.device 
sys-subsystem-net-devices-tun0.device sys-subsystem-net-devices-tun1.device 
-.mount boot-efi.mount dev-hugepages.mount
  dev-mqueue.mount 

Bug#962838: Apparmor profile for syslog-ng assumes trivial config

[Elliott Mitchell]

Package: apparmor-profiles
Version: 2.13.2-10

I've added the option "use_dns(yes);" and am allowing messages from the
local network.  With this small configuration adjustment in place, I see
the kernel log getting severely spammed by AppArmor:

[##.##] audit: type=1400 audit(): 
apparmor="ALLOWED" operation="open" profile="syslog-ng" 
name="/proc//cmdline" pid= comm="syslog-ng" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[##.##] audit: type=1400 audit(): 
apparmor="ALLOWED" operation="open" profile="syslog-ng" 
name="/proc//loginuid" pid= comm="syslog-ng" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[##.##] audit: type=1400 audit(): 
apparmor="ALLOWED" operation="open" profile="syslog-ng" 
name="/proc//sessionid" pid= comm="syslog-ng" 
requested_mask="r" denied_mask="r" fsuid=0 ouid=0


I'm cautiously optimistic this is due to the AppArmor profile for
syslog-ng being incomplete and not someone having broken into this
machine and done something to syslog-ng.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.

[Vctl Piotr Kolasinski]

Hi
I'm new on that list and and notified (from another -email address -
that will be removed), about my desire to help and contribute that
port. Please don't remove it, Debian is only one of two free (not
charged) distributions.
The mainframe platform is evolving, now exist not only IBM Z servers
but also fully dedicated to Linux the LinuxONE servers. I know from
one case in Poland, taht it was very successful to supersede AIX
installation by LinuxOne installation with Oracle database as main
engine.

I also met the problem witch perl:any dependency  (and a few others
during installation), but I resolved them using another installation
(trial RedHat) and debootstrap (with foreign option). The additional
difficulty was lack of Internet access (it is normal in some
environments), but I was determined.
In my opinion the big problem may be w ith access to the real platform
(currently I have access and possibilities but I don't know how long).
Of course we have emulators like hercules (which I use from very long
time) and know qemu s390 port (only with virtio, not tested by me),
but it is probably not enough in power (as long as yo don't have very
powerful emulation platform or use cross-compile). Anyway if Debian
maintainers have access to valid build environment, I think you should
not remove the architecture.

Kind Regards
Piotr (aka nome)

niedz., 14 cze 2020 o 17:20 Philipp Kern  napisał(a):
>
> On 11.05.20 11:53, Winfried Münch wrote:
> > package: s390-tools
> >
> > Version: current Installer from 04.05.2020 21:14
> > http://ftp.halifax.rwth-aachen.de/debian/dists/buster/main/installer-s390x/current/images/generic/
> >
> >
> > When I install debian I run in this Problem (from console 4):
> >
> > May 11 09:43:43 debootstrap: Errors were encountered while processing:
> > May 11 09:43:43 debootstrap:  s390-tools
> > May 11 09:43:44 debootstrap: dpkg: dependency problems prevent
> > configuration of s390-tools:
> > May 11 09:43:44 debootstrap:  s390-tools depends on perl:any.
> > May 11 09:43:44 debootstrap:
> > May 11 09:43:44 debootstrap: dpkg: error processing package s390-tools
> > (--configure):
> > May 11 09:43:44 debootstrap:  dependency problems - leaving unconfigured
> >
> > Installation failed in step install base system.
>
> perl:any is not part of the transitive closure that debootstrap
> calculates. To me it looks like a bug in debootstrap in that it does not
> find a deb to download because it does not drop the :any - either in
> pkgdetails or before.
>
> This was presumably broken by 2.3.0-1 which packaged ziomon and included
> a ${perl:Depends} on the main package as well - possibly because Lintian
> alerted about the missing dependency. That was technically correct, as
> it includes binaries that require modules from perl rather than
> perl-base. And it would presumably have worked if "perl:any" had instead
> been substituted as "perl".
>
> It's pretty telling how late this was discovered, sort of pointing out
> that Debian s390x has no users at all if that kind of bug slips into a
> stable release. Ubuntu forked the base tooling and thus was not
> affected. To be honest, that tells me that the port should be demoted
> and not be part of the next release. Especially given the lack of
> (motivated) porters.
>
> Furthermore it seems like the current debian-installer daily build does
> not boot and ends up in disabled PSW before printing even a single line
> of output.
>
> I never managed to get any kind of continuous integration going myself
> given how hard it is to integrate with existing Debian infrastructure to
> test it properly - unless you are an admin there already. Even a qemu
> setup would have spotted this particular bug. But without any users who
> care I also don't think it is worth spending much time on this.
>
> Kind regards and sorry
> Philipp Kern
>

Bug#962837: ITP: python-pyclustering -- Data mining algorithms

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: python-pyclustering
  Version : 0.9.3.1
  Upstream Author : Andrei Novikov
* URL : 
https://github.com/annovikov/pyclustering
* License : GPL-3
  Programming Lang: Python
  Description : Data mining algorithms

 This library provides tools for clustering algorithms, oscillatory
 networks and neural networks.

I want to package it because it is a dep of https://flopedt.org .

I'll maintain it within the Debian Python Modules Team.

Cheers,

JP

Bug#962836: ITP: python-django-import-export -- Django application and library for data import/export

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: python-django-import-export
  Version : 2.2.0
  Upstream Author : Bojan Mihelac and contributors
* URL : 
https://github.com/django-import-export/django-import-export
* License : BSD-2-clause
  Programming Lang: Python
  Description : Django application and library for data
import/export

 Django application and library for importing and exporting of
 data in multiple formats with included admin integration.

I want to package it because it is a dep of https://flopedt.org .

I'll maintain it within the Debian Python Modules Team.

Cheers,

JP

Bug#962811: calibre: ebook-viewer crash on start

[Davide Prina]

I have try to debug

# apt install python3-dbg

$ gdb python3
[...]
Reading symbols from python3...
Reading symbols from 
/usr/lib/debug/.build-id/97/0f19629d98e5c631b44f6803fa34a5a07c3806.debug...


(gdb) run /usr/bin/ebook-viewer /tmp/a.epub
Starting program: /usr/bin/python3 /usr/bin/ebook-viewer /tmp/a.epub
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 42697]
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway.

[New Thread 0x7fffdfab3700 (LWP 42698)]
[New Thread 0x7fffde7de700 (LWP 42699)]
[New Thread 0x7fffddfdd700 (LWP 42700)]
[New Thread 0x7fffdd780700 (LWP 42701)]
[New Thread 0x7fffdcf7f700 (LWP 42702)]
[New Thread 0x7fffc0a0c700 (LWP 42703)]
[New Thread 0x7fffbbfff700 (LWP 42704)]
[New Thread 0x7fffb37fe700 (LWP 42705)]
[New Thread 0x7fffbb7fe700 (LWP 42706)]
[New Thread 0x7fffbaffd700 (LWP 42707)]
[New Thread 0x7fffba361700 (LWP 42708)]
[New Thread 0x7fffb91c3700 (LWP 42710)]
[Detaching after fork from child process 42711]
[New Thread 0x7fffb89c2700 (LWP 42712)]
[New Thread 0x7fffb2ffd700 (LWP 42714)]
[New Thread 0x7fffb3fff700 (LWP 42713)]
[New Thread 0x7fffb27fc700 (LWP 42715)]
[New Thread 0x7fffb1ffb700 (LWP 42716)]
[New Thread 0x7fffb17fa700 (LWP 42717)]
[New Thread 0x7fffb0ff9700 (LWP 42718)]
[New Thread 0x7fff83fff700 (LWP 42719)]
[New Thread 0x7fff837fe700 (LWP 42720)]
[New Thread 0x7fff82ffd700 (LWP 42721)]
[New Thread 0x7fff827fc700 (LWP 42722)]
[New Thread 0x7fff81ffb700 (LWP 42723)]
[New Thread 0x7fff817fa700 (LWP 42724)]
[New Thread 0x7fff80ff9700 (LWP 42725)]
[New Thread 0x7fff4700 (LWP 42726)]
[New Thread 0x7fff4f7fe700 (LWP 42727)]
[New Thread 0x7fff4e7fc700 (LWP 42729)]
[New Thread 0x7fff4effd700 (LWP 42728)]
[New Thread 0x7fff4dffb700 (LWP 42752)]
[Thread 0x7fff4dffb700 (LWP 42752) exited]
[New Thread 0x7fff4dffb700 (LWP 42753)]
Fatal Python error: PyEval_SaveThread: NULL tstate
Python runtime state: initialized

Current thread 0x77c20740 (most recent call first):
  File "/usr/lib/calibre/calibre/gui2/webengine.py", line 126 in 
_dispatch_messages

  File "/usr/lib/calibre/calibre/gui2/viewer/main.py", line 229 in main
  File "/usr/lib/calibre/calibre/gui_launch.py", line 81 in ebook_viewer
  File "/usr/bin/ebook-viewer", line 20 in 

Thread 1 "LoadBook" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: File o directory non esistente.


If I try to continue it stop

(gdb) next
Couldn't get registers: Nessun processo corrisponde.
Couldn't get registers: Nessun processo corrisponde.
(gdb) [Thread 0x7fff4dffb700 (LWP 42869) exited]
[Thread 0x7fff4e7fc700 (LWP 42845) exited]
[Thread 0x7fff4effd700 (LWP 42844) exited]
[Thread 0x7fff4f7fe700 (LWP 42843) exited]
[Thread 0x7fff4700 (LWP 42842) exited]
[Thread 0x7fff78ff9700 (LWP 42841) exited]
[Thread 0x7fff797fa700 (LWP 42840) exited]
[Thread 0x7fff79ffb700 (LWP 42839) exited]
[Thread 0x7fff7a7fc700 (LWP 42838) exited]
[Thread 0x7fff7affd700 (LWP 42837) exited]
[Thread 0x7fff7b7fe700 (LWP 42836) exited]
[Thread 0x7fff7bfff700 (LWP 42835) exited]
[Thread 0x7fffb0ff9700 (LWP 42834) exited]
[Thread 0x7fffb17fa700 (LWP 42833) exited]
[Thread 0x7fffb1ffb700 (LWP 42832) exited]
[Thread 0x7fffb27fc700 (LWP 42831) exited]
[Thread 0x7fffb2ffd700 (LWP 42830) exited]
[Thread 0x7fffb3fff700 (LWP 42829) exited]
[Thread 0x7fffb89c2700 (LWP 42828) exited]
[Thread 0x7fffb91c3700 (LWP 42826) exited]
[Thread 0x7fffba361700 (LWP 42825) exited]
[Thread 0x7fffbaffd700 (LWP 42824) exited]
[Thread 0x7fffbb7fe700 (LWP 42823) exited]
[Thread 0x7fffb37fe700 (LWP 42822) exited]
[Thread 0x7fffbbfff700 (LWP 42821) exited]
[Thread 0x7fffc0a0c700 (LWP 42820) exited]
[Thread 0x7fffdcf7c700 (LWP 42819) exited]
[Thread 0x7fffdd77d700 (LWP 42818) exited]
[Thread 0x7fffde7db700 (LWP 42816) exited]
[Thread 0x7fffdfab0700 (LWP 42815) exited]
[Thread 0x77c20740 (LWP 42810) exited]

Cannot execute this command without a live selected thread.


let me know if I can do more test

Ciao
Davide

Bug#962835: ITP: tomcat-jakartaee-migration -- Apache Tomcat migration tool for Jakarta EE

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: tomcat-jakartaee-migration
  Version : 0.0.2
  Upstream Author : The Apache Software Foundation
* URL : https://github.com/apache/tomcat-jakartaee-migration
* License : Apache-2.0
  Programming Lang: Java
  Description : Apache Tomcat migration tool for Jakarta EE

The aim of the Apache Tomcat migration tool for Jakarta EE is to take a web
application written for Java EE 8 that runs on Apache Tomcat 9 and convert
it automatically so it runs on Apache Tomcat 10 which implements Jakarta EE 9.

This package is a build dependency of Tomcat 10. It'll be maintained by the 
Java Team.

Bug#962834: bcftools: Have dependency on Perl demoted to "recommended"

[Steffen Moeller]

Package: bcftools
Version: 1.10.2-2
Severity: wishlist

Dear Maintainer,

The tools in bcftools that depend on Perl are only of secondary interest. For 
an improved efficiency in cloud and docker setups, please demote the dependency 
on Perl to a mere recommendation. Other executables of bcftools depend on 
Python that is even a suggestion, only. That sounds like a reasonable 
alternative.

Thanks!

This bug report emerged upon as discussion on the Debian Med Mailing list on 
June 15th, 2020.

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

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

Versions of packages bcftools depends on:
ii  libc62.30-8
ii  libhts3  1.10.2-3
ii  perl 5.30.3-4
ii  zlib1g   1:1.2.11.dfsg-2

bcftools recommends no packages.

Versions of packages bcftools suggests:
ii  python 2.7.17-2
pn  python-matplotlib  
ii  python-numpy   1:1.16.5-5
ii  texlive-latex-recommended  2020.20200417-1

-- no debconf information

Bug#962833: ITP: python-django-ical -- Calendar feeds for Django

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: python-django-ical
  Version : 1.7.0
  Upstream Author : Ian Lewis
* URL : 
https://github.com/jazzband/django-ical
* License : 
  Programming Lang: Python
  Description : Calendar feeds for Django

 This module provides iCalendar feeds support in Django
 applications.

I want to package it because it is a dep of https://flopedt.org .

I'll maintain it within the Debian Python Modules Team.

Cheers,

JP

Bug#962141: docker.io: CVE-2020-13401

[Felix Geyer]

Hi security team / maintainers,

On Wed, 03 Jun 2020 20:58:53 +0200 Salvatore Bonaccorso  
wrote:

Source: docker.io
Version: 19.03.7+dfsg1-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for docker.io.

CVE-2020-13401[0]:
| An issue was discovered in Docker Engine before 19.03.11. An attacker
| in a container, with the CAP_NET_RAW capability, can craft IPv6 router
| advertisements, and consequently spoof external IPv6 hosts, obtain
| sensitive information, or cause a denial of service.


I've prepared an update for buster-security (debdiff attached).
With the update accept_ra is correctly set to 0 for bridges Docker creates.


@Maintainers:
Do you want me push the patch to the Git repo for unstable or are you
planning to update to 19.03.11 anyway?

Cheers,
Felix
diff -Nru docker.io-18.09.1+dfsg1/debian/changelog 
docker.io-18.09.1+dfsg1/debian/changelog
--- docker.io-18.09.1+dfsg1/debian/changelog2019-09-03 19:59:35.0 
+0200
+++ docker.io-18.09.1+dfsg1/debian/changelog2020-06-14 22:12:29.0 
+0200
@@ -1,3 +1,9 @@
+docker.io (18.09.1+dfsg1-7.1+deb10u2) buster-security; urgency=medium
+
+  * Add upstream patch for CVE-2020-13401 (Closes: #962141)
+
+ -- Felix Geyer   Sun, 14 Jun 2020 22:12:29 +0200
+
 docker.io (18.09.1+dfsg1-7.1+deb10u1) buster-security; urgency=medium
 
   [ Arnaud Rebillout ]
diff -Nru 
docker.io-18.09.1+dfsg1/debian/patches/cve-2020-13401-disable-IPv6-router-advertisements.patch
 
docker.io-18.09.1+dfsg1/debian/patches/cve-2020-13401-disable-IPv6-router-advertisements.patch
--- 
docker.io-18.09.1+dfsg1/debian/patches/cve-2020-13401-disable-IPv6-router-advertisements.patch
  1970-01-01 01:00:00.0 +0100
+++ 
docker.io-18.09.1+dfsg1/debian/patches/cve-2020-13401-disable-IPv6-router-advertisements.patch
  2020-06-14 22:12:20.0 +0200
@@ -0,0 +1,65 @@
+From 153d0769a1181bf591a9637fd487a541ec7db1e6 Mon Sep 17 00:00:00 2001
+From: Samuel Karp 
+Date: Fri, 3 Apr 2020 16:23:18 -0700
+Subject: [PATCH] bridge: disable IPv6 router advertisements
+
+Signed-off-by: Samuel Karp 
+---
+ libnetwork/drivers/bridge/bridge.go   |  6 ++
+ libnetwork/drivers/bridge/setup_device.go | 19 +++
+ 2 files changed, 25 insertions(+)
+
+diff --git a/drivers/bridge/bridge.go b/drivers/bridge/bridge.go
+index b617ea7bc4..22ee29e238 100644
+--- a/libnetwork/drivers/bridge/bridge.go
 b/libnetwork/drivers/bridge/bridge.go
+@@ -679,6 +679,12 @@ func (d *driver) createNetwork(config 
*networkConfiguration) (err error) {
+   bridgeAlreadyExists := bridgeIface.exists()
+   if !bridgeAlreadyExists {
+   bridgeSetup.queueStep(setupDevice)
++  bridgeSetup.queueStep(setupDefaultSysctl)
++  }
++
++  // For the default bridge, set expected sysctls
++  if config.DefaultBridge {
++  bridgeSetup.queueStep(setupDefaultSysctl)
+   }
+ 
+   // Even if a bridge exists try to setup IPv4.
+diff --git a/drivers/bridge/setup_device.go b/drivers/bridge/setup_device.go
+index 548ad951df..1343305ae9 100644
+--- a/libnetwork/drivers/bridge/setup_device.go
 b/libnetwork/drivers/bridge/setup_device.go
+@@ -2,6 +2,9 @@ package bridge
+ 
+ import (
+   "fmt"
++  "io/ioutil"
++  "os"
++  "path/filepath"
+ 
+   "github.com/docker/docker/pkg/parsers/kernel"
+   "github.com/docker/libnetwork/netutils"
+@@ -49,6 +52,22 @@ func setupDevice(config *networkConfiguration, i 
*bridgeInterface) error {
+   return err
+ }
+ 
++func setupDefaultSysctl(config *networkConfiguration, i *bridgeInterface) 
error {
++  // Disable IPv6 router advertisements originating on the bridge
++  sysPath := filepath.Join("/proc/sys/net/ipv6/conf/", config.BridgeName, 
"accept_ra")
++  if _, err := os.Stat(sysPath); err != nil {
++  logrus.
++  WithField("bridge", config.BridgeName).
++  WithField("syspath", sysPath).
++  Info("failed to read ipv6 
net.ipv6.conf..accept_ra")
++  return nil
++  }
++  if err := ioutil.WriteFile(sysPath, []byte{'0', '\n'}, 0644); err != 
nil {
++  return fmt.Errorf("libnetwork: Unable to disable IPv6 router 
advertisement: %v", err)
++  }
++  return nil
++}
++
+ // SetupDeviceUp ups the given bridge interface.
+ func setupDeviceUp(config *networkConfiguration, i *bridgeInterface) error {
+   err := i.nlh.LinkSetUp(i.Link)
diff -Nru docker.io-18.09.1+dfsg1/debian/patches/series 
docker.io-18.09.1+dfsg1/debian/patches/series
--- docker.io-18.09.1+dfsg1/debian/patches/series   2019-09-03 
17:25:39.0 +0200
+++ docker.io-18.09.1+dfsg1/debian/patches/series   2020-06-14 
22:12:29.0 +0200
@@ -20,6 +20,7 @@
 cve-2019-13509-03-DebugRequestMiddleware-unconditionally-scrub-data-field.patch
 cve-2019-13509-04-DebugRequestMiddleware-Remove-path-handling.patch
 

Bug#962779: djview4 color PDF export results in a blank page

[Barak A. Pearlmutter]

Thanks for your very thorough bug report.

The changes to tiff2pdf.c in the Debian package are actually inherited
from upstream, because we're tracking upstream development as that's
the easiest way to deal with bugs etc, and upstream is very
cooperative.

So I'd suggest filing this on upstream, because as you say, I'm not
sure it's a good idea for me to patch the Debian package with this
kind of might-break-something-else fix.

Cheers,

--Barak.

Bug#959386: php-imagick: diff for NMU version 3.4.4-4.1

[Ondřej Surý]

Adrian,

please do a direct upload to unstable and thanks for the fix. No need to wait 
15 days.

--
Ondřej Surý 

> On 14 Jun 2020, at 18:51, Adrian Bunk  wrote:
> 
> Control: tags 959386 + patch
> Control: tags 959386 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for php-imagick (versioned as 3.4.4-4.1) and
> uploaded it to DELAYED/15. Please feel free to tell me if I should 
> cancel it.
> 
> cu
> Adrian
> 

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Peter Wu]

Hi Anthony,

On Mon, Jun 08, 2020 at 11:06:29AM +0100, Anthony Perkins wrote:

> > There have some fixes since the 0.2 release, so if it helps I could tag
> > a new version.
> 
> That would be very useful. At the moment I've pulled in a few patches
> that looked like bug fixes since the 0.2 release, but if you could tag a
> new version I can just include all the changes and fixes.

I have just released 0.3 with some additional fixes. Most notably,
support for listing and pairing new devices for a certain Nano receiver.

The v0.3 git tag is signed with my PGP key, key ID
AF74F895D8467CE9050B2B876F256F687D2DF7BB
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

Bug#962832: openms-doc: missing Breaks+Replaces: openms (<< 2.5)

[Andreas Beckmann]

Package: openms-doc
Version: 2.5.0+cleaned1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../openms-doc_2.5.0+cleaned1-3_all.deb ...
  Unpacking openms-doc (2.5.0+cleaned1-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/openms-doc_2.5.0+cleaned1-3_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/openms/AUTHORS', which is also in 
package openms 2.4.0-real-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/openms-doc_2.5.0+cleaned1-3_all.deb


cheers,

Andreas


openms=2.4.0-real-1_openms-doc=2.5.0+cleaned1-3.log.gz
Description: application/gzip

Bug#962831: libmumps-headers-dev: missing Breaks+Replaces: libmumps-seq-dev (<= 5.3.1-2)

[Andreas Beckmann]

Package: libmumps-headers-dev
Version: 5.3.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libmumps-headers-dev_5.3.1-3_all.deb ...
  Unpacking libmumps-headers-dev (5.3.1-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libmumps-headers-dev_5.3.1-3_all.deb (--unpack):
   trying to overwrite '/usr/include/mumps_seq/elapse.h', which is also in 
package libmumps-seq-dev:amd64 5.3.1-2
  Errors were encountered while processing:
   /var/cache/apt/archives/libmumps-headers-dev_5.3.1-3_all.deb

cheers,

Andreas


libmumps-seq-dev=5.3.1-2_libmumps-headers-dev=5.3.1-3.log.gz
Description: application/gzip

Bug#817954: Does this bug prevent firefox from entering backports also?

[Mike Hommey]

On Sun, Jun 14, 2020 at 08:25:10PM +0530, Pirate Praveen wrote:
> 
> 
> On Sun, Jun 14, 2020 at 7:31 am, Mike Hommey  wrote:
> > On Thu, Jun 11, 2020 at 03:22:40PM +0530, Pirate Praveen wrote:
> > >  On Thu, 25 Jul 2019 12:10:45 +0200 Johannes Rohr 
> > > wrote:
> > >  > It would be great to have firefox (or the next firefox-esr) in
> > >  > buster-backports, as it has important new functionality relevant
> > > for
> > >  > privacy and data protection, such as the multi account containers
> > >  > function. However, this bug prevents firefox from entering
> > > testing,
> > >  > which in my understanding implies, that it cannot make it into
> > > backports
> > >  > as well. Is there some way of getting an up-to-date firefox
> > > version into
> > >  > stable? For now I work with the binary directly downloaded from
> > >  > mozilla.org, but this is a kludge.
> > >  >
> > > 
> > >  We have created https://fasttrack.debian.net for packages like this
> > >  which cannot go with stable releases and hence blocked from entering
> > >  testing and backports as well.
> > > 
> > >  Mike,
> > > 
> > >  Would you like to maintain firefox in buster-fasttrack?
> > > 
> > >  I'm part of the team that maintain this unofficial service and
> > > maintains
> > >  gitlab there. If you are okay with the idea, but does not want to
> > > do the
> > >  extra work, I'd be happy to maintain it in fasttrack.
> > 
> > The package in unstable can be built for stable as long as its version
> > contains a ~bpo thing. That could be changed to also support fto. But
> > the bigger problem is that it requires new versions of rustc, cargo and
> > cbindgen, which in turn requires a new version of llvm. And it requires
> > new versions of these quite regularly.
> > 
> > So, no, I'm not really interested in maintaining that.
> > 
> 
> Thanks for the reply. I will ask around if more people are willing to take
> on the challenge and will try it if there is an interest. Things like webRTC
> suport (jitsi video conferencing) needs recent versions of firefox to work
> well and which is my main interest to take on this.

Stable is going to be updated to 78 in a few weeks.

Mike

Bug#962828: libpgjava: CVE-2020-13692

[Christoph Berg]

Re: Salvatore Bonaccorso
> CVE-2020-13692[0]:
> | PostgreSQL JDBC Driver (aka PgJDBC) before 42.2.13 allows XXE.

Hi,

upstream switched the buildsystem in the .13 release, so uploading
isn't as easy as I had hoped. Details are in

https://github.com/pgjdbc/pgjdbc/issues/1440

(Seen the end of the thread, the beginning is about Fedora.)

> Please adjust the affected versions in the BTS as needed.

More info from Dave Cramer:

> > which older versions are affected by this, and what is the impact?
> >
> 
> I would probably only worry about 42.2.x versions
> impact summary
> https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html
> 
> 
> > In Debian, we currently ship:
> >
> > libpgjava  | 9.2-1002-1| oldoldstable | source (ignore, it's EOL
> > really soon)
> > libpgjava  | 9.4.1212-1| oldstable| source
> > libpgjava  | 42.2.5-2  | stable   | source
> > libpgjava  | 42.2.12-1 | testing  | source
> > libpgjava  | 42.2.12-1 | unstable | source
> >
> > Can you share the actual CVE diff, so we can fix it in the older
> > versions?
>
> Here is the diff
> https://github.com/pgjdbc/pgjdbc/commit/14b62aca4764d496813f55a43d050b017e01eb65

(I haven't checked yet if that diff applies to the buster package.)

Christoph

Bug#917574: tcpreplay: CVE-2018-20552 CVE-2018-20553

[Fred Klassen]

Unfortunately this issue got reopened rather than having the a new issue being
opened. I considered original bugs being fixed in 4.3.1 by preventing invalid
data from reaching the functions. The author of the issue took exception
to the fact that the function in question didn’t have safeguards adding
to address potential issues in the future should there be regression.

The latest updates in 4.3.3 safeguards against future issues by additional
checks in the functions rather than simply preventing bad data from reaching
the functions.

Regards,
Fred.

> On Jun 12, 2020, at 10:52 PM, Salvatore Bonaccorso  wrote:
> 
> Hi Christoph,
> 
> On Fri, Dec 28, 2018 at 10:12:14PM +0100, Salvatore Bonaccorso wrote:
>> Source: tcpreplay
>> Version: 4.2.6-1
>> Severity: important
>> Tags: security upstream
>> Forwarded: https://github.com/appneta/tcpreplay/issues/530
>> 
>> Hi,
>> 
>> The following vulnerabilities were published for tcpreplay.
>> 
>> CVE-2018-20552[0]:
>> | Tcpreplay before 4.3.1 has a heap-based buffer over-read in packet2tree
>> | in tree.c.
>> 
>> CVE-2018-20553[1]:
>> | Tcpreplay before 4.3.1 has a heap-based buffer over-read in get_l2len
>> | in common/get.c.
>> 
>> Unless I'm completely mistaken, I think the issues are at least
>> present in 4.2.6, but please double check to be on safe side.
>> 
>> If you fix the vulnerabilities please also make sure to include the
>> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>> 
>> For further information see:
>> 
>> [0] https://security-tracker.debian.org/tracker/CVE-2018-20552
>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20552
>> [1] https://security-tracker.debian.org/tracker/CVE-2018-20553
>>https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20553
>> [2] https://github.com/appneta/tcpreplay/issues/530
>> 
>> Please adjust the affected versions in the BTS as needed.
> 
> Reopened this bug report, as it looks from upstream discussion in
> https://github.com/appneta/tcpreplay/issues/530#issuecomment-480219130
> and following that the fixes were not correct.
> 
> Regards,
> Salvatore
> 

Bug#962830: libpam-tacplus: CVE-2020-13881

[Salvatore Bonaccorso]

Source: libpam-tacplus
Version: 1.3.8-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/kravietz/pam_tacplus/issues/149

Hi,

The following vulnerability was published for libpam-tacplus.

CVE-2020-13881[0]:
| In support.c in pam_tacplus 1.3.8 through 1.5.1, the TACACS+ shared
| secret gets logged via syslog if the DEBUG loglevel and journald are
| used.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13881
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13881
[1] https://github.com/kravietz/pam_tacplus/issues/149

Regards,
Salvatore

Bug#962829: libjpeg-turbo: CVE-2020-13790

[Salvatore Bonaccorso]

Source: libjpeg-turbo
Version: 1:1.5.2-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/libjpeg-turbo/libjpeg-turbo/issues/433

Hi,

The following vulnerability was published for libjpeg-turbo.

CVE-2020-13790[0]:
| libjpeg-turbo 2.0.4, and mozjpeg 4.0.0, has a heap-based buffer over-
| read in get_rgb_row() in rdppm.c via a malformed PPM input file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13790
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13790
[1] https://github.com/libjpeg-turbo/libjpeg-turbo/issues/433
[2] 
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/1bfb0b5247f4fc8f6677639781ce468543490216
 (1.5.x)
[3] 
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/3de15e0c344d11d4b90f4a47136467053eb2d09a
 (2.0.x)

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#962665: python3: System site-packages directory not in sys.path breaking mechanism for pip3 install from source

[Matthias]

> did you use pip3 from Debian or upstream?

It is pip3 from Debian installed via python3-pip package:
pip3 --version
pip 9.0.1 from /usr/lib/python3/dist-packages (python 3.6)

> [¹] https://wiki.debian.org/Python#Deviations_from_upstream
>
> so… if you're using our pip3, then there's a bug (it should install into
> dist-packages ...

I'm a little surprised, that the modules installed from source with pip3
should be placed in the same folder, as the modules installed via *.deb
packages.
As I understand the wiki article, dist-packages was chosen to separate
python modules installed via Debian packages from packages, that were
installed from source.

So the same approach why /usr/ and /usr/local/ exists.

When this is the wanted behavior, than fine, at least it will work.



Am 12.06.20 um 10:33 schrieb Piotr Ozarowski:

[Matthias, 2020-06-11]

after installing a python package (radiotray) from source with pip3 (sudo pip3
install .) The package is not listed by pip3 (pip3 list), nor can it be
imported.


did you use pip3 from Debian or upstream?


When checking manually the files a located under: /usr/lib/python3.6/site-
packages/radiotray
But this path is missing in the sys.path of python3:

[...]

So please add the site-packages directory under /usr to the sys.path of
python3.


this will never happen, we removed site-packages for a good reason¹

[¹] https://wiki.debian.org/Python#Deviations_from_upstream

so… if you're using our pip3, then there's a bug (it should install into
dist-packages even if user used the
--I-know-it-s-stupid-but-please-use-sudo-and-break-my-system option)
If not (i.e. you used pip3 from outside Debian) then there's nothing we
can do.

Bug#962828: libpgjava: CVE-2020-13692

[Salvatore Bonaccorso]

Source: libpgjava
Version: 42.2.12-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for libpgjava.

CVE-2020-13692[0]:
| PostgreSQL JDBC Driver (aka PgJDBC) before 42.2.13 allows XXE.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13692
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13692
[1] 
https://github.com/pgjdbc/pgjdbc/commit/14b62aca4764d496813f55a43d050b017e01eb65

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#956213: sa-exim: Can't stat /var/spool/sa-exim/tuplets: Permission denied

[Stephan Helma]

I had a fresh look at the problem and noticed, that the parent directory
'/var/spool/sa-exim/' were not owned by Debian-exim, but by me (a simple
user). I believe that happened when I had to migrate the system to a new
virtual machine. I now changed the ownership of '/var/spool/sa-exim/' to
'Debian-exim:Debian-exim' and I don't get this error message anymore.

I guess that resolved the problem and the bug report can be closed.

Bug#962827: libphp-phpmailer: CVE-2020-13625

[Salvatore Bonaccorso]

Source: libphp-phpmailer
Version: 6.1.5-0.1
Severity: grave
Tags: security upstream
Control: found -1 6.0.6-0.1
Control: found -1 5.2.14+dfsg-2.3+deb9u1
Control: found -1 5.2.14+dfsg-2.3

Hi,

The following vulnerability was published for libphp-phpmailer.

Filling as RC severity as currently as libphp-phpmailer seems
currently without maintainer. Bullseye should ideally be released with
an active maintainer for libphp-phpmailer.

CVE-2020-13625[0]:
| PHPMailer before 6.1.6 contains an output escaping bug when the name
| of a file attachment contains a double quote character. This can
| result in the file type being misinterpreted by the receiver or any
| mail relay processing the message.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13625
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13625
[1] 
https://github.com/PHPMailer/PHPMailer/security/advisories/GHSA-f7hx-fqxw-rvvj
[2] 
https://github.com/PHPMailer/PHPMailer/commit/c2796cb1cb99d7717290b48c4e6f32cb6c60b7b3

Regards,
Salvatore

Bug#962826: nagios4: CVE-2020-13977

[Salvatore Bonaccorso]

Source: nagios4
Version: 4.3.4-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for nagios4.

CVE-2020-13977[0]:
| Nagios 4.4.5 allows an attacker, who already has administrative access
| to change the "URL for JSON CGIs" configuration setting, to modify the
| Alert Histogram and Trends code via crafted versions of the
| archivejson.cgi, objectjson.cgi, and statusjson.cgi files.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13977
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13977
[1] 
https://github.com/NagiosEnterprises/nagioscore/commit/8deeca7cad3df1143ad9c351d107b5c0a6c61213

Regards,
Salvatore

Bug#962825: node-opencv: FTBFS against nodejs 12.18 - fixed in upstream version 7.0.0

[Jérémy Lal]

Package: node-opencv
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi
this package fails to build against node 12.18,
and upstream has already version 7.0.0 fixing the issue.

However, upstream forgot to push git tags:
https://github.com/peterbraden/node-opencv/issues/652#issuecomment-643807293

Jérémy

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

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

Versions of packages node-opencv depends on:
ii  libc6   2.30-8
ii  libgcc-s1   10.1.0-3
ii  libnode64   10.21.0~dfsg-1
pn  libopencv-calib3d4.2
pn  libopencv-contrib4.2
pn  libopencv-core4.2   
pn  libopencv-highgui4.2
pn  libopencv-imgcodecs4.2  
pn  libopencv-imgproc4.2
pn  libopencv-objdetect4.2  
pn  libopencv-video4.2  
pn  libopencv-videoio4.2
ii  libstdc++6  10.1.0-3
pn  node-buffers
pn  node-istanbul   
ii  node-nan2.14.0-1
ii  node-pre-gyp0.10.2-3
hi  nodejs  10.21.0~dfsg-1

node-opencv recommends no packages.

node-opencv suggests no packages.

Bug#962804: wfmath: autopkgtest failure: no acceptable C compiler found in $PATH

[Olek Wojnar]

Ah, ok. Good to know and that makes sense. Thanks to you both. I'm still a
bit new to this autopkgtest thing but it seems worthwhile to get it figured
out. I'll add build-essential explicitly since none of the other build
dependencies should be necessary to compile the test.

-Olek

Bug#962824: r-cran-v8: FTBFS against nodejs 12.18.0

[Jérémy Lal]

Package: r-cran-v8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

this package cannot be built against nodejs 12.18.0.
this blocks nodejs migration to testing.

I pinged upstream about that:
https://github.com/jeroen/V8/pull/87

Cheers,
Jérémy

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

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

Versions of packages r-cran-v8 depends on:
ii  libc6 2.30-8
ii  libgcc-s1 10.1.0-3
ii  libjs-underscore  1.9.1~dfsg-1
ii  libnode64 10.21.0~dfsg-1
ii  libstdc++610.1.0-3
pn  r-api-4.0 
pn  r-base-core   
pn  r-cran-curl   
pn  r-cran-jsonlite   
pn  r-cran-rcpp   

Versions of packages r-cran-v8 recommends:
pn  r-cran-testthat  

Versions of packages r-cran-v8 suggests:
pn  r-cran-knitr  
pn  r-cran-rmarkdown  

Bug#962518: cegui-mk2 FTBFS on mipsel/mips64el: symbol differences

[Olek Wojnar]

Thanks to all of you for taking a look at this and for your insights and
advice!I think I've definitely learned a couple things about how to
do symbols better in the future.

In the near term, I'm going to take the advice to just get rid of the
symbols file. I've been so busy with Bazel [1] recently that I just don't
have the time to work through this right now. But I'm keeping this email
flagged for follow-up because I would definitely like to implement a
visibility patch in the future. It looks like it will make the symbols file
MUCH more manageable! Thanks again!

-Olek

[1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1

Bug#962804: wfmath: autopkgtest failure: no acceptable C compiler found in $PATH

[Simon McVittie]

On Sun, 14 Jun 2020 at 14:15:02 -0400, Olek Wojnar wrote:
> Hmm, is build-essential not automatically installed in the CI environment? 
> That
> seems to be the most likely reason for this failure. I assumed that all
> packages (e.g. build-essential) that we assume to be present for packaging
> would be present here as well. Is that not the case?

No, as with ordinary packaging you can only rely on having the
Essential:yes set, plus their hard dependencies, plus the hard
dependencies you declare (recursively). (In practice testbeds will
usually have a few extra packages, such as an init system, but don't
rely on those.)

Some tests compile what they need from scratch, but some don't. In
particular, this means maintainers are able to verify with reasonable
confidence that a package's dependencies are sufficient to make it work.

smcv

Bug#962804: wfmath: autopkgtest failure: no acceptable C compiler found in $PATH

[Paul Gevers]

Hi Olek,

On 14/06/2020 20.15, Olek Wojnar wrote:
> checking for gcc... no
> checking for cc... no
> checking for cl.exe... no
> configure: error: in
> `/tmp/autopkgtest-lxc.nwce0fke/downtmp/build.tAZ/src':
> configure: error: no acceptable C compiler found in $PATH
> 
> 
> Hmm, is build-essential not automatically installed in the CI
> environment? That seems to be the most likely reason for this failure. I
> assumed that all packages (e.g. build-essential) that we assume to be
> present for packaging would be present here as well. Is that not the
> case? If so, this will likely be a very easy fix.

No, as per specification, you need @builddeps@ for that:
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst


Paul



signature.asc
Description: OpenPGP digital signature

Bug#962823: RFS: lv2dynparam1/2-6.1 [NMU, RC] -- LV2 plugin interface extension

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "lv2dynparam1"

 * Package name: lv2dynparam1
   Version : 2-6.1
   Upstream Author : Nedko Arnaudov 
 * URL : http://download.gna.org/lv2dynparam/
 * License : GPL-2
 * Vcs : 
https://anonscm.debian.org/cgit/pkg-multimedia/lv2dynparam1.git
   Section : sound

It builds those binary packages:

  liblv2dynparamhost1-1 - LV2 plugin interface extension - host
  liblv2dynparamplugin1-0 - LV2 plugin interface extension - plugin
  liblv2dynparam1-dev - lv2dynparam is a LV2 plugin interface extension

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/lv2dynparam1/lv2dynparam1_2-6.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix FTCBFS. (Closes: #946068)


-- 
Regards
Sudip

Bug#946068: lv2dynparam1: diff for NMU version 2-6.1

[Sudip Mukherjee]

Control: tags 946068 + patch
Control: tags 946068 + pending

Dear maintainer,

I've prepared an NMU for lv2dynparam1 (versioned as 2-6.1) and
uploaded it to mentors for sponsoring. Please feel free to tell me if I
should remove it.

--
Regards
Sudip

diff -Nru lv2dynparam1-2/debian/changelog lv2dynparam1-2/debian/changelog
--- lv2dynparam1-2/debian/changelog 2016-11-07 22:56:45.0 +
+++ lv2dynparam1-2/debian/changelog 2020-06-14 18:57:30.0 +0100
@@ -1,3 +1,10 @@
+lv2dynparam1 (2-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS. (Closes: #946068)
+
+ -- Sudip Mukherjee   Sun, 14 Jun 2020 18:57:30 
+0100
+
 lv2dynparam1 (2-6) unstable; urgency=medium
 
   * Remove DMUA.
diff -Nru lv2dynparam1-2/debian/patches/fix_ftbfs.patch 
lv2dynparam1-2/debian/patches/fix_ftbfs.patch
--- lv2dynparam1-2/debian/patches/fix_ftbfs.patch   1970-01-01 
01:00:00.0 +0100
+++ lv2dynparam1-2/debian/patches/fix_ftbfs.patch   2020-06-14 
18:48:57.0 +0100
@@ -0,0 +1,20 @@
+Description: Use lv2.pc
+ The dependency was changed to lv2-dev previously but lv2-dev provides lv2.pc,
+ not lv2core.pc.
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/946068
+
+---
+
+--- lv2dynparam1-2.orig/configure.ac
 lv2dynparam1-2/configure.ac
+@@ -32,7 +32,7 @@ AC_PROG_LIBTOOL
+ #AC_HEADER_STDC
+ #AC_CHECK_HEADERS([stddef.h stdint.h stdlib.h string.h])
+ 
+-PKG_CHECK_MODULES(LV2, lv2core >= 1)
++PKG_CHECK_MODULES(LV2, lv2 >= 1)
+ 
+ # Checks for typedefs, structures, and compiler characteristics.
+ #AC_C_CONST
diff -Nru lv2dynparam1-2/debian/patches/series 
lv2dynparam1-2/debian/patches/series
--- lv2dynparam1-2/debian/patches/series2013-10-30 20:45:07.0 
+
+++ lv2dynparam1-2/debian/patches/series2020-06-14 18:43:17.0 
+0100
@@ -1 +1,2 @@
 0001-buildsystem.patch
+fix_ftbfs.patch

Bug#962822: ITP: bmtk -- development package for building, simulating and analysing large-scale networks

[Shayan Doust]

Package: wnpp
Severity: wishlist

Subject: ITP: bmtk -- development package for building, simulating and 
analysing large-scale networks
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: bmtk
  Version : 0.0.7
  Upstream Author : Allen Institute
* URL : https://github.com/AllenInstitute/bmtk
* License : BSD-3-Clause
  Programming Lang: Python
  Description : development package for building, simulating and analysing 
large-scale networks
 The brain modelling toolkit is a software development package for
 building, simulating and analysing large-scale networks of different
 levels of resolution.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/bmtk

Bug#962821: libwebsockets 4.x package built without extensions support

[Matti Hamalainen]

Source: libwebsockets
Severity: normal
Tags: patch

Dear Maintainer,

libwebsockets 4.0.15 recently landed to Debian testing, and I noticed that one
of my own programs using it failed to build against it, as the new version
apparently is not built with extensions support enabled (appearing as undefined
reference to `lws_extension_callback_pm_deflate').

I am attaching a patch to debian/rules to enable the extensions support, as it
was enabled in previous (3.2 etc) versions of this package.



-- 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.6.18-qcmm (SMP w/8 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)
diff -ur lws-orig/libwebsockets-4.0.15/debian/rules 
lws-fix/libwebsockets-4.0.15/debian/rules
--- lws-orig/libwebsockets-4.0.15/debian/rules  2019-12-28 12:13:56.0 
+0200
+++ lws-fix/libwebsockets-4.0.15/debian/rules   2020-06-14 21:06:51.836172331 
+0300
@@ -24,7 +24,8 @@
dh_auto_configure -- -DCMAKE_LIBRARY_ARCHITECTURE=${arch} \
-DLIB_SUFFIX=/${arch} -DLWS_WITHOUT_DAEMONIZE=OFF \
-DLWS_WITH_LIBEV=ON -DLWS_WITH_LIBUV=ON \
-   -DLWS_UNIX_SOCK=ON -DLWS_IPV6=ON
+   -DLWS_UNIX_SOCK=ON -DLWS_IPV6=ON \
+   -DLWS_WITH_ZLIB=ON -DLWS_WITHOUT_EXTENSIONS=OFF
 
 override_dh_install-arch:
$(RM) 
$(CURDIR)/debian/tmp/usr/lib/${arch}/pkgconfig/libwebsockets_static.pc

Bug#962804: wfmath: autopkgtest failure: no acceptable C compiler found in $PATH

[Olek Wojnar]

Hi Paul,

Thanks for the bug report. I'd noticed the error on DDPO but hadn't had
time to investigate.

On Sun, Jun 14, 2020 at 7:18 AM Paul Gevers  wrote:

> I copied some of the output at the bottom of this report. Are you
> missing a test dependency?
>




> checking for gcc... no
> checking for cc... no
> checking for cl.exe... no
> configure: error: in `/tmp/autopkgtest-lxc.nwce0fke/downtmp/build.tAZ/src':
> configure: error: no acceptable C compiler found in $PATH


Hmm, is build-essential not automatically installed in the CI environment?
That seems to be the most likely reason for this failure. I assumed that
all packages (e.g. build-essential) that we assume to be present for
packaging would be present here as well. Is that not the case? If so, this
will likely be a very easy fix.

-Olek

Bug#962808: vmdb2: LVM partitions do not work for grub

[Gunnar Wolf]

Florian La Roche dijo [Sun, Jun 14, 2020 at 02:26:17PM +0200]:
> creating one big LVM partition without encryption and then using grub to
> boot up does not seem to have a valid configuration.
> 
> With vmdb2 0.14.1 I couldn't find any way to reference the device grub
> is getting installed on. It works for me by hardcoding the
> loopback-Device into the configuration ("/dev/loop0") with some crude
> checks within the Makefile for nobody else to use the loopback device.
> 
> The used yaml config file can be seen here:
> https://github.com/laroche/arm-devel-infrastructure/blob/master/vmdb2-debian/debian-testing-amd64.yaml
> 
> How can this be configured correctly in the *.yaml file? Any working
> example for this?
> (0.16 from unstable also does not work for me.)

I have never created an image with lvm2 using vmdb2, although it is
supported. Please note that (starting from 0.16-2) we are now shipping
the vmdb2 manual in /usr/share/doc/vmdb2; please refer to it - The
lvcreate step is 4.11 (page 13 of the PDF), vgcreate is 4.20 (page 16
-- Yes, they are quite apart; the manual is autogenerated, with the
steps in alphabetical order :-P )

I do not completely follow what is the issue with Grub here. Is it
failing to find your logical volumes? Have you tried setting up a
non-LVM boot partition, and a LVM setting for the rest of your system?
(I guess you have, as your /boot partition is commented out in your
yaml)

I understand the reason why /dev/loop0 is not expressly referenced is
because vmdb2 is intended to build an image (a single image), so no
more than a single device is supported ..?

What happens when you build with the file you are sharing? What error
do you report?

Bug#962809: vmdb2: allow setting partitions bootable

[Gunnar Wolf]

Florian La Roche dijo [Sun, Jun 14, 2020 at 02:29:50PM +0200]:
> it would be good to add configuration possibiities to toggle a partition
> bootable within the config file. I am right now changing the image after
> creating it with vmdb2, code within vmdb2 would keep the whole setup in
> one place.

What do you mean by bootable? Is it the old DOS partition flag for
this? What difference does that make nowadays?

Greetings,

Bug#962820: hashcash: Newer version available

[Christer Mjellem Strand]

Package: hashcash
Version: 1.21-2
Severity: wishlist

Dear Maintainer,

A newer version, 1.22, has been available for 14(!) years at time of writing.
A pre-release of 1.23 was also released in 2011, but given its age, I think
this should be considered for packaging.

Upstream continues to live at , but the source is
also available from , though it's
unclear whether this is an official or third party effort.

Please consider packaging a marginally newer version.

Thanks.


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

Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/8 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hashcash depends on:
ii  libc6  2.28-10

hashcash recommends no packages.

hashcash suggests no packages.

-- no debconf information

Bug#959386: php-imagick: diff for NMU version 3.4.4-4.1

[Adrian Bunk]

Control: tags 959386 + patch
Control: tags 959386 + pending

Dear maintainer,

I've prepared an NMU for php-imagick (versioned as 3.4.4-4.1) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru php-imagick-3.4.4/debian/changelog php-imagick-3.4.4/debian/changelog
--- php-imagick-3.4.4/debian/changelog	2020-03-02 11:04:48.0 +0200
+++ php-imagick-3.4.4/debian/changelog	2020-06-14 12:26:18.0 +0300
@@ -1,3 +1,10 @@
+php-imagick (3.4.4-4.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Skip tests that fail with PHP 7.4 on armel. (Closes: #959386)
+
+ -- Adrian Bunk   Sun, 14 Jun 2020 12:26:18 +0300
+
 php-imagick (3.4.4-4) unstable; urgency=medium
 
   [ Ondřej Surý ]
diff -Nru php-imagick-3.4.4/debian/patches/armel.patch php-imagick-3.4.4/debian/patches/armel.patch
--- php-imagick-3.4.4/debian/patches/armel.patch	1970-01-01 02:00:00.0 +0200
+++ php-imagick-3.4.4/debian/patches/armel.patch	2020-06-14 12:26:18.0 +0300
@@ -0,0 +1,44 @@
+Description: Skip tests that fail with PHP 7.4 on armel
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/959386
+
+--- php-imagick-3.4.4.orig/imagick-3.4.4/tests/064_cropThumbNailImage.phpt
 php-imagick-3.4.4/imagick-3.4.4/tests/064_cropThumbNailImage.phpt
+@@ -2,6 +2,7 @@
+ Test for round issues
+ --SKIPIF--
+ 
+--- php-imagick-3.4.4.orig/imagick-3.4.4/tests/072_Imagick_evaluateImage_basic.phpt
 php-imagick-3.4.4/imagick-3.4.4/tests/072_Imagick_evaluateImage_basic.phpt
+@@ -2,6 +2,7 @@
+ Test Imagick, evaluateImage
+ --SKIPIF--
+ 
diff -Nru php-imagick-3.4.4/debian/patches/series php-imagick-3.4.4/debian/patches/series
--- php-imagick-3.4.4/debian/patches/series	2020-03-02 11:04:48.0 +0200
+++ php-imagick-3.4.4/debian/patches/series	2020-06-14 12:23:59.0 +0300
@@ -3,3 +3,4 @@
 no-openmp-threads.patch
 0003-Disable-test-014-which-fails-due-to-system-resources.patch
 0004-Disable-remaining-tests-failing-with-7.4.patch
+armel.patch

Bug#863511: numba: segfaults on ppc64el

[Rebecca N. Palmer]

Control: tag -1 - fixed-upstream

Upstream discussion suggests this was fixed ... but then reintroduced in 
the move to LLVM 8:

https://github.com/numba/numba/issues/4026

test_array_reshape is still one of the tests that crashes (but a full 
test run doesn't even get that far because test_typedlist.py crashes 
during collection - see #863507).

Bug#863507: numba: test collection crashes/errors out [armel, ppc64el]

[Rebecca N. Palmer]

Control: retitle -1 test collection crashes/errors out [armel, ppc64el]

The tests now do get run on armhf, but still don't on armel and ppc64el. 
 This appears to be because some test modules crash/abruptly exit 
*during test collection*.  (pytest-xdist can start a new worker after a 
crash, but each worker collects all tests before running any of them, so 
if collection crashes no tests ever get run.)


The files affected are
ppc64el and armel: test_typedlist.py

armel only:
test_errorhandling.py
test_inlining.py
test_serialize.py
npyufunc/test_ufuncbuilding.py

The exact errors aren't displayed from pytest, but are if one imports 
these modules directly.  They suggest that the armel crash might be 
related to #863508 (it no longer happens during documentation build, but 
might not be totally fixed) and the ppc64el one to 
https://github.com/numba/numba/issues/4026


qemu-armel$ python3 -X faulthandler ; echo $?
Python 3.8.3 (default, May 14 2020, 11:03:12)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numba.tests.test_typedlist
LLVM ERROR: Symbol not found: __sync_fetch_and_add_4
1

(If you want to set a breakpoint here, it's probably 
https://sources.debian.org/src/llvm-toolchain-8/1:8.0.1-9/lib/Support/ErrorHandling.cpp/?hl=126#L115 
)


qemu-ppc64el$ python3 -X faulthandler
Python 3.8.3 (default, May 14 2020, 11:03:12)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numba.tests.test_typedlist
/usr/lib/python3/dist-packages/numpy/core/getlimits.py:53: 
RuntimeWarning: divide by zero encountered in log10

  self.precision = int(-log10(self.eps))
Fatal Python error: Segmentation fault

Current thread 0x004000d5ed20 (most recent call first):
  File "/usr/lib/python3/dist-packages/numba/typed/typedlist.py", line 
260 in append
  File "/usr/lib/python3/dist-packages/numba/tests/test_typedlist.py", 
line 25 in 
  File "", line 219 in 
_call_with_frames_removed

  File "", line 783 in exec_module
  File "", line 671 in _load_unlocked
  File "", line 975 in _find_and_load_unlocked
  File "", line 991 in _find_and_load
  File "", line 1 in 
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

The above testing was with 0.48.0-5 (unstable), but the build logs imply 
that this bug still exists in 0.49.1-1exp1 (experimental).

Bug#962819: RFP: foliate -- simple and modern GTK eBook reader

[Lev Lamberov]

Package: wnpp
Severity: wishlist

* Package name: foliate
  Version : 2.2.1
  Upstream Author : John Factotum
* URL or Web page : https://johnfactotum.github.io/foliate/
* License : GPL-3+
  Programming Lang: Javascipt
  Description : simple and modern GTK eBook reader

A simple and modern GTK eBook viewer, built with GJS and Epub.js.

Its features:

 - Supports EPUB, Mobipocket, Kindle, FictionBook, and comic book
   archive formats
 - Single-column, two-column, or continuous scrolling layouts
 - Adjust font, line-spacing, and margins
 - Customize colors and brightness
 - Auto-hyphenation
 - Skeuomorphic mode
 - Auto-hide cursor and window controls
 - Supports right-to-left and vertical text
 - Table of contents menu or sidebar
 - Find in book
 - Progress slider, with chapter marks
 - Reading time estimates
 - Zoom in on and rotate images
 - Open footnotes in popovers
 - Trackpad gestures—use two-finger swipe to turn the page
 - Open multiple books at the same time, or open the same file in
   multiple windows
 - Reading progress, bookmarks, and annotations stored in your XDG data
   directory as plain JSON files, so you can backup or sync them easily
 - Learn More
 - Search annotations
 - Export annotations to plain text, HTML, Markdown, and more
 - Look up words in Wiktionary, Wikipedia, or offline DICT and StarDict
   dictionaries
 - Translate passages with Google Translate
 - Text-to-speech with eSpeak NG, Festival, or other engines
 - Get books online from OPDS feeds

Bug#962818: ucf: dpkg-divert error when upgrading grub with diverted config

[debian]

Package: ucf
Version: 3.0042
Severity: important

Dear Maintainer,

Seeing this when I upgrade or reinstall grub-pc. When that happens:


Setting up grub-pc (2.04-8) ...
grep: ]: No such file or directory
/usr/bin/ucf: 445: [: missing ]
dpkg-divert: error: filename "\/etc\/default\/grub" is not absolute

Use --help for help about diverting files.
dpkg: error processing package grub-pc (--configure):
installed grub-pc package post-installation script subprocess returned
error exit status 2


If I change /usr/bin/ucf like this diff, I still get the grep error but
the rest proceeds as expected:

diff --git a/ucf b/ucf
index fde42ae..49d07c9 100755
--- a/ucf
+++ b/ucf
@@ -448,11 +448,11 @@ if [ -n "$divert_line" ]; then
else
# extract the name of the diverted package.
# The fact that this requires output parsing is bug #485012
- divert_package=$(dpkg-divert --listpackage "$safe_dest_file")
+ divert_package=$(dpkg-divert --listpackage "$dest_file")
fi

if [ "$divert_package" != "$opt_package" ]; then
- safe_dest_file=$(dpkg-divert --truename "safe_dest_file")
+ safe_dest_file=$(dpkg-divert --truename "$dest_file")
fi
fi


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

Kernel: Linux 5.6.0-2-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ucf depends on:
ii coreutils 8.30-3
ii debconf 1.5.74
ii sensible-utils 0.0.12+nmu1

ucf recommends no packages.

ucf suggests no packages.

-- debconf information excluded

Bug#962784: [Pkg-puppet-devel] Bug#962784: facter aborts with free(): invalid pointer

[Russ Allbery]

Stig Sandbeck Mathisen  writes:

> Looks like the same bug as http://bugs.debian.org/962692 and related to
> https://bugs.debian.org/962320

Ah, indeed, thank you!  Somehow I missed those.  #962320 seems like it
should be assigned to facter and merged with this bug; I don't think it's
Boost's fault that a binary links with two versions of the same shared
library (unless the contention is that symbol versioning should make this
safe, which can be quite challenging for C++ libraries).

> A quick workaround to get facter to run is to create the three
> directories:

> /etc/facter/facts.d
> /etc/puppetlabs/facter/facts.d
> /opt/puppetlabs/facter/facts.d

Yup, confirmed that works.  Thank you!

-- 
Russ Allbery (r...@debian.org)  

Bug#960594: systemd: services (bind9, squid) are started before their filesystems had been mounted

[Michael Biebl]

Hi


Am 20.05.20 um 23:01 schrieb Michael Biebl:
> Am 19.05.20 um 18:38 schrieb Michael Biebl:
> 
>> Could you restore the original (i.e. undo all the changes I asked you to
>> do) and copy the attached file to /lib/lsb/init-functions.d/40-systemd
>>
>> Please report back if that fixes your problem (and/or if you encountered
>> new problems)
> 
> Did you have a chance to test with the updated lsb init-functions script?

I would still be interested if the proposed changes to the lsb hook did
solve your problems.
In that case I might consider updating the lsb-hook/service/invoke-rc.d
accordingly (to use --no-block for reload and not --ignore-dependencies)

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#962817: ITP: python-django-colorfield -- Simple color fields for Django

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 

* Package name: python-django-colorfield
  Version : 0.3.0
  Upstream Author : Fabio Caccamo
* URL : 
https://github.com/fabiocaccamo/django-colorfield
* License : Expat
  Programming Lang: Python
  Description : Simple color fields for Django

 This module contains functions to provide color fields
 picker in Django applications.

I want to package it because it is a dep of https://flopedt.org .

I'll maintain it within the Debian Python Modules Team.

Cheers,

JP

Bug#962806: RFS: cwm/6.6-2 -- lightweight and efficient window manager for X11

[James McDonald]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "cwm"

* Package name: cwm
  Version : 6.6-2
  Upstream Author : Leah Neukirchen 
* URL : https://github.com/leahneukirchen/cwm
* License : ISC
* Vcs : https://github.com/jamesmcdonald/cwm
  Section : x11

It builds those binary packages:

 cwm - lightweight and efficient window manager for X11

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

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

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

 dget -x https://mentors.debian.net/debian/pool/main/c/cwm/cwm_6.6-2.dsc

Changes since the last upload:

  * Allow override of pkg-config location to support cross-platform
builds (Closes: #960512)
  * Add VCS fields to debian/control
  * Update standards version to 4.5.0
  * Update debhelper compat to 13

Regards,

--
James McDonald

Bug#962816: ITP: emacs-pg-el -- Emacs Lisp interface for PostgreSQL

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 
Control: block 962688 by -1

* Package name: emacs-pg-el
  Version : 0.13~git.20130731.456516ec-1
  Upstream Author : Eric Marsden 
* URL : https://github.com/cbbrowne/pg.el
* License : GPL-2+
  Programming Lang: Emacs Lisp
  Description : Emacs Lisp interface for PostgreSQL

Packaging as a dependency of emacsql, another ITP of mine.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#962814: /usr/bin/glxgears: glxgears crashes with segmentation fault

[Aleksei Gorelov]

Package: mesa-utils
Version: 8.4.0-1+b1
Severity: important
File: /usr/bin/glxgears

Dear Maintainer,

After last update glxgears begun to crash with segmentation fault error:
$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
Segmentation fault

I also have segfaults when trying to start other software which uses GPUs (for 
example mpv).
I suppose that the latest update of mesa to the version 20.0.7-1 might be the 
reason of this.

My GPU is:
00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 
520] (rev 07) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Skylake GT2 [HD Graphics 520]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915


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

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

Versions of packages mesa-utils depends on:
ii  libc6   2.30-8
ii  libgl1  1.3.1-1
ii  libglew2.1  2.1.0-4+b1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libx11-62:1.6.9-2+b1
ii  libxext62:1.3.3-1+b2

mesa-utils recommends no packages.

mesa-utils suggests no packages.

-- no debconf information

Bug#962815: Please upgrade to latest upstream version (1.1.1)

[Ole Streicher]

Source: pywavelets
Version: 0.5.1-1.3
Severity: wishlist

Dear maintainer,

The current version of pywavelet (0.5.1) is quite old, from 2016. The
newest version, 1.1.1, is out since Oct 2019 and is now required for the
new version (0.17.2) of skimage. Therefore, I would ask to upgrade the
package to the latest version.

Best regards

Ole Streicher

Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.

[Philipp Kern]

On 11.05.20 11:53, Winfried Münch wrote:
> package: s390-tools
> 
> Version: current Installer from 04.05.2020 21:14
> http://ftp.halifax.rwth-aachen.de/debian/dists/buster/main/installer-s390x/current/images/generic/
> 
> 
> When I install debian I run in this Problem (from console 4):
> 
> May 11 09:43:43 debootstrap: Errors were encountered while processing:
> May 11 09:43:43 debootstrap:  s390-tools
> May 11 09:43:44 debootstrap: dpkg: dependency problems prevent
> configuration of s390-tools:
> May 11 09:43:44 debootstrap:  s390-tools depends on perl:any.
> May 11 09:43:44 debootstrap:
> May 11 09:43:44 debootstrap: dpkg: error processing package s390-tools
> (--configure):
> May 11 09:43:44 debootstrap:  dependency problems - leaving unconfigured
> 
> Installation failed in step install base system.

perl:any is not part of the transitive closure that debootstrap
calculates. To me it looks like a bug in debootstrap in that it does not
find a deb to download because it does not drop the :any - either in
pkgdetails or before.

This was presumably broken by 2.3.0-1 which packaged ziomon and included
a ${perl:Depends} on the main package as well - possibly because Lintian
alerted about the missing dependency. That was technically correct, as
it includes binaries that require modules from perl rather than
perl-base. And it would presumably have worked if "perl:any" had instead
been substituted as "perl".

It's pretty telling how late this was discovered, sort of pointing out
that Debian s390x has no users at all if that kind of bug slips into a
stable release. Ubuntu forked the base tooling and thus was not
affected. To be honest, that tells me that the port should be demoted
and not be part of the next release. Especially given the lack of
(motivated) porters.

Furthermore it seems like the current debian-installer daily build does
not boot and ends up in disabled PSW before printing even a single line
of output.

I never managed to get any kind of continuous integration going myself
given how hard it is to integrate with existing Debian infrastructure to
test it properly - unless you are an admin there already. Even a qemu
setup would have spotted this particular bug. But without any users who
care I also don't think it is worth spending much time on this.

Kind regards and sorry
Philipp Kern

Bug#956694: Clarification: [RFS] spdlog

[Nilesh Patra]

> For sopt, the build fails with the logs same as what Ole sharedearlier - but 
> looking at them, it seems that spdlog is probably not responsible for the 
> failure.


By same logs, I do not mean the one in the original bug report, but the
logs which Ole got after workaround: #953855

cd /build/sopt-3.0.1/obj-x86_64-linux-gnu/cpp/tests && /usr/bin/cmake -E
cmake_link_script CMakeFiles/test_padmm.dir/link.txt --verbose=1
/usr/lib/ccache/c++  -g -O2 -fdebug-prefix-map=/build/sopt-3.0.1=.
-fstack-protector-strong -Wformat -Werror=format-security
-DSPDLOG_FMT_EXTERNAL -Wdate-time -D_FORTIFY_SOURCE=2  -std=gnu++11
-Wl,-z,relro >
/usr/bin/ld: CMakeFiles/copy_tiff.dir/copy_tiff.cc.o: in function
`fmt::v6::basic_format_context
>, char>::on_error(char const*)':
/usr/include/fmt/core.h:1169: undefined reference to
`fmt::v6::internal::error_handler::on_error(char const*)'

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

I suspect this is due to a missing flag like I said earlier.

Regards,
Nilesh

Bug#817954: Does this bug prevent firefox from entering backports also?

[Pirate Praveen]

On Sun, Jun 14, 2020 at 7:31 am, Mike Hommey  wrote:

On Thu, Jun 11, 2020 at 03:22:40PM +0530, Pirate Praveen wrote:
 On Thu, 25 Jul 2019 12:10:45 +0200 Johannes Rohr  
wrote:

 > It would be great to have firefox (or the next firefox-esr) in
 > buster-backports, as it has important new functionality relevant 
for

 > privacy and data protection, such as the multi account containers
 > function. However, this bug prevents firefox from entering 
testing,
 > which in my understanding implies, that it cannot make it into 
backports
 > as well. Is there some way of getting an up-to-date firefox 
version into

 > stable? For now I work with the binary directly downloaded from
 > mozilla.org, but this is a kludge.
 >

 We have created https://fasttrack.debian.net for packages like this
 which cannot go with stable releases and hence blocked from entering
 testing and backports as well.

 Mike,

 Would you like to maintain firefox in buster-fasttrack?

 I'm part of the team that maintain this unofficial service and 
maintains
 gitlab there. If you are okay with the idea, but does not want to 
do the

 extra work, I'd be happy to maintain it in fasttrack.


The package in unstable can be built for stable as long as its version
contains a ~bpo thing. That could be changed to also support fto. But
the bigger problem is that it requires new versions of rustc, cargo 
and
cbindgen, which in turn requires a new version of llvm. And it 
requires

new versions of these quite regularly.

So, no, I'm not really interested in maintaining that.



Thanks for the reply. I will ask around if more people are willing to 
take on the challenge and will try it if there is an interest. Things 
like webRTC suport (jitsi video conferencing) needs recent versions of 
firefox to work well and which is my main interest to take on this.



Mike

Bug#962813: does not build with ghc 8.8

[Picca Frédéric-Emmanuel]

Source: haskell-tree-monad
Severity: critical

Hello,

this package does not build with the up-comming ghc 8.8 version.
It is not part of stackage LTS, and it was not updated by upstream since 2009.
It means that there is few chance to see the upstream fix this issue.

so it is considere to remove it from Debian.

Someone can salvage it by providing a patch (prefereably to the upstream first).

Cheers
 


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

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

Bug#956694: [RFS] spdlog

[Nilesh]

Hi,

I've pushed a patch to the team repo[1] to fix this. I patched
./include/spdlog/tweakme.h: Since this file wasn't getting included to
other .h files, I included this bit.
It looks fine to me.

To test this, I did the following:

1. I wrote my own sample code to just include the libs, and it seems to
work.
2. For purify package: Since Ole did a workaround and uploaded, I
checked out the version w/o those workarounds, and it works.

I did the following:
    $ git checkout debian/2.0.0-4
    $ quilt push remove-GreatCMakeCookOff-dependency.patch
   
Append the following lines to cpp/purify/CMakeLists.txt

++if(logging)
++  target_link_libraries(libpurify "-lspdlog -lfmt")
++endif()

So as to include relevant flags. When build this with my changes to
spdlog applied, build passes! \o/

3. For sopt, the build fails with the logs same as what Ole shared
earlier - but looking at them, it seems that spdlog is probably not
responsible for the failure.
    Maybe something else - I'm not sure here. The fmt errors look like
there's a missing flag "-lfmt" and maybe this will do the trick? I
didn't investigate this further.

Andreas, Please take a look at my changes, if you feel it's good to go,
could you please upload?
That'd be great!

[1]: https://salsa.debian.org/med-team/spdlog

Kind Regards,

Nilesh

Bug#962812: nonfree firmware install media exists

[Geert Stappers]

Package: www.debian.org


Hello Website team,

We, Debian, as friendly as we are, have several welcoming entrances.
One entry point, install media that does support hardware
that insists on binary only artifacs, is poorly documented.

Please make it possible that unofficial/non-free/images-including-firmware
can be "clicked" through links.

I did know that page 
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/daily-builds
exists, but had to find an extrenal websearch to get there again.


Regards
Geert Stappers
DD


On Sun, Jun 14, 2020 at 02:17:12PM +0200, Geert Stappers wrote:
> On Sun, Jun 14, 2020 at 01:03:09PM +0200, Dylan Lom wrote:
> > Package: installation-reports
> > 
> > Boot method: USB
> > Image version: 
> > http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-xfce-CD-1.iso
>  
> > Base System Installation Checklist:
> > 
> > Initial boot:   [O]
> > Detect network card:[E]
> > Configure network:  [O]
> > Overall install:[O]
> > 
>  
> > Comments/Problems:
> > 
> > The laptop uses the relatively new Realtek 8822CE card, which the
> > firmware-realtek package doesn't include yet. Running `dmesg | grep
> > network` contained an error about the rtw_pci module not being able
> > to find the driver (I didn't record the precise error).
> > 
> > I was able to get the WiFi working in the installer by downloading the
> > latest linux-firmware tarball[1] from git.kernel.org, and replacing
> > the files in /lib/firmware/rtw88 in a shell.
> > 
>  
> Woh, SKILLED[2]
> 
> Thanks for the install report  and especial from reporting how to add
> what is missing.
> 
> On the "firmware-realtek package doesn't include yet" are the expections
> not quiet right.  https://packages.debian.org/buster/firmware-realtek
> says that the package is in "non-free". Which means it wouldn't get
> included on official Debian install media.
> 
> Workaround is
> https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/
> 
> Please do an install with firmware-testing-amd64-netinst.iso from
> https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/daily-builds/sid_d-i/20200614-3/amd64/iso-cd/
> and report back.
> 
>  
> Regards
> Geert Stappers
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/linux-firmware-20200519.tar.gz
> [2] Yes, that is a compliment
> 

Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#962811: calibre: ebook-viewer crash on start

[Davide Prina]

Package: calibre
Version: 4.99.4+dfsg+really4.17.0-1
Severity: normal

Dear Maintainer,

ebook-viewer crash for every ebook I try to open

$ ebook-viewer a.epub
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway.

Fatal Python error: PyEval_SaveThread: NULL tstate
Python runtime state: initialized

Current thread 0x7f3ee047d740 (most recent call first):
  File "/usr/lib/calibre/calibre/gui2/webengine.py", line 126 in 
_dispatch_messages

  File "/usr/lib/calibre/calibre/gui2/viewer/main.py", line 229 in main
  File "/usr/lib/calibre/calibre/gui_launch.py", line 81 in ebook_viewer
  File "/usr/bin/ebook-viewer", line 20 in 
Annullato

I have found this bug report in arch:
https://bugs.archlinux.org/task/66905

in this bug report the prolem is a python2 library, I have see that the 
corresponding python3 library has been updated today:

python3-pyqt5

but I cant try to install the previews version, elsewhere it will remove 
calibre and so I cannot test if this is the problem.


Let me know if you need more information or what I can do for try to 
understand the problem


Ciao
Davide

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

Kernel: Linux 5.6.14-dp-20200530 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), 
LANGUAGE=it_IT.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages calibre depends on:
ii  calibre-bin  4.99.4+dfsg+really4.17.0-1+b1
ii  dpkg 1.19.7
ii  fonts-liberation 1:1.07.4-11
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  libjpeg-turbo-progs  1:1.5.2-2+b1
ii  libjs-mathjax2.7.8+dfsg-1
ii  libjxr-tools 1.1-6+b1
ii  optipng  0.7.7-1+b1
ii  poppler-utils0.71.0-6
ii  python3  3.8.2-3
ii  python3-apsw 3.30.1-r1-1.1+b1
ii  python3-bs4  4.9.1-1
ii  python3-chardet  3.0.4-7
ii  python3-chm  0.8.6-2+b1
ii  python3-css-parser   1.0.4-2
ii  python3-cssselect1.1.0-2
ii  python3-cssutils 1.0.2-3
ii  python3-dateutil 2.8.1-4
ii  python3-dbus 1.2.16-2
ii  python3-feedparser   5.2.1-2
ii  python3-html2text2020.1.16-1
ii  python3-html5-parser 0.4.9-3+b1
ii  python3-html5lib 1.0.1-3
ii  python3-lxml 4.5.0-1.1
ii  python3-markdown 3.2.2-1
ii  python3-mechanize1:0.4.5-2
ii  python3-msgpack  0.6.2-1+b1
ii  python3-netifaces0.10.9-0.2+b1
ii  python3-pil  7.0.0-4+b1
ii  python3-pkg-resources46.1.3-1
ii  python3-pygments 2.3.1+dfsg-3
ii  python3-pyparsing2.4.7-1
ii  python3-pyqt55.15.0+dfsg-1
ii  python3-pyqt5.qtsvg  5.15.0+dfsg-1
ii  python3-pyqt5.qtwebengine5.14.0-2+b1
ii  python3-regex0.1.20190819-2+b1
ii  python3-routes   2.4.1-2
ii  python3-zeroconf 0.26.1-1
ii  xdg-utils1.1.3-2

Versions of packages calibre recommends:
ii  python3-dnspython  1.16.0-2
ii  udisks22.9.0-1

Versions of packages calibre suggests:
ii  python3-openssl   19.1.0-2
pn  python3-unrardll  

-- debconf-show failed

Bug#962810: bluetooth issues leads to kernel panic

[ganomi]

Package: bluetooth
Version: 5.50-1.2
Severity: normal

Dear Maintainer,

Environment:
Debian Unstable
Bose NC 700 bluetooth headphones
KDE
Thinkpad Extreme Gen 2


Issue:
Headphones get disconnected without reason and I start seeing the following
logs:

Jun 14 22:27:29 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:27:29 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:27:31 superman kernel: Bluetooth: hci0: command 0x041f tx timeout
Jun 14 22:27:33 superman kernel: Bluetooth: hci0: command 0x0406 tx timeout
Jun 14 22:27:59 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:27:59 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:28:03 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:28:03 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:28:06 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:28:06 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:28:09 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:28:09 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53

I can still see the connection in KDE bluetooth system tray setting.
I click on remove - this sometimes removes it and sometimes not.
When I click on connect - it crashes the system and I have to reboot

Jun 14 22:31:08 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:31:08 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:31:11 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:31:11 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:31:11 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:31:11 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:31:11 superman acpid[862]: input device has been disconnected, fd 23
Jun 14 22:31:11 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:31:11 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:31:14 superman bluetoothd[949]: Disconnecting failed: already
disconnected
Jun 14 22:31:18 superman bluetoothd[949]: Close: Connection timed out (110)
Jun 14 22:31:18 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:31:18 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:31:19 superman kernel: debugfs: Directory '256' with parent 'hci0'
already present!
Jun 14 22:31:19 superman kernel: sysfs: cannot create duplicate filename
'/devices/pci:00/:00:14.0/usb1/1-14/1-14:1.0/bluetooth/hci0/hci0:256'
Jun 14 22:31:19 superman kernel: CPU: 5 PID: 115328 Comm: kworker/u25:2
Tainted: P   OE 5.6.0-2-amd64 #1 Debian 5.6.14-2
Jun 14 22:31:19 superman kernel: Hardware name: LENOVO 20QVCTO1WW/20QVCTO1WW,
BIOS N2OET41W (1.28 ) 11/25/2019
Jun 14 22:31:19 superman kernel: Workqueue: hci0 hci_rx_work [bluetooth]
Jun 14 22:31:19 superman kernel: Call Trace:
Jun 14 22:31:19 superman kernel:  dump_stack+0x66/0x90
Jun 14 22:31:19 superman kernel:  sysfs_warn_dup.cold+0x17/0x2d
Jun 14 22:31:19 superman kernel:  sysfs_create_dir_ns+0xb6/0xd0
Jun 14 22:31:19 superman kernel:  kobject_add_internal+0xc2/0x2b0
Jun 14 22:31:19 superman kernel:  kobject_add+0x7e/0xb0
Jun 14 22:31:19 superman kernel:  ? kobject_get_ownership+0x10/0x20
Jun 14 22:31:19 superman kernel:  device_add+0x123/0x7d0
Jun 14 22:31:19 superman kernel:  hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
Jun 14 22:31:19 superman kernel:  hci_event_packet+0x114c/0x2880 [bluetooth]
Jun 14 22:31:19 superman kernel:  ? __switch_to_asm+0x40/0x70
Jun 14 22:31:19 superman kernel:  ? __switch_to_asm+0x34/0x70
Jun 14 22:31:19 superman kernel:  ? __switch_to_asm+0x34/0x70
Jun 14 22:31:19 superman kernel:  ? __switch_to_asm+0x40/0x70
Jun 14 22:31:19 superman kernel:  hci_rx_work+0x17c/0x360 [bluetooth]
Jun 14 22:31:19 superman kernel:  ? __schedule+0x2e0/0x760
Jun 14 22:31:19 superman kernel:  process_one_work+0x1b4/0x380
Jun 14 22:31:19 superman kernel:  worker_thread+0x50/0x3c0
Jun 14 22:31:19 superman kernel:  kthread+0xf9/0x130
Jun 14 22:31:19 superman kernel:  ? process_one_work+0x380/0x380
Jun 14 22:31:19 superman kernel:  ? kthread_park+0x90/0x90
Jun 14 22:31:19 superman kernel:  ret_from_fork+0x35/0x40
Jun 14 22:31:19 superman kernel: kobject_add_internal failed for hci0:256 with
-EEXIST, don't try to register things with the same name in the same directory.
Jun 14 22:31:19 superman kernel: Bluetooth: hci0: failed to register connection
device
Jun 14 22:31:20 superman bluetoothd[949]: Abort: Connection timed out (110)
Jun 14 22:31:20 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:31:20 superman kernel: Bluetooth: hci0: killing stalled connection
4c:87:5d:2b:95:53
Jun 14 22:31:20 superman kernel: Bluetooth: hci0: link tx timeout
Jun 14 22:31:20 superman kernel: Bluetooth: hci0: killing stalled 

Bug#743512: grub-probe can't handle md devices that are not in a good state

[Simon Arlott]

If any device in the array is failed, grub-probe will decide that the
md device does not exist. It will then claim that anything on top of
this (LVM) also does not exist.

Removed devices are ok, but recovering devices are not.

This means that you can't install/update a grub installation while / is
on an md device that has failed or recovering devices:

# grub-probe /
btrfs

# mdadm --manage --fail /dev/md0 /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md0

# grub-probe /
grub-probe: error: disk 
`lvmid/**------**/**------**'
 not found.

# mdadm --manage --remove /dev/md0 /dev/sda1
mdadm: hot removed /dev/sda1 from /dev/md0

# grub-probe /
btrfs

# mdadm --manage --re-add /dev/md0 /dev/sda1
mdadm: re-added /dev/sda1

# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] 
[raid10] 
md0 : active raid1 sda1[0](W) sdb1[1](W) sdd1[4] sdc1[3]
  976629760 blocks super 1.2 [4/3] [_UUU]
  [>]  recovery =  0.2% (2473984/976629760) 
finish=141.5min speed=114688K/sec
  bitmap: 6/8 pages [24KB], 65536KB chunk

unused devices: 

# grub-probe /
grub-probe: error: disk 
`lvmid/**------**/**------**'
 not found.

# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] 
[raid10] 
md0 : active raid1 sda1[0](W) sdb1[1](W) sdd1[4] sdc1[3]
  976629760 blocks super 1.2 [4/4] []
  bitmap: 4/8 pages [16KB], 65536KB chunk

unused devices: 

# grub-probe /
btrfs

-- 
Simon Arlott

Bug#950488: buster-pu: package kronosnet/1.8-2

[wferi]

Dear Stable Release Team,

We'd be immensely grateful for your input on this matter, since your
position more or less determines how we can plan to support the HA users
in Debian.  We'd still prefer a stable update (either to 1.13 as in the
original request or to a more recent stable release), but if that isn't
possible, we'll move forward with backports.  (Which isn't a particularly
appealing option in itself, because the imminent libqb 2 transition will
cause much churn across the stack.)
-- 
Thanks,
Feri

Bug#962809: vmdb2: allow setting partitions bootable

[Florian La Roche]

Package: vmdb2
Version: 0.14.1-1
Severity: normal

Dear Maintainer,

it would be good to add configuration possibiities to toggle a partition
bootable within the config file. I am right now changing the image after
creating it with vmdb2, code within vmdb2 would keep the whole setup in
one place.

Just an idea, current package still works great.

best regards,

Florian La Roche

Bug#962802: Installation Report Lenovo Yoga S730

[Geert Stappers]

Control: tag 962802 +moreinfo

On Sun, Jun 14, 2020 at 01:03:09PM +0200, Dylan Lom wrote:
> Package: installation-reports
> 
> Boot method: USB
> Image version: 
> http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-xfce-CD-1.iso
> Date: 2020-06-14

Hey, that is today

 
> Machine: Lenovo Yoga S730
 
> Base System Installation Checklist:
> 
> Initial boot:   [O]
> Detect network card:[E]
> Configure network:  [O]
> Overall install:[O]

;-)

> 
> Comments/Problems:
> 
> The laptop uses the relatively new Realtek 8822CE card, which the
> firmware-realtek package doesn't include yet. Running `dmesg | grep
> network` contained an error about the rtw_pci module not being able
> to find the driver (I didn't record the precise error).
> 
> I was able to get the WiFi working in the installer by downloading the
> latest linux-firmware tarball[1] from git.kernel.org, and replacing
> the files in /lib/firmware/rtw88 in a shell.
> 
 
Woh, SKILLED[2]

Thanks for the install report  and especial from reporting how to add
what is missing.

On the "firmware-realtek package doesn't include yet" are the expections
not quiet right.  https://packages.debian.org/buster/firmware-realtek
says that the package is in "non-free". Which means it wouldn't get
included on official Debian install media.

Workaround is
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/

Please do an install with firmware-testing-amd64-netinst.iso from
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/daily-builds/sid_d-i/20200614-3/amd64/iso-cd/
and report back.

 
Regards
Geert Stappers

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/linux-firmware-20200519.tar.gz
[2] Yes, that is a compliment
-- 
Silence is hard to parse

Bug#962808: vmdb2: LVM partitions do not work for grub

[Florian La Roche]

Package: vmdb2
Version: 0.14.1-1
Severity: normal

Dear Maintainer,

creating one big LVM partition without encryption and then using grub to
boot up does not seem to have a valid configuration.

With vmdb2 0.14.1 I couldn't find any way to reference the device grub
is getting installed on. It works for me by hardcoding the
loopback-Device into the configuration ("/dev/loop0") with some crude
checks within the Makefile for nobody else to use the loopback device.

The used yaml config file can be seen here:
https://github.com/laroche/arm-devel-infrastructure/blob/master/vmdb2-debian/debian-testing-amd64.yaml

How can this be configured correctly in the *.yaml file? Any working
example for this?
(0.16 from unstable also does not work for me.)

best regards,

Florian La Roche

Bug#962807: binfmt-support from Debian stable reports errors/warnings within lxc guests

[Florian La Roche]

Package: binfmt-support
Version: 2.2.1-1
Severity: normal

Dear Maintainer,


Installing Debian stable within lxc gives warnings/errors for
binfmt-support. Expected and nothing unusual. Maybe you can detect lxc
and just not enable any access to /proc/sys/fs/binfmt_misc?
Thos only occurs with Debian stable (10), Debian testing seems to be ok
already.

If no easy solution can be found or this does not warrant a backport
from the current package into the stable release, feel free to just close this
bug-report.

best regards,

Florian La Roche



logmessages during installation of the deb package:

binfmt-support (2.2.0-2) wird eingerichtet ...
Created symlink 
/etc/systemd/system/multi-user.target.wants/binfmt-support.service → 
/lib/systemd/system/binfmt-support.service.
Job for binfmt-support.service failed because the control process exited with 
error code.
See "systemctl status binfmt-support.service" and "journalctl -xe" for details.
invoke-rc.d: initscript binfmt-support, action "start" failed.
● binfmt-support.service - Enable support for additional executable binary 
formats
   Loaded: loaded (/lib/systemd/system/binfmt-support.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sat 2020-06-13 18:55:34 UTC; 4ms ago
 Docs: man:update-binfmts(8)
  Process: 22871 ExecStart=/usr/sbin/update-binfmts --enable (code=exited, 
status=2)
 Main PID: 22871 (code=exited, status=2)

Jun 13 18:55:34 debian01 systemd[1]: Starting Enable support for additional 
executable binary formats...
Jun 13 18:55:34 debian01 update-binfmts[22871]: update-binfmts: warning: unable 
to open /proc/sys/fs/binfmt_misc/status for writing: Permission denied
Jun 13 18:55:34 debian01 update-binfmts[22871]: update-binfmts: warning: unable 
to open /proc/sys/fs/binfmt_misc/status for writing: Permission denied
Jun 13 18:55:34 debian01 update-binfmts[22871]: update-binfmts: warning: unable 
to open /proc/sys/fs/binfmt_misc/register for writing: Permission denied
Jun 13 18:55:34 debian01 update-binfmts[22871]: update-binfmts: warning: unable 
to open /proc/sys/fs/binfmt_misc/status for writing: Permission denied
Jun 13 18:55:34 debian01 update-binfmts[22871]: update-binfmts: warning: unable 
to open /proc/sys/fs/binfmt_misc/register for writing: Permission denied
Jun 13 18:55:34 debian01 update-binfmts[22871]: update-binfmts: exiting due to 
previous errors
Jun 13 18:55:34 debian01 systemd[1]: binfmt-support.service: Main process 
exited, code=exited, status=2/INVALIDARGUMENT
Jun 13 18:55:34 debian01 systemd[1]: binfmt-support.service: Failed with result 
'exit-code'.
Jun 13 18:55:34 debian01 systemd[1]: Failed to start Enable support for 
additional executable binary formats.

Bug#962805: python-geotiepoints: autopkgtest regression: No module named 'h5py

[Paul Gevers]

Source: python-geotiepoints
Version: 1.2.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of python-geotiepoints the autopkgtest of
python-geotiepoints fails in testing when that autopkgtest is run with
the binary packages of python-geotiepoints from unstable. It passes when
run with only packages from testing. In tabular form:

   passfail
python-geotiepointsfrom testing1.2.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? It seems like you're
missing a (test) dependency.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=python-geotiepoints

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-geotiepoints/5889557/log.gz

autopkgtest [19:08:51]: test python3: [---
=== python3.8 ===
tests (unittest.loader._FailedTest) ... ERROR

==
ERROR: tests (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: tests
Traceback (most recent call last):
  File "/usr/lib/python3.8/unittest/loader.py", line 154, in
loadTestsFromName
module = __import__(module_name)
  File "/usr/lib/python3/dist-packages/geotiepoints/tests/__init__.py",
line 27, in 
from geotiepoints.tests import (test_geointerpolator,
  File
"/usr/lib/python3/dist-packages/geotiepoints/tests/test_modis.py", line
7, in 
import h5py
ModuleNotFoundError: No module named 'h5py'


--
Ran 1 test in 0.000s

FAILED (errors=1)
autopkgtest [19:08:51]: test python3: ---]



signature.asc
Description: OpenPGP digital signature

Bug#962804: wfmath: autopkgtest failure: no acceptable C compiler found in $PATH

[Paul Gevers]

Source: wfmath
Version: 1.0.2+dfsg1-8
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package wfmath, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report. Are you
missing a test dependency?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=wfmath

https://ci.debian.net/data/autopkgtest/testing/amd64/w/wfmath/5792572/log.gz

autopkgtest [10:33:44]: test command1: ./configure && make check
autopkgtest [10:33:44]: test command1: [---
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in `/tmp/autopkgtest-lxc.nwce0fke/downtmp/build.tAZ/src':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details
autopkgtest [10:33:46]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#962803: rust-csv: autopkgtest failure: could not compile `csv`

[Paul Gevers]

Source: rust-csv
Version: 1.1.3-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package rust-csv, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rust-csv

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-csv/5751831/log.gz

 Running `CARGO_MANIFEST_DIR=/usr/share/cargo/registry/csv-1.1.3
CARGO_PKG_VERSION=1.1.3
CARGO_PKG_REPOSITORY='https://github.com/BurntSushi/rust-csv'
CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_PRE=
CARGO_PKG_VERSION_PATCH=3 CARGO_PKG_NAME=csv
CARGO_PKG_HOMEPAGE='https://github.com/BurntSushi/rust-csv'
CARGO_PKG_DESCRIPTION='Fast CSV parsing with support for serde.'
CARGO_PKG_AUTHORS='Andrew Gallant '
CARGO_PKG_VERSION_MINOR=1
LD_LIBRARY_PATH='/tmp/tmp.5fF0MMXKFR/target/debug/deps:/usr/lib'
CARGO=/usr/bin/cargo rustc --crate-name cookbook_read_colon
--edition=2018 examples/cookbook-read-colon.rs --error-format=json
--json=diagnostic-rendered-ansi --emit=dep-info,link -C debuginfo=2
--test -C metadata=98c6dd6c57a87f8b -C extra-filename=-98c6dd6c57a87f8b
--out-dir
/tmp/tmp.5fF0MMXKFR/target/x86_64-unknown-linux-gnu/debug/examples
--target x86_64-unknown-linux-gnu -C
incremental=/tmp/tmp.5fF0MMXKFR/target/x86_64-unknown-linux-gnu/debug/incremental
-L
dependency=/tmp/tmp.5fF0MMXKFR/target/x86_64-unknown-linux-gnu/debug/deps
-L dependency=/tmp/tmp.5fF0MMXKFR/target/debug/deps --extern
bstr=/tmp/tmp.5fF0MMXKFR/target/x86_64-unknown-linux-gnu/debug/deps/libbstr-2c0cf4055cf1f260.rlib
--extern
csv=/tmp/tmp.5fF0MMXKFR/target/x86_64-unknown-linux-gnu/debug/deps/libcsv-923bd41be0db7cc6.rlib
--extern
csv_core=/tmp/tmp.5fF0MMXKFR/target/x86_64-unknown-linux-gnu/debug/deps/libcsv_core-8f96475e9851770d.rlib
--extern
itoa=/tmp/tmp.5fF0MMXKFR/target/x86_64-unknown-linux-gnu/debug/deps/libitoa-18ec922b937f216f.rlib
--extern
ryu=/tmp/tmp.5fF0MMXKFR/target/x86_64-unknown-linux-gnu/debug/deps/libryu-562a5218e32671cf.rlib
--extern
serde=/tmp/tmp.5fF0MMXKFR/target/x86_64-unknown-linux-gnu/debug/deps/libserde-df896d28cb66ae5b.rlib
-C debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C
link-arg=-Wl,-z,relro --remap-path-prefix
/usr/share/cargo/registry/csv-1.1.3=/usr/share/cargo/registry/csv-1.1.3`
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> benches/bench.rs:1:1
  |
1 | #![feature(test)]
  | ^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: could not compile `csv`.



signature.asc
Description: OpenPGP digital signature

Bug#412914: reportbug: please add support for SSL protected SMTP communication

[Nis Martensen]

Package: reportbug
Version: 7.5.3~deb10u1
Followup-For: Bug #412914

I'd prefer if we could avoid introducing a new configuration variable
for this. How about implicitly always using SSL if the user specifies
port 465?

(NB: This message serves as a test for a patch I am preparing.)

Bug#962787: gocr: dangling gocr-dev

[Gürkan Myczko]

there was bugs.debian.org/582575
but i agree i will look i to the lib packaginh
> On Jun 14, 2020, at 07:33, Yangfl  wrote:
> 

Bug#962802: Installation Report

[Dylan Lom]

Package: installation-reports

Boot method: USB
Image version: 
http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-xfce-CD-1.iso
Date: 2020-06-14

Machine: Lenovo Yoga S730
Processor: Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz
Memory: 16GB
Partitions: 
Filesystem Type 1K-blocks Used Available Use% Mounted on
udev   devtmpfs   80312240   8031224   0% /dev
tmpfs  tmpfs  1617052 1476   1615576   1% /run
/dev/nvme0n1p5 ext4  47797996  4501564  40838680  10% /
tmpfs  tmpfs  8085244   102396   7982848   2% /dev/shm
tmpfs  tmpfs 51204  5116   1% /run/lock
tmpfs  tmpfs  80852440   8085244   0% /sys/fs/cgroup
/dev/nvme0n1p1 vfat26214442100220044  17% /boot/efi
/dev/nvme0n1p7 ext4 342852932 15011212 310356052   5% /home
tmpfs  tmpfs  1617048   16   1617032   1% /run/user/1000

Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:9b61] (rev 0c)
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 
[8086:9b41] (rev 02)
00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c)
00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 / 
E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911]
00:12.0 Signal processing controller [1180]: Intel Corporation Comet Lake 
Thermal Subsytem [8086:02f9]
00:14.0 USB controller [0c03]: Intel Corporation Device [8086:02ed]
00:14.2 RAM memory [0500]: Intel Corporation Device [8086:02ef]
00:15.0 Serial bus controller [0c80]: Intel Corporation Serial IO I2C Host 
Controller [8086:02e8]
00:16.0 Communication controller [0780]: Intel Corporation Comet Lake 
Management Engine Interface [8086:02e0]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:02b8] (rev f0)
00:1c.4 PCI bridge [0604]: Intel Corporation Device [8086:02bc] (rev f0)
00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:02b0] (rev f0)
00:1d.1 PCI bridge [0604]: Intel Corporation Device [8086:02b1] (rev f0)
00:1d.4 PCI bridge [0604]: Intel Corporation Device [8086:02b4] (rev f0)
00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:0284]
00:1f.3 Audio device [0403]: Intel Corporation Device [8086:02c8]
00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:02a3]
00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake SPI (flash) 
Controller [8086:02a4]
6c:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8822CE 
802.11ac PCIe Wireless Network Adapter [10ec:c822]
6d:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe 
SSD Controller SM981/PM981/PM983 [144d:a808]

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [O]
Detect CD:  [ ]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

The laptop uses the relatively new Realtek 8822CE card, which the 
firmware-realtek package doesn't include yet. Running `dmesg | grep network` 
contained an error about the rtw_pci module not being able to find the driver 
(I didn't record the precise error).

I was able to get the WiFi working in the installer by downloading the latest 
linux-firmware tarball[1] from git.kernel.org, and replacing the files in 
/lib/firmware/rtw88 in a shell.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/linux-firmware-20200519.tar.gz

Bug#949482: exim4-config: Please drop the pointless warning "Warning: No server certificate defined; will use a selfsigned one."

[Vincent Lefevre]

On 2020-06-14 12:16:06 +0200, Francesco Poli wrote:
> On Tue, 28 Apr 2020 22:23:31 +0200 Vincent Lefevre wrote:
> 
> > On 2020-04-28 19:22:34 +0200, Francesco Poli wrote:
> > > On Tue, 21 Jan 2020 13:55:20 +0100 Vincent Lefevre 
> > > wrote: [...]
> > > > Each time I upgrade exim4, I get:
> > > > 
> > > > Setting up exim4-config (4.93-9) ...
> > > > 2020-01-21 13:27:26 Warning: No server certificate defined; will use a 
> > > > selfsigned one.
> > > >  Suggested action: either install a certificate or change 
> > > > tls_advertise_hosts option
> > > 
> > > It is also written to /var/log/exim4/mainlog at *each* queue run (thus
> > > twice per hour).
> > 
> > Twice per hour by default. I run the queue every 5 minutes in order
> > to get greylisted mail sent faster. Thus I get this message every
> > 5 minutes.
> [...]
> 
> It seems to me that this warning is no longer written by
> exim4/4.94-2 ...
> 
> Is this solved in the new upstream version 4.94 ?
> Should this bug report be closed as fixed in exim4/4.94-2 ?

I haven't upgraded to 4.94-2 yet, but there has been an improvement
in 4.94-1: the message no longer appears each time the queue is run:

2020-06-05 12:23:19 Warning: No server certificate defined; will use a 
selfsigned one.
 Suggested action: either install a certificate or change tls_advertise_hosts 
option
2020-06-05 12:23:19 Start queue run: pid=1961359
2020-06-05 12:23:19 End queue run: pid=1961359
2020-06-05 12:28:19 Warning: No server certificate defined; will use a 
selfsigned one.
 Suggested action: either install a certificate or change tls_advertise_hosts 
option
2020-06-05 12:28:19 Start queue run: pid=1963247
2020-06-05 12:28:19 End queue run: pid=1963247
2020-06-05 13:14:20 Warning: No server certificate defined; will use a 
selfsigned one.
 Suggested action: either install a certificate or change tls_advertise_hosts 
option
2020-06-05 13:14:20 exim 4.94 daemon started: pid=1983516, -q5m, listening for 
SMTP on [127.0.0.1]:25 [::1]:25
2020-06-05 13:14:20 Start queue run: pid=1983517
2020-06-05 13:14:20 End queue run: pid=1983517
2020-06-05 13:19:20 Start queue run: pid=1986520
2020-06-05 13:19:20 End queue run: pid=1986520
2020-06-05 13:24:20 Start queue run: pid=1987227
2020-06-05 13:24:20 End queue run: pid=1987227

However, it still appears when the service is restarted:

2020-06-14 12:09:22 Start queue run: pid=3686663
2020-06-14 12:09:22 End queue run: pid=3686663
2020-06-14 12:14:22 Start queue run: pid=3686820
2020-06-14 12:14:22 End queue run: pid=3686820
2020-06-14 12:19:22 Start queue run: pid=3687035
2020-06-14 12:19:22 End queue run: pid=3687035
2020-06-14 12:23:25 Warning: No server certificate defined; will use a 
selfsigned one.
 Suggested action: either install a certificate or change tls_advertise_hosts 
option
2020-06-14 12:23:25 exim 4.94 daemon started: pid=3687887, -q5m, listening for 
SMTP on [127.0.0.1]:25 [::1]:25
2020-06-14 12:23:25 Start queue run: pid=3687888
2020-06-14 12:23:25 End queue run: pid=3687888

So, either there's nothing wrong and there should be no warning, or
something is wrong and the dpkg configuration system should handle
the issue. For instance, if tls_advertise_hosts needs to be changed,
this should be part of update-exim4.conf.

But instead of changing tls_advertise_hosts, since a certificate
may be needed, the configuration system should propose to use one,
possibly a self-signed one as this may be sufficient for a limited
use (e.g. a single user with several machines or a group of users,
where one can rely on the fingerprint rather than the signature).

For instance, postfix, which uses libssl, depends on ssl-cert,
which creates a self-signed certificate at install time, and
postfix can use it. The apache2 web server can also use it, though
apache2 only recommends ssl-cert.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#962801: simple-image-reducer: ImportError: No module named Image

[Janusz S. Bień]

Package: simple-image-reducer
Version: 1.0.2-7
Severity: important

The problem is already solved upstream:

https://github.com/henrythasler/simple-image-reducer/issues/5

Regards

Janusz

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

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

Versions of packages simple-image-reducer depends on:
ii  python   2.7.16-1
ii  python-exif  2.1.2-1
ii  python-gtk2  2.24.0-5.1+b1
ii  python-pil   5.4.1-2+deb10u1

simple-image-reducer recommends no packages.

simple-image-reducer suggests no packages.

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#962800: nut: NUT and systemd interacting poorly

[Christi Scarborough]

Package: nut-client
Version: 2.7.4-8
Severity: normal
File: nut

Dear Maintainer,

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

   * What led up to the situation?

Installing of nut-client on the host system - I believe the problem is also 
present in a full NUT installation though.

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

apt install nut-client
Basic configuration of NUT to act as a client to a UPS on a different machine 
on the network.

   * What was the outcome of this action?

Errors present in syslog as follows:

Jun 14 11:29:51 yaga systemd[1]: /lib/systemd/system/nut-monitor.service:6: 
PIDFile= references path below legacy directory /var/run/, updating 
/var/run/nut/upsmon.pid → /run/nut/upsmon.pid; please update the unit file 
accordingly.
Jun 14 11:32:46 yaga systemd[1]: Starting Network UPS Tools - power device 
monitor and shutdown controller...
Jun 14 11:32:46 yaga upsmon[34188]: fopen /var/run/nut/upsmon.pid: No such file 
or directory
Jun 14 11:32:46 yaga upsmon[34188]: UPS:  (slave) (power value 1)
Jun 14 11:32:46 yaga upsmon[34188]: Using power down flag file /etc/killpower
Jun 14 11:32:46 yaga systemd[1]: nut-monitor.service: Can't open PID file 
/run/nut/upsmon.pid (yet?) after start: No such file or directory
Jun 14 11:32:46 yaga upsmon[34195]: Startup successful
Jun 14 11:32:46 yaga systemd[1]: Started Network UPS Tools - power device 
monitor and shutdown controller.
Jun 14 11:32:46 yaga upsmon[34196]: Init SSL without certificate database

Although the app is working, both errors (the first and 6th lines above are of 
concern, as I am uncertain whether they will cause unpredictable behaviour.

Thank you,

Christi

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.4.41-1-pve (SMP w/32 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 nut-client depends on:
ii  adduser3.118
ii  libc6  2.28-10
ii  libupsclient4  2.7.4-8
ii  lsb-base   10.2019051400

Versions of packages nut-client recommends:
ii  bash-completion  1:2.8-6

Versions of packages nut-client suggests:
pn  nut-monitor  

-- Configuration Files:
/etc/nut/nut.conf changed [not included]
/etc/nut/upsmon.conf changed [not included]
/etc/nut/upssched.conf changed [not included]

-- no debconf information

Bug#949482: exim4-config: Please drop the pointless warning "Warning: No server certificate defined; will use a selfsigned one."

[Francesco Poli]

On Sun, 14 Jun 2020 12:16:06 +0200 Francesco Poli wrote:

[...]
> It seems to me that this warning is no longer written by
> exim4/4.94-2 ...

Well, not really.

It is still written, whenever exim4 is restarted as in:

  # service exim4 restart

But, at least, it seems to be no longer written
to /var/log/exim4/mainlog at *each* queue run, which looks like an
improvement!

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpSOyPYzNqjE.pgp
Description: PGP signature

Bug#949482: exim4-config: Please drop the pointless warning "Warning: No server certificate defined; will use a selfsigned one."

[Francesco Poli]

On Tue, 28 Apr 2020 22:23:31 +0200 Vincent Lefevre wrote:

> On 2020-04-28 19:22:34 +0200, Francesco Poli wrote:
> > On Tue, 21 Jan 2020 13:55:20 +0100 Vincent Lefevre 
> > wrote: [...]
> > > Each time I upgrade exim4, I get:
> > > 
> > > Setting up exim4-config (4.93-9) ...
> > > 2020-01-21 13:27:26 Warning: No server certificate defined; will use a 
> > > selfsigned one.
> > >  Suggested action: either install a certificate or change 
> > > tls_advertise_hosts option
> > 
> > It is also written to /var/log/exim4/mainlog at *each* queue run (thus
> > twice per hour).
> 
> Twice per hour by default. I run the queue every 5 minutes in order
> to get greylisted mail sent faster. Thus I get this message every
> 5 minutes.
[...]

It seems to me that this warning is no longer written by
exim4/4.94-2 ...

Is this solved in the new upstream version 4.94 ?
Should this bug report be closed as fixed in exim4/4.94-2 ?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpm6y3oyxz3R.pgp
Description: PGP signature