Bug#951189: ITP: opensurge -- Fun 2D retro platformer inspired by Sonic games

[Carlos Donizete Froes]

Package: wnpp
Severity: wishlist
Owner: Carlos Donizete Froes 

* Package name: opensurge
  Version : 0.5.1.2-1
  Upstream Author : Alexandre Martins 
* URL : https://opensurge2d.org
* License : GPL-3+
  Programming Lang: C
  Description : Fun 2D retro platformer inspired by Sonic games

 Open Surge is a fun 2D retro platformer inspired by Sonic games
 and a game creation system that lets you unleash your creativity!
 Play, create games & share!

 I plan to keep the OpenSurge package on the Debian Games team.

 Thanks!

--
 Carlos Donizete Froes [a.k.a coringao] 

Bug#944227: transition: prompt-toolkit

[John Scott]

It appears that bugs haven't been filed to get reverse dependencies depending 
on version 1 out of testing.

Britney [1] says
> trying: prompt-toolkit
> skipped: prompt-toolkit (39, 2, 91)
> 
> got: 26+0: a-1:a-0:a-0:a-0:i-17:m-0:m-7:p-0:s-1
> * mipsel: caffe-cpu, python3-caffe-cpu, python3-guiqwt,
> python3-line-profiler, python3-pyraf, python3-sfepy, python3-yt
and so since these binaries are still in Bullseye, prompt-toolkit isn't going 
to be migrating until they're removed.

I'm only an interested user and may be misunderstanding. Could you file these 
bugs or help me understand what I'm overlooking?
[1] https://release.debian.org/britney/update_output.txt

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

Bug#951093: libmypaint: please package v2.0.0-beta.0

[Sandro Tosi]

Control: retitle -1 libmypaint: please package 1.5.0

> Speaking as the current de facto mypaint/libmypaint maintainer, I
> would advice against this, because MyPaint 2.0 will depend on
> libmypaint 1.5.0 and not libmypaint-2.0. This is a fairly recent
> development, though it's been discussed for a few weeks:
> https://github.com/mypaint/libmypaint/releases/tag/v1.5.0-beta.0
>
> v1.5.0 will be released shortly, and MyPaint 2.0 shortly after (today
> or tomorrow).

oh that's even better (i was basing my request on mypaint 2.0.0-beta.0
which requires `libmypaint-2.0`).

I see 1.5.0 was released at
https://github.com/mypaint/libmypaint/releases so i retitled this bug
accordingly.

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

Bug#951188: dpkg ldconfig, start-stop-daemon not found in PATH. solved edit /root/.bashrc add end of file PATH

[dpkg error with warning ldconfig and start-stop-daemon]

Package: dpkg
Version: 1.19.7
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   install sofwares via package, from web, with dpkg -i *.deb

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  pkg: warning: 'ldconfig' not found in PATH or not executable.
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable.
dpkg: error: 2 expected programs not found in PATH or not executable.
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin.
E: Sub-process /usr/bin/dpkg returned an error code (2). 
I Solved edit file /root/.bashrc  , and end of file add line :"export 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

   * What was the outcome of this action?
 install the package softwares I download from internet.
   * What outcome did you expect instead?
i solved using this wai..  maybe the imagens net-install debian 10.3, have 
this problam. 

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


-- Package-specific info:
System tainted due to merged-usr-via-symlinks.

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  liblzma5 5.2.4-1
ii  libselinux1  2.8-1+b1
ii  tar  1.30+dfsg-6
ii  zlib1g   1:1.2.11.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.8.2
pn  debsig-verify  

-- no debconf information

Bug#950052: please warn for files installed into /

[Felix Lechner]

Hi Matthias,

On Tue, Jan 28, 2020 at 9:33 AM Matthias Klose  wrote:
>
> seen at #950027, a packaging issue.  I think it would be trivial to warn about
> installations into /, however I didn't check about any false 
> positives.

I read the other bug. What should Lintian do, please?

Kind regards
Felix Lechner

Bug#951187: proj: 'make distclean' deletes README which is not regenerated

[Andreas Beckmann]

Source: proj
Version: 6.3.1~rc1-1~exp1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

proj/experimental FTBFS twice in a row. 'debian/rules clean' after the
first build removes 'README' via 'make distclean', but that file
is not regenerated during the second build causing the install target to
fail. I did not check whether the package in sid has the same problem.

[...]
dh_auto_clean
make -j3 distclean
[...]
make[3]: Entering directory '/build/proj-6.3.1~rc1'
rm -rf .libs _libs
rm -f README
rm -f *.lo
test -z "proj.pc" || rm -f proj.pc
rm -f libtool config.lt
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
test . = "." || test -z "" || rm -f 
rm -f cscope.out cscope.in.out cscope.po.out cscope.files
make[3]: Leaving directory '/build/proj-6.3.1~rc1'
[...]
   debian/rules override_dh_installdocs
make[1]: Entering directory '/build/proj-6.3.1~rc1'
dh_installdocs -A AUTHORS NEWS README
cp: cannot stat 'README': No such file or directory
dh_installdocs: error: cp --reflink=auto -a README 
debian/proj-data/usr/share/doc/proj-data returned exit code 1
make[1]: *** [debian/rules:57: override_dh_installdocs] Error 25
make[1]: Leaving directory '/build/proj-6.3.1~rc1'
make: *** [debian/rules:28: binary] Error 2
[...]


Cheers,

Andreas


proj_6.3.1~rc1-1~exp1_twice.log.gz
Description: application/gzip

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Jonas Smedegaard]

Hi Sandro,

Quoting Sandro Mani (2020-02-12 00:24:50)
> The perl Array-IntSpan module is licensed Artistic v1 [1], but this 
> license is considered a non-free license [2] and not allowed in Fedora 
> [3].
> 
> As such, Fedora won't be able to ship newer versions of licensecheck 
> as long as there is a dependency on this module. Could it's use please 
> be reconsidered? Thanks.

Thank you very much for bringing this issue to my attention.

Yes, I will certainly try avoid that oddly-licensed library.

 - Jonas

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

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


signature.asc
Description: signature

Bug#949941: byobu build depends on the removed pep8 transitional package

[Boyuan Yang]

Control: reopen -1
Control: notfixed -1 5.131-1
Control: found -1 5.131-1
X-Debbugs-CC: kirkl...@ubuntu.com anar...@koumbit.org

Unfortunately the latest upload still FTBFS currently. It looks like
the building process still invokes the "pep8" executable (in
debian/rules), which is not provided in the system.

-- 
Thanks,
Boyuan Yang

On Sun, 9 Feb 2020 10:23:46 -0600 Dustin Kirkland 
wrote:
> Fixing this now.  Thanks.
> 
> @DustinKirkland
> Ubuntu Core Dev
> 
> 
> On Mon, Jan 27, 2020 at 5:27 AM Adrian Bunk  wrote:
> 
> > Source: byobu
> > Version: 5.130-1.1
> > Severity: serious
> > Tags: ftbfs
> >
> > pep8 is no longer built by src:pep8.
> >


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

Bug#951186: Please reconsider usage of perl-Array-IntSpan in licensecheck

[Sandro Mani]

Package: licensecheck
Version: 3.0.41

The perl Array-IntSpan module is licensed Artistic v1 [1], but this 
license is considered a non-free license [2] and not allowed in Fedora [3].


As such, Fedora won't be able to ship newer versions of licensecheck as 
long as there is a dependency on this module. Could it's use please be 
reconsidered? Thanks.


[1] https://metacpan.org/release/Array-IntSpan
[2] https://www.gnu.org/licenses/license-list.html#ArtisticLicense
[3] 
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Bad_Licenses 

Bug#951185: RM: nvidia-graphics-drivers-tesla -- ROM; renamed to nvidia-graphics-drivers-tesla-418

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

in preparation for adding a tesla-440 driver variant, I've renamed
nvidia-graphics-drivers-tesla to nvidia-graphics-drivers-tesla-418

Andreas

Bug#951184: RFP: libfido2 -- communicate with a FIDO device over USB

[Colin Watson]

Package: wnpp
Severity: wishlist

* Package name: libfido2
  Version : 1.3.0
  Upstream Author : Yubico AB
* URL : https://github.com/Yubico/libfido2
* License : BSD-2-clause
  Programming Lang: C
  Description : communicate with a FIDO device over USB

libfido2 provides library functionality and command-line tools to
communicate with a FIDO device over USB, and to verify attestation and
assertion signatures.

libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols.


This is going to be an optional dependency of OpenSSH 8.2 (optional at
build time, I think, though it seems sufficiently useful that I'd be
inclined to link against it by default if it doesn't impose an
unreasonable run-time footprint), needed for U2F/FIDO support which is
the principal new feature in that release.  As such I'd like to be able
to enable it.

I do have a Yubikey 5 NFC which would be suitable for testing this with,
and in principle I'd probably be able to maintain this package
reasonably well, but I also have a lot to do and would rather give
somebody else the chance to take it on first.  I expect I'll start work
on it in a week or two if nobody else picks this up.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#950038: Looks like a bug in httplib2 rather than on wsgi-intercept

[Andreas Beckmann]

Control: affects -1 + src:python-wsgi-intercept

On 11/02/2020 12.45, Håvard Flaget Aasen wrote:
> Since you marked it as found after my reply, does it mean that you want
> it to be fixed in this (python-httplib2) package?
> 
> How can it be found in a python2 package when python-wsgi-intercept only
> builds for python3?

In this context (found/fixed versions of bugs) python-httplib2 refers
the source package. The bug itself is assigned to the python3 binary
package built from it.

I only added the missing version (I used the one that was installed
according the failure log) to this bug, otherwise it shows up as a RC
bug in stable.

I have a little trouble getting what you mean here:

On Mon, 10 Feb 2020 17:52:33 +0100 =?UTF-8?Q?H=c3=a5vard_Flaget_Aasen?=
 wrote:
> Though they write that the change was indeed in the httplib2 package.

* the change that introduced the bug
* the change that fixed the bug (is there an embedded copy of httplib2
somewhere?)
* both ?


Andreas

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

Control: severity -1 normal
Control: reassign -1 enlightenment 0.23.1-4
Control: retitle -1 eo logs in .xsession-errors eat all disk space

On Tue, Feb 11, 2020 at 01:31:28PM +0300, sergio wrote:
> Package: libecore1
> Version: 1.23.3-6
> Severity: critical
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
> it's critical as it eats all disk space causing other programs fail and
> lose data.

I haven't seen this, so lowering the priority to normal.  Let's try to
figure out the trigger.

> I don't know how to reproduce it. It happens after several days of
> running enlightenment. (My desktop is always on.)
> 
> At the beginning all works fine, and ~/.xsession-errors takes less than
> 100Kb. But some time later I find it taking all free space (dozen
> gigabytes in my case).

How do you start enlightenment?  Does your desktop suspend after
inactivity?  Do you leave any other EFL apps running?

> It repeats the following two lines endlessly:
> 
> ERR<32091>:eo ../src/lib/eo/eo.c:2192 efl_data_scope_get() Eo ID 
> 0x402d3617 is not a valid object. Current thread: main. This ID has 
> probably been deleted or this was never a valid object ID. (domain=0, 
> current_domain=0, local_domain=0, available_domains=[0 1], 
> generation=217, id=b4d, ref=1)
> ERR<32091>:eo ../src/lib/eo/eo.c:1814 efl_isa() Eo ID 0x402d3617 is not a 
> valid object. Current thread: main. This ID has probably been deleted or this 
> was never a valid object ID. (domain=0, current_domain=0, local_domain=0, 
> available_domains=[0 1], generation=217, id=b4d, ref=1)

Does this end if you restart enlightenemnt? (Main -> Enlightenment ->
Restart)

> With the previous version of E all worked fine, began to happen with the
> update to 0.23.1-4

This bug was opened against libecore1, not enlightenment.  I've
reassigned.

Ross

Bug#951182: RM: mate-icon-theme-faenza -- ROM; unmaintained upstream

[Mike Gabriel]

Package: ftp.debian.org
Severity: normal


Please remove mate-icon-theme-faenza from testing/unstable. It is
unmaintained upstream.

Bug#951183: O: htpdate -- HTTP based time synchronization tool

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the htpdate package.

The package description is:
 The  HTTP Time Protocol (HTP) is used to synchronize a computer's time with
 web servers as reference time source. This program can be used instead
 ntpdate or similar, in networks that has a firewall blocking the NTP port.
 .
 Htpdate will synchronize the computer time to Greenwich Mean Time (GMT),
 using the timestamps from HTTP headers found in web servers response (the
 HEAD method will be used to get the information).
 .
 Htpdate works through proxy servers. Accuracy of htpdate will be usually
 within 0.5 seconds (better with multiple servers).

Bug#921445: mailman3 assumes Postfix is not chrooted

[Johannes Schauer]

Hi,

On Tue, 05 Feb 2019 11:04:15 -0500 Antoine Beaupre  wrote:
> Package: mailman3
> Version: 3.2.0-4~bpo9+1
> Severity: important
> 
> During the jessie to stretch upgrade of my mail server:
> 
> -postfix 2.11.3-1+deb8u2 amd64
> +postfix 3.1.4-7 amd64
> 
> The following happened to my `master.cf` file:
> 
> -pickupfifo  n   -   -   60  1   pickup
> -cleanup   unix  n   -   -   -   0   cleanup
> +pickup fifo  n   -   y   60  1   pickup
> +cleanupunix  n   -   y   -   0   cleanup
> 
> ie. most Postfix processes now run in a chroot. This includes the
> endpoints Mailman talks with. This makes the location of the LMTP and
> transport files created by mailman 3 unreadable by postfix, even
> though the README.Debian suggests the following configuration:
> 
> transport_maps = hash:/var/lib/mailman3/data/postfix_lmtp
> local_recipient_maps = proxy:unix:passwd.byname $alias_maps 
> hash:/var/lib/mailman3/data/postfix_lmtp
> relay_domains = ${{$compatibility_level} < {2} ? {$mydestination} : {}} 
> hash:/var/lib/mailman3/data/postfix_domains
> 
> That configuration doesn't work, as Postfix can't read those
> directories.

I can confirm this observation.

> I used this configuration instead:
> 
> transport_maps = hash:/etc/postfix/transport
>  hash:mailman3/postfix_lmtp
> local_recipient_maps = proxy:unix:passwd.byname $alias_maps 
> hash:mailman3/postfix_lmtp
> relay_domains = ${{$compatibility_level} < {2} ? {$mydestination} : {}} 
> hash:mailman3/postfix_domains

The file /etc/postfix/transport does not exist by default, so it should not be
included in a future README.Debian.

> And then created the directories in the new location:
> 
> touch /var/spool/postfix/mailman3/postfix_domains 
> /var/spool/postfix/mailman3/postfix_lmtp
> chown list:list /var/spool/postfix/mailman3/postfix_*
> postmap /var/spool/postfix/mailman3/postfix_domains 
> /var/spool/postfix/mailman3/postfix_lmtp
> ln -s /var/spool/postfix/mailman3/postfix_domains 
> /var/spool/postfix/mailman3/postfix_lmtp /var/lib/mailman3/data/

Are you sure those were the steps you followed?

With how you are doing it, /var/spool/postfix/mailman3 will not be owned by
list:list and thus mailman3 cannot create additional files in it.

Also, instead of creating a symbolic link to the individual files, maybe
instead do:

$ ln -s /var/spool/postfix/mailman3 /var/lib/mailman3/data/

And in the beginning an mkdir command is missing.

> Finally, the `data_dir` location needs to be changed in the
> `mailman.cfg` as well:
> 
> data_dir: /var/spool/postfix/mailman3/
> 
> I'm surprised the suggested configuration works for people - I suspect
> it might only work on older machines that upgraded Postfix from
> stretch without accepting the upstream changes.

It certainly didn't work for me.

Please fix README.Debian.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#951152: new archmage version breaks keepass2 documentation build

[Julian Taylor]

On 11.02.20 22:13, Mikhail Gusarov wrote:
> Hi Julian,
> 
> On 11 Feb 2020, at 21:25, Julian Taylor wrote:
> 
>> For keepass I only need to be able to build html files from the chm
>> source directory, the package has no compiled chm file one can use the
>> current cli functions on.
> 
> Please try
> https://github.com/dottedmag/archmage/commit/c8f186dff0c8da56590e900cc2a32b39e19bf08b
> 
> 
> - if it works, then I'll cut a new release and a package.
> 

it is working great, thanks



signature.asc
Description: OpenPGP digital signature

Bug#951180: hledger: New upstream version 1.16.2

[Michael Berg]

Package: hledger
Version: 1.14.2-1+b1
Severity: wishlist

Upstream has released hledger 1.16.2, which includes a
number of improvements in versions 1.15.x and 1.16.x.
https://hledger.org/release-notes.html

One improvement relevant to building and packaging is
that hledger 1.16 added support for GHC 8.8, which is
the ghc version in debian unstable and testing.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hledger depends on:
ii  libatomic1  10-20200204-1
ii  libc6   2.29-10
ii  libffi7 3.3-3
ii  libgmp102:6.2.0+dfsg-3
ii  libtinfo6   6.1+20191019-1

hledger recommends no packages.

hledger suggests no packages.

-- no debconf information

Bug#951181: suricata: Dropping privileges fails in nflog runmode - patch available

[Timo Sigurdsson]

Package: suricata
Version: 1:4.1.2-2
Severity: important

Dear Maintainer,

attempting to use the run-as configuration option with the nflog capture method
results in the following error during the startup of suricata:
[ERRCODE: SC_ERR_NFLOG_BIND(248)] - nflog_bind_pf() for AF_INET failed

Suricata ultimately fails to start without root privileges in the nflog
runmode (if you remove the run-as configuration section, suricata runs just
fine).

This is because SCDropMainThreadCaps in src/util-privs.c does not define the
required capabilities for the nflog runmode, unlike other runmodes.

I have reported this bug upstream [1] and also submitted a patch to address
this which has been accepted upstream [2].

I would appreciate if you could consider adding this patch to the suricata
package in the current stable release (buster) as the inabilitiy to drop root
privileges may have severe security implications and the patch itself is
trivial.

Of course, I have tested the patch against the current version of suricata in
stable (4.1.2-2). It works fine and allows suricata to drop root privileges
via the run-as configuration option, as expected. I'm attaching a backported
version of the aforementioned fix (same patch, just with 1 line offset).

Regards,

Timo

[1] https://redmine.openinfosecfoundation.org/issues/3265
[2] 
https://github.com/OISF/suricata/commit/1262ecbde0c2130f3fd4ca336cd2646828de9391


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

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

Versions of packages suricata depends on:
ii  dpkg   1.19.7
ii  libc6  2.28-10
ii  libcap-ng0 0.7.9-2
ii  libevent-2.1-6 2.1.8-stable-4
ii  libevent-pthreads-2.1-62.1.8-stable-4
ii  libgcc11:8.3.0-6
ii  libgeoip1  1.6.12-1
ii  libgnutls303.6.7-4+deb10u2
ii  libhiredis0.14 0.14.0-3
ii  libhtp21:0.5.30-1
ii  libhyperscan5  5.1.0-1
ii  libjansson42.12-1
ii  libltdl7   2.4.6-9
ii  libluajit-5.1-22.1.0~beta3+dfsg-5.1
ii  liblz4-1   1.8.3-1
ii  libmagic1  1:5.35-4+deb10u1
ii  libnet11.1.6+dfsg-3.1
ii  libnetfilter-log1  1.0.1-1.1+b1
ii  libnetfilter-queue11.0.3-1
ii  libnfnetlink0  1.0.1-3+b1
ii  libnspr4   2:4.20-1
ii  libnss32:3.42.1-1+deb10u2
ii  libpcap0.8 1.8.1-6
ii  libpcre3   2:8.39-12
ii  libprelude23   4.1.0-4.2
ii  libpython2.7-stdlib [python-argparse]  2.7.16-2+deb10u1
ii  libyaml-0-20.2.1-1
ii  lsb-base   10.2019051400
ii  python 2.7.16-1
ii  python-simplejson  3.16.0-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages suricata recommends:
ii  python   2.7.16-1
pn  snort-rules-default  
pn  suricata-oinkmaster  

Versions of packages suricata suggests:
pn  libtcmalloc-minimal4  

-- no debconf information>From 987c80cb4222e605fc98debd40694fbea49f3173 Mon Sep 17 00:00:00 2001
From: Timo Sigurdsson 
Date: Tue, 11 Feb 2020 23:29:06 +0100
Subject: [PATCH] init: Fix dropping privileges in nflog runmode

Using the run-as configuration option with the nflog capture method
results in the following error during the startup of suricata:
[ERRCODE: SC_ERR_NFLOG_BIND(248)] - nflog_bind_pf() for AF_INET failed

This is because SCDropMainThreadCaps does not have any capabilities
defined for the nflog runmode (unlike other runmodes). Therefore, apply
the same capabilities to the nflog runmode that are already defined for
the nfqueue runmode. This has been confirmed to allow suricata start
and drop its privileges in the nflog runmode.

Fixes redmine issue #3265.

Backport of commit 1262ecb upstream to suricata 4.1.2 (Debian Buster).

Signed-off-by: Timo Sigurdsson 
---
 src/util-privs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/util-privs.c b/src/util-privs.c
index 5ce6843eb7..bed5889b9a 100644
--- a/src/util-privs.c
+++ b/src/util-privs.c
@@ -75,9 +75,10 @@ void SCDropMainThreadCaps(uint32_t userid, uint32_t groupid)
 CAP_NET_ADMIN, CAP_NET_RAW, CAP_SYS_NICE,
  

Bug#951179: RM: glslang [s390x] -- ROM; Blocking migration of glslang to testing

[Jordan Justen]

Package: ftp.debian.org
Severity: normal

s390x was removed from the latest glslang (8.13.3559-2) unstable upload:

https://salsa.debian.org/xorg-team/vulkan/glslang/commit/6466e35acadc5de8d75b7285eaaf1312b81b054d

the s390x arch missing is preventing glslang from migrating to testing:

https://qa.debian.org/excuses.php?package=glslang

Bug#951178: O: gconjugue -- GTK+ program to conjugate Brazilian verbs

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the gconjugue package.

The package description is:
 Graphical program to conjugate Portuguese verbs as spoken in Brazil.
 .
 If the entered expression is not a verb, GConjugue tries to find it
 among the conjugated forms of known verbs. It also has the option of
 conjugating verbs as ordinary Brazilians do. In fact, Brazilians of
 different regions deviate from the normative grammar in different ways,
 but the conjugation displayed will already help foreigners to grasp
 what Brazilians are saying.
 .
 This program is a graphical front-end to console tool known as conjugue
 (package brazilian-conjugate). Alternatively, you can use conjugar, the
 text only version for gconjugue.

Bug#951166: ITP: shortwave -- Find and listen to internet radio stations

[Wolfgang Silbermayr]

On 2/11/20 9:40 PM, David Heidelberg wrote:
> Package: wnpp
> Severity: wishlist
> Owner: David Heidelberg 
> 
> * Package name: shortwave
[...]

Hi David,

I work in the debian-rust team on the general rust crates ecosystem.
Shortwave is one of the programs for which I have worked towards getting
it's dependencies into Debian. There's still some levels of dependencies
missing, and the tooling does not yet support packaging of crates that
are not published on crates.io which is the case for shortwave, but
that's in the works [0]. For this project however, it might also be
feasible to maintain it separately because it doesn't use cargo
directly, but instead uses meson which wraps the cargo procedure.

We coordinate our work in the #debian-rust irc.oftc.net channel, feel
free to drop by so we can coordinate the required steps.

Progress is currently blocked, mainly by what is described in a mailing
list thread [1]. Once that is unlocked, we hope to be able to update
many of the crates that have been stuck, among which are also the
gtk-related crates.

You can use the cargo-debstatus tool to take a look at the dependency
tree that needs work before the program can be uploaded.

I'm currently a Debian Maintainer, so I won't be able to sponsor package
uploads for now, but we have members on the team who can do so.

Best regards,
Wolfgang.

--

[0] https://salsa.debian.org/rust-team/debcargo/merge_requests/22
[1]
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2020-February/009828.html

Bug#951177: NULL pointer dereference in iwlwifi

[Matt Corallo]

Package: linux-image-5.4.0-3-amd64
Version: 5.4.13-1

Since switching to 5.4.13 from 5.3.15 (IIRC, though I may have been on
5.4.8), my laptop hangs regularly when transmitting a bunch of wireguard
traffic over iwlwifi. The following kernel log is one of the lucky cases
where the soft-lockup recovered, but other times it seems to not.

Feb 11 15:53:26 BMXPSv3 kernel: iwlwifi :3b:00.0: Error sending
STATISTICS_CMD: time out after 2000ms.
Feb 11 15:53:26 BMXPSv3 kernel: iwlwifi :3b:00.0: Current CMD queue
read_ptr 248 write_ptr 249
Feb 11 15:53:28 BMXPSv3 kernel: iwlwifi :3b:00.0: HW error,
resetting before reading
Feb 11 15:53:28 BMXPSv3 kernel: iwlwifi :3b:00.0: Microcode SW error
detected. Restarting 0xA5A505A2.
Feb 11 15:53:28 BMXPSv3 kernel: BUG: kernel NULL pointer dereference,
address: 0008
Feb 11 15:53:28 BMXPSv3 kernel: #PF: supervisor read access in kernel mode
Feb 11 15:53:28 BMXPSv3 kernel: #PF: error_code(0x) - not-present page
Feb 11 15:53:28 BMXPSv3 kernel: PGD 0 P4D 0
Feb 11 15:53:28 BMXPSv3 kernel: Oops:  [#1] SMP PTI
Feb 11 15:53:28 BMXPSv3 kernel: CPU: 0 PID: 568 Comm: irq/158-iwlwifi
Tainted: G   OE 5.4.0-3-amd64 #1 Debian 5.4.13-1
Feb 11 15:53:28 BMXPSv3 kernel: Hardware name: Dell Inc. Precision
5530/0W8N6V, BIOS 1.8.1 02/01/2019
Feb 11 15:53:28 BMXPSv3 kernel: RIP:
0010:iwl_pcie_irq_msix_handler+0x12f/0x370 [iwlwifi]
Feb 11 15:53:28 BMXPSv3 kernel: Code: 00 41 f6 c6 01 0f 85 a4 00 00 00
48 8b 45 10 44 89 f2 83 e2 02 83 78 10 13 0f 84 2d 01 00 00 85 d2 74 37
48 8b 83 38 72 00 00 <8b> 40 08 3d d3 00 00 00 0f 84 06 02 00 00 3d d0
00 00 00 0f 84 fb
Feb 11 15:53:28 BMXPSv3 kernel: RSP: 0018:ae2680cd3e60 EFLAGS: 00010202
Feb 11 15:53:28 BMXPSv3 kernel: RAX:  RBX:
9c92dc240318 RCX: 
Feb 11 15:53:28 BMXPSv3 kernel: RDX: 0002 RSI:
0246 RDI: 0246
Feb 11 15:53:28 BMXPSv3 kernel: RBP: 9c92dc240018 R08:
9c92dc248fa8 R09: ae2680cd3df8
Feb 11 15:53:28 BMXPSv3 kernel: R10: ae2680cd3b50 R11:
 R12: a5a505a2
Feb 11 15:53:28 BMXPSv3 kernel: R13: 9c92dc24907c R14:
24000182 R15: 9c92dc247ea4
Feb 11 15:53:28 BMXPSv3 kernel: FS:  ()
GS:9c92ec00() knlGS:
Feb 11 15:53:28 BMXPSv3 kernel: CS:  0010 DS:  ES:  CR0:
80050033
Feb 11 15:53:28 BMXPSv3 kernel: CR2: 0008 CR3:
0002c1660006 CR4: 003606f0
Feb 11 15:53:28 BMXPSv3 kernel: Call Trace:
Feb 11 15:53:28 BMXPSv3 kernel:  ? irq_finalize_oneshot.part.0+0x100/0x100
Feb 11 15:53:28 BMXPSv3 kernel:  irq_thread_fn+0x20/0x60
Feb 11 15:53:28 BMXPSv3 kernel:  irq_thread+0xdc/0x170
Feb 11 15:53:28 BMXPSv3 kernel:  ? irq_forced_thread_fn+0x80/0x80
Feb 11 15:53:28 BMXPSv3 kernel:  kthread+0xf9/0x130
Feb 11 15:53:28 BMXPSv3 kernel:  ? irq_thread_check_affinity+0xd0/0xd0
Feb 11 15:53:28 BMXPSv3 kernel:  ? kthread_park+0x90/0x90
Feb 11 15:53:28 BMXPSv3 kernel:  ret_from_fork+0x35/0x40
Feb 11 15:53:28 BMXPSv3 kernel: Modules linked in: veth ccm ip6t_REJECT
nf_reject_ipv6 sch_fq_codel sch_htb ipt_REJECT nf_reject_ipv4 xt_tcpudp
xt_MASQUERADE xt_nat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 crc32c_generic nft_counter xt_mark xt_owner nft_compat
bridge stp llc wireguard(OE) ip6_udp_tunnel udp_tunnel wacom usbhid
hid_multitouch hid_generic dell_rbtn snd_sof_pci
snd_sof_intel_hda_common nf_tables snd_sof_intel_hda snd_sof_intel_byt
nfnetlink snd_sof_intel_ipc snd_sof snd_sof_xtensa_dsp snd_soc_skl
snd_hda_codec_hdmi snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc
snd_soc_sst_dsp x86_pkg_temp_thermal intel_powerclamp
snd_soc_acpi_intel_match coretemp snd_soc_acpi snd_hda_codec_realtek
snd_soc_core snd_hda_codec_generic kvm_intel iTCO_wdt rtsx_pci_ms iwlmvm
i2c_designware_platform snd_compress rtsx_pci_sdmmc mei_wdt
iTCO_vendor_support i2c_designware_core dell_laptop intel_rapl_msr
mmc_core memstick watchdog kvm ledtrig_audio snd_hda_intel btusb
dell_wmi wmi_bmof irqbypass
Feb 11 15:53:28 BMXPSv3 kernel:  mac80211 btrtl intel_wmi_thunderbolt
mxm_wmi tpm_crb snd_intel_nhlt dell_smbios btbcm snd_hda_codec btintel
dell_wmi_descriptor dcdbas dell_smm_hwmon bluetooth uvcvideo libarc4
snd_hda_core crct10dif_pclmul crc32_pclmul videobuf2_vmalloc snd_hwdep
ahci videobuf2_memops snd_pcm videobuf2_v4l2 ghash_clmulni_intel drbg
videobuf2_common libahci efi_pstore snd_timer intel_cstate iwlwifi
ansi_cprng intel_uncore cfg80211 ecdh_generic intel_lpss_pci
processor_thermal_device joydev ecc intel_rapl_perf videodev snd
intel_lpss pcspkr libata efivars rfkill crc16 ucsi_acpi soundcore mei_me
typec_ucsi cdc_acm rtsx_pci intel_rapl_common idma64 mei mc i2c_i801
i2c_hid mfd_core tpm_tis intel_pch_thermal intel_soc_dts_iosf typec
battery hid tpm_tis_core tpm int3403_thermal int3400_thermal intel_hid
wmi int340x_thermal_zone dell_smo8800 rng_core ac sparse_keymap
acpi_thermal_rel acpi_pad button efivarfs ip_tables 

Bug#951149: libreoffice-base: Missing versioned dependency on dpkg?

[Rene Engelhard]

notfound 951149 1:6.3.4-2
foun 951149 1:6.4.0~beta1-2
tag 951149 + moreinfo
thanks

Hi,

On Tue, Feb 11, 2020 at 11:03:57AM -0800, Peter Eckersley wrote:
> (Reading database ... 405556 files and directories currently installed.)
> Preparing to unpack .../libreoffice-base_1%3a6.4.1~rc1-2_amd64.deb ...
> dpkg-divert: error: unknown option --no-rename

MMh.

Which dpkg version?

Since stable has a suitable dpkg.

rene@frodo:~$ dpkg -l dpkg
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
 Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name   Version  Architektur  Beschreibung
+++-==---=
ii  dpkg   1.19.7   amd64Debian package management system
rene@frodo:~$ dpkg-divert --help | grep rename
  --rename Datei tatsächlich beiseite schieben (oder zurück).
  --no-rename  Datei nicht beiseite (oder zurück) schieben 
(Vorgabe).
rene@frodo:~$ ^C
rene@frodo:~$ LANG=C
rene@frodo:~$ cat /etc/debian_version 
10.3
rene@frodo:~$ dpkg -l dpkg
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  dpkg   1.19.7   amd64Debian package management system
rene@frodo:~$ dpkg-divert --help | grep rename
  --rename actually move the file aside (or back).
  --no-rename  do not move the file aside (or back) (default).

(and thus my upgrade, and even apt -t buster-backports install) just worked.

Regards,

Rene

Bug#951176: ITP: mate-hud -- Run menubar commands, much like the Unity 7 HUD

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: mate-hud
  Version : 19.10.1
  Upstream Author : Martin Wimpress 
* URL : https://github.com/ubuntu-mate/mate-hud/
* License : GPL-2+
  Programming Lang: Python
  Description : Run menubar commands, much like the Unity 7 HUD

 A Heads-Up Display (HUD) allows you to search through an application's
 appmenu. So if you're trying to find that single filter in Gimp but
 can't remember which filter category it fits into or if you can't
 recall if preferences sits under File, Edit or Tools on your favourite
 browser, you can just search for it rather than hunting through the
 menus.
 .
 This package will be maintained under the umbrella of the Debian+Ubuntu
 MATE Packaging Team.

Bug#951152: new archmage version breaks keepass2 documentation build

[Mikhail Gusarov]

Hi Julian,

On 11 Feb 2020, at 21:25, Julian Taylor wrote:


For keepass I only need to be able to build html files from the chm
source directory, the package has no compiled chm file one can use the
current cli functions on.


Please try 
https://github.com/dottedmag/archmage/commit/c8f186dff0c8da56590e900cc2a32b39e19bf08b


- if it works, then I'll cut a new release and a package.

Best,
Misha.

Bug#951175: O: volatility -- advanced memory forensics framework

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the volatility package.

The package description is:
 The Volatility Framework is a completely open collection of tools for
 the extraction of digital artifacts from volatile memory (RAM) samples.
 It is useful in forensics analysis. The extraction techniques are
 performed completely independent of the system being investigated but
 offer unprecedented visibility into the runtime state of the system.
 .
 Volatility supports memory dumps from all major 32- and 64-bit Windows
 versions and service packs. Whether your memory dump is in raw format,
 a Microsoft crash dump, hibernation file, or virtual machine snapshot,
 Volatility is able to work with it.
 .
 Linux memory dumps in raw or LiME format are supported too. There are
 several plugins for analyzing memory dumps from 32- and 64-bit Linux
 kernels and relevant distributions such as Debian, Ubuntu, openSUSE,
 RedHat, Fedora, CentOS, Mandriva, etc.
 .
 Volatility also support several versions of Mac OSX memory dumps, both
 32- and 64-bit. Android phones with ARM processors are also supported.
 .
 These are some of the data that can be extracted from a memory image:
- Image information (date, time, CPU count);
- Running processes;
- Open network sockets and connections;
- OS kernel modules loaded;
- Memory maps for each process;
- Executables samples;
- Command history;
- Suspicious process mappings (i.e. injected code);
- Passwords, as LM/NTLM hashes and LSA secrets;
- Cached Truecrypt passphrases;
- Others.
 .
 Current version (2.6) supports investigations of the memory images from
 the following operational systems:
- 32-bit Windows XP Service Pack 2 and 3
- 32-bit Windows 2003 Server Service Pack 0, 1, 2
- 32-bit Windows Vista Service Pack 0, 1, 2
- 32-bit Windows 2008 Server Service Pack 1, 2 (there is no SP0)
- 32-bit Windows 7 Service Pack 0, 1
- 32-bit Windows 8, 8.1, and 8.1 Update 1
- 32-bit Windows 10 (initial support)
- 64-bit Windows XP Service Pack 1 and 2 (there is no SP0)
- 64-bit Windows 2003 Server Service Pack 1 and 2 (there is no SP0)
- 64-bit Windows Vista Service Pack 0, 1, 2
- 64-bit Windows 2008 Server Service Pack 1 and 2 (there is no SP0)
- 64-bit Windows 2008 R2 Server Service Pack 0 and 1
- 64-bit Windows 7 Service Pack 0 and 1
- 64-bit Windows 8, 8.1, and 8.1 Update 1
- 64-bit Windows Server 2012 and 2012 R2
- 64-bit Windows 10 (including at least 10.0.14393)
- 64-bit Windows Server 2016 (including at least 10.0.14393.0)
- 32-bit Linux kernels 2.6.11 to 4.2.3
- 64-bit Linux kernels 2.6.11 to 4.2.3
- 32-bit 10.5.x Leopard (the only 64-bit 10.5 is Server, which isn't
  supported)
- 32-bit 10.6.x Snow Leopard
- 64-bit 10.6.x Snow Leopard
- 32-bit 10.7.x Lion
- 64-bit 10.7.x Lion
- 64-bit 10.8.x Mountain Lion (there is no 32-bit version)
- 64-bit 10.9.x Mavericks (there is no 32-bit version)
- 64-bit 10.10.x Yosemite (there is no 32-bit version)
- 64-bit 10.11.x El Capitan (there is no 32-bit version)
- 64-bit 10.12.x Sierra (there is no 32-bit version)
 .
 Volatility supports a variety of sample file formats:
- Raw linear sample (dd)
- Hibernation file (from Windows 7 and earlier)
- Crash dump file
- VirtualBox ELF64 core dump
- VMware saved state and snapshot files
- EWF format (E01)
- LiME format
- Mach-O file format
- QEMU virtual machine dumps
- Firewire
- HPAK (FDPro)

Bug#951173: O: bittwist -- libpcap based Ethernet packet generator

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the bittwist package.

The package description is:
 bittwist (or Bit-Twist) is designed to complement tcpdump, which by itself has
 done a great job in capturing network traffic. Bit-Twist can regenerate the
 captured traffic onto a live network (the packets are generated from tcpdump
 trace file, generating a .pcap file).
 .
 Bit-Twist also comes with a comprehensive trace file editor to allow one to
 change the contents of a trace file (bittwiste).
 .
 Generally, a packet generator is useful in simulating networking traffic or
 scenario, testing firewall, IDS, and IPS, and troubleshooting various network
 problems.
 .
 The Bit-Twist features are:
 .
* runs on Mac OS X (and *BSD), Linux, and Windows;
* send multiple trace files at a time;
* send packets at a specific speed or line rate in Mbps;
* comprehensive trace file editor with control over most fields in
  Ethernet, ARP, IP, ICMP, TCP, and UDP headers with automatic header
  checksum correction;
* append user payload to existing packets after a specific header;
* select a specific range of packets and save them in another trace file;
* highly scriptable - with proper manipulation you can turn Bit-Twist
  into an extremely flexible packet generator tool;
* if you are teaching Computer Networks classes, you may find Bit-Twist
  useful as a practical teaching material. It gives your students a
  hands-on experience to learn various networking protocols etc.

Bug#951174: RM: ruby-grape-msgpack -- ROM; RC Buggy + FTBFS against Ruby2.7

[Utkarsh Gupta]

Package: ftp.debian.org
Severity: normal
User: pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: ruby2.7-transition

Hi,

This package hasn't been in testing since 1288 days and also fails to
build against Ruby 2.7. And also has an RC bug since a long time.

Each of its reverse dependencies are being filed for removal as well.
This was discussed at the Ruby sprints and finally in the Ruby list, too.

I hereby request the removal of the same.


Best,
Utkarsh

Bug#951154: Acknowledgement (prosody: ejabberd2prosody crashes)

[Marvin Gülker]

I have found that the problem can be worked around by copying the module 
which the script complains about to a directory "util" under the 
current working directory:


   # cd /tmp
   # mkdir util
   # cp /usr/lib/prosody/util/encodings.so util
   # ejabberd2prosody /tmp/dump.txt
   [success] private: [redacted] - storage:bookmarks
   [success] private: [redacted] - storage:bookmarks
   [...]

That is, the required file "encodings.so" is supplied by the "prosody" 
package already, it is just not being found when the ejabberd2prosody 
script is executed:


   # dpkg -L prosody | grep -i encoding
   /usr/lib/prosody/util/encodings.so

I have found that workaround by looking at the error message; it appears 
that among several other pathes, Lua tries to load that file also from 
"./util/encodings.so".


Am 11. Februar 2020 um 19:54 Uhr + schrieb Debian Bug Tracking System:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 951154: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951154.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
 post+debb...@guelker.eu
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
Debian XMPP Maintainers 

If you wish to submit further information on this problem, please
send it to 951...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
951154: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951154
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
Blog: https://mg.guelker.eu

Bug#951172: RM: ruby-dep-selector -- ROM; RC Buggy + FTBFS against Ruby2.7

[Utkarsh Gupta]

Package: ftp.debian.org
Severity: normal
User: pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: ruby2.7-transition

Hi,

This package hasn't been in testing since 1661 days and also fails to
build against Ruby 2.7. And also has an RC bug since a long time.

Each of its reverse dependencies are being filed for removal as well.
This was discussed at the Ruby sprints and finally in the Ruby list, too.

I hereby request the removal of the same.


Best,
Utkarsh

Bug#951170: "krb5-config.heimdal: Command not found" error when building package

[Richard Landster]

Source: cyrus-sasl2
Version: 2.1.27+dfsg-1+deb10u1
Severity: normal

Dear Maintainer,


When building the cyrus-sasl2 source package version 2.1.27+dfsg-1+deb10u1
we get the error

/bin/sh: krb5-config.heimdal: command not found
make: krb5-config.heimdal: Command not found

We are using "gbp buildpackage" and pbuilder to build the package. The
package _does_ build, that is, we get a package at the end, but the error
message above is concerning.

Here is more of the build log:


dpkg-checkbuilddeps: error: Unmet build dependencies: chrpath 
default-libmysqlclient-dev | li\
bmysqlclient-dev docbook-to-man heimdal-multidev libdb-dev libpam0g-dev 
libpod-pom-view-restr\
uctured-perl libpq-dev libsqlite3-dev python3-sphinx
^[[1;33mW: Unmet build-dependency in source^[[0m
dpkg-source: info: using options from 
cyrus-sasl2-2.1.27+dfsg/debian/source/options: --diff-i\
gnore --tar-ignore
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Make-the-libsasl2-symbols-versioned.patch
dpkg-source: info: applying 
0002-Use-etc-sasldb2-instead-of-.-sasldb-in-the-testsuite.patch
dpkg-source: info: applying 
0003-Update-saslauthd.conf-location-in-documentation.patch
dpkg-source: info: applying 
0004-Include-dbconverter-2-in-sbin_PROGRAMS-and-set-defau.patch
dpkg-source: info: applying 0005-Fixes-in-library-mutexes.patch
dpkg-source: info: applying 0006-Enable-autoconf-maintainer-mode.patch
dpkg-source: info: applying 
0008-Don-t-overwrite-PIC-objects-with-non-PIC-variant.patch
dpkg-source: info: applying 0009-Look-for-generic-Berkeley-DB-first.patch
dpkg-source: info: applying 
0010-Update-required-libraries-when-ld-as-needed-is-used.patch
dpkg-source: info: applying 0013-Don-t-use-la-files-for-opening-plugins.patch
dpkg-source: info: applying 0018-Temporary-multiarch-fixes.patch
dpkg-source: info: applying 
0019-Add-reference-to-LDAP_SASLAUTHD-file-to-the-saslauth.patch
dpkg-source: info: applying 0022-Fix-keytab-option-for-MIT-Kerberos.patch
dpkg-source: info: applying 0025-Revert-upstream-soname-bump.patch
dpkg-source: info: applying 0027-properly-create-libsasl2.pc.patch
dpkg-source: info: applying 
0032-Add-with_pgsql-include-postgresql-to-include-path.patch
dpkg-source: info: applying 
0017-Just-completely-remove-libobj-from-autotools-files.patch
dpkg-source: info: applying 0033-cross.patch
dpkg-source: info: applying 
0019-Stop-importing-docutils_version-in-sphinx-build-manp.patch
dpkg-source: info: applying 
0020-Restore-LIBS-after-checking-gss_inquire_sec_context_.patch
dpkg-source: info: applying 0021-CVE-2019-19906.patch
/bin/sh: krb5-config.heimdal: command not found
make: krb5-config.heimdal: Command not found
dh clean 
   debian/rules override_dh_auto_clean
make[1]: Entering directory 
'/srv/scratch/adamhl/sasl/sasl-build/build-area/cyrus-sasl2-2.1.2\
7+dfsg'
/bin/sh: krb5-config.heimdal: command not found
make[1]: krb5-config.heimdal: Command not found
dh_auto_clean -Bbuild-mit
dh_auto_clean -Bbuild-heimdal
rm -f sample/sample-client \
sample/sample-server
[ ! -f Makefile ] || /usr/bin/make distclean
rm -f config.h config.log autom4ate.cache
# Remove symlinks that the CMU build sets up but never removes.
# They can be found by running find . -lname '*' -print in the



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Bug#951171: RM: volatility -- NBS; Purely Python2 based

[Joao Eriberto Mota Filho]

Package: ftp.debian.org
Severity: normal

Please, remove volatility from Debian. This package is based on Python2
and is FTBFS because depends of other packages also based on Python2.

>From the upstream[1]:

  Requirements
  
  - Python 2.6 or later, but not 3.0. http://www.python.org

[1] https://github.com/volatilityfoundation/volatility

Cheers,

Eriberto

Bug#951169: django-sekizai: autopkgtest regression: 'runtests.py': [Errno 2] No such file or directory

[Paul Gevers]

Source: django-sekizai
Version: 1.1.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of django-sekizai the autopkgtest of django-sekizai
fails in testing when that autopkgtest is run with the binary packages
of django-sekizai from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
django-sekizai from testing1.1.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?

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=django-sekizai

https://ci.debian.net/data/autopkgtest/testing/amd64/d/django-sekizai/4260329/log.gz

autopkgtest [17:09:32]: test command1: python3 runtests.py
autopkgtest [17:09:32]: test command1: [---
python3: can't open file 'runtests.py': [Errno 2] No such file or directory
autopkgtest [17:09:32]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#951168: node-tmp: autopkgtest regression on arm64: issue121 - clean up on terminating signals

[Paul Gevers]

Source: node-tmp
Version: 0.1.0+dfsg-5
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of node-tmp the autopkgtest of node-tmp fails in
testing when that autopkgtest is run with the binary packages of
node-tmp from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
node-tmp   from testing0.1.0+dfsg-5
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?

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=node-tmp

https://ci.debian.net/data/autopkgtest/testing/arm64/n/node-tmp/4252491/log.gz

  1) tmp
   issue121 - clean up on terminating signals
 for signal SIGTERM:

  AssertionError [ERR_ASSERTION]:  should exist
  + expected - actual

  -false
  +true

  at Object.assertExists (test/assertions.js:59:10)
  at
/tmp/autopkgtest-lxc.wmntos5t/downtmp/autopkgtest_tmp/smoke5H8Kvk/test/issue121-test.js:38:22
  at _close (test/child-process.js:58:7)
  at Socket._stdoutEnd (test/child-process.js:73:5)
  at Pipe._handle.close (net.js:607:12)



signature.asc
Description: OpenPGP digital signature

Bug#951166: ITP: shortwave -- Find and listen to internet radio stations

[David Heidelberg]

Package: wnpp
Severity: wishlist
Owner: David Heidelberg 

* Package name: shortwave
  Version : 0.0.2
  Upstream Author : Felix Häcker 
* URL : https://gitlab.gnome.org/World/Shortwave
* License : GPL-3.0-or-later
  Programming Lang: Rust
  Description : Find and listen to internet radio stations

GNOME application for listening internet radio streams.


 - it's modern, clean and functional radio player for GNOME, it also
   features ability to save previously played songs
 - I need a sponsor

Bug#951167: node-delayed-stream: autopkgtest failure: killed

[Paul Gevers]

Source: node-delayed-stream
Version: 1.0.0-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: always-fails

Dear maintainers,

With a recent upload of node-delayed-stream you added an autopkgtest to
node-delayed-stream, great. However, it fails. 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?

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=node-delayed-stream

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-delayed-stream/4163317/log.gz

[0:03:19 0/10/10 100.0% run.js]Killed



signature.asc
Description: OpenPGP digital signature

Bug#951164: ITP: php-phpoption -- Option type for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-phpoption
  Version : 1.7.2
  Upstream Author : Johannes M. Schmitt 
* URL : https://github.com/schmittjoh/php-option
* License : Apache-2.0
  Programming Lang: PHP
  Description : Option type for PHP

PHP library implementing an Option type for PHP.

The Option type is intended for cases where you sometimes might return a value
(typically an object), and sometimes you might return a base value (typically
null) depending on arguments, or other runtime factors.

This package is a dependency of php-vlucas-phpdotenv (ITP #951163).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951162: ITP: php-dragonmantank-cron-expression -- cron expression parser for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-dragonmantank-cron-expression
  Version : 2.3.0
  Upstream Author : Chris Tankersley 
* URL : https://github.com/dragonmantank/cron-expression
* License : MIT
  Programming Lang: PHP
  Description : cron expression parser for PHP

PHP library implementing a cron expression parser.

The PHP cron expression parser can parse a cron expression, determine if it is
due to run, calculate the next run date of the expression, and calculate the
previous run date of the expression.

This package is a dependency of php-laravel-lumen-framework (ITP #951156).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951163: ITP: php-vlucas-phpdotenv -- environment variable file loader for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-vlucas-phpdotenv
  Version : 3.6.0
  Upstream Author : Vance Lucas 
* URL : https://github.com/vlucas/phpdotenv
* License : BSD
  Programming Lang: PHP
  Description : environment variable file loader for PHP

PHP library implementing an environment variable file (.env) loader for PHP.

The environment file loader will load environment variables from .env files to
getenv(), $_ENV and $_SERVER automagically.

This package is a dependency of php-laravel-lumen-framework (ITP #951156).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951165: mmseqs2: autopkgtest regression: ./test_alignment: No such file or directory

[Paul Gevers]

Source: mmseqs2
Version: 10-6d92c+ds-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of mmseqs2 the autopkgtest of mmseqs2 fails in
testing when that autopkgtest is run with the binary packages of mmseqs2
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
mmseqs2from testing10-6d92c+ds-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? If needed, please
change the bug's severity.

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=mmseqs2

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mmseqs2/4252776/log.gz

Invoking test_alignment
/tmp/autopkgtest-lxc.tn0ha254/downtmp/build.g6E/src/debian/tests/run-unit-test:
line 27: ./test_alignment: No such file or directory



signature.asc
Description: OpenPGP digital signature

Bug#951159: ITP: php-laravel-framework -- web application framework for PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-laravel-framework
  Version : 6.15.0
  Upstream Author : Taylor Otwell 
* URL : https://github.com/laravel/framework
* License : MIT
  Programming Lang: PHP
  Description : web application framework for PHP

Laravel is a web application framework for PHP with expressive, elegant syntax.

This package will be a multi-binary package building the many php-illuminate-*
library components that make up the Laravel framework, but that are also used
by other PHP frameworks and applications.

It will replace the separate php-illuminate-* source packages that are already
in Debian.

This package is a dependency of php-laravel-lumen-framework (ITP #951156).

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951156: ITP: php-laravel-lumen-framework -- micro-framework for building web applications in PHP

[Robin Gustafsson]

Package: wnpp
Severity: wishlist
Owner: Robin Gustafsson 

* Package name: php-laravel-lumen-framework
  Version : 6.3.3
  Upstream Author : Taylor Otwell 
* URL : https://github.com/laravel/lumen-framework
* License : MIT
  Programming Lang: PHP
  Description : micro-framework for building web applications in PHP

Laravel Lumen is a stunningly fast PHP micro-framework for building web
applications with expressive, elegant syntax. Lumen attempts to take the pain
out of development by easing common tasks used in the majority of web projects,
such as routing, database abstraction, queueing, and caching.

This library contains the core code of the Laravel Lumen framework.

I plan to maintain this package within the Debian PHP PEAR Maintainers team.

Bug#951157: wireguard-dkms: DKMS make.log for wireguard-0.0.20200205 for kernel 5.3.9-sunxi (armv7l)

[carlosnewmusic]

Package: wireguard-dkms
Version: 0.0.20200205-1
Severity: serious
Tags: newcomer ftbfs
Justification: fails to build from source

Dear Maintainer,

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

   * What led up to the situation?
wireguard metapackage installation
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
install, install kernel headers, but it's useless
   * What was the outcome of this action?
error 10 in the construction of the dkms package
   * What outcome did you expect instead?
that the module and wireguard will be installed correctly

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



-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.3.9-sunxi (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wireguard-dkms depends on:
ii  dkms  2.6.1-4
ii  perl  5.28.1-6

Versions of packages wireguard-dkms recommends:
pn  wireguard
pn  wireguard-tools  

wireguard-dkms suggests no packages.

-- no debconf information
DKMS make.log for wireguard-0.0.20191226 for kernel 5.3.9-sunxi (armv7l)
lun ene 20 04:47:15 CET 2020
make: se entra en el directorio '/usr/src/linux-headers-5.3.9-sunxi'
  CC [M]  /var/lib/dkms/wireguard/0.0.20191226/build/main.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20191226/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20191226/build/device.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20191226/build/peer.o
/bin/sh: 1: ./scripts/recordmcount: not found
make[1]: *** [scripts/Makefile.build:281: 
/var/lib/dkms/wireguard/0.0.20191226/build/main.o] Error 127
make[1]: *** Se borra el archivo 
'/var/lib/dkms/wireguard/0.0.20191226/build/main.o'
make[1]: *** Se espera a que terminen otras tareas
/bin/sh: 1: ./scripts/recordmcount: not found
make[1]: *** [scripts/Makefile.build:281: 
/var/lib/dkms/wireguard/0.0.20191226/build/peer.o] Error 127
make[1]: *** Se borra el archivo 
'/var/lib/dkms/wireguard/0.0.20191226/build/peer.o'
/bin/sh: 1: ./scripts/recordmcount: not found
make[1]: *** [scripts/Makefile.build:281: 
/var/lib/dkms/wireguard/0.0.20191226/build/device.o] Error 127
make[1]: *** Se borra el archivo 
'/var/lib/dkms/wireguard/0.0.20191226/build/device.o'
/bin/sh: 1: ./scripts/recordmcount: not found
make[1]: *** [scripts/Makefile.build:281: 
/var/lib/dkms/wireguard/0.0.20191226/build/noise.o] Error 127
make[1]: *** Se borra el archivo 
'/var/lib/dkms/wireguard/0.0.20191226/build/noise.o'
make: *** [Makefile:1626: _module_/var/lib/dkms/wireguard/0.0.20191226/build] 
Error 2
make: se sale del directorio '/usr/src/linux-headers-5.3.9-sunxi'

Bug#951152: new archmage version breaks keepass2 documentation build

[Mikhail Gusarov]

Hello Julian,

On 11 Feb 2020, at 20:23, Julian Taylor wrote:

> The new archmage version breaks the documentation build of the keepass2
> package. This is due to the (maybe accidental) removal of the availity
> to render html files from chm sources.

Fun. While reworking pychm I had a careful look of all dependencies to see
what subsets of API do they use, but it never occurred to me that there
might be programs out there that use (never guaranteed to be stable) innards
of Archmage.

Keepass packaging definitely needs to stop doing this. What's missing from
Archmage CLI if I reimplement HTML generation from unpacked CHM files tree?

> I have filed patch upstream to restore that ability:
> https://github.com/dottedmag/archmage/pull/17
>
> As it is required to update keepass2 and remove its python2 dependency,
> could it be considered to add it to the package if upstream does not
> react soon?

Well, I'm the upstream.

Best,
Misha.

Bug#951152: new archmage version breaks keepass2 documentation build

[Julian Taylor]

On 11.02.20 21:20, Mikhail Gusarov wrote:
> Hello Julian,
> 
> On 11 Feb 2020, at 20:23, Julian Taylor wrote:
> 
>> The new archmage version breaks the documentation build of the keepass2
>> package. This is due to the (maybe accidental) removal of the availity
>> to render html files from chm sources.
> 
> Fun. While reworking pychm I had a careful look of all dependencies to see
> what subsets of API do they use, but it never occurred to me that there
> might be programs out there that use (never guaranteed to be stable) innards
> of Archmage.
> 
> Keepass packaging definitely needs to stop doing this. What's missing from
> Archmage CLI if I reimplement HTML generation from unpacked CHM files tree?
> 

I'll gladly remove the usage of the module functions when the cli
provides this functionality. Currently (and in the past) it requires a
compiled chm to extract from.

For keepass I only need to be able to build html files from the chm
source directory, the package has no compiled chm file one can use the
current cli functions on.

Bug#951161: O: distorm3 -- powerful disassembler library for x86/AMD64 binary streams

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the distorm3 package.

The package description is:
 diStorm3 is a binary stream disassembler library project.
 .
 With diStorm3, no more parsing strings is needed. diStorm3 is really a
 decomposer, which means it takes an instruction and returns a binary
 structure which describes it rather than static text. This is great for
 advanced binary code analysis.
 .

Note: diStorm3 was useful for volatility, a project based in Python2 and
to be removed from Debian (or already removed).

Bug#777230: libmp3-info-perl: CVE-2013-6499: loading a module relative to the cwd

[Salvatore Bonaccorso]

Hi,

On Thu, Aug 27, 2015 at 05:56:56PM +0200, gregor herrmann wrote:
> On Fri, 06 Feb 2015 17:04:40 +0100, Salvatore Bonaccorso wrote:
> 
> > the following vulnerability was published for libmp3-info-perl.
> > 
> > CVE-2013-6499[0]:
> > loading a module relative to the cwd
> > 
> > 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-2013-6499
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1018805
> 
> FWIW, the bug is closed in Red Hat Bugzilla mentioned above as
> "bogus".

The assigning CNA for this CVE did in meanwhile reject the CVE. I'm
marking this as wontfix and closing the issue (as very unlikely the
underlying bug will be fixed).

Regards,
Salvatore

Bug#951160: linux-image-5.4.0-3-amd64: modules randomly become unresponsive after resume

[Nicolas Braud-Santoni]

Package: src:linux
Version: 5.4.13-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainers,

Since the latest kernel upgrade (effective January 26th, on this system),
I've encountered 2 different kernel modules becoming unresponsive after
resuming from suspend-to-RAM, and being unable to unload/reload them:

> list_del corruption. prev->next should be 966c89802498, but was 
> 966c89802
> 
> [ cut here ]
> kernel BUG at lib/list_debug.c:51!
> invalid opcode:  [#1] SMP PTI
> CPU: 3 PID: 2672288 Comm: rmmod Tainted: P   OE 5.4.0-2-amd64 #1 
> Debi
> 
> Hardware name: LENOVO 23252QG/23252QG, BIOS CBET4000 4.8-883-gd308ed37bc 
> 07/26/20
> 
> RIP: 0010:__list_del_entry_valid.cold+0x31/0x55
> Code: 5b ee 99 e8 d4 1e ce ff 0f 0b 48 c7 c7 f0 5b ee 99 e8 c6 1e ce ff 0f 0b 
> 48 89 f2 48 89 fe 48 c7 c7 b0 5b ee 99 e8 b2 1e ce ff <0f> 0b 48 89 fe 4c 89 
> c2 48 c7 c7 78 5b ee 99 e8 9e 1e ce ff 0f 0b
> RSP: 0018:a7a34ea6bd80 EFLAGS: 00010246
> RAX: 0054 RBX: 966e28e2e558 RCX: 0006
> RDX:  RSI: 0086 RDI: 966e2b197680
> RBP: 966e28e2c260 R08: 1555 R09: 0064
> R10: a7a34ea6bc30 R11:  R12: 02b0
> R13: 1580 R14: 966c89802498 R15: 966e28e2e3f0
> FS:  7fcd76bdf4c0() GS:966e2b18() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 55ebf4ab11b8 CR3: ac6bc006 CR4: 001606e0
> Call Trace:
>  xhci_mem_cleanup+0x122/0x4a0 [xhci_hcd]
>  xhci_stop+0x125/0x1a0 [xhci_hcd]
>  usb_remove_hcd+0x104/0x1bc [usbcore]
>  usb_hcd_pci_remove+0x69/0xd0 [usbcore]
>  pci_device_remove+0x3b/0xa0
>  device_release_driver_internal+0xe4/0x1c0
>  driver_detach+0x46/0x87
>  bus_remove_driver+0x58/0xcc
>  pci_unregister_driver+0x29/0xb0
>  __x64_sys_delete_module+0x192/0x2d0
>  ? exit_to_usermode_loop+0xb0/0xf0
>  do_syscall_64+0x52/0x160
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7fcd76d00be7
> Code: 73 01 c3 48 8b 0d a9 e2 0b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 
> 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 
> 01 c3 48 8b 0d 79 e2 0b 00 f7 d8 64 89 01 48
> RSP: 002b:7fff357e8738 EFLAGS: 0206 ORIG_RAX: 00b0
> RAX: ffda RBX: 55ebf4aa75a0 RCX: 7fcd76d00be7
> RDX: 000a RSI: 0800 RDI: 55ebf4aa7608
> RBP: 7fff357e8798 R08:  R09: 
> R10: 7fcd76d73ac0 R11: 0206 R12: 7fff357e8960
> R13: 7fff357ea89e R14: 55ebf4aa52a0 R15: 55ebf4aa75a0
> Modules linked in: [...]
> ---[ end trace 4690752726649ac3 ]---
> RIP: 0010:__list_del_entry_valid.cold+0x31/0x55
> Code: 5b ee 99 e8 d4 1e ce ff 0f 0b 48 c7 c7 f0 5b ee 99 e8 c6 1e ce ff 0f 0b 
> 48 89 f2 48 89 fe 48 c7 c7 b0 5b ee 99 e8 b2 1e ce ff <0f> 0b 48 89 fe 4c 89 
> c2 48 c7 c7 78 5b ee 99 e8 9e 1e ce ff 0f 0b
> RSP: 0018:a7a34ea6bd80 EFLAGS: 00010246
> RAX: 0054 RBX: 966e28e2e558 RCX: 0006
> RDX:  RSI: 0086 RDI: 966e2b197680
> RBP: 966e28e2c260 R08: 1555 R09: 0064
> R10: a7a34ea6bc30 R11:  R12: 02b0
> R13: 1580 R14: 966c89802498 R15: 966e28e2e3f0
> FS:  7fcd76bdf4c0() GS:966e2b18() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 55ebf4ab11b8 CR3: ac6bc006 CR4: 001606e0


This occured on both the psmouse module (so I had no working mouse anymore
until reboot) and xhci (so USB peripherals did not work, again until reboot).

Please find attached the dmesg logs, as complete as I was able to obtain.

In case you need additional information and I'm not sufficiently responsive,
please feel free to poke me on #debian-kernel.


Best,

  nicoo


- -- Package-specific info:
** Version:
Linux version 5.4.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20200117 (Debian 9.2.1-24)) #1 SMP Debian 5.4.13-1 (2020-01-19)

** Command line:
BOOT_IMAGE=/vmlinuz-5.4.0-3-amd64 root=ZFS=neon/ROOT/debian ro 
spec_store_bypass_disable=auto quiet

** Tainted: PWOE (12801)
 * proprietary module was loaded
 * kernel issued warning
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[449115.080536] OOM killer enabled.
[449115.080538] Restarting tasks ... 
[449115.080669] usb 1-2: USB disconnect, device number 91
[449115.098328] systemd-journald[3494174]: Retention time reached.
[449115.123336] done.
[449115.134064] video LNXVIDEO:00: Restoring backlight state
[449115.141096] PM: suspend exit
[449115.144507] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[449115.145329] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq

Bug#951158: pbuilder: bash-completion does not know about --binary-indep

[Ralf Treinen]

Package: pbuilder
Version: 0.230.4
Severity: minor

Hi,

the bash-completion for pbuilder proposes the option --binary-arch but
does not seem to know the --binary-indep option.

-Ralf.

Bug#951155: RFS: 1.3.1+dfsg-1~bpo10+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
buster-backports repository.

 * Package name: streamlink
   Version : 1.3.1+dfsg-1~bpo10+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.3.1+dfsg-1~bpo10+1.dsc

More information about streamlink can be obtained at
https://streamlink.github.io/


Changes since the last upload to buster-backports:
streamlink (1.3.1+dfsg-1~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.

 -- Alexis Murzeau   Tue, 11 Feb 2020 20:52:45 +0100

streamlink (1.3.1+dfsg-1) unstable; urgency=medium

  * New upstream version 1.3.1+dfsg
  * Update d/copyright years to 2020
  * Add patch to remove external images in html documentation
  * Bump Standards-Version to 4.5.0 (no changes)

 -- Alexis Murzeau   Wed, 29 Jan 2020 22:34:41 +0100


Differences from testing package (1.3.1+dfsg-1):
  * Update d/README.source for buster-backports

Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#949739: iptables: ufw fails with iptables 1.8.4-2

[Jamie Strandboge]

On Mon, 10 Feb 2020, Ximin Luo wrote:

> Control: reassign -1 ufw
> Control: severity -1 grave # breaks security software
> 
> ufw needs to be patched/updated to call iptables{,6}-legacy-{save,restore}.

Thank you for the bug report.

This is not the correct path forward and this is iptables bug:
https://bugzilla.netfilter.org/show_bug.cgi?id=1400

which is a regression in upstream 1.8.4's iptables-restore parser.
iptables is supposed to be command line and input compatible with
iptables-legacy and ufw is not going to force the use of
iptables-legacy and will instead honor the alternatives mechanism for
how the system administrator configured the system (since you cannot
reliably mix xtables (ie, -legacy) and nftables rulesets.

> In the meantime, iptables 1.8.3 is no longer in Debian, but the user can work 
> around this by doing `sudo update-alternatives --config ip{,6}tables` and 
> using the legacy commands accordingly.
> 
> You might need to restart your computer as well. I tried restarting ufw and 
> even running `iptables -F` and `-X` but my system was still entirely screwed 
> (all internet blocked) even when iptables seemingly had no rules, and only 
> was fixed until after I restarted.

This is probably due to ordering. You would need to flush all the
tables, then cut over to iptables-legacy, then use the firewall.

> X
> 
> On Fri, 24 Jan 2020 12:53:08 +0100 Peje Nilsson  wrote:
> > Package: iptables
> > Version: 1.8.4-2
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> >    * What led up to the situation?
> > Upgraded iptables to latest unstable and then restarted ufw.
> > 
> > root:~# iptables --version
> > iptables v1.8.4 (nf_tables)
> > root:~# ufw disable
> > Firewall stopped and disabled on system startup
> > root:~# ufw enable
> > ERROR: problem running ufw-init
> > iptables-restore: COMMIT expected at line 19
> > ip6tables-restore: COMMIT expected at line 19
> > 
> > Problem running '/etc/ufw/user.rules'
> > Problem running '/etc/ufw/user6.rules'
> > 
> > root:~# ping -n 8.8.8.8
> > PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> > ^C
> > --- 8.8.8.8 ping statistics ---
> > 9 packets transmitted, 0 received, 100% packet loss, time 8184ms
> > 
> > root:~# ufw disable
> > Firewall stopped and disabled on system startup
> > root:~# ping -n 8.8.8.8
> > PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> > 64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=9.18 ms
> > 64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=9.01 ms
> > 64 bytes from 8.8.8.8: icmp_seq=3 ttl=51 time=9.13 ms
> > ^C
> > --- 8.8.8.8 ping statistics ---
> > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
> > rtt min/avg/max/mdev = 9.013/9.105/9.177/0.068 ms
> > 
> > Downgrading to iptables 1.8.3-2 makes things work again:
> > 
> > root:~# iptables --version
> > iptables v1.8.3 (nf_tables)
> > root:~# ufw enable
> > Firewall is active and enabled on system startup
> > root:~# ping -n 8.8.8.8
> > PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> > 64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=9.00 ms
> > 64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=9.01 ms
> > ^C
> > --- 8.8.8.8 ping statistics ---
> > 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> > rtt min/avg/max/mdev = 8.999/9.002/9.006/0.003 ms
> > 
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
> > 'experimental')
> 
> -- 
> GPG: ed25519/56034877E1F87C35
> GPG: rsa4096/1318EFAC5FBBDBCE
> https://github.com/infinity0/pubkeys.git
-- 
Jamie Strandboge | http://www.canonical.com


signature.asc
Description: PGP signature

Bug#912569: ssh packet_write_wait: broken pipe

[Roberto Lumbreras]

Hi,

Same problem here. It happens to me when I try to copy a big file with
rsync or scp.
After a few seconds, boom, broken pipe.
Normal ssh use, interactive, just works as expected.

I tried all these things and none solved the problem:

IPQoS=throughput
ServerAliveInterval 30
ServerAliveCountMax 5
TCPKeepAlive yes

Looking forward for a solution...

Client and Server: OpenSSH_7.9p1 Debian-10+deb10u2

Server configuration /etc/ssh/sshd_config:
PermitRootLogin yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem   sftp/usr/lib/openssh/sftp-server
AllowUsers rover pepe

Client configuration:
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes

Regards,
-- 
Roberto Lumbreras
Debian developer

Bug#951154: prosody: ejabberd2prosody crashes

[Marvin Gülker]

Package: prosody
Version: 0.11.2-1
Severity: normal

Dear Maintainer,

the ejabberd2prosody script, which imports ejabberd data into prosody
with the goal of migrating from ejabberd to prosody, crashes. The
crash can be reproduced as followed:

0. Have ejabberd running with some users and their contacts.

1. Dump the existing ejabberd database:

 # ejabberdctl dump /tmp/dump.txt

2. Stop ejabberd and start prosody instead.

3. Try to import the dump.txt file with ejabberd2prosody:

 # ejabberd2prosody /tmp/dump.txt

The script then crashes with this error message:

   lua: /usr/lib/prosody/util/stanza.lua:27: module 'util.encodings' not found:
   no field package.preload['util.encodings']
   no file '/usr/local/share/lua/5.2/util/encodings.lua'
   no file '/usr/local/share/lua/5.2/util/encodings/init.lua'
   no file '/usr/local/lib/lua/5.2/util/encodings.lua'
   no file '/usr/local/lib/lua/5.2/util/encodings/init.lua'
   no file '/usr/share/lua/5.2/util/encodings.lua'
   no file '/usr/share/lua/5.2/util/encodings/init.lua'
   no file './util/encodings.lua'
   no file '/usr/lib/prosody/util/util/encodings.lua'
   no file '/usr/lib/prosody/util/encodings.lua'
   no file '/usr/bin/../util/encodings.lua'
   no file '/usr/bin/util/encodings.lua'
   no file '/usr/local/lib/lua/5.2/util/encodings.so'
   no file '/usr/lib/aarch64-linux-gnu/lua/5.2/util/encodings.so'
   no file '/usr/lib/lua/5.2/util/encodings.so'
   no file '/usr/local/lib/lua/5.2/loadall.so'
   no file './util/encodings.so'
   no file '/usr/bin/../util/encodings.so'
   no file '/usr/local/lib/lua/5.2/util.so'
   no file '/usr/lib/aarch64-linux-gnu/lua/5.2/util.so'
   no file '/usr/lib/lua/5.2/util.so'
   no file '/usr/local/lib/lua/5.2/loadall.so'
   no file './util.so'
   no file '/usr/bin/../util.so'
   stack traceback:
   [C]: in function 'require'
   /usr/lib/prosody/util/stanza.lua:27: in main chunk
   [C]: in function 'require'
   /usr/bin/ejabberd2prosody:28: in main chunk
   [C]: in ?

Expected result is that the script does not crash, but instead imports
the data into prosody successfully.

This was run on my Raspberry Pi 3B on an arm64 system.

-- System Information:
Debian Release: 10.3
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages prosody depends on:
ii  adduser 3.118
ii  libc6   2.28-10
ii  libidn111.33-2.2
ii  libssl1.1   1.1.1d-0+deb10u2
ii  lsb-base10.2019051400
ii  lua-bitop [lua5.2-bitop]1.0.2-5
ii  lua-expat [lua5.2-expat]1.3.0-4
ii  lua-filesystem [lua5.2-filesystem]  1.6.3-1
ii  lua-sec [lua5.2-sec]0.7-1
ii  lua-socket [lua5.2-socket]  3.0~rc1+git+ac3201d-4
ii  lua5.2  5.2.4-1.1+b2
ii  ssl-cert1.0.39

Versions of packages prosody recommends:
ii  lua-event [lua5.2-event]  0.4.6-1

Versions of packages prosody suggests:
pn  lua-dbi-mysql   
pn  lua-dbi-postgresql  
pn  lua-dbi-sqlite3 
pn  lua-zlib

-- Configuration Files:
/etc/prosody/conf.avail/example.com.cfg.lua [Errno 13] Keine Berechtigung: 
'/etc/prosody/conf.avail/example.com.cfg.lua'
/etc/prosody/conf.avail/localhost.cfg.lua [Errno 13] Keine Berechtigung: 
'/etc/prosody/conf.avail/localhost.cfg.lua'
/etc/prosody/prosody.cfg.lua [Errno 13] Keine Berechtigung: 
'/etc/prosody/prosody.cfg.lua'

-- no debconf information

Bug#951153: mhonarc: "Author Index" view includes link to "Author Index" instead of "Date Index"

[Ansgar]

Package: mhonarc
Version: 2.6.19-1
Severity: minor
Tags: upstream

https://lists.debian.org/debian-devel/2020/02/author.html includes the
links "[Thread Index] [Date Index] [Subject Index]" at the top, but
"[Thread Index] [Subject Index] [Author Index]" at the bottom.

The bottom should also link to "[Date Index]" instead of the redundant
"[Author Index]".

Ansgar

Bug#951152: new archmage version breaks keepass2 documentation build

[Julian Taylor]

Package: archmage
Version:  1:0.4.1-2
Severity: important
Tags: patch

The new archmage version breaks the documentation build of the keepass2
package.
This is due to the (maybe accidental) removal of the availity to render
html files from chm sources.

I have filed patch upstream to restore that ability:
https://github.com/dottedmag/archmage/pull/17

As it is required to update keepass2 and remove its python2 dependency,
could it be considered to add it to the package if upstream does not
react soon?

From 7591fd2427ebef2585347c7c567aa038a1fcab66 Mon Sep 17 00:00:00 2001
From: Julian Taylor 
Date: Sun, 9 Feb 2020 19:31:45 +0100
Subject: [PATCH] restore ability to render html from chm templates

add back the ability to export htlm files from chm templates via:

python3 -c 'import archmage.CHM; archmage.CHM.CHMFile("chmdir").process_templates("output")'

Closes gh-16
---
 archmage/CHM.py | 45 -
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/archmage/CHM.py b/archmage/CHM.py
index 93b0591..fbd37c4 100644
--- a/archmage/CHM.py
+++ b/archmage/CHM.py
@@ -82,16 +82,24 @@ class CHMFile:
 return self.cache['entries']
 
 def _entries(self):
-def get_name(chmfile, ui, out):
-path = ui.path.decode('utf-8')
-if path != '/':
-out.append(path)
-return chmlib.CHM_ENUMERATOR_CONTINUE
+if self._chm is None:
+entries = []
+for root, dirs, files in os.walk(self.sourcename):
+for f in files:
+fn = '/'.join((root.lstrip(self.sourcename), f))
+entries.append(fn)
+return entries
+else:
+def get_name(chmfile, ui, out):
+path = ui.path.decode('utf-8')
+if path != '/':
+out.append(path)
+return chmlib.CHM_ENUMERATOR_CONTINUE
 
-out = []
-if chmlib.chm_enumerate(self._chm, chmlib.CHM_ENUMERATE_ALL, get_name, out) == 0:
-sys.exit('UnknownError: CHMLIB or PyCHM bug?')
-return out
+out = []
+if chmlib.chm_enumerate(self._chm, chmlib.CHM_ENUMERATE_ALL, get_name, out) == 0:
+sys.exit('UnknownError: CHMLIB or PyCHM bug?')
+return out
 
 # retrieves the list of HTML files contained into the CHM file, **in order**
 # (that's the important bit).
@@ -327,14 +335,17 @@ class CHMEntry(object):
 
 def read(self):
 """Read CHM entry content"""
-result, ui = chmlib.chm_resolve_object(self.parent._chm, self.name.encode('utf-8'))
-if result != chmlib.CHM_RESOLVE_SUCCESS:
-return None
-
-size, content = chmlib.chm_retrieve_object(self.parent._chm, ui, 0, ui.length)
-if size == 0:
-return None
-return content
+if self.parent._chm:
+result, ui = chmlib.chm_resolve_object(self.parent._chm, self.name.encode('utf-8'))
+if result != chmlib.CHM_RESOLVE_SUCCESS:
+return None
+
+size, content = chmlib.chm_retrieve_object(self.parent._chm, ui, 0, ui.length)
+if size == 0:
+return None
+return content
+else:
+return open(self.parent.sourcename + self.name).read()
 
 def lower_links(self, text):
 """Links to lower case"""
-- 
2.20.1




signature.asc
Description: OpenPGP digital signature

Bug#949622: proftpd-basic: SSH authentication fails for many clients due to receiving of SSH_MSG_IGNORE packet

[Hilmar Preuße]

Am 11.02.2020 um 08:58 teilte Ghislain Adnet mit:

Hi Ghislain,

> the problem still exist for debian 9 and debian 8, is it possible to 
> backport the patch for those versions?
> 
I'm aware of the issue. However I did not considered yet to fix the
issue for oldstable (Debian 9). I had a look at porting the fix to
Debian stable, but failed until now.

If you have patches, let me know. The Fedora project could have patches,
but I'll have to have a closer look[1].

H.

[1] https://src.fedoraproject.org/rpms/proftpd/blob/HEAD/f/proftpd.spec
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#951150: kbd: psfaddtable: wrong output for maps containing sequences followed by non-sequences

[Thorsten Glaser]

Package: kbd
Version: 2.0.4-4
Severity: minor
Tags: upstream

With a Unicode map containing a line like this…

0xFFU+23B5 U+1234,U+5678 U+CAFE

… (of course, the codepoints are only examples) which follows
the format specification in kbd-2.0.4/src/psfxtable.c, the output
is wrong:

1790  b5 23 fe ff 34 12 78 56  fe ca ff ff  |.#..4.xV|

This is the output for…
0xFFU+23B5 U+1234,U+5678,U+CAFE
… while expected would have been:

1790  b5 23 fe ca fe ff 34 12  78 56 ff ff  |.#4.xV..|

This is caused by parse_itab_line() around lines 198‥204 not
checking if the current element is a sequnce or not first,
and blindly adding/mixing sequences and non-sequences to the
uclistheads, by using addpair() also for sequences, combined
with kbd-2.0.4/src/psffontop.c (which incidentally duplicates
addpair et al.) writepsffont, around lines 490‥500, not sorting
the codepoints before the sequences.

I discovered this during creating an independent PSF version 1
writer implementation. Mine basically goes through the map for
a given fontpos twice, first outputting every entry without a
comma, then every entry with.

Proof:

tglase@tglase-nb:/tmp $ tail -1 x.map
0xFFU+23B5 U+1234,U+5678 U+CAFE
tglase@tglase-nb:/tmp $ psfaddtable /usr/share/consolefonts/mirf16v8.psf x.map 
x.psfu
tglase@tglase-nb:/tmp $ psfgettable x.psfu | tail -1
0x0ff   U+23b5 U+1234, U+5678, U+cafe
tglase@tglase-nb:/tmp $ bdfctool -dp x.map x.psfu
tglase@tglase-nb:/tmp $ psfgettable x.psfu | tail -1
0x0ff   U+23b5 U+cafe U+1234, U+5678


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

Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages kbd depends on:
ii  libc6  2.29-10

Versions of packages kbd recommends:
ii  console-setup  2:11

kbd suggests no packages.

-- no debconf information

Bug#944922: postfix: Init script in 3.4.7-2 does not start all instances

[jaroslav]

On 11. 02. 20 19:33, Scott Kitterman wrote:
On Tuesday, February 11, 2020 12:35:16 PM EST jaros...@thinline.cz 
wrote:

On Sun, 12 Jan 2020 21:18:15 -0500 Scott Kitterman


wrote:

On Sun, 17 Nov 2019 12:04:46 -0600 Andy Dorman


wrote:

Package: postfix
Version: 3.4.7-2
Severity: normal

Dear Maintainer,

We have several servers that run three instances of postfix on our 
own


hardware (not in a virtual machine environment).

The enabled_instances() command from line 32 of the 
/etc/init.d/postfix


init


script shows the three instances:

Do you have multiple postfix master processes running?  If so, where
are they
located?

Can you tell me the value of queue_directory for each instance?

Scott K


I've set up a docker image where I can use sysv init with multiple
instances
and they all start/stop fine.  They were set up per the Postfix
MULTI_INSTANCE_README.  I am unable to replicate your problem.

If you have multiple master processes running (not the standard
configuration),
then I can see how the new version might fail, but I can't make
progress on
this bug without input from you.

Scott K


Hello,

we got hit by this too during 10.2 to 10.3 update. Hotfixed it by
replacing running() function from the previous version of the init
script. (More on that below.)

Could you please clarify how having multiple master processes running 
is
not the standard configuration? Our multiple instance setup was 
created

according to Postfix MULTI_INSTANCE_README using these:

postmulti -e init
postmulti -e create -I postfix-fwd

and there has always been one master process per instance (same 
binary,

but multiple processes spawning off it.) Even with systemd as init
system, there is one master process per instance (just tested on 
Postfix

   3.4.8-0+10debu1 on Debian 10.3)

About the running() function in the current 3.4.8 init script - in my
opinion its current form makes no sense. It's called with instance 
name

as parameter by the for cycle in start) and stop) cases for each
instance in the system. However, this line:

daemon_directory=$($POSTCONF -hx daemon_directory 2>/dev/null || echo
/usr/lib/postfix/sbin)

is always returning the same directory: /usr/lib/postfix/sbin ,
regardless of the parameter passed to the function. Subsequent call to
/usr/lib/postfix/sbin/master -t then yields result regardless of the
parameter as well: it always returns the state of the main Postfix
instance, not the instance being checked by the caller.

Was there a reason to change this function? Previous version from 
3.4.7
did the right thing here. Seemingly it even went beyong simple "pid 
file

exists" check that "master -t" does, and checked if the PID inside the
file exists and is Postfix's master process.

Also, considering this now affects stable and causes regression on
update, increasing severity might be warranted.


There are environments where the old approach didn't work.  I had 
intended to
work on this sooner, but ran out of time.  Changing priority won't give 
me
more time to work on Postfix in Debian.  This is the next thing I plan 
to do.


The current version replicates the upstream approach, but obviously 
something
else is different.  My intent is to got back to the previous version of 
the
function by default and only use the new one if /proc isn't accessible 
(which

is the original problem I was trying to solve).

Sorry for the inconvenience.

Scott K



Hello,

thanks for putting your time into this.

If it helps, I made a quick and dirty fix to the new approach

running() {
INSTANCE="$1"
if [ "X$INSTANCE" = X ]; then
POSTMULTI=""
else
POSTMULTI="postmulti -i $INSTANCE -x "
fi
POSTCONF="${POSTMULTI} postconf"

daemon_directory=$($POSTCONF -hx daemon_directory 2>/dev/null || 
echo /usr/lib/postfix/sbin)

if ! ${POSTMULTI} $daemon_directory/master -t 2>/dev/null ; then
echo y
fi
}

This way postmulti calls master (or any program) with some environment 
variables set, namely [1]:


MAIL_LOGTAG=postfix
MAIL_CONFIG=/etc/postfix-fwd
daemon_directory=/usr/lib/postfix/sbin
command_directory=/usr/sbin
config_directory=/etc/postfix-fwd
queue_directory=/var/spool/postfix-fwd
data_directory=/var/lib/postfix-fwd
multi_instance_name=postfix-fwd
multi_instance_group=
multi_instance_enable=yes

Apparently master process uses these and does the right thing, ie. looks 
for the pidfile in correct directory - see strace:


[pid  8180] chdir("/var/spool/postfix-fwd") = 0
[pid  8180] access("pid/master.pid", F_OK) = 0

I admit I have no idea whatsoever if this approach is correct, 
documented or supported. Just occured to me it might work and it did.


[1] postmulti -i postfix-fwd -x cat /proc/self/environ | tr "\0" "\n"

Bug#951151: polymake: test failure on mips64el

[David Bremner]

Package: polymake
Version: 4.0-2
Severity: serious
Justification: FTBFS


After building on mips64el, I get

 HOME=$(mktemp -p build -d) perl perl/polymake --script run_testcases 
--emacs-style
polymake:  WARNING: created private directory build/tmp.8rZQYU191i/.polymake

[snip]

[ /core/functions/Schemas/create_restrictive_schema ] 1
verifying: 1 OK
 [ /common/functions/Linear Algebra/det ] 1 2zsh: segmentation fault  
HOME=$(mktemp -p build -d) perl perl/polymake --script run_testcases

My naive attempt to get a backtrace just got the following:

rogram received signal SIGSEGV, Segmentation fault.
0x00fff786029c in _fmpz_poly_xgcd_modular () from 
/usr/lib/mips64el-linux-gnuabi64/libflint-2.5.2.so
(gdb) bt
#0  0x00fff786029c in _fmpz_poly_xgcd_modular () from 
/usr/lib/mips64el-linux-gnuabi64/libflint-2.5.2.so
#1  0x00fff7860294 in _fmpz_poly_xgcd_modular () from 
/usr/lib/mips64el-linux-gnuabi64/libflint-2.5.2.so
Backtrace stopped: frame did not save the PC

It looks like it's flint related? 

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

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

Versions of packages polymake depends on:
ii  libbliss2   0.73-2
ii  libc6   2.28-10
ii  libcdd0d094j-2
ii  libgcc1 1:8.3.0-6
ii  libgmp102:6.1.2+dfsg-4
ii  libgmpxx4ldbl   2:6.1.2+dfsg-4
ii  libgomp18.3.0-6
ii  liblrs0 0.70-3
ii  libmpfr64.0.2-1
ii  libnormaliz33.6.3+ds-1
ii  libpolymake-dev-common  3.2r4-4
ii  libppl141:1.2-7
ii  libstdc++6  8.3.0-6
ii  libxml2 2.9.4+dfsg1-7+b3
ii  ninja-build 1.8.2-1
ii  polymake-common 3.2r4-4

Versions of packages polymake recommends:
ii  chromium   79.0.3945.130-1~deb10u1
ii  gfan   0.6.2-2
ii  graphviz   2.40.1-6
ii  sketch 1:0.3.7-11
ii  xdg-utils  1.1.3-1

Versions of packages polymake suggests:
pn  povray
ii  texlive-pictures  2018.20190227-2

-- no debconf information

Bug#951144: libpam-cap: PAM unable to dlopen(pam_cap.so): /lib/security/pam_cap.so: cannot open shared object file

[Christian Kastner]

On 11.02.20 17:32, Francois Marier wrote:
> I see the following in my logs:
> 
>   Feb 11 07:39:22 hostname systemd: PAM unable to dlopen(pam_cap.so): 
> /lib/security/pam_cap.so: cannot open shared object file: No such file or 
> directory
>   Feb 11 07:39:22 hostname systemd: PAM adding faulty module: pam_cap.so
>   Feb 11 07:39:54 hostname systemd: PAM unable to dlopen(pam_cap.so): 
> /lib/security/pam_cap.so: cannot open shared object file: No such file or 
> directory
>   Feb 11 07:39:54 hostname systemd: PAM adding faulty module: pam_cap.so
> 
> Not sure why because the file is installed:
> 
>   $ ls -lh /lib/x86_64-linux-gnu/security/pam_cap.so
>   -rw-r--r-- 1 root root 14K Feb  9 05:52 
> /lib/x86_64-linux-gnu/security/pam_cap.so

I'm afraid that at this point, I don't know why you are seeing this.

I can reproduce the log message trivially (with sshd, didn't try
systemd) by moving pam_cap.so out of the way.

I would suspect an issue with the recent update form 2.27 to 2.31.
However, I just created a test entry in /etc/security/capability.conf,
and verified the results with capsh(1), and 2.31 worked as intended.

Bug#950851: runit: Obey policy-rc.d aka use invoke-rc.d to run statup/shutdown scripts

[Lorenzo Puliti]

Control: tag -1 moreinfo

Followup-For: Bug #950851
Package: src:runit

Hello,

> as in policy 9.3.3. Interfacing with init systems
> rc.d should not be called directly, but invoke-rc.d should be used.

9.3.3 talks about maintainerscripts, is this the case? 

> This allows one to control environment with policy-rc.d hack.
> 
> Unfortunatelly runit does not follow this rule, this lead to some unexpected 
> issues:
> 
> e.g.
> I want to run several process inside docker container (or other limited 
> environment):
> - I disable rc.d scripts with policy-rc.d
> - create /etc/sv config for daemons
> - set runit as entrypoint
> 
> But, unexpectedly, runit starts my other process with 
> /lib/runit/run_sysv_scripts

> [...]
> Init: systemd (via /run/systemd/system)
> [...]

I need more info to reproduce the issue; I'm not even sure I understand it
correctly. The fact that I've never used docker doesn't help, so please be
patient.

I've just read some (probably obsolete) documentation about docker
and I can make a guess:

* You have a systemd machine with runit (and maybe runit-systemd) installed
* You want to use runit as service manager inside docker
* when you start the docker image you end up with all services that are
  not managed with runit started with sysv script inside the container. 
  But you want only services started with runit.

Is the above correct?
Are you using /etc/runit/2 as an entrypoint?
Have you installed runit-init in the docker image, or just runit?
Is the version of runit 2.1.2-25?

Can you post details about the Dockerfile and the image you are using?

Thanks,
Lorenzo 

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: 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: runit (via /run/runit.stopit)

Bug#916260: gparted mounts partition without protection

[Marc Lehmann]

On Tue, Feb 11, 2020 at 09:18:30AM -0500, Phillip Susi  
wrote:
> > The effective permissions for a path depend on more than just the
> > permissions of the file it refers to. For example, a root-only readable
> > file can still be changed by normal users if the directory is writable for
> > them.
> 
> No, it can't.

Yes it can.

> If the directory is writable, then the user can modify the directory,
> i.e. to rm the file, but they can't modify the file itself.

When you recreate a file with different contents you have modified it.
Anything else is weird word twisting, and not useful in this context - it
doesn't matter how exactly I change a file, as long as I can change it
when I shouldn't be, it is a security bug.

> > effective permissions in ways not expected by the user, by mounting it in
> > an insecure location.
> 
> The only way it can change the effective permissions are if you normally
> have it mounted in a directory that uses the traverse/execute permission
> to restrict who can traverse it with the files inside otherwise having

No, there are other possibilities, but that is one way, yes.

> looser permissions, and that amounts to the same thing as just not
> keeping it mounted most of the time.

No, these are very different things.

> filesystem namespace so that it is only mounted to the one user and not
> visable to the rest of the system.  Either way, it begs the question:
> why not just set the permissions correctly instead?

Your question is loaded, because it presumes that the correct permissions
are somehow incorrect (a contradiction that any answer would have to
accept, which makes it impossible to answer your question). That is not
so, of course, which I have already pointed out (wehich begs the question
why you repeat this falsehood :).

> Come to think of it, maybe using filesystem namespaces would be a better
> idea than chmod()ing the /tmp mount point ( and then creating another
> subdirectory in which to actually mount the fs ).

A less portable, more complicated, but altogether valid solution, yes.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#950545: FTBFS against opencv 4.2.0

[Cesar Mauri]

Thanks for the patch. It works fine.


On Tue, Feb 11, 2020 at 4:30 PM Gianfranco Costamagna <
locutusofb...@debian.org> wrote:

> control: tags -1 patch
> control: forwarded -1 https://github.com/cmauri/eviacam/pull/24
>
>
> Hello, I did craft a patch to make it build, I didn't test but the patch
> was straightforward
> I also sent it upstream for consideration
>
> cheers,
>
> G.
>
>
> On Mon, 3 Feb 2020 12:30:54 + Mo Zhou  wrote:
> > Source: eviacam
> > Version: 2.1.4-1
> > Severity: serious
> >
> > Dear maintainer,
> >
> > eviacam FTBFS against the latest version of OpenCV:
> > https://buildd.debian.org/status/package.php?p=eviacam=sid
> >
> https://buildd.debian.org/status/fetch.php?pkg=eviacam=amd64=2.1.4-1%2Bb1=1580642132=0
> >
> > which looks due an API change at the first glance.
> >
> >
> > crvnormroi.cpp:449:35: error: cannot convert ‘cv::Size’ {aka
> ‘cv::Size_’} to ‘const CvSize&’
> >   449 |  SetP1ResizeInteger (pImg->GetSize(), x, y);
> >   |  ~^~
> >   |   |
> >   |   cv::Size {aka cv::Size_}
> > crvnormroi.cpp:359:50: note:   initializing argument 1 of ‘void
> CNormROI::SetP1ResizeInteger(const CvSize&, int, int)’
> >   359 | void CNormROI::SetP1ResizeInteger (const CvSize& size, const int
> x, const int y)
> >   |~~^~~~
> > crvnormroi.cpp: In member function ‘void CNormROI::SetP1MoveImg(const
> CIplImage*, int, int)’:
> > crvnormroi.cpp:457:33: error: cannot convert ‘cv::Size’ {aka
> ‘cv::Size_’} to ‘const CvSize&’
> >   457 |  SetP1MoveInteger (pImg->GetSize(), x, y);
> >   |~^~
> >   | |
> >   | cv::Size {aka cv::Size_}
> > crvnormroi.cpp:369:48: note:   initializing argument 1 of ‘void
> CNormROI::SetP1MoveInteger(const CvSize&, int, int)’
> >   369 | void CNormROI::SetP1MoveInteger (const CvSize& size, const int
> x, const int y)
> >   |  ~~^~~~
> > crvnormroi.cpp: In member function ‘void CNormROI::SetP2ResizeImg(const
> CIplImage*, int, int)’:
> > crvnormroi.cpp:465:35: error: cannot convert ‘cv::Size’ {aka
> ‘cv::Size_’} to ‘const CvSize&’
> >   465 |  SetP2ResizeInteger (pImg->GetSize(), x, y);
> >   |  ~^~
> >   |   |
> >   |   cv::Size {aka cv::Size_}
> > crvnormroi.cpp:379:50: note:   initializing argument 1 of ‘void
> CNormROI::SetP2ResizeInteger(const CvSize&, int, int)’
> >   379 | void CNormROI::SetP2ResizeInteger (const CvSize& size, const int
> x, const int y)
> >   |~~^~~~
> > crvnormroi.cpp: In member function ‘void CNormROI::SetCenterImg(const
> CIplImage*, int, int)’:
> > crvnormroi.cpp:473:33: error: cannot convert ‘cv::Size’ {aka
> ‘cv::Size_’} to ‘const CvSize&’
> >   473 |  SetCenterInteger (pImg->GetSize(), x, y);
> >   |~^~
> >   | |
> >   | cv::Size {aka cv::Size_}
> > crvnormroi.cpp:389:48: note:   initializing argument 1 of ‘void
> CNormROI::SetCenterInteger(const CvSize&, int, int)’
> >   389 | void CNormROI::SetCenterInteger (const CvSize& size, const int
> x, const int y)
> >   |  ~~^~~~
> > crvnormroi.cpp: In member function ‘void CNormROI::GetCenterImg(const
> CIplImage*, int&, int&)’:
> > crvnormroi.cpp:481:33: error: cannot convert ‘cv::Size’ {aka
> ‘cv::Size_’} to ‘const CvSize&’
> >   481 |  GetCenterInteger (pImg->GetSize(), x, y);
> >   |~^~
> >   | |
> >   | cv::Size {aka cv::Size_}
> > crvnormroi.cpp:398:48: note:   initializing argument 1 of ‘void
> CNormROI::GetCenterInteger(const CvSize&, int&, int&)’
> >   398 | void CNormROI::GetCenterInteger (const CvSize& size, int& x,
> int& y)
> >   |  ~~^~~~
> > crvnormroi.cpp: In member function ‘void CNormROI::SetSizeImg(const
> CIplImage*, int, int)’:
> > crvnormroi.cpp:489:31: error: cannot convert ‘cv::Size’ {aka
> ‘cv::Size_’} to ‘const CvSize&’
> >   489 |  SetSizeInteger (pImg->GetSize(), width, height);
>

Bug#951149: libreoffice-base: Missing versioned dependency on dpkg?

[Peter Eckersley]

Package: libreoffice-base
Version: 1:6.3.4-2
Severity: normal

This may affect people upgrading packages piecemeal:

sudo apt-get -f install
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
   (XYZ)
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  libreoffice-base
Suggested packages:
  unixodbc
The following NEW packages will be installed:
  libreoffice-base
0 upgraded, 1 newly installed, 0 to remove and 2080 not upgraded.
22 not fully installed or removed.
Need to get 0 B/1,621 kB of archives.
After this operation, 6,088 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
(Reading database ... 405556 files and directories currently installed.)
Preparing to unpack .../libreoffice-base_1%3a6.4.1~rc1-2_amd64.deb ...
dpkg-divert: error: unknown option --no-rename


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

Kernel: Linux 5.4.0-2-amd64 (SMP w/4 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)
LSM: AppArmor: enabled

Versions of packages libreoffice-base depends on:
ii  libc6  2.29-6
ii  libgcc-s1  10-20200204-1
ii  libgcc11:9.2.1-21
pn  libreoffice-base-core  
pn  libreoffice-base-drivers   
ii  libreoffice-common 1:6.4.1~rc1-2
pn  libreoffice-core   
pn  libreoffice-core | libreoffice-core-nogui  
ii  libstdc++6 9.2.1-21
ii  libuno-cppu3   1:6.4.0-1
ii  libuno-cppuhelpergcc3-31:6.4.0-1
ii  libuno-sal31:6.4.0-1
ii  libuno-salhelpergcc3-3 1:6.4.0-1
ii  uno-libs-private   1:6.4.0-1
pn  uno-libs3  
ii  ure1:6.4.0-1

Versions of packages libreoffice-base recommends:
ii  default-jre [java8-runtime]2:1.8-59
ii  libreoffice-java-common1:6.4.1~rc1-2
pn  libreoffice-writer 
ii  openjdk-8-jre [java8-runtime]  8u242-b08-1

Versions of packages libreoffice-base suggests:
pn  libreoffice-report-builder  
pn  python3-uno 
pn  unixodbc

Bug#951148: RFS: par2cmdline/0.8.1-1 -- PAR 2.0 compatible file verification and repair tool

[JCF Ploemen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for "par2cmdline":
  Package name: par2cmdline
  Version : 0.8.1-1
  Upstream Author : Ike Devolder et al.
  URL : https://github.com/Parchive/par2cmdline
  License : GPL-2+
  Section : utils

It builds a single binary package:
  par2 - PAR 2.0 compatible file verification and repair tool

Mentors URL:
  https://mentors.debian.net/package/par2cmdline

Download:
  dget -x 
https://mentors.debian.net/debian/pool/main/p/par2cmdline/par2cmdline_0.8.1-1.dsc

Changes since the last upload:
  * New upstream release.
  * Patches:
+ refresh 01 to remove fuzz.
+ add 02_fix_syntax_error_in_tests.
  * Rules: drop redundant '--with autoreconf' from dh sequencer.
  * Bump Standards-Version to 4.5.0 (from 4.4.1; no further changes).
  * Copyright: refresh upstream years, add new author.


Thanks!


pgpZbL0lZcPCo.pgp
Description: OpenPGP digital signature

Bug#944922: postfix: Init script in 3.4.7-2 does not start all instances

[Scott Kitterman]

On Tuesday, February 11, 2020 12:35:16 PM EST jaros...@thinline.cz wrote:
> > On Sun, 12 Jan 2020 21:18:15 -0500 Scott Kitterman
> > 
> > 
> > wrote:
> >> On Sun, 17 Nov 2019 12:04:46 -0600 Andy Dorman
> >> 
> >> 
> >> wrote:
> >> > Package: postfix
> >> > Version: 3.4.7-2
> >> > Severity: normal
> >> > 
> >> > Dear Maintainer,
> >> > 
> >> > We have several servers that run three instances of postfix on our own
> >> 
> >> hardware (not in a virtual machine environment).
> >> 
> >> > The enabled_instances() command from line 32 of the /etc/init.d/postfix
> > 
> > init
> > 
> >> script shows the three instances:
> >> 
> >> Do you have multiple postfix master processes running?  If so, where
> >> are they
> >> located?
> >> 
> >> Can you tell me the value of queue_directory for each instance?
> >> 
> >> Scott K
> > 
> > I've set up a docker image where I can use sysv init with multiple
> > instances
> > and they all start/stop fine.  They were set up per the Postfix
> > MULTI_INSTANCE_README.  I am unable to replicate your problem.
> > 
> > If you have multiple master processes running (not the standard
> > configuration),
> > then I can see how the new version might fail, but I can't make
> > progress on
> > this bug without input from you.
> > 
> > Scott K
> 
> Hello,
> 
> we got hit by this too during 10.2 to 10.3 update. Hotfixed it by
> replacing running() function from the previous version of the init
> script. (More on that below.)
> 
> Could you please clarify how having multiple master processes running is
> not the standard configuration? Our multiple instance setup was created
> according to Postfix MULTI_INSTANCE_README using these:
> 
> postmulti -e init
> postmulti -e create -I postfix-fwd
> 
> and there has always been one master process per instance (same binary,
> but multiple processes spawning off it.) Even with systemd as init
> system, there is one master process per instance (just tested on Postfix
>   3.4.8-0+10debu1 on Debian 10.3)
> 
> About the running() function in the current 3.4.8 init script - in my
> opinion its current form makes no sense. It's called with instance name
> as parameter by the for cycle in start) and stop) cases for each
> instance in the system. However, this line:
> 
> daemon_directory=$($POSTCONF -hx daemon_directory 2>/dev/null || echo
> /usr/lib/postfix/sbin)
> 
> is always returning the same directory: /usr/lib/postfix/sbin ,
> regardless of the parameter passed to the function. Subsequent call to
> /usr/lib/postfix/sbin/master -t then yields result regardless of the
> parameter as well: it always returns the state of the main Postfix
> instance, not the instance being checked by the caller.
> 
> Was there a reason to change this function? Previous version from 3.4.7
> did the right thing here. Seemingly it even went beyong simple "pid file
> exists" check that "master -t" does, and checked if the PID inside the
> file exists and is Postfix's master process.
> 
> Also, considering this now affects stable and causes regression on
> update, increasing severity might be warranted.

There are environments where the old approach didn't work.  I had intended to 
work on this sooner, but ran out of time.  Changing priority won't give me 
more time to work on Postfix in Debian.  This is the next thing I plan to do.

The current version replicates the upstream approach, but obviously something 
else is different.  My intent is to got back to the previous version of the 
function by default and only use the new one if /proc isn't accessible (which 
is the original problem I was trying to solve).

Sorry for the inconvenience.

Scott K



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

Bug#401368: audacity: does not create mp3 header

[Dennis Braun]

Version: 2.3.3-1

it creates a header somehow, i can read it with rightclick in nautilus >
preferences > audio.
but with id3v2 it still can't be read, it says "No ID3 tag"...



signature.asc
Description: OpenPGP digital signature

Bug#950707: closed by Sergey B Kirpichev (reply to skirpic...@gmail.com) (Re: [monit] Depends: libcrypt1 (>= 1:4.1.0) but it is not going to be installed)

[Jean-Marc LACROIX]

Dear Sergey,

It seems that on Debian 10.3, monit is now available without any 
issue...because


ansible@srv-mmonit-110:~$ dpkg -l |grep monit
ansible@srv-mmonit-110:~$ cat /etc/debian_version
10.3

I have taken into account your recommendation regarding the backports 
package.


Now, my preferences are :

ansible@srv-mmonit-110:~$ grep P 
/etc/apt/preferences.d/preferences_debian_v_10_buster.pref  |grep -v "#"

Package: *
Pin: release o=Debian,l=Debian,n=buster/updates
Pin-Priority: 920
Package: *
Pin: release o=Debian,l=Debian,n=buster-update
Pin-Priority: 910
Package: *
Pin: release o=Debian,l=Debian,n=buster
Pin-Priority: 900
Package: *
Pin: release o=Debian,l=Debian,n=buster-backports
Pin-Priority: 905
Package: *
Pin: release o=Debian,l=Debian,n=stretch
Pin-Priority: 400
Package: *
Pin: release o=Debian,l=Debian,n=testing
Pin-Priority: -1
Package: *
Pin: release o=Debian,l=Debian,n=unstable
Pin-Priority: -1
Package: udev
Pin: release o=Debian,l=Debian,n=*
Pin-Priority: -1

and when i install monit

ansible@srv-mmonit-110:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
ansible@srv-mmonit-110:~$ deborphan
ansible@srv-mmonit-110:~$ sudo apt install monit
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  exim4 | postfix | mail-transport-agent
The following NEW packages will be installed:
  monit
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 296 kB of archives.
After this operation, 762 kB of additional disk space will be used.
Get:1 http://ftp.debian.org/debian stretch/main armhf monit armhf 
1:5.20.0-6+deb9u1 [296 kB]

Fetched 296 kB in 0s (9105 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package monit.
(Reading database ... 20938 files and directories currently installed.)
Preparing to unpack .../monit_1%3a5.20.0-6+deb9u1_armhf.deb ...
Unpacking monit (1:5.20.0-6+deb9u1) ...
Setting up monit (1:5.20.0-6+deb9u1) ...
[ ok ] Starting daemon monitor: monit.
ansible@srv-mmonit-110:~$


I don't understand why i install the stretch release, (because pining!),
but for my point of view, the problem is solved !

Regards

Le 2/5/20 à 2:09 PM, Debian Bug Tracking System a écrit :

This is an automatic notification regarding your Bug report
which was filed against the monit package:

#950707: [monit] Depends: libcrypt1 (>= 1:4.1.0) but it is not going to be 
installed

It has been closed by Sergey B Kirpichev  (reply to 
skirpic...@gmail.com).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Sergey B Kirpichev 
 (reply to skirpic...@gmail.com) by
replying to this email.

Bug#944922: postfix: Init script in 3.4.7-2 does not start all instances

[jaroslav]

On Sun, 12 Jan 2020 21:18:15 -0500 Scott Kitterman 


wrote:
On Sun, 17 Nov 2019 12:04:46 -0600 Andy Dorman 


wrote:
> Package: postfix
> Version: 3.4.7-2
> Severity: normal
>
> Dear Maintainer,
>
> We have several servers that run three instances of postfix on our own
hardware (not in a virtual machine environment).
>
> The enabled_instances() command from line 32 of the /etc/init.d/postfix

init

script shows the three instances:

Do you have multiple postfix master processes running?  If so, where 
are they

located?

Can you tell me the value of queue_directory for each instance?

Scott K


I've set up a docker image where I can use sysv init with multiple 
instances

and they all start/stop fine.  They were set up per the Postfix
MULTI_INSTANCE_README.  I am unable to replicate your problem.

If you have multiple master processes running (not the standard 
configuration),
then I can see how the new version might fail, but I can't make 
progress on

this bug without input from you.

Scott K


Hello,

we got hit by this too during 10.2 to 10.3 update. Hotfixed it by 
replacing running() function from the previous version of the init 
script. (More on that below.)


Could you please clarify how having multiple master processes running is 
not the standard configuration? Our multiple instance setup was created 
according to Postfix MULTI_INSTANCE_README using these:


postmulti -e init
postmulti -e create -I postfix-fwd

and there has always been one master process per instance (same binary, 
but multiple processes spawning off it.) Even with systemd as init 
system, there is one master process per instance (just tested on Postfix 
 3.4.8-0+10debu1 on Debian 10.3)


About the running() function in the current 3.4.8 init script - in my 
opinion its current form makes no sense. It's called with instance name 
as parameter by the for cycle in start) and stop) cases for each 
instance in the system. However, this line:


daemon_directory=$($POSTCONF -hx daemon_directory 2>/dev/null || echo 
/usr/lib/postfix/sbin)


is always returning the same directory: /usr/lib/postfix/sbin , 
regardless of the parameter passed to the function. Subsequent call to 
/usr/lib/postfix/sbin/master -t then yields result regardless of the 
parameter as well: it always returns the state of the main Postfix 
instance, not the instance being checked by the caller.


Was there a reason to change this function? Previous version from 3.4.7 
did the right thing here. Seemingly it even went beyong simple "pid file 
exists" check that "master -t" does, and checked if the PID inside the 
file exists and is Postfix's master process.


Also, considering this now affects stable and causes regression on 
update, increasing severity might be warranted.

Bug#951147: /sbin/lvm: error in 'man pvdisplay'

[tkoeck]

Package: lvm2
Version: 2.03.02-3
Severity: minor
File: /sbin/lvm

Dear Maintainer,

in the man page of pvdisplay it says

---
   pvs(8) is a preferred alternative that shows the same
   information  and
  more, using a more compact and configurable output format.
---

but for instance I cannot see an option to show the PE size with the pvs
command.

So pvs doesn't seem to show exactly the same information? Wouldn't it be
good to add at least the PE size to pvs to be able to substitute
pvdisplay?

Greetings,
Tobias

-- System Information:
Debian Release: 10.3
  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/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-3
ii  dmsetup   2:1.02.155-3
ii  libaio1   0.3.112-3
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-10
ii  libdevmapper-event1.02.1  2:1.02.155-3
ii  libdevmapper1.02.12:1.02.155-3
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-7~deb10u3
ii  libudev1  241-7~deb10u3
ii  lsb-base  10.2019051400

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.7.6-2.1

lvm2 suggests no packages.

-- no debconf information

Bug#951145: jove: [INTL:it] Updated Italian translation of debconf messages

[Beatrice Torracca]

Package: jove
Severity: wishlist
Tags: l10n patch

Hi.

Please find attached the updated Italian translation of jove debconf messages
proofread by the Italian localization team.

Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of jove debconf messages
# Copyright (C) 2020, jove package copyright holder
# This file is distributed under the same license as the jove package.
# Beatrice Torracca , 2020.
msgid ""
msgstr ""
"Project-Id-Version: jove\n"
"Report-Msgid-Bugs-To: j...@packages.debian.org\n"
"POT-Creation-Date: 2020-02-04 22:52+0100\n"
"PO-Revision-Date: 2020-02-11 17:25+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.4\n"

#. Type: note
#. Description
#: ../jove.templates:1001
msgid "Found old version of /etc/jove.rc. Moved it to /etc/jove/jove.rc"
msgstr ""
"Trovata una vecchia versione di /etc/jove.rc. Spostata in /etc/jove/jove.rc"

#. Type: note
#. Description
#: ../jove.templates:2001
msgid "Old version of /etc/jove.rc and new version /etc/jove/jove.rc found"
msgstr ""
"Trovate una vecchia versione di /etc/jove.rc e una nuova in /etc/jove/jove.rc"

#. Type: note
#. Description
#: ../jove.templates:2001
msgid "Moving old version to /etc/jove/jove.rc.old"
msgstr "La vecchia versione viene spostata in /etc/jove/jove.rc.old"

#. Type: note
#. Description
#: ../jove.templates:3001
msgid "Removed obsolete /etc/init.d/jove script"
msgstr "Rimosso lo script obsoleto /etc/init.d/jove"

#. Type: note
#. Description
#: ../jove.templates:3001
msgid "Check NEWS.Debian for more information"
msgstr "Controllare NEWS.Debian per maggiori informazioni."

#. Type: note
#. Description
#: ../jove.templates:4001
msgid "Found old files in /var/lib/jove/preserve/"
msgstr "Trovati vecchi file in /var/lib/jove/preserve/"

#. Type: note
#. Description
#: ../jove.templates:4001
msgid ""
"You can recover those by running jove -r Check NEWS.Debian for more "
"information."
msgstr ""
"Possono essere recuperati eseguendo jove -r. Controllare NEWS.Debian per "
"maggiori informazioni."

Bug#951146: buster-pu: package rootskel/1.131+10u1

[Steve McIntyre]

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

Hi folks,

We released buster with a new feature in d-i: support for running d-i
on multiple consoles. This is very useful on some systems (e.g. arm64
machines with both serial console and normal graphical console), but
had an unexpected side-effect: preseeded installations with more than
one console defined would end up trying to run the preseeded d-i on
all the consoles in parallel, with unpredictable behaviour. See
#940028, #932416.

I've added a workaround/fix for this in unstable already, in rootskel
1.132. Here's a debdiff which just cherry-picks that one fix into a
1.131+10u1 for a buster upload. We'd like to fix this for the 10.4
point release.

I've already got kibi's ACK for this.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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
diff -Nru rootskel-1.131/debian/changelog rootskel-1.131+10u1/debian/changelog
--- rootskel-1.131/debian/changelog 2019-06-13 20:28:44.0 +0100
+++ rootskel-1.131+10u1/debian/changelog2020-02-11 16:33:42.0 
+
@@ -1,3 +1,15 @@
+rootskel (1.131+10u1) buster; urgency=medium
+
+  [ Steve McIntyre ]
+  * Backport fix from unstable:
+Tweak how multiple consoles are used. If we detect that we're
+trying to run using preseeding, do *not* run on multiple consoles
+in parallel as that causes race conditions and weird
+behaviour. Instead, just run on the "preferred" console. Hopefully
+Closes: #940028, #932416
+
+ -- Steve McIntyre <93...@debian.org>  Tue, 11 Feb 2020 16:33:54 +
+
 rootskel (1.131) unstable; urgency=medium
 
   * Team upload
diff -Nru rootskel-1.131/src/sbin/reopen-console-linux 
rootskel-1.131+10u1/src/sbin/reopen-console-linux
--- rootskel-1.131/src/sbin/reopen-console-linux2019-06-02 
12:29:14.0 +0100
+++ rootskel-1.131+10u1/src/sbin/reopen-console-linux   2020-02-11 
16:28:51.0 +
@@ -16,6 +16,17 @@
 LOGGER_UP=0
 LOG_FILE=/var/log/reopen-console
 
+# If we're running with preseeding, we have a problem with running d-i
+# on multiple consoles. We'll end up running each of those d-i
+# instances in parallel with all kinds of hilarious undefined
+# behaviour as they trip over each other! If we detect that we're
+# preseeding (via any of the possible preseed methods), DO NOT run d-i
+# multiple times. Instead, fall back to the older, more simple
+# behaviour and run it once. If the user wants to see or interact with
+# their preseed on a specific console, they get to tell us which one
+# they want to use.
+PRESEEDING=0
+
 log() {
# In very early startup we don't have syslog. Log to file that
# we can flush out later so we can at least see what happened
@@ -32,6 +43,20 @@
rm $LOG_FILE
 }
 
+# If we have a preseed.cfg in the initramfs
+if [ -e /preseed.cfg ]; then
+log "Found /preseed.cfg; falling back to simple mode for preseeding"
+PRESEEDING=1
+fi
+
+# Have we been told to do preseeding stuff on the boot command line?
+for WORD in auto url; do
+if (grep -qw "$WORD" /proc/cmdline); then
+   log "Found \"$WORD\" in the command line; falling back to simple mode 
for preseeding"
+   PRESEEDING=1
+fi
+done
+
 consoles=
 preferred=
 # Retrieve all enabled consoles from kernel; ignore those
@@ -44,7 +69,7 @@
status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e 's/(^.*) 
*.*\((.*)\).*$/\2/p' )
if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ]; then
consoles="${consoles:+$consoles$NL}$cons"
-   log "   Adding $cons to consoles list"
+   log "   Adding $cons to possible consoles list"
fi
# 'C' console is 'most prefered'.
if [ $(echo "$status" | grep -o 'C') ]; then
@@ -64,6 +89,13 @@
log "Found no preferred console. Picking $preferred"
 fi
 
+# If we're preseeding, do simple stuff here (see above). We just
+# want one console. Let's pick the preferred one ONLY
+if [ $PRESEEDING = 1 ]; then
+log "Running with preseeding. Picking preferred $preferred ONLY"
+consoles=$preferred
+fi
+
 for cons in $consoles
 do
echo "/dev/$cons " >> /var/run/console-devices
@@ -88,7 +120,7 @@
 flush_logger
 
 # Finally restart init to run debian-installer on discovered consoles
-log "Restarting init to start d-i on the consoles we found"
+log "Restarting init to start d-i on the console(s) we found"
 kill -HUP 1
 
 exit 0

Bug#951111: libreoffice: it is impossible to saveas in a directory unless it is a leaf directory

[Rene Engelhard]

tag 95 + moreinfo
tag 95 + unreproducible
thanks

On Tue, Feb 11, 2020 at 10:38:31AM +0100, fulvio ciriaco wrote:
> The saveas dialog always select the first subdirectory of the current one,
> if I press  the dialogue simple brings me to the next subdirectory.

Can't reproduce this. Tried with "gen" ("use LibreOffice dialogs" in the
options, gtk3 and kde5).

> I freshly installed libreoffice 6.4.0 from  
> LibreOffice_6.4.0_Linux_x86-64_rpm.tar.gz
> at the libreoffice site and it behaves correctly, i.e. there is no 
> subdirectory
> autoselection.

And comparing apples with pies doesn't help. And we don't patch that
code. 

What desktop are you on? Which UI setting? (See Tools->About, maybe, if
you have no clue). Did you force gtk2 somehow and this is an other
incarnation of #951060.

Regards,

Rene

Bug#820081: libreoffice-writer: can't open LibreOffice Writer

[Rene Engelhard]

On Mon, Feb 10, 2020 at 05:45:30PM +0100, Jan Jona Javoršek wrote:
>I can confirm the same bug with the now current 6.1.5-3+rpi1+deb10u5

And this is not raspbian. And in Debian there's no +rpi1+

>I can attach strace and package info if necessary, but it looks related to
>gtk3 theme integration.

Honestly, I don't care, unless it happens with proper Debian, too.

And then it'd be important if it happens with default theme or whether
you use a special(tm) theme. Since there was no overwhelming reports of
it not starting since the buster release, I'd assume - if it happens at
all - doesn*'t happen all times.

Regards,

Rene

Bug#951144: libpam-cap: PAM unable to dlopen(pam_cap.so): /lib/security/pam_cap.so: cannot open shared object file

[Francois Marier]

Package: libpam-cap
Version: 1:2.31-1
Severity: normal

I see the following in my logs:

  Feb 11 07:39:22 hostname systemd: PAM unable to dlopen(pam_cap.so): 
/lib/security/pam_cap.so: cannot open shared object file: No such file or 
directory
  Feb 11 07:39:22 hostname systemd: PAM adding faulty module: pam_cap.so
  Feb 11 07:39:54 hostname systemd: PAM unable to dlopen(pam_cap.so): 
/lib/security/pam_cap.so: cannot open shared object file: No such file or 
directory
  Feb 11 07:39:54 hostname systemd: PAM adding faulty module: pam_cap.so

Not sure why because the file is installed:

  $ ls -lh /lib/x86_64-linux-gnu/security/pam_cap.so
  -rw-r--r-- 1 root root 14K Feb  9 05:52 
/lib/x86_64-linux-gnu/security/pam_cap.so

Francois

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

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

Versions of packages libpam-cap depends on:
ii  libc6   2.29-10
ii  libcap2 1:2.31-1
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5

libpam-cap recommends no packages.

libpam-cap suggests no packages.

-- no debconf information

-- 
https://fmarier.org/

Bug#951142: mwic: Please package new upstream version (0.7.8)

[Georg Faerber]

Hi Boyuan,

On 20-02-11 11:20:11, Boyuan Yang wrote:
> The upstream mwic developers have already release a new version of
> mwic. Please upload the new version in Debian.

Thanks for asking.

> Since I am also a member of the Debian Python Modules Team, I might be
> uploading one with a deferred upload.

I'll handle this within the next days, up until end of February.

Cheers,
Georg

Bug#951143: bluefish: Please migrate to enchant-2

[Boyuan Yang]

Source: bluefish
Version: 2.2.10-3
Severity: important
Control: block 947979 by -1

Dear bluefish maintainer,

Your package is affected by an ongoing transition from enchant(1) to enchant-
2. You may find the transition information at 
https://release.debian.org/transitions/html/enchant-2.html and 
https://bugs.debian.org/947979 .

Current bluefish source code in Debian does not support enchant-2 yet. Please
consider working with upstream for a complete enchant-2 support.

-- 
Thanks,
Boyuan Yang


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

Bug#951142: mwic: Please package new upstream version (0.7.8)

[Boyuan Yang]

Source: mwic
Version: 0.7.7-1
Severity: normal
X-Debbugs-CC: ge...@riseup.net

Dear mwic maintainers,

The upstream mwic developers have already release a new version of mwic.
Please upload the new version in Debian.

Since I am also a member of the Debian Python Modules Team, I might be
uploading one with a deferred upload.

-- 
Thanks,
Boyuan Yang


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

Bug#951141: syncthing-relaysrv: Allow configuration with /etc/default/syncthing-relaysrv

[no real name]

Package: syncthing-relaysrv
Version: 1.0.0~ds1-1+b11
Severity: important

Dear Maintainer,

I wanted to use other commendlineoptions of strelaysrv then "-nat". So I wrote 
in /etc/default/syncthing-relaysrv something like 

STRELAYSRV_OPTS='-pools="" -listen="0.0.0.0:23456"'

After that, syncthing-relaysrv won't start.

I think, there should be a way to start strelaysrv for example with the 
following options:

strelaysrv -pools="" -listen="0.0.0.0:23456"

best regards


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

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

Versions of packages syncthing-relaysrv depends on:
ii  adduser  3.118
ii  libc62.28-10

syncthing-relaysrv recommends no packages.

syncthing-relaysrv suggests no packages.

-- Configuration Files:
/etc/default/syncthing-relaysrv changed:
NAT=false
STRELAYSRV_OPTS=-pools=


-- no debconf information

Bug#951140: geany-plugins: Please switch from enchant(1) to enchant-2

[Boyuan Yang]

Source: geany-plugins
Severity: important
Version: 1.36+dfsg-1
X-Debbugs-CC: hyper...@debian.org evg...@debian.org
Control: block 947979 by -1

Dear geany-plugins maintainers,

Your package is affected by an ongoing transition from enchant(1) to enchant-
2. You may find the transition information at 
https://release.debian.org/transitions/html/enchant-2.html .

The upstream geany-plugins developers already supported enchant-2 so I guess
all you need is to switch the build-dependency and make tests to ensure
everything is ok.

-- 
Best,
Boyuan Yang


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

Bug#951139: toil fails it's autopkg tests

[Matthias Klose]

Package: src:toil
Version: 3.23.1-1
Severity: serious
Tags: sid bullseye

seen in https://ci.debian.net/packages/t/toil
toil fails it's autopkg tests

[...]
autopkgtest [19:11:47]: test smoke-test: [---
Traceback (most recent call last):
  File "/usr/bin/toil", line 11, in 
load_entry_point('toil==3.18.0', 'console_scripts', 'toil')()
  File "/usr/lib/python3/dist-packages/toil/utils/toilMain.py", line 13, in main
modules = loadModules()
  File "/usr/lib/python3/dist-packages/toil/utils/toilMain.py", line 39, in
loadModules
from toil.utils import (toilKill,
  File "/usr/lib/python3/dist-packages/toil/utils/toilStatus.py", line 34, in

from toil.jobStores.abstractJobStore import NoSuchJobStoreException,
NoSuchFileException
  File "/usr/lib/python3/dist-packages/toil/jobStores/abstractJobStore.py", line
39, in 
from toil.job import JobException
  File "/usr/lib/python3/dist-packages/toil/job.py", line 51, in 
from toil.deferred import DeferredFunction
  File "/usr/lib/python3/dist-packages/toil/deferred.py", line 34, in 
from toil.resource import ModuleDescriptor
  File "/usr/lib/python3/dist-packages/toil/resource.py", line 43, in 
from toil.version import exactPython
ImportError: cannot import name 'exactPython' from 'toil.version'
(/usr/lib/python3/dist-packages/toil/version.py)
autopkgtest [19:11:48]: test smoke-test: ---]
autopkgtest [19:11:48]: test smoke-test:  - - - - - - - - - - results - - - - -
- - - - -
smoke-test   FAIL non-zero exit status 1
autopkgtest [19:11:48]: test smoke-test:  - - - - - - - - - - stderr - - - - - -
- - - -
Traceback (most recent call last):
  File "/usr/bin/toil", line 11, in 
load_entry_point('toil==3.18.0', 'console_scripts', 'toil')()
  File "/usr/lib/python3/dist-packages/toil/utils/toilMain.py", line 13, in main
modules = loadModules()
  File "/usr/lib/python3/dist-packages/toil/utils/toilMain.py", line 39, in
loadModules
from toil.utils import (toilKill,
  File "/usr/lib/python3/dist-packages/toil/utils/toilStatus.py", line 34, in

from toil.jobStores.abstractJobStore import NoSuchJobStoreException,
NoSuchFileException
  File "/usr/lib/python3/dist-packages/toil/jobStores/abstractJobStore.py", line
39, in 
from toil.job import JobException
  File "/usr/lib/python3/dist-packages/toil/job.py", line 51, in 
from toil.deferred import DeferredFunction
  File "/usr/lib/python3/dist-packages/toil/deferred.py", line 34, in 
from toil.resource import ModuleDescriptor
  File "/usr/lib/python3/dist-packages/toil/resource.py", line 43, in 
from toil.version import exactPython
ImportError: cannot import name 'exactPython' from 'toil.version'
(/usr/lib/python3/dist-packages/toil/version.py)
autopkgtest [19:11:48]:  summary
smoke-test   FAIL non-zero exit status 1

Bug#949518: [pkg-netfilter-team] Bug#949518: (no subject)

[Alberto Molina Coballes]

El mar., 11 feb. 2020 a las 14:03, Vasanth Srivatsa ()
escribió:

> Is this bug fixed or still open? When can users expect a fix (approximate
> time)? I have servers which are non-functional due to this bug. I just
> updated them yesterday and they are blocking all incoming connections.
>

Hi Vasanth,

This is not a debian specific bug, but an upstream one related to iptables
1.8.4 that affects the way ufw is using iptables-restore and Jamie
Strandboge has opened a bug on netfilter as mentioned before (thanks Jamie!)

In the meanwhile, the workaround is configure iptables to use
iptables-legacy:

update-alternatives --config iptables
update-alternatives --config ip6tables

Regards,

Alberto

Bug#951130: RM: reel/0.6.1-4

[Utkarsh Gupta]

reassign 951130 ftp.debian.org
user pkg-ruby-extras-maintain...@lists.alioth.debian.org
usertags 951130 + ruby2.7-transition
thanks

On Tue, Feb 11, 2020 at 9:39 AM Adam D. Barratt 
wrote:

> This sounds like you want the package removing from unstable?
>

Ah, yes. Fixed.
Thanks!


Best,
Utkarsh

Bug#883893: digikam: freezing when using geolocation editor

[mgrocha]

I am triaging some digikam bugs. I tried to reproduce this problem with both
4:5.9.0-1 (currently in Debian stable) and 4:6.4.0+dfsg-2 (currently in
Debian sid), but I could not reproduce it at all.

Please confirm if this is still a problem for you. Otherwise this bug report
will be closed.


Hi,

Thank you for asking. I couldn't reproduce the problem either 
(4:5.9.0-1). Guess it's time to close this bug.


Thanks again

Michael

Bug#864242: acct monthly cron fails if /var/log/wtmp rotation has not happened

[Tomáš Szaniszlo]

Package: acct
Version: 6.6.4-2
Followup-For: Bug #864242

In my case I see that although I have logrotate installed, its wtmp
configuration is such that the rotation happens only if its size
exceeds 1 MB and therefore its rotation may not happen for quite a few
months and only /var/log/wtmp will exist. I believe this is the out of
the box configuration.

Maybe there should be a final fallback to /var/log/wtmp, so at least
something is produced, although it won't be monthly totals, but
since-the-last-wtmp-rotation totals. That may be better than nothing.

In any case, there should be some else branch if no form of wtmp.1 was
found, so that the rest of the script won't end up operating on empty
WTMP string resulting in cron mails with errors.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 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)
LSM: AppArmor: enabled

Versions of packages acct depends on:
ii  libc6 2.29-10
ii  lsb-base  11.1.0

acct recommends no packages.

acct suggests no packages.

-- no debconf information

Bug#950545: FTBFS against opencv 4.2.0

[Gianfranco Costamagna]

control: tags -1 patch
control: forwarded -1 https://github.com/cmauri/eviacam/pull/24


Hello, I did craft a patch to make it build, I didn't test but the patch was 
straightforward
I also sent it upstream for consideration

cheers,

G.


On Mon, 3 Feb 2020 12:30:54 + Mo Zhou  wrote:
> Source: eviacam
> Version: 2.1.4-1
> Severity: serious
> 
> Dear maintainer,
> 
> eviacam FTBFS against the latest version of OpenCV:
> https://buildd.debian.org/status/package.php?p=eviacam=sid
> https://buildd.debian.org/status/fetch.php?pkg=eviacam=amd64=2.1.4-1%2Bb1=1580642132=0
> 
> which looks due an API change at the first glance.
> 
> 
> crvnormroi.cpp:449:35: error: cannot convert ‘cv::Size’ {aka 
> ‘cv::Size_’} to ‘const CvSize&’
>   449 |  SetP1ResizeInteger (pImg->GetSize(), x, y);
>   |  ~^~
>   |   |
>   |   cv::Size {aka cv::Size_}
> crvnormroi.cpp:359:50: note:   initializing argument 1 of ‘void 
> CNormROI::SetP1ResizeInteger(const CvSize&, int, int)’
>   359 | void CNormROI::SetP1ResizeInteger (const CvSize& size, const int x, 
> const int y)
>   |~~^~~~
> crvnormroi.cpp: In member function ‘void CNormROI::SetP1MoveImg(const 
> CIplImage*, int, int)’:
> crvnormroi.cpp:457:33: error: cannot convert ‘cv::Size’ {aka 
> ‘cv::Size_’} to ‘const CvSize&’
>   457 |  SetP1MoveInteger (pImg->GetSize(), x, y);
>   |~^~
>   | |
>   | cv::Size {aka cv::Size_}
> crvnormroi.cpp:369:48: note:   initializing argument 1 of ‘void 
> CNormROI::SetP1MoveInteger(const CvSize&, int, int)’
>   369 | void CNormROI::SetP1MoveInteger (const CvSize& size, const int x, 
> const int y)
>   |  ~~^~~~
> crvnormroi.cpp: In member function ‘void CNormROI::SetP2ResizeImg(const 
> CIplImage*, int, int)’:
> crvnormroi.cpp:465:35: error: cannot convert ‘cv::Size’ {aka 
> ‘cv::Size_’} to ‘const CvSize&’
>   465 |  SetP2ResizeInteger (pImg->GetSize(), x, y);
>   |  ~^~
>   |   |
>   |   cv::Size {aka cv::Size_}
> crvnormroi.cpp:379:50: note:   initializing argument 1 of ‘void 
> CNormROI::SetP2ResizeInteger(const CvSize&, int, int)’
>   379 | void CNormROI::SetP2ResizeInteger (const CvSize& size, const int x, 
> const int y)
>   |~~^~~~
> crvnormroi.cpp: In member function ‘void CNormROI::SetCenterImg(const 
> CIplImage*, int, int)’:
> crvnormroi.cpp:473:33: error: cannot convert ‘cv::Size’ {aka 
> ‘cv::Size_’} to ‘const CvSize&’
>   473 |  SetCenterInteger (pImg->GetSize(), x, y);
>   |~^~
>   | |
>   | cv::Size {aka cv::Size_}
> crvnormroi.cpp:389:48: note:   initializing argument 1 of ‘void 
> CNormROI::SetCenterInteger(const CvSize&, int, int)’
>   389 | void CNormROI::SetCenterInteger (const CvSize& size, const int x, 
> const int y)
>   |  ~~^~~~
> crvnormroi.cpp: In member function ‘void CNormROI::GetCenterImg(const 
> CIplImage*, int&, int&)’:
> crvnormroi.cpp:481:33: error: cannot convert ‘cv::Size’ {aka 
> ‘cv::Size_’} to ‘const CvSize&’
>   481 |  GetCenterInteger (pImg->GetSize(), x, y);
>   |~^~
>   | |
>   | cv::Size {aka cv::Size_}
> crvnormroi.cpp:398:48: note:   initializing argument 1 of ‘void 
> CNormROI::GetCenterInteger(const CvSize&, int&, int&)’
>   398 | void CNormROI::GetCenterInteger (const CvSize& size, int& x, int& y)
>   |  ~~^~~~
> crvnormroi.cpp: In member function ‘void CNormROI::SetSizeImg(const 
> CIplImage*, int, int)’:
> crvnormroi.cpp:489:31: error: cannot convert ‘cv::Size’ {aka 
> ‘cv::Size_’} to ‘const CvSize&’
>   489 |  SetSizeInteger (pImg->GetSize(), width, height);
From d98f25bbc31463b7dc0446d442f6fed60a55eff0 Mon Sep 17 00:00:00 2001
From: Gianfranco Costamagna 
Date: Tue, 11 Feb 2020 16:23:43 +0100
Subject: [PATCH] Patch for new opencv 4.2

---
 creavision/crvnormroi.cpp  | 24 
 creavision/crvnormroi.h| 22 +++---
 src/visionpipeline.cpp |  2 +-
 src/visionpipeline.h   |  2 +-
 wxcamwindow/visiblenormroi.cpp | 30 +++---
 wxcamwindow/visiblenormroi.h   | 20 ++--
 wxcamwindow/wxnormroi.cpp  |  4 ++--
 7 files changed, 52 insertions(+), 52 deletions(-)

diff --git a/creavision/crvnormroi.cpp b/creavision/crvnormroi.cpp
index 4ae0052..2137141 100755
--- a/creavision/crvnormroi.cpp
+++ b/creavision/crvnormroi.cpp
@@ 

Bug#951138: ITP: ydotool -- Generic command-line automation tool (no X!)

[Alexandre Viau]

Package: wnpp
Severity: wishlist
Owner: Alexandre Viau 

* Package name: ydotool
  Version : v0.1.8
  Upstream Author : Reimu NotMoe
* URL : https://github.com/ReimuNotMoe/ydotool
* License : MIT
  Programming Lang: C++
  Description : Generic command-line automation tool (no X!)

Cheers,

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

Bug#951137: polymake: FTBFS if terminal is unset

[Gianfranco Costamagna]

Source: polymake
Version: 4.0-2
Severity: important
tags: patch

Hello, looks like with TERM=unknown the testsuite fails:

*** Failed tests ***

/<>/apps/common/rules/functions_help.rules:248: testcase 1
expected: regular return
 got: EXCEPTION: Can't find a valid termcap file at 
/<>/perllib/Polymake/Core/InteractiveCommands.pm line 32.


diff -Nru polymake-4.0/debian/changelog polymake-4.0/debian/changelog
--- polymake-4.0/debian/changelog   2020-02-06 23:46:45.0 +
+++ polymake-4.0/debian/changelog   2020-02-11 11:35:39.0 +
@@ -1,3 +1,9 @@
+polymake (4.0-2.1) unstable; urgency=medium
+
+  * Force term=linux (Closes: #-1)
+
+ -- Gianfranco Costamagna   Tue, 11 Feb 2020 
12:35:39 +0100
+
 polymake (4.0-2) unstable; urgency=medium
 
   [ Benjamin Lorenz ]
diff -Nru polymake-4.0/debian/rules polymake-4.0/debian/rules
--- polymake-4.0/debian/rules   2020-02-06 23:46:45.0 +
+++ polymake-4.0/debian/rules   2020-02-11 11:35:37.0 +
@@ -14,6 +14,8 @@
MAX_CPUS=$(shell awk '/^MemTotal/ { print int($$2/(4096*1024)+0.5) }' 
/proc/meminfo)
 endif
 
+export TERM=linux
+
 ARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH)
 WEAK_ARCHES="mips mipsel armhf"
 ifneq (,$(findstring ${ARCH},${WEAK_ARCHES}))

I think exporting a valid TERM in rules file is something sane to do.

thanks

Gianfranco

Bug#951136: lintian: handle filenames with \ properly

[Bernd Zeimetz]

Package: lintian
Version: 2.51.0
Severity: normal


Hi,


lintian whines badly about filenames containing \:

E: open-vm-tools-desktop: md5sums-lists-nonexistent-file 
lib/systemd/system/run-vmblock\x2dfuse.mount
W: open-vm-tools-desktop: file-missing-in-md5sums 
lib/systemd/system/run-vmblock\\x2dfuse.mount

See 
https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/jobs/540252
for a log.


The current output in the md5sums file is the result of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843163 - having the
appropriate support in lintian would be really nice.


Thanks,

Bernd



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#951129: RM: ruby-websocket-parser/1.0.0-1

[Utkarsh Gupta]

reassign 951129 ftp.debian.org
User pkg-ruby-extras-maintain...@lists.alioth.debian.org
Usertags: ruby2.7-transition
thanks

On Tue, Feb 11, 2020 at 9:39 AM Adam D. Barratt 
wrote:

> This sounds like you want the package removing from unstable?
>

Ah, yes. Reassigned to ftp.d.o.
Shall fix the other bugs as well.


Best,
Utkarsh

Bug#911560: [Kinda solved] Re: Network not working on Olimex LIME2 rev K ??

[Jonas Smedegaard]

Quoting Dominique Dumont (2020-02-11 14:16:22)
> On Tuesday, 11 February 2020 12:13:23 CET Dominique Dumont wrote:
> > I'll search in u-boot archive for other threads
> 
> This is promising:
> 
> https://lists.denx.de/pipermail/u-boot/2016-March/249735.html

I suspect that addresses only the issue on one of the newer LIME2 
variants, not both.  But that's just speculation - actually testing 
against all 3 variants is obviously far better ;-)


 - Jonas

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

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


signature.asc
Description: signature

Bug#950535: iptables-restore segfaults on nat table

[Bernhard Übelacker]

Dear Maintainer,
I tried to collect some more information and got
the following backtrace with the restore command
from the submitter.

It looks like "expr->ops" contains a null pointer
that gets dereferenced.

Unfortunately I still see the same crash after
upgrading to the versions in backports in my test VM.

Also this crash is still visible in a minimal
Bullseye/testing VM.

Kind regards,
Bernhard


(gdb) bt
#0  0x7fd480466793 in nftnl_expr_build_payload (nlh=0x7fd47fc7a178, 
expr=0x55fe70704f40) at expr.c:210
#1  0x7fd480461783 in nftnl_rule_nlmsg_build_payload (nlh=0x7fd47fc7a178, 
r=0x55fe70705650) at rule.c:320
#2  0x55fe6e793c66 in nft_compat_rule_batch_add (h=, 
type=, flags=, seq=, 
rule=) at nft.c:2579
#3  0x55fe6e79493e in nft_action (h=0x7fff14b33560, action=0) at nft.c:2673
#4  0x55fe6e790555 in xtables_restore_parse (h=h@entry=0x7fff14b33560, 
p=p@entry=0x7fff14b33540, cb=cb@entry=0x55fe6e7b8140 , 
argc=argc@entry=1, argv=argv@entry=0x7fff14b336e8) at xtables-restore.c:143
#5  0x55fe6e790f90 in xtables_restore_main (family=2, progname=, argc=1, argv=0x7fff14b336e8) at xtables-restore.c:474
#6  0x7fd47fcf709b in __libc_start_main (main=0x55fe6e78bfb0 , 
argc=1, argv=0x7fff14b336e8, init=, fini=, 
rtld_fini=, stack_end=0x7fff14b336d8) at ../csu/libc-start.c:308
#7  0x55fe6e78bfea in _start ()

(gdb) print expr
$3 = (struct nftnl_expr *) 0x55fe70704f40

(gdb) print expr->ops
$4 = (struct expr_ops *) 0x0

(gdb) list expr.c:210
205
206 void nftnl_expr_build_payload(struct nlmsghdr *nlh, struct nftnl_expr 
*expr)
207 {
208 struct nlattr *nest;
209
210 mnl_attr_put_strz(nlh, NFTA_EXPR_NAME, expr->ops->name);
211
212 if (!expr->ops->build)
213 return;
214

https://sources.debian.org/src/libnftnl/1.1.2-2/src/expr.c/#L210

# Buster/stable amd64 qemu VM 2020-02-11


apt update
apt dist-upgrade


apt install systemd-coredump mc git fakeroot strace gdb iptables-dbgsym 
libnftnl11-dbgsym
apt build-dep iptables libnftnl11



mkdir /home/benutzer/source/libnftnl11/orig -p
cd/home/benutzer/source/libnftnl11/orig
apt source libnftnl11
cd

mkdir /home/benutzer/source/iptables/orig -p
cd/home/benutzer/source/iptables/orig
apt source iptables
cd

mkdir /home/benutzer/source/iptables/git -p
cd/home/benutzer/source/iptables/git
git clone git://git.netfilter.org/iptables
cd





iptables-restore < *nat
> -F PREROUTING
> -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
> -F PREROUTING
> -F POSTROUTING
> COMMIT
> EOF
Speicherzugriffsfehler (Speicherabzug geschrieben)


# journalctl --no-pager
Feb 11 13:34:26 debian kernel: iptables-restor[1104]: segfault at 0 ip 
7fd480466793 sp 7fff14b30530 error 4 in 
libnftnl.so.11.0.0[7fd48045b000+17000]
Feb 11 13:34:26 debian kernel: Code: 0c 25 28 00 00 00 75 05 48 83 c4 18 c3 e8 
b5 4a ff ff 0f 1f 44 00 00 41 54 55 48 89 fd 53 48 8b 46 18 48 89 f3 be 01 00 
00 00 <48> 8b 10 e8 b5 51 ff ff 48 8b 43 18 48 83 78 30 00 74 32 48 89 ef
Feb 11 13:34:26 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Feb 11 13:34:26 debian systemd[1]: Started Process Core Dump (PID 1105/UID 0).
Feb 11 13:34:26 debian systemd-coredump[1106]: Process 1104 (iptables-restor) 
of user 0 dumped core.
   
   Stack trace of thread 1104:
   #0  0x7fd480466793 n/a 
(libnftnl.so.11)
   #1  0x7fd480461783 
nftnl_rule_nlmsg_build_payload (libnftnl.so.11)
   #2  0x55fe6e79493e n/a 
(xtables-nft-multi)
   #3  0x55fe6e790555 n/a 
(xtables-nft-multi)
   #4  0x55fe6e790f90 n/a 
(xtables-nft-multi)
   #5  0x7fd47fcf709b 
__libc_start_main (libc.so.6)
   #6  0x55fe6e78bfea n/a 
(xtables-nft-multi)
Feb 11 13:34:26 debian systemd[1]: systemd-coredump@0-1105-0.service: Succeeded.



root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2020-02-11 13:34:26 CET1104 0 0  11 present   
/usr/sbin/xtables-nft-multi





root@debian:~# coredumpctl gdb 1104
   PID: 1104 (iptables-restor)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Tue 2020-02-11 13:34:26 CET (2min 44s ago)
  Command Line: iptables-restore
Executable: /usr/sbin/xtables-nft-multi
 Control Group: /user.slice/user-1000.slice/session-1.scope
  Unit: session-1.scope
 Slice: user-1000.slice
   Session: 1
 Owner UID: 1000 (benutzer)
   Boot ID: 07b3a6dc70ab428eb2a3fb217276c015
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   

Bug#951135: zeromq3: zmq_addons.hpp missing from installed headers

[Gordon Ball]

Source: zeromq3
Severity: wishlist

Dear Maintainer,

zeromq3 installs /usr/include/zmq.hpp, which has been copied from cppzmq
(https://github.com/zeromq/cppzmq).

It's unclear which version of zmq.hpp this is (the copyright dates would
suggest fairly old). Possibly since this version the cppzmq repo now
includes a second header zmq_addons.hpp ; it would be useful if
libzmq3-dev would include updated versions of both headers from cppzmq.

(this would be needed for eg, https://github.com/jupyter-xeus/xeus ).

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

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

Bug#951122: WIP package available on Salsa

[Adam Cecile]

https://salsa.debian.org/acecile-guest/tiledb

Bug#951134: postfix-policyd-spf-python: breaks due to lack of versioned dependency

[Michael Stone]

Package: postfix-policyd-spf-python
Version: 2.9.2-0+deb10u1
Severity: important

postfix-policyd-spf-python has a dependency on python3-spf-engine, but does not
specify a version. If the policyd package is upgraded but the engine package is
not, then mail delivery halts on the system due to the policyd exiting
prematurely. There are no logs emitted showing what the problem is, but running
the program manually from the command line results in:

> /usr/bin/policyd-spf 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 791, in 
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (spf-engine 2.9.1 
(/usr/lib/python3/dist-packages), Requirement.parse('spf-engine==2.9.2'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/policyd-spf", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3191, 
in 
@_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3175, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3204, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 585, in 
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 598, in 
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'spf-engine==2.9.2' distribution was 
not found and is required by the application


Upgrading the engine restores proper operation.


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

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

Versions of packages postfix-policyd-spf-python depends on:
ii  adduser3.118
ii  postfix3.4.7-0+deb10u1
ii  python33.7.3-1
ii  python3-authres1.1.1-1
ii  python3-pkg-resources  40.8.0-1
ii  python3-spf2.0.12t-3
ii  python3-spf-engine 2.9.1-0+deb10u1

postfix-policyd-spf-python recommends no packages.

postfix-policyd-spf-python suggests no packages.

Bug#951133: RM: berkshelf/4.3.5-2

[Utkarsh Gupta]

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

Hi,

This package hasn't been in testing since 1057 days and also fails to build
against Ruby 2.7. And also has an RC bug since a long time.

Each of its reverse dependencies are being filed for removal as well.
This was discussed at the Ruby sprints and finally in the Ruby list, too.

I hereby request the removal of the same.


Best,
Utkarsh
---

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

Kernel: Linux 5.4.0-3-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=>
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#951129: RM: ruby-websocket-parser/1.0.0-1

[Adam D. Barratt]

On 2020-02-11 14:23, Utkarsh Gupta wrote:

Package: release.debian.org [1]
User: release.debian@packages.debian.org
Usertags: rm
Severity: normal

Hi,

This package hasn't been in testing since 1578 days and was last
uploaded on 13th October, 2015. This fails to build against Ruby 2.7.
And also has an RC bug since a long time.

Each of its reverse dependencies are being filed for removal as well.

This was discussed at the Ruby sprints and finally in the Ruby list,
too.

I hereby request the removal of the same.


This sounds like you want the package removing from unstable?

Regards,

Adam

Bug#951130: RM: reel/0.6.1-4

[Adam D. Barratt]

On 2020-02-11 14:28, Utkarsh Gupta wrote:

Package: release.debian.org [1]
User: release.debian@packages.debian.org
Usertags: rm
Severity: normal

Hi,

This package hasn't been in testing since 1124 days and also fails to
build against Ruby 2.7. And also has an RC bug since a long time.

Each of its reverse dependencies are being filed for removal as well.

This was discussed at the Ruby sprints and finally in the Ruby list,
too.

I hereby request the removal of the same.


This sounds like you want the package removing from unstable?

Regards,

Adam

Bug#951131: RM: berkshelf-api/2.2.0-1

[Utkarsh Gupta]

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

Hi,

This package hasn't been in testing since 1242 days and also fails to build
against Ruby 2.7. And also has an RC bug since a long time.

Each of its reverse dependencies are being filed for removal as well.
This was discussed at the Ruby sprints and finally in the Ruby list, too.

I hereby request the removal of the same.


Best,
Utkarsh
---

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

Kernel: Linux 5.4.0-3-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=>
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled