Bug#986356: summary and action items

2021-04-21 Thread Osamu Aoki
Hi,

Let me summarize:

There are at least 1 bug and 1 concern.

 * bug: support for deb.debian.org
 * concern: truncated InRelease file

As for the bug of deb.debian.org, resolution can be:

 * root cause fix: Support redirect (SRV record?) so apt-cacher-ng
   works as expected.
- See http://deb.debian.org/
 * work around: Add cdn-fastly.deb.debian.org to /usr/lib/apt-cacher-
   ng/deb_mirrors.gz  and document to recommend to use  cdn-
   fastly.deb.debian.org instead of  deb.debian.org 
- Without adding cdn-fastly.d.d.o to this file, debs are not placed to
  the debian package cache and also initialization code to generate
  /etc/apt-cacher-ng/backends_debian has problem..
- The same work around needs to be added to security and volatile ...
  (If Ubuntu mirror URL uses the same kind of cdn, you may wish to
  support them too.)
- Please note deb.debian.org is becoming installation default these
  days.  If your apt line list normal old-fashoned mirror site such as
  ftp.de.debian.org, you may not have as much problem.

As for the concern of truncated InRelease, this happens with cdn-
fastly.deb.debian.org with fesh new cache.  If this is not expected
behavior, please think about fixing this.  Very reproduceble. For work
around, run apt-get update multiple time until it is neat shape.

Thanks for your attention.

Osamu



Bug#987336: ITP: dtkcommon -- dtk common files

2021-04-21 Thread clay stan
Package: wnpp
Severity: wishlist
Owner: clay stan 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: dtkcommon
  Version : 5.5.2
  Upstream Author : linuxdeepin
* URL : https://github.com/linuxdeepin/dtkcommon
  License : GPL-3+



Bug#966807: man page for paperinfo(3)

2021-04-21 Thread bod-2.0
Package: libpaper-dev
Tags: patch, newcomer

I've attached the corrected man page in text form. Let me know if you need it 
in any other format and what package(s) I need to install in order to generate 
that format.

The man page was converted to text using the following commands.
man 3 paperinfo | col -bx > paperinfo-3.txt

Sent with [ProtonMail](https://protonmail.com) Secure Email.PAPERINFO(3)   Library Functions Manual   PAPERINFO(3)

NAME
   paperinfo, paperwithsize, paperfirst, paperlast, papernext, paperprev -
   return informations about a paper

SYNOPSYS
   #include 

   const struct paper* paperinfo(const char* papername)
   const struct paper* paperwithsize(double psw, double psh)

   char*  papername(const struct paper*)
   double paperpswidth(const struct paper*)
   double paperpsheight(const struct paper*)

   const struct paper* paperfirst(void)
   const struct paper* papernext(const struct paper* pinfo)
   const struct paper* paperprev(const struct paper* pinfo)
   const struct paper* paperlast(void)

DESCRIPTION
   paperinfo() returns a pointer to a struct paper containing informations
   about  the  paper with name papername paperwithsize() looks for a paper
   whose width and height is psw and psh in PostScript points, and  return
   a pointer to a struct paper corresponding to the paper found.

   papername()  returns  the name of a paper described by an opaque struct
   paper object paperpswidth() returns the width, in PostScript points, of
   a  paper described by an opaque struct paper object paperpsheight() re‐
   turns the height, in PostScript points, of  a  paper  described  by  an
   opaque struct paper object

   paperfirst()  and paperlast() return the first and last entries for pa‐
   pers.  Iteration from one entry to the next or the previous one can  be
   done with papernext() and paperprev() respectively.

SEE ALSO
   paperinit(3), paperdone(3) defaultpapername(3)
   papersize(5)

   24 September 1996  PAPERINFO(3)


Bug#987312: please allow ignoring recommends/suggests

2021-04-21 Thread Matthias Klumpp
Am Mi., 21. Apr. 2021 um 15:51 Uhr schrieb Marc Haber
:
>
> Package: debspawn
> Version: 0.4.1-1
> Severity: wishlist
>
> Hi,
>
> I would like to have a possibility to not install recommends/suggests in
> the container, to keep the containers small.

Does passing `--variant=minbase` to `debspawn create` work for you?
Suggests should never be auto installed, and if Recommends are
installed at package build time, that would actually be a bug - those
should not be present in the build environment...

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/



Bug#987335: ITP: dpa-ext-gnomekeyring -- GNOME keyring extension for dde-polkit-agent

2021-04-21 Thread clay stan
Package: wnpp
Severity: wishlist
Owner: clay stan 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: dpa-ext-gnomekeyring
  Version : 5.0.4
  Upstream Author : linuxdeepin
* URL : https://github.com/linuxdeepin/dpa-ext-gnomekeyring
  License : GPL-3+



Bug#986733: Support for pipewire

2021-04-21 Thread Paul Wise
On Sat, 10 Apr 2021 18:13:18 +0200 Yuri D'Elia wrote:

> Would the current package/build already work with pipewire, or would
> pulseeffects require a different package entirely?

Support for PipeWire requires upgrading to PulseEffects 5.x and doing
so will drop support for pulseaudio, which is only available in 4.x.

https://github.com/wwmm/pulseeffects#note-for-users-that-did-not-moved-from-pulseaudio-to-pipewire

Since PipeWire won't be suitable for all users, I suggest that both
versions of PulseEffects be included in Debian, under different names.

There are lots of different options for that:

 * pulseeffects-pulseaudio pulseeffects-pipewire
 * pulseeffects pulseeffects-pipewire
 * pulseeffects-pulseaudio pulseeffects
 * pulseeffects-legacy pulseeffects

The last option is in line with how upstream named their branch.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#987334: reportbug: replying via "x - Provide extra information" breaks threading, In-Reply-To/References missing

2021-04-21 Thread Paul Wise
Package: reportbug
Version: 7.10.3
Severity: important

When I reply to a bug report via the "x - Provide extra information"
option, reportbug does not include the In-Reply-To/References headers,
which means that the reply breaks mail threading, which is likely to
help recipients of the mail find other messages in the thread and
having this information missing will be annoying to maintainers.

Here is an example of a reply where I recently discovered this:

   $ cat /tmp/user/1000/reportbug-pulseeffects-backup-20210422090628-07ud97t0
   Content-Type: text/plain; charset="us-ascii"
   MIME-Version: 1.0
   Content-Transfer-Encoding: 7bit
   From: Paul Wise 
   To: Debian Bug Tracking System <986...@bugs.debian.org>
   Subject: Re: Support for pipewire
   X-Reportbug-Version: 7.10.3
   
   Package: pulseeffects
   Followup-For: Bug #986733
   
   ...

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental'), 
(500, 'testing-security')
Architecture: amd64 (x86_64)

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

Versions of packages reportbug depends on:
ii  apt2.2.2
ii  python33.9.2-2
ii  python3-reportbug  7.10.3
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf-utils  1.5.75
ii  debsums3.0.2
pn  dlocate
pn  emacs-bin-common   
ii  exim4  4.94-17
ii  exim4-daemon-light [mail-transport-agent]  4.94-17
ii  file   1:5.39-3
ii  gnupg  2.2.27-1
ii  python3-urwid  2.1.2-1
ii  reportbug-gtk  7.10.3
ii  xdg-utils  1.1.3-4

Versions of packages python3-reportbug depends on:
ii  apt2.2.2
ii  file   1:5.39-3
ii  python33.9.2-2
ii  python3-apt2.1.7
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#892842: OpenJDK 8 archive re-entry

2021-04-21 Thread Thorsten Glaser
Hi Phil,

> I'm sure it's just a matter of time, but have you had any feedback from
> ftp-masters about openjdk-8?

unfortunately not yet. They’re probably depriorising sid in times of
freeze, but the grace period for not bothering them is probably over
by now so if ebourg doesn’t want to prod them now, I can do this but
nobody else should so they don’t get annoyed.

Emmanuel, will you or should I?

> Thanks to Sunil for the major breakthrough,
> we are now ready to [upload] kotlin which is now [blocked] on this.

I’m not exactly sure this method is the preferred one, especially
given ebourg’s alternative bootstrapping path from source is
progressing admirably. (Not to throw away that work though, it’ll
become useful nearer to that bootstrapping processes end.)

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*



Bug#892842: OpenJDK 8 archive re-entry

2021-04-21 Thread Phil Morrell
On Wed, Mar 24, 2021 at 11:03:44PM +0100, Thorsten Glaser wrote:
> On Wed, 24 Mar 2021, Emmanuel Bourg wrote:
> > Le 24/03/2021 à 22:13, Thorsten Glaser a écrit :
> > > I can certainly bring it back to unstable, built with
> > > gcc 10, if there are no major issues involved in making
> > > it build with GCC 10, if there is interest.
> >
> > We are certainly doomed without openjdk-8 in unstable, we really need it
> > back.
> 
> Okay. So, unless doko vetos (it was he who was the maintainer
> and he who requested the removal (to be able to remove GCC 9,
> which he is also maintainer of) but I would enter the d-java
> list as team maintainer, with myself as uploader for now) I’ll
> try to get it building with GCC 10 and upload that to unstable.

Hello mirabilos,

I'm sure it's just a matter of time, but have you had any feedback from
ftp-masters about openjdk-8? Thanks to Sunil for the major breakthrough,
we are now ready to [upload] kotlin which is now [blocked] on this.

[upload]: https://salsa.debian.org/java-team/kotlin/-/issues/11
[blocked]: https://salsa.debian.org/java-team/kotlin/-/issues/12


signature.asc
Description: PGP signature


Bug#987333: jumpnbump crashes on systems with unsigned char.

2021-04-21 Thread peter green

Package: jumpnbump
Severity: important

A raspbian user reported that jumpnbump "crashes while jumping", but only
if sound was enabled. The issue was also reported by a ubuntu powerpc user.
(back when ubuntu still supported traditional powerpc)

https://bugs.launchpad.net/ubuntu/+source/jumpnbump/+bug/722370

https://bugs.launchpad.net/raspbian/+bug/1639586

Neither of the original reporters tracked down this issue, but
another raspbian user was able to track it down to a char signedness issue
and has posted a fix upstream at

https://gitlab.com/LibreGames/jumpnbump/-/merge_requests/33/diffs

In the C standard, the signedness of type "char" is implementation defined.
In practice it varies between architectures. on x86* it is signed, but on
arm* and powerpc* it is unsigned.

The result is that when dj_play_sfx is called with the "channel" parameter
set to -1 on an architecture with unsigned char it instead gets interpreted
as 255 resulting in an overflow.

I have not personally tested this issue but I intend to do so soon.

If I get no response to this bug and I get time to test out the patch
I will likely upload a NMU in a week or so.



Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

2021-04-21 Thread Ross Vandegrift
Package: fwupd
Version: 1.5.7-3
Followup-For: Bug #943343
X-Debbugs-Cc: rvandegr...@debian.org

I have a pair of laptops, one where fwupd-refresh.service is broken and one
where it works.  Both are running bullseye with the same versions of fwupd,
systemd, and dbus.  No remote users, nfs, freeipa, etc.


I've run both with this config:
  $ cat /etc/systemd/system/fwupd-refresh.service.d/override.conf
  [Service]
  StandardError=
  StandardError=journal
  ExecStart=
  ExecStart=/usr/bin/strace -ff /usr/bin/fwupdmgr -v refresh


The results aren't too enlightening - the broken one cannot auth to dbus as
it's systemd dynamic user:

  socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 7
  fcntl(7, F_GETFL)  = 0x2 (flags O_RDWR)
  fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
  connect(7, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 
110) = 0
  sendmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", 
iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, 
cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=128515, uid=62803, gid=62803}}], 
msg_controllen=32, msg_flags=0}, MSG_NOSIGNAL) = 1
  sendto(7, "AUTH\r\n", 6, MSG_NOSIGNAL, NULL, 0) = 6
  recvfrom(7, "REJECTED EXTERNAL\r\n", 4096, 0, NULL, NULL) = 19
  sendto(7, "AUTH EXTERNAL 3632383033\r\n", 26, MSG_NOSIGNAL, NULL, 0) = 26
  recvfrom(7, "REJECTED EXTERNAL\r\n", 4096, 0, NULL, NULL) = 19


I don't know why that would fail.  If I could provide more details or test
something, please let me know.

Ross



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

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

Versions of packages fwupd depends on:
ii  libc6  2.31-11
ii  libcurl3-gnutls7.74.0-1.2
ii  libefiboot137-6
ii  libelf10.183-1
ii  libflashrom1   1.2-5
ii  libfwupd2  1.5.7-2
ii  libfwupdplugin11.5.7-2
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-3
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.5-1
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpolkit-gobject-1-0  0.105-30
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libsystemd0247.3-3
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
ii  bolt   0.9.1-1
ii  dbus   1.12.20-2
ii  fwupd-amd64-signed [fwupd-signed]  1.5.7+3
ii  python33.9.2-2
pn  secureboot-db  
ii  udisks22.9.2-1

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information



Bug#987155: unblock: libpod/3.0.1+dfsg1-2

2021-04-21 Thread Reinhard Tartler


On 4/20/21 4:33 AM, Sebastian Ramacher wrote:

> What's the status of #987207? If that also requires changes in the
> package, it would be good to include them as well.


Indeed, turned out to be less severe, but I agree it's a good idea to pick it 
up too.
I took the liberty of uploading this change to unstable, please consider 
unblocking:

diff --git a/debian/changelog b/debian/changelog
index ec4748cb8..7ec3e362d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libpod (3.0.1+dfsg1-2) unstable; urgency=medium
+
+  * Prefer crun over runc, Closes: #985379
+  * Add depends in iptables, Closes: #987207
+
+ -- Reinhard Tartler   Wed, 21 Apr 2021 17:36:07 -0400
+
 libpod (3.0.1+dfsg1-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/control b/debian/control
index dedbb4462..d3865b0c1 100644
--- a/debian/control
+++ b/debian/control
@@ -94,7 +94,8 @@ Depends: ${misc:Depends}, ${shlibs:Depends}
 ,conmon (>= 2.0.18~)
 ,containernetworking-plugins (>= 0.8.7)
 ,golang-github-containers-common
-,runc (>= 1.0.0~rc92~) | crun
+,crun | runc (>= 1.0.0~rc92~)
+,iptables
 Breaks: buildah (<< 1.10.1-6), slirp4netns (<< 0.4.1), fuse-overlayfs (<< 
0.7.1)
 Recommends: ${misc:Recommends}
 ,buildah (>= 1.10.1-6~)



Bug#987207: podman not running out-of-the-box as root

2021-04-21 Thread Reinhard Tartler
Control: tag -1 pending
Control: severity -1 important
Control: retitle -1 Missing dependency on "iptables"

On Wed, Apr 21, 2021 at 6:07 AM Laurent Bigonville  wrote:

> So the problem here is, again, linked to the fact that I'm using a test
> SELinux policy that doesn't contain all the needed contexts, so yeah it's a
> mix of configuration issue and the fact that podman is not ignoring these
> errors if SELinux is in permissive. I'll ping upstream again.
>
Thanks, let's track this in #984879

> So the remaining problem here is iptables command not being installed (and
> the seccomp.json file missing to a lower extend)
>
Agreed.

-- 
regards,
Reinhard


Bug#987038: clamav 0.103.2+dfsg-0+deb10u1 flagged for acceptance

2021-04-21 Thread Adam D Barratt
package release.debian.org
tags 987038 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: clamav
Version: 0.103.2+dfsg-0+deb10u1

Explanation: new upstream stable release; fix denial of security issue 
[CVE-2021-1405]



Bug#987332: aprx automatically starts up with really bad default config

2021-04-21 Thread Heikki Hannikainen

Package: aprx
Version: 2.9.0+dfsg-2

I just noticed that many of the aprs2.net APRS-IS servers have a whole lot of 
aprx 2.9.0 clients connected using the N0CALL-1 dummy callsign, having sent 
zero packets. There are probably hundreds of these clients, T2UKRAINE currently 
and T2FINLAND has 67. I didn't even check other servers (there's a 
hundred).


After some looking around I found out that the aprx package in Debian these 
days has the following flaw:


If you just install it ("apt install aprx"), it will start up automatically and 
by default, and it will actually connect to the APRS-IS network using the dummy 
callsign (which one should never use) and stay connected.


I suspect this bug came up in aprx (2.9.0+dfsg-2), right here:

- Update aprx.default to remove environment STARTAPRX variable for
  daemon enable/disable for Debian Policy § 9.3.3.1
- Update aprx.init script to remove /etc/default check for daemon
  enable/disable

The old default was that it did not automatically start up before 
STARTAPRX was manually adjusted in /etc/default/aprx.


Please release a high-priority update which shuts down these clients which have 
been automatically started up by this change.


- Have it not start up by default after installation, before it is configured

- Remove N0CALL-1 from the default configuration (comment the line out) so that 
it will refuse to start up before configured with the callsign of the user


- Ensure that the instances which have already been started up like this will 
shut down again when upgraded to the next version


Assuming that these clients run with the default configuration file 
supplied, one fix would be to intentionally break the default 
configuration file so that the startup fails. If the user has not modified 
the config file, an upgrade would replace it.


Thank you!

  - Hessu, OH7LZB (aprs.fi, aprsc server author)

Bug#987331: ruby-mysql2: flaky autopkgtest

2021-04-21 Thread Sebastian Ramacher
Source: ruby-mysql2
Version: 0.5.3-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

Many of the autopkgtest runs on amd64 fail with:
| Failures:
|
|   1) Mysql2::Result streaming should raise an exception if streaming ended 
due to a timeout
|  Failure/Error:
|expect do
|  res.each_with_index do |_, i|
|# Exhaust the first result packet then trigger a timeout
|sleep 4 if i > 0 && i % 1000 == 0
|  end
|end.to raise_error(Mysql2::Error, /Lost connection/)
|
|expected Mysql2::Error with message matching /Lost connection/ but 
nothing was raised
|  # ./spec/mysql2/result_spec.rb:164:in `block (3 levels) in '
|
| Finished in 42.81 seconds (files took 0.2193 seconds to load)
| 321 examples, 1 failure, 5 pending

See also 
https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-mysql2/11803835/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#987316: Fwd: Re: Bug#987316: initscripts: tmpfs has wrong size

2021-04-21 Thread Roger Lynn

Sorry, I failed to send this to the bug. Resending...

 Forwarded Message 
Subject: Re: Bug#987316: initscripts: tmpfs has wrong size
Date: Wed, 21 Apr 2021 22:11:12 +0100
From: Roger Lynn 
To: Thorsten Glaser 

On 21/04/2021 18:38, Thorsten Glaser wrote:

• add “set -x” as first and “set +x” as last line to
   /lib/init/tmpfs.sh
• perhaps also add “grep Total /proc/meminfo” in there
   for extra debugging
• reboot with serial console, so we can actually capture
   all the debug messages

I suspect one of the operations involved fails for you,
or swap is initialised later. Hrm.


Swap is apparently initialised later. There are three calls to that script 
recorded by bootlogd and on all of them SwapTotal is 0 kB. It then prints 
the lines for "Mounting local filesystems", "Activating swapfile swap, if 
any" and "Cleaning up temporary files". Do you still need the full debug output?


Regards,

Roger



Bug#987316: initscripts: tmpfs has wrong size

2021-04-21 Thread Thorsten Glaser
On Wed, 21 Apr 2021, Roger Lynn wrote:

> Swap is apparently initialised later. There are three calls to that script
> recorded by bootlogd and on all of them SwapTotal is 0 kB. It then prints the
> lines for "Mounting local filesystems", "Activating swapfile swap, if any" and
> "Cleaning up temporary files". Do you still need the full debug output?

No, I think we have it then.

Nothing I can immediately think of to fix this.
We really want tmpfs as early as possible; some
swap devices may not yet be available. Maybe we
could initialise those which are, though, but
not for bullseye, definitely.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*



Bug#987330: tpm2-pkcs11: Explicitly enable/disable fapi

2021-04-21 Thread Bastian Germann

Source: tpm2-pkcs11
Version: 1.5.0-4

Please set the configure flag --enable-fapi or --disable-fapi. The automatic selection makes the 
packages fragile. Currently, the auto detection builds with fapi backend enabled but the current 
binary has it disabled.




Bug#986984: Bug#987327: autopkgtests for debian-edu-doc binary packages

2021-04-21 Thread Wolfgang Schweer
[ Holger Levsen, 2021-04-21 ]
> we should add autopkgtests to debian-edu-doc to ensure each document 
> has been built for the three formats pdf, epub and html.
> 
> another condition is that every debian-edu-doc-* package should 
> contain at least one document, unless the package has 'transitional' 
> in it's description.

sounds good.
 
> On Wed, Apr 21, 2021 at 09:20:38PM +0200, Petter Reinholdtsen wrote:
> > [Holger Levsen]
> > > I'll guess I'll invent something myself then...
> > What about looking for selected keywords like 'Debian Edu', 'Skolelinux,
> > "$(lsb_release -c -s)" or similar by grepping the documentation files,
> 
> thanks, grepping for known strings is indeed a good idea, though
> we should choose those few untranslated english ones...
> 
> > to ensure the content is somewhat relevant?  And perhaps linting the
> > HTML (weblint-perl?) and epub (epubcheck?) files to verify the format is
> > correct?
> 
> I was thinking of just using /usr/bin/file...

IIRC, we had all sorts of problems in the past, some of them unnoticed
for some time:
- missing files of some format due to wrong XML syntax in PO files
- missing PDF files for a specific language
- problems with non-ascii language PDF files
- HTML files with somehow broken markup
- invalid EPUB files

In some cases, verifying the format would have revealed the cause for 
missing files/internal issues, i.e would have allowed one to locate the 
broken XML syntax (most cases) more easily.

src:desktop-base has an autopkgtest to validate XML files, xmllint from 
libxml2-utils is used. Maybe xmllint could also be used to check HTML 
files.

Besides checking EPUB files, epubcheck has also been useful in the past 
to detect HTML markup errors caused by XML tag mismatch (which xmllint 
failed to detect).

And 'qpdf --check ' could be used to validate PDF files.

Wolfgang


signature.asc
Description: PGP signature


Bug#972679: chrony 4.0 in backports

2021-04-21 Thread Diederik de Haas
On Thu, 22 Oct 2020 13:58:06 +0200 Kurt Roeckx  wrote:
> Would it be possible to get chrony 4.0 in buster backports?

Buster backports now has 4.0-5~bpo10+1, so I guess this bug can be closed?



Bug#986969: gnucash: FTBFS with glib 2.68

2021-04-21 Thread Micha Lenk

Control: tags -1 + patch upstream fixed-upstream
Control: forwarded -1 https://bugs.gnucash.org/show_bug.cgi?id=798156

For fixing the package in Debian I suggest applying the corresponding 
upstream commit instead:

https://github.com/Gnucash/gnucash/commit/bbb4113a5a996dcd7bb3494e0be900b275b49a4f

Best regards,
Micha



Bug#987307: unblock: nodejs/12.21.0~dfsg-4

2021-04-21 Thread Sebastian Ramacher
Control: tags -1 moreinfo confirmed

On 2021-04-21 12:56:51 +0200, Jérémy Lal wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package nodejs

Please remove the moreinfo tag once the new version is available in
unstable.

Cheers

> 
> [ Reason ]
> Fixing bug #987301: please add Breaks: node-babel-runtime (<< 7)
> 
> [ Impact ]
> Problem for users having node-babel-runtime when upgrading
> from buster to bullseye.
> 
> [ Tests ]
> Piuparts... see also bug report.
> 
> [ Risks ]
> Probably none.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> unblock nodejs/12.21.0~dfsg-4

> diff -Nru nodejs-12.21.0~dfsg/debian/changelog 
> nodejs-12.21.0~dfsg/debian/changelog
> --- nodejs-12.21.0~dfsg/debian/changelog  2021-03-19 18:43:52.0 
> +0100
> +++ nodejs-12.21.0~dfsg/debian/changelog  2021-04-21 12:42:46.0 
> +0200
> @@ -1,3 +1,11 @@
> +nodejs (12.21.0~dfsg-4) unstable; urgency=medium
> +
> +  [ Andreas Beckmann ]
> +  * nodejs: Add Breaks: node-babel-runtime (<< 7)
> +for smoother upgrades from buster. (Closes: #987301)
> +
> + -- Jérémy Lal   Wed, 21 Apr 2021 12:42:46 +0200
> +
>  nodejs (12.21.0~dfsg-3) unstable; urgency=medium
>  
>* Upstream patch fix test-worker-prof (Closes: #985550)
> diff -Nru nodejs-12.21.0~dfsg/debian/control 
> nodejs-12.21.0~dfsg/debian/control
> --- nodejs-12.21.0~dfsg/debian/control2021-02-23 19:22:31.0 
> +0100
> +++ nodejs-12.21.0~dfsg/debian/control2021-04-21 12:40:54.0 
> +0200
> @@ -69,7 +69,7 @@
>  Suggests: npm
>  Replaces: nodejs-legacy
>  Conflicts: nodejs-legacy
> -Breaks: node-typescript-types (<< 20210110~)
> +Breaks: node-typescript-types (<< 20210110~), node-babel-runtime (<< 7)
>  Provides: node-types-node (= ${types:Node})
>  Description: evented I/O for V8 javascript - runtime executable
>   Node.js is a platform built on Chrome's JavaScript runtime for easily


-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#987319: unblock: tasksel/3.67

2021-04-21 Thread Holger Wansing
Package: release.debian.org
Usertags: unblock


I would like to request an unblock for version 3.67 of tasksel.

This migration has been discussed with release managers already, and has been 
given their agreement.
It fixes recently spotted issues with input methods / ibus in various
languages, via some meta packages.
I have tested the changings, and confirm that they work as expected.


Attached is a debdiff from 3.67 (currently in unstable) against 3.65
(currently in testing).


Thanks
Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff -Nru tasksel-3.65/debian/changelog tasksel-3.67/debian/changelog
--- tasksel-3.65/debian/changelog	2021-03-13 16:26:46.0 +0100
+++ tasksel-3.67/debian/changelog	2021-04-18 12:10:40.0 +0200
@@ -1,3 +1,33 @@
+tasksel (3.67) unstable; urgency=medium
+
+  * Team upload.
+
+  * Add forgotten files in ./tasks/ to make recently added *-gnome-desktop
+packages work.
+
+ -- Holger Wansing   Sun, 18 Apr 2021 12:10:40 +0200
+
+tasksel (3.66) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Shengjing Zhu ]
+  * Switch to fcitx5 for Simplified and Traditional Chinese desktop.
+Fcitx5 works for Wayland. (Closes: #983704)
+
+  [ Holger Wansing]
+  * GNOME now depends on ibus as input method. For some languages, there are
+additional packages needed, to make ibus work. Adding them for Amharic,
+Simplified chinese, Traditional chinese, Japanese, Kannada, Malayalam and
+Telugu. This requires new task-*-gnome-desktop packages to be added for
+Amharic, Simplified chinese, Traditional chinese, and Kannada.
+Thanks to Shengjing Zhu for working out the circumstances.
+Closes: #941624, #983653.
+  * ibus does not have default configurations for all languages, so force
+to create one via gnome-initial-setup for all the languages using ibus.
+
+ -- Holger Wansing   Sat, 20 Mar 2021 16:22:17 +0800
+
 tasksel (3.65) unstable; urgency=medium
 
   * Team upload.
diff -Nru tasksel-3.65/debian/control tasksel-3.67/debian/control
--- tasksel-3.65/debian/control	2021-03-13 16:26:46.0 +0100
+++ tasksel-3.67/debian/control	2021-04-18 12:10:40.0 +0200
@@ -439,6 +439,16 @@
 	fcitx-frontend-gtk3,
 	fcitx-config-gtk
 
+Package: task-amharic-gnome-desktop
+Architecture: all
+Description: Amharic GNOME desktop
+ This task localises the GNOME desktop in Amharic.
+Depends: ${misc:Depends}
+Recommends:
+	ibus-m17n,
+# ibus doesn't have a default config for all languages, so force creation
+	gnome-initial-setup
+
 Package: task-amharic-kde-desktop
 Architecture: all
 Description: Amharic KDE Plasma desktop
@@ -733,10 +743,8 @@
 Recommends:
 # Input method stuff
 	im-config,
-	fcitx,
-	fcitx-sunpinyin,
-	fcitx-googlepinyin,
-	fcitx-table-wubi,
+	fcitx5,
+	fcitx5-chinese-addons,
 # Fonts
 	fonts-noto,
 	fonts-noto-cjk,
@@ -753,14 +761,24 @@
 	fonts-arphic-ukai,
 	fonts-arphic-uming
 
+Package: task-chinese-s-gnome-desktop
+Architecture: all
+Description: Simplified Chinese GNOME desktop
+ This task localises the GNOME desktop in Simplified Chinese.
+Depends: ${misc:Depends}
+Recommends:
+	ibus-libpinyin,
+# ibus doesn't have a default config for all languages, so force creation
+	gnome-initial-setup
+
 Package: task-chinese-s-kde-desktop
 Architecture: all
 Description: Simplified Chinese KDE Plasma desktop
  This task localises the KDE Plasma desktop in Simplified Chinese.
 Depends: ${misc:Depends},
 Recommends:
-	fcitx-frontend-qt5,
-	kde-config-fcitx
+	fcitx5-frontend-qt5,
+	kde-config-fcitx5
 
 Package: task-chinese-t
 Architecture: all
@@ -778,10 +796,11 @@
  This task localises the desktop in Traditional Chinese.
 Depends: ${misc:Depends},
 Recommends:
-	fcitx,
-	fcitx-chewing,
-	fcitx-table,
+# Input method stuff
 	im-config,
+	fcitx5,
+	fcitx5-chewing,
+	fcitx5-chinese-addons,
 # seems openjdk needs this to display Chinese.
 	fonts-noto,
 	fonts-noto-cjk,
@@ -795,11 +814,24 @@
 	fonts-arphic-ukai,
 	fonts-arphic-uming
 
+Package: task-chinese-t-gnome-desktop
+Architecture: all
+Description: Traditional Chinese GNOME desktop
+ This task localises the GNOME desktop in Traditional Chinese.
+Depends: ${misc:Depends}
+Recommends:
+	ibus-chewing,
+# ibus doesn't have a default config for all languages, so force creation
+	gnome-initial-setup
+
 Package: task-chinese-t-kde-desktop
 Architecture: all
 Description: Traditional Chinese KDE Plasma desktop
  This task localises the KDE Plasma desktop in Traditional Chinese.
 Depends: ${misc:Depends},
+Recommends:
+	fcitx5-frontend-qt5,
+	kde-config-fcitx5
 
 Package: task-croatian
 Architecture: all
@@ -1429,7 +1461,8 @@
 # subject instead of iso-2022-jp used Japanese de-facto. I recommend
 # thunderbird as default mailer for Japanese desktop users.
 	thunderbird,
-	thunderbird-l10n-ja
+	thunderbird-l10n-ja,
+	ibus-mozc | ibus-anthy
 
 Package: task-japanese-kde-desktop
 Architecture: all
@@ -1449,6 +1482,16 @@
 	fcitx-m17n,
 	fcitx-config-gtk
 

Bug#795421: version 5.01 freezes on test #7 in SMP mode

2021-04-21 Thread Christoph Anton Mitterer
Anything new here?

memtest86+ seems effectively fully broken on all modernish CPUs (at
least all systems I have freeze after a short while, regardless of
SMP/non-SMP mode).



A new version 5.31b seems out since quite a while.


Cheers,
Chris.



Bug#987329: unblock: ceph/14.2.20-2

2021-04-21 Thread Thomas Goirand
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Bernd Zeimetz , Moritz Muehlenhoff 
, Adam Borowski 

Dear release team,

I've uploaded version 14.2.20-2 of Ceph. This is the last point release
from usptream, including the fixes for CVE-2021-20288 and CVE-2020-27839.

With such large software such as Ceph, the debdiff can be quite big.
This unfortunately is no exception. I understand that the rule is that
the release team insist reviewing all changes. That's clearly not
possible considering the debdiff size. However, I don't think it is
reasonable to not include point release fixes from upstream, just like
we do with other large software in Debian. I intend to keep Ceph 14.2.x
updated during the lifetime of Bullseye, following upstream updates,
hopefully you will agree that this is the sensitive thing to do.

I've uploaded the debdiff here:
http://shade.infomaniak.ch/ceph_14.2.20-2.debdiff

Note that I have setup and used version 14.2.20-2 in a production
OpenStack cluster: Ceph is used there for storing Glance images,
Cinder volumes, and Nova VM disks. I haven't seen any regression.

Please unblock package ceph/14.2.20-2

Cheers,

Thomas Goirand (zigo)

P.S: bzed, jmm and kilobyte as CC after discussing this update with bzed
who co-maintains the Ceph package. Also, this bug is instead of #985885
that I have closed.



Bug#987328: unblock: lyskom-elisp-client/0.48+git.20200923.ec349ff4-3

2021-04-21 Thread Joel Rosdahl
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lyskom-elisp-client

0.48+git.20200923.ec349ff4-3 fixes two important/release critical
bugs: #985871 and #987260.

Changes:

1. Only support Emacs flavor "emacs", i.e., drop support for xemacs21 since it's
   unsupported. This addresses #987260.
2. Be more robust when removing files on purge of the package. This addresses
   #985871.

Debdiff between the version currently in testing (0.48+git.20200923.ec349ff4-1)
and the one in unstable (0.48+git.20200923.ec349ff4-3) attached.

Regards,
Joel


lyskom-elisp-client.debdiff
Description: Binary data


Bug#983896: [Pkg-raspi-maintainers] Bug#983896: raspi-firmware: please link /boot/firmware/*.txt to /etc/raspi-firmware/*.txt

2021-04-21 Thread Holger Levsen
hi Gunnar,

I've just added some bits to /etc/default/raspi-firmware-custom and
indeed after an apt upgrade run i found them in /boot/firmware/config.txt !

Yay & thank you again!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

„If you don't like vaccination, try the disease.“ (Herwig Kollaritsch)


signature.asc
Description: PGP signature


Bug#987327: autopkgtests for debian-edu-doc binary packages

2021-04-21 Thread Holger Levsen
package: src:debian-edu-doc
severity: wishlist
x-debbugs-cc:  Petter Reinholdtsen , Paul Gevers 
, 986...@bugs.debian.org, debian-...@lists.debian.org

Hi,

we should add autopkgtests to debian-edu-doc to ensure each document has been
built for the three formats pdf, epub and html.

another condition is that every debian-edu-doc-* package should contain
at least one document, unless the package has 'transitional' in it's 
description.

On Wed, Apr 21, 2021 at 09:20:38PM +0200, Petter Reinholdtsen wrote:
> [Holger Levsen]
> > I'll guess I'll invent something myself then...
> What about looking for selected keywords like 'Debian Edu', 'Skolelinux,
> "$(lsb_release -c -s)" or similar by grepping the documentation files,

thanks, grepping for known strings is indeed a good idea, though
we should choose those few untranslated english ones...

> to ensure the content is somewhat relevant?  And perhaps linting the
> HTML (weblint-perl?) and epub (epubcheck?) files to verify the format is
> correct?

I was thinking of just using /usr/bin/file...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"Climate change" is an euphenism. "Global warming" as well.


signature.asc
Description: PGP signature


Bug#987038: buster-pu: package clamav/0.103.2+dfsg-0+deb10u1

2021-04-21 Thread Sebastian Andrzej Siewior
On 2021-04-20 20:52:09 [+0100], Adam D. Barratt wrote:
> 
> I'm certainly happy to defer to your judgement here, given our previous
> experience with clamav updates in stable. I was simply trying to
> ascertain the scale of the update involved, but fear I may have just
> confused the discussion; perhaps it doesn't really matter that much, in
> the end.

Sure thing. I tried to cover some bits regarding the update in the
initial bug report. If you have any questions feel free to ask.

> Please feel free to upload. I assume that, given there are security
> fixes involved, you'd prefer an early release via stable-updates as
> we've done with a number of updates in the past?

Thank you, uploaded. Yes, please. In the past we had it stable-pu for a
day or two and then enabled it via stable/updates if I remember
correctly. If you want me draft a SUA, I could try to.

> Regards,
> 
> Adam

Sebastian



Bug#986622: [Pkg-clamav-devel] Bug#986622: Bug#986622: fixes

2021-04-21 Thread Sebastian Andrzej Siewior
On 2021-04-21 08:17:53 [+0100], Athanasius wrote:
> So long as any Debian update of the packages both addresses the
> outstanding CVEs *and* quiets this logging I'll be happy.

Be aware that I am following the process to get an update into Buster.

Sebastian



Bug#986984: unblock: debian-edu-doc/2.11.22

2021-04-21 Thread Petter Reinholdtsen
[Holger Levsen]
> I'll guess I'll invent something myself then...

What about looking for selected keywords like 'Debian Edu', 'Skolelinux,
"$(lsb_release -c -s)" or similar by grepping the documentation files,
to ensure the content is somewhat relevant?  And perhaps linting the
HTML (weblint-perl?) and epub (epubcheck?) files to verify the format is
correct?

-- 
Happy hacking
Petter Reinholdtsen



Bug#305622: gimp-dcraw: Cannot process filenames with single quotes

2021-04-21 Thread Haowen Liu

> Tagging newcomer; this bug should be quite easy to fix.

Is this bug still existent / relevant? This is my first time 
contributing to Debian. Should I look into this?


Haowen



Bug#987326: pupnp-1.8: CVE-2021-29462

2021-04-21 Thread Salvatore Bonaccorso
Source: pupnp-1.8
Version: 1:1.8.4-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for pupnp-1.8.

CVE-2021-29462[0]:
| The Portable SDK for UPnP Devices is an SDK for development of UPnP
| device and control point applications. The server part of pupnp
| (libupnp) appears to be vulnerable to DNS rebinding attacks because it
| does not check the value of the `Host` header. This can be mitigated
| by using DNS revolvers which block DNS-rebinding attacks. The
| vulnerability is fixed in version 1.14.6 and later.


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-2021-29462
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29462
[1] https://github.com/pupnp/pupnp/security/advisories/GHSA-6hqq-w3jq-9fhg
[2] 
https://github.com/pupnp/pupnp/commit/21fd85815da7ed2578d0de7cac4c433008f0ecd4
[3] https://www.openwall.com/lists/oss-security/2021/04/20/4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#987325: mysql-8.0: Security fixes from the April 2021 CPU

2021-04-21 Thread Salvatore Bonaccorso
Source: mysql-8.0
Version: 8.0.23-3
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi

See
https://www.oracle.com/security-alerts/cpuapr2021.html#AppendixMSQL
for a list of CVEs affecting src:mysql-8.0.

Regards,
Salvatore



Bug#987324: rust-hashbrown: missing ahash feature makes building hashlink crate impossible

2021-04-21 Thread Daniel Kahn Gillmor
Package: rust-hashbrown
Version: 0.9.1-2
Control: forwarded -1 https://github.com/kyren/hashlink/issues/6

I'm trying to build the hashlink crate, which is needed by a transitive
dependency of future work on Sequoia (https://sequoia-pgp.org).

However, the build of hashlink 0.6.0 fails with an error:

```
error[E0599]: no variant or associated item named `default` found for enum 
`DefaultHashBuilder` in the current scope
  --> src/linked_hash_map.rs:50:57
   |
50 | hash_builder: hash_map::DefaultHashBuilder::default(),
   | ^^^ variant or 
associated item not found in `DefaultHashBuilder`

error[E0599]: no variant or associated item named `default` found for enum 
`DefaultHashBuilder` in the current scope
  --> src/linked_hash_map.rs:60:57
   |
60 | hash_builder: hash_map::DefaultHashBuilder::default(),
   | ^^^ variant or 
associated item not found in `DefaultHashBuilder`

error: aborting due to 2 previous errors
```

I reported this to the hashlink project upstream, and @nathaniel-daniel
identified the problem as being the stripping of the ahash feature from
the hashbrown crate in debian.

Presumably this means that we need the ahash crate in debian first; and
then we should enable that feature for the hashbrown crate.

 --dkg


signature.asc
Description: PGP signature


Bug#986565: unusable with current git

2021-04-21 Thread Lisandro Damián Nicanor Pérez Meyer
reopen 986565
thanks

Hi! Indeed it's not working again, so reopening the bug.

On Wed, 21 Apr 2021 10:12:03 + Damyan Ivanov  wrote:
> Package: git-flow
> Version: 1.12.3-2
> Followup-For: Bug #986565
>
> Control: reopen -1 1.12.3-2
>
> Sigh. Now git reverted to using /usr/lib again, and git-flow is broken.
>
> Reverting the changes in 1.12.3-2 would fix it.
>
> Reading https://bugs.debian.org/985416 (the bug report in git about changing
> the path), I am left with the impression that the proper fix is to ship
> /usr/bin/git-flow. Perhaps the other scripts need to be in /usr/bin too.
>
>
> HTH,
> Damyan
>
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
> (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages git-flow depends on:
> ii  git [git-core]  1:2.31.1-1
> ii  git-core1:2.15.0~rc0-1
>
> git-flow recommends no packages.
>
> git-flow suggests no packages.
>
> -- no debconf information
>
>



Bug#987323: gpac: CVE-2021-29279 CVE-2021-30014 CVE-2021-30015 CVE-2021-30019 CVE-2021-30020 CVE-2021-30022 CVE-2021-30199

2021-04-21 Thread Salvatore Bonaccorso
Source: gpac
Version: 1.0.1+dfsg1-3
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for gpac, filling a
seprate bug for this set of new CVEs araised yesterday.

CVE-2021-29279[0]:
| There is a integer overflow in function
| filter_core/filter_props.c:gf_props_assign_value in GPAC 1.0.1. In
| which, the arg const GF_PropertyValue *value,maybe
| value-value.data.size is a negative number. In result, memcpy in
| gf_props_assign_value failed.


CVE-2021-30014[1]:
| There is a integer overflow in media_tools/av_parsers.c in the
| hevc_parse_slice_segment function in GPAC 1.0.1 which results in a
| crash.


CVE-2021-30015[2]:
| There is a Null Pointer Dereference in function
| filter_core/filter_pck.c:gf_filter_pck_new_alloc_internal in GPAC
| 1.0.1. The pid comes from function av1dmx_parse_flush_sample, the
| ctx.opid maybe NULL. The result is a crash in
| gf_filter_pck_new_alloc_internal.


CVE-2021-30019[3]:
| In the adts_dmx_process function in filters/reframe_adts.c in GPAC
| 1.0.1, a crafted file may cause ctx-hdr.frame_size to be smaller
| than ctx-hdr.hdr_size, resulting in size to be a negative number
| and a heap overflow in the memcpy.


CVE-2021-30020[4]:
| In the function gf_hevc_read_pps_bs_internal function in
| media_tools/av_parsers.c in GPAC 1.0.1 there is a loop, which with
| crafted file, pps-num_tile_columns may be larger than
| sizeof(pps-column_width), which results in a heap overflow in the
| loop.


CVE-2021-30022[5]:
| There is a integer overflow in media_tools/av_parsers.c in the
| gf_avc_read_pps_bs_internal in GPAC 1.0.1. pps_id may be a negative
| number, so it will not return. However, avc-pps only has 255 unit,
| so there is an overflow, which results a crash.


CVE-2021-30199[6]:
| In filters/reframe_latm.c in GPAC 1.0.1 there is a Null Pointer
| Dereference, when gf_filter_pck_get_data is called. The first arg pck
| may be null with a crafted mp4 file,which results in a crash.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-29279
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29279
[1] https://security-tracker.debian.org/tracker/CVE-2021-30014
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30014
[2] https://security-tracker.debian.org/tracker/CVE-2021-30015
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30015
[3] https://security-tracker.debian.org/tracker/CVE-2021-30019
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30019
[4] https://security-tracker.debian.org/tracker/CVE-2021-30020
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30020
[5] https://security-tracker.debian.org/tracker/CVE-2021-30022
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30022
[6] https://security-tracker.debian.org/tracker/CVE-2021-30199
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30199

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#986984: unblock: debian-edu-doc/2.11.22

2021-04-21 Thread Holger Levsen
Hi Paul,

On Mon, Apr 19, 2021 at 09:56:01PM +0200, Paul Gevers wrote:
> I guess that's about the best we can do for such -doc packages. I
> realize it's slightly "unfair" because of the different treatment we
> have in the current freeze, but I wonder if adding autopkgtest (to test
> as-installed packages) is really worth it for such packages.
> Documentation changes and translations have always been on the exception
> list, even very explicitly this time around [1], so I think we're happy
> to just unblock manually. Having said that, I'll not stop you from
> adding the test. :)

thanks for your comments! TBH I was hoping for some prior art in some
other doc package, not primarily to ease testing migration but rather
to make sure the contents are as we would like them to be. we've had
failures to build pdf|epub|html versions of some languages in the past
and it would be nice to catch those automatically. I'll guess I'll invent
something myself then...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

There are no jobs on a dead planet. (Also many other things but people mostly
seem to care about jobs.)


signature.asc
Description: PGP signature


Bug#926539: (no subject)

2021-04-21 Thread Omar Sandoval
https://bugzilla.redhat.com/show_bug.cgi?id=1351968 suggests looking up
the console by major:minor instead of name when using /proc/consoles,
would it be possible to have debian-installer do that?

At the very least, it'd be nice to have some kind of workaround
available, like specifying the console name on the command line or
preseed file.



Bug#987322: RFS: nsd/4.3.6-1 -- authoritative domain name server

2021-04-21 Thread Markus Schade

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nsd" or a DD who would grant 
me the upload rights for my DM key for the "nsd" package.


 * Package name: nsd
   Version : 4.3.6-1
   Upstream Author : nsd-us...@nlnetlabs.nl
 * URL : https://www.nlnetlabs.nl/projects/nsd/about/
 * License : MIT, public-domain, BSD-2-clause, NSD-BSD-like
 * Vcs : https://salsa.debian.org/dns-team/nsd
   Section : net

It builds those binary packages:

  nsd - authoritative domain name server

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


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

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

  dget -x https://mentors.debian.net/debian/pool/main/n/nsd/nsd_4.3.6-1.dsc

Changes since the last upload:

 nsd (4.3.6-1) unstable; urgency=medium
 .
   * New upstream version 4.3.6



Regards,
Markus



Bug#987321: openntpd: if-up.d script uses SysV command instead of systemd and blocks boot

2021-04-21 Thread François Cerbelle

Package: openntpd
Version: 1:6.2p3-4.1
Severity: important

Dear Maintainer,

openntpd installs a smart if-up.d script to reload the configuration
when an interface is started. It blocks the boot process until a timeout
occurs at the "Raise network interfaces" step. 
I noticed an "invoke-rc.d force-reload" in the script. this force-reload
is supported by SysV scripts, but not by SystemD scripts, according to
the doc. I changed the "force-reload" to a simple 'reload', and the boot
process is not blocked anymore.



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

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

Versions of packages openntpd depends on:
ii  adduser   3.118
ii  libc6 2.31-11
ii  lsb-base  11.1.0
ii  netbase   6.3

openntpd recommends no packages.

Versions of packages openntpd suggests:
ii  apparmor  2.13.6-10

-- Configuration Files:
/etc/apparmor.d/usr.sbin.ntpd changed:
/usr/sbin/ntpd flags=(attach_disconnected) {
  #include 
  #include 
  # conf
  /etc/openntpd/ntpd.conf r,
  # capabilities
  capability kill,
  capability sys_chroot,
  capability setgid,
  capability setuid,
  capability sys_time,
  capability sys_nice,
  /usr/sbin/ntpd mrix,
  /var/lib/openntpd/db/ntpd.drift rw,
  /var/lib/openntpd/run/ntpd.sock rw,
  /run/openntpd.pid rw,
}

/etc/default/openntpd changed:
DAEMON_OPTS="-f /etc/openntpd/ntpd.conf -p /var/run/openntpd.pid"

/etc/network/if-up.d/openntpd changed:
CONFIG="/etc/openntpd/ntpd.conf"
if [ "${METHOD}"X = "loopback"X ] || [ "${METHOD}"X = "none"X ]
then
exit 0
fi
invoke-rc.d openntpd reload || true

/etc/openntpd/ntpd.conf changed:
listen on 127.0.0.1
servers 0.debian.pool.ntp.org
servers 1.debian.pool.ntp.org
servers 2.debian.pool.ntp.org
servers 3.debian.pool.ntp.org


-- no debconf information

-- 
François - 21 rue d'Eaubonne - 95580 Margency
Free : +33 6 03 01 55 12
http://www.cerbelle.net


signature.asc
Description: PGP signature


Bug#987316: initscripts: tmpfs has wrong size

2021-04-21 Thread Thorsten Glaser
severity 987316 minor
thanks

On Wed, 21 Apr 2021, Roger Lynn wrote:

> Thanks for the clarification. I think that reduces this bug to "Why is my
> tmpfs set to 20% of physical RAM rather than 20% of total virtual memory?"

There’s a difference betwen setting it to 20% and to 20%VM.
The default value is 20%VM though.

tmpfs_size_vm uses vm_size which combines RAM and swap size
and calculates a size in KiB based on it (with some extra
rounding down due to dividing by 100 first in order to stay
within values shell arithmetic can do without UB). However
ram_size and swap_size rely on /proc/meminfo, grep and a
pretty involved sed command, which can even fail badly, as
it doesn’t use sed -n.

If anything fails in calculating vm_size, or if using 20%
instead of 20%VM, the value is passed as '20%' instead of
a size in KiB to mount, so the kernel will do the rest.

I think our best bet to tracking this down would be:

• add “set -x” as first and “set +x” as last line to
  /lib/init/tmpfs.sh
• perhaps also add “grep Total /proc/meminfo” in there
  for extra debugging
• reboot with serial console, so we can actually capture
  all the debug messages

I suspect one of the operations involved fails for you,
or swap is initialised later. Hrm.

I have TMP_SIZE=80%VM in my /etc/default/tmpfs and I get…

$ df -k
Filesystem  1K-blocks  Used   Available  Use%  Mountpoint
tmpfs   64586403624664283397657%   /tmp

$ fgrep Total /proc/meminfo 
MemTotal:8073324 kB
SwapTotal:   3206140 kB

Okaaay, I guess I can reproduce this. Then I can probably
debug this in a VM, as to easier get serial console (I do
have a physical serial port, but…).

> (And the rewording of the manual page would be nice too.)

Agreed, but I believe this is now of minor severity. If
nobody complains I’ll commit that change for the next
regular upload.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*



Bug#987241: uscan: Use version from package.json when mode=git and type=nodejs for multi tar sources

2021-04-21 Thread Pirate Praveen
Control: reopen -1

On 2021, ഏപ്രിൽ 21 9:32:52 PM IST, Yadd  wrote:
>Le 21/04/2021 à 17:23, Pirate Praveen a écrit :
>> On Wed, 21 Apr 2021 15:48:14 +0200 Yadd  wrote:
>>> Hi,
>>>
>>> `pretty=describe` uses the result of `git describe`. You got a
>>> "4.17.4.20" because this is the last tag on the branch you tried to
>>> clone. The "4.17.5" tag is attached to a different branch (unnamed).
>>>
>>> So uscan is right here ;-)
>> 
>> I don't think uscan is right here. The correct version is available in
>> the package.json. I think it'd be a nice option if uscan can pick the
>> version available in package.json instead of us adding it manually for
>> every update. I currently have to hard code the version in watch file
>> which I don't think is a right solution.
>> 
>> Tag is only one way of finding the version and often not used by node
>> projects. package.json is also a way to find the version of the node
>> module and consistently used by all node modules. Since we already have
>> a type=nodejs we know it has a package.json.
>
>This is not the spirit of HEAD/pretty mode: the goal is to pick commits
>after last tag. Upstream did a strange thing in this repo: set a tag
>outside any named branch. I'm not sure we should modify uscan because of
>an unlikely upstream behavior.
>But if Devscript Team agree with you, I can modify "ctype" feature to
>fix tag when last tag is lower than package.json#version, then version
>will be 4.17.5+timestamp instead of 4.17.4.20+timestamp

I have reopened for comments from devscripts team.

It does not have to be the default, but as an optional setting in the watch 
file. May be ctype=nodejs,version=package.json

Or ctype=nodejs,pretty=package.json

In this case it should be 4.17.21+git.timestamp.hash as version in package.json 
is 4.17.21.

uscan supports a lot of weird upstream conventions anyway. Many upstream don't 
use tags consistently so we need ways to handle those cases.

Also checksum option does not support mode=git scheme default values. So I used 
pretty=4.17.21.%cd to force using digits only.

Should I open another bug for using checksum with git ? Current it supports 
only digits in version so ~git or +git or the hash in version does not work.

>Cheers,
>Yadd

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Bug#987290: GIMP 2.10.8-2 crashes on segmentation error while opening in buster

2021-04-21 Thread Bernhard Übelacker

Dear Maintainer,

...

#3  0x559e07a698d8 in gimp_fatal_error ()
#4  0x559e07a6a037 in ?? ()
#5  
#6  0x559e07dd1e3b in gimp_param_spec_layer_id ()
#7  0x559e07cf57ed in gimp_pdb_compat_param_spec ()
#8  0x559e07d02077 in gimp_plug_in_handle_message ()
#9  0x559e07d10501 in gimp_plug_in_manager_call_query ()
#10 0x559e07d085b8 in gimp_plug_in_manager_restore ()
#11 0x559e07d25e7d in ?? ()

...


This backtrace seems similar to following upstream issues:
  https://gitlab.gnome.org/GNOME/gimp/-/issues/4392
  https://gitlab.gnome.org/GNOME/gimp/-/issues/6021   (mentions a possible 
workaround)

And downstream this bug shows up and links to a few others:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968005

Kind regards,
Bernhard



Bug#987285: pound FTCBFS: runs cmake for the build architecture

2021-04-21 Thread Helmut Grohne
Hi Carsten,

On Wed, Apr 21, 2021 at 12:17:05PM +0200, Carsten Leonhardt wrote:
> thanks for the patch - do you think I should try to get this into
> bullseye?

Certainly not. We're deep-frozen and we no longer fix severity normal
bugs at this time. Just fix it with your next upload post-bullseye.

Helmut



Bug#987316: initscripts: tmpfs has wrong size

2021-04-21 Thread Roger Lynn

On 21/04/2021 16:56, Thorsten Glaser wrote:

To “provide no value” you have to actually do…

TMPFS_SIZE=

… in /etc/defaults/tmpfs because the commented-out value is default.

Perhaps rewording tmpfs(5) to say “If this is explicitly set to the
empty string, the kernel default…” is in order?


Thanks for the clarification. I think that reduces this bug to "Why is my 
tmpfs set to 20% of physical RAM rather than 20% of total virtual memory?" 
(And the rewording of the manual page would be nice too.)


I've now tried uncommenting the default TMPFS_SIZE line, and that makes no 
difference. An empty value does give 50% of physical RAM, as expected based 
on Thorsten's explanation.


Regards,

Roger



Bug#987320: dracut: Version is not included in --version, --help or initramfs runtime

2021-04-21 Thread Scott Moser
Package: dracut
Version: 051-1
Severity: normal

Dear Maintainer,

The dracut package does not seem to 'know' its own version.

Example:

$ cat /lib/dracut/dracut-version.sh
DRACUT_VERSION=

$ dracut --version
dracut 

$ dpkg-query --show dracut-core
dracut-core 051-1

$ dracut --help | head -n 5
Usage: /usr/bin/dracut [OPTION]... [ []]

Version:

Creates initial ramdisk images for preloading modules


This is admittedly a minor issue, but also manifests itself in the
initramfs that is created by 'dracut'.  It means an initramfs module
cannot make decisions based on the dracut version.

The fix seems simple enough:

% echo DRACUT_VERSION=051-1 > /lib/dracut/dracut-version.sh
% dracut --version
dracut 051-1


So you just need to manage to write the version to that file during
package build.

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

Kernel: Linux 5.8.0-45-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dracut depends on:
pn  dracut-core  

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  



Bug#987303: neutron-common: fails to install: cp: cannot stat '/usr/share/neutron-common/plugins/ml2/ml2_conf.ini': No such file or directory

2021-04-21 Thread Thomas Goirand
On 4/21/21 11:28 AM, Andreas Beckmann wrote:
> Package: neutron-common
> Version: 2:17.1.1-3
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
> 
>>From the attached log (scroll to the bottom...):
> 
>   Setting up neutron-common (2:17.1.1-3) ...
>   cp: cannot stat '/usr/share/neutron-common/plugins/ml2/ml2_conf.ini': No 
> such file or directory
>   dpkg: error processing package neutron-common (--configure):
>installed neutron-common package post-installation script subprocess 
> returned error exit status 1
>   Processing triggers for ca-certificates (20210119) ...
>   Updating certificates in /etc/ssl/certs...
>   0 added, 0 removed; done.
>   Running hooks in /etc/ca-certificates/update.d...
>   done.
>   Errors were encountered while processing:
>neutron-common
> 
> 
> cheers,
> 
> Andreas
> 

Hi,

Thanks for your bug report.

This was fixed in 2:17.1.1-4 that I just uploaded, before I saw your bug
report. I'm not sure how to fix the BTS metadata then... :/

Cheers,

Thomas Goirand (zigo)



Bug#987241: uscan: Use version from package.json when mode=git and type=nodejs for multi tar sources

2021-04-21 Thread Yadd
Le 21/04/2021 à 17:23, Pirate Praveen a écrit :
> On Wed, 21 Apr 2021 15:48:14 +0200 Yadd  wrote:
>> Hi,
>>
>> `pretty=describe` uses the result of `git describe`. You got a
>> "4.17.4.20" because this is the last tag on the branch you tried to
>> clone. The "4.17.5" tag is attached to a different branch (unnamed).
>>
>> So uscan is right here ;-)
> 
> I don't think uscan is right here. The correct version is available in
> the package.json. I think it'd be a nice option if uscan can pick the
> version available in package.json instead of us adding it manually for
> every update. I currently have to hard code the version in watch file
> which I don't think is a right solution.
> 
> Tag is only one way of finding the version and often not used by node
> projects. package.json is also a way to find the version of the node
> module and consistently used by all node modules. Since we already have
> a type=nodejs we know it has a package.json.

This is not the spirit of HEAD/pretty mode: the goal is to pick commits
after last tag. Upstream did a strange thing in this repo: set a tag
outside any named branch. I'm not sure we should modify uscan because of
an unlikely upstream behavior.
But if Devscript Team agree with you, I can modify "ctype" feature to
fix tag when last tag is lower than package.json#version, then version
will be 4.17.5+timestamp instead of 4.17.4.20+timestamp

Cheers,
Yadd



Bug#987316: initscripts: tmpfs has wrong size

2021-04-21 Thread Thorsten Glaser
On Wed, 21 Apr 2021, Roger Lynn wrote:

> tmpfs(5) says:
>TMPFS_SIZE
>   Maximum  size  for  all tmpfs filesystems if no specific size is
>   provided.  The default is 20%VM (20% of virtual memory,  includ‐
>   ing  swap  space).  If no value is provided here, the kernel de‐
>   fault (50% RAM) will be used.
> 
> I find this confusing, because the default in /etc/defaults/tmpfs is:
> #TMPFS_SIZE=20%VM

I found it confusing as well, which is why I tracked this down.

To “provide no value” you have to actually do…

TMPFS_SIZE=

… in /etc/defaults/tmpfs because the commented-out value is default.

Perhaps rewording tmpfs(5) to say “If this is explicitly set to the
empty string, the kernel default…” is in order?

HTH,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*



Bug#987267: unblock: neutron/17.1.1-3

2021-04-21 Thread Thomas Goirand
Hi,

Version -4 add this commit:

https://salsa.debian.org/openstack-team/services/neutron/-/commit/4840df25084d28bd010e46e97cb4f4866379392e

Did some crap yesterday, backporting the fix from another branch, had to
fix...

Please unblock neutron/17.1.1-4

Cheers,

Thomas Goirand (zigo)



Bug#987241: uscan: Use version from package.json when mode=git and type=nodejs for multi tar sources

2021-04-21 Thread Pirate Praveen
On Wed, 21 Apr 2021 15:48:14 +0200 Yadd  wrote:
> Hi,
> 
> `pretty=describe` uses the result of `git describe`. You got a
> "4.17.4.20" because this is the last tag on the branch you tried to
> clone. The "4.17.5" tag is attached to a different branch (unnamed).
> 
> So uscan is right here ;-)

I don't think uscan is right here. The correct version is available in the 
package.json. I think it'd be a nice option if uscan can pick the version 
available in package.json instead of us adding it manually for every update. I 
currently have to hard code the version in watch file which I don't think is a 
right solution.

Tag is only one way of finding the version and often not used by node projects. 
package.json is also a way to find the version of the node module and 
consistently used by all node modules. Since we already have a type=nodejs we 
know it has a package.json.

> Cheers,
> Yadd
> 
> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#987318: qt5gamepad: Missing qt5 gamepad declarative part (libdeclarative_gamepad.so & co)

2021-04-21 Thread BogDan Vatra
Package: libqt5gamepad5-dev
Version: 5.15.2-2
Severity: important
File: qt5gamepad

Dear Maintainer,

There is no libdeclarative_gamepad.so in any debian package.
Did someone forgot to submit the qml-module-qtgamepad package?

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

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

Versions of packages libqt5gamepad5-dev:amd64 depends on:
ii  libqt5gamepad5  5.15.2-2

libqt5gamepad5-dev:amd64 recommends no packages.

libqt5gamepad5-dev:amd64 suggests no packages.

-- no debconf information


Bug#232584: /usr/bin/svnserve: Need an init.d script?

2021-04-21 Thread Roger Lynn

On 06/04/2021 22:34, Roger Lynn wrote:

I've written a new version of the script for Bullseye, based on Yubao Liu's
version and the template in init-d-script(5). Attached should be the
/etc/init.d/svnserve script and /etc/defaults/svnserve file. I am not an
expert on scripting, but it seems to work. It still needs Yubao Liu's
logrotate file.


And... that version didn't handle restarts properly. Here is a another 
attempt...


Regards,

Roger
#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides:  svnserve
# Required-Start:$syslog $remote_fs $local_fs $network
# Required-Stop: $syslog $remote_fs $local_fs $network
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: SVN server daemon service
# Description:   Debian init script to start the daemon
#serving Subversion repositories.
### END INIT INFO


DAEMON=/usr/bin/svnserve
LOG_FILE=/var/log/svnserve.log

START_ARGS="-c svn:svn"


do_start_prepare()
{
DAEMON_ARGS="-d -T -r $REPOS_DIR --config-file=$CONFIG_FILE 
--log-file=$LOG_FILE $SVNSERVE_OPTIONS"

if [ ! -f "$LOG_FILE" ]; then
touch $LOG_FILE
chown svn:adm $LOG_FILE
chmod 640 $LOG_FILE
fi
}


do_restart_prepare()
{
do_start_prepare
}


Bug#986949: Linux 4.19 staging driver mt7621-mmc has problematic license

2021-04-21 Thread Gernot Hillier

On 15.04.21 16:09, Salvatore Bonaccorso wrote:

For 4.19.y it is now queued up upstream to be dropped, cf.
https://lore.kernel.org/stable/YHghlaftXxH49lUy@sashalap/ .


Thank you, Salvatore - that's for sure way better than removing the file 
in Debian only!




Bug#725934: debsecan: automatically add apt pinning for packages with security issues

2021-04-21 Thread Antoine Beaupré
Control: tag -1 +patch

On 2017-04-13 13:14:37, Paul Wise wrote:
> On Sat, 28 Nov 2015 10:47:54 +0800 Paul Wise wrote:
>
>> There were a couple of bugs, now I am using this:
>
> I've now integrated it into apt, fixed dbgsym and
> moved it out of /etc into /var.

I've reviewed pabs' script and improved it a bit. Here's a "commitlog"
of changes:

 * silence a shellcheck warning
 * linting: fix indentation and add description
 * simplify main loop
 * add explanatory header for generated file
 * add warning at beginning of debsecan script to explain delay

Commitlog also available here, somewhat:

https://gitlab.com/anarcat/puppet/-/commits/b6bc3e3dc982abcc4100143abb6594404b1241ac

The code is attached and also available here:

https://gitlab.com/anarcat/puppet/-/raw/b6bc3e3dc982abcc4100143abb6594404b1241ac/site-modules/profile/files/debsecan-apt-priority

I also wrote this Puppet manifest (also attached) to deploy it on
machines running testing:

https://gitlab.com/anarcat/puppet/-/raw/a7a7b75e0f3a0d2795449e7159ec6c3d023ad508/site-modules/profile/manifests/debsecan.pp

I understand that it would be better if this was merged inside debsecan
itself (and therefore rewritten in Python), but I think just having this
at all would be great. Maybe just shipping the script in the Debian
package would be a start?

Let us not make perfect the ennemy of good here, this has been sitting
in the BTS for 8 years now, can we at least get this to land in bookworm
and see where we go from here? :)

a.

-- 
Si Dieu est, l'homme est esclave ; 
or l'homme peut, doit être libre, donc Dieu n'existe pas.
Et si Dieu existait, il faudrait s'en débarrasser!
- Michel Bakounine
#!/bin/sh

# this program will add APT pinning for packages that are fixed in
# unstable and not testing
#
# see https://bugs.debian.org/725934

set -e

echo "running debsecan check for issues fixed in unstable..." >&2

rm -f /var/lib/debsecan/apt_preferences.disabled
cat > /var/lib/debsecan/apt_preferences.disabled <> /var/lib/debsecan/apt_preferences.disabled
Package: $pkg
Pin: release a=$suite
Pin-Priority: 900

EOF
done
chmod 644 /var/lib/debsecan/apt_preferences.disabled
mv --force /var/lib/debsecan/apt_preferences.disabled /var/lib/debsecan/apt_preferences
# setup debsecan on machines
#
# this is mostly to follow security upgrades from unstable in testing
class profile::debsecan {
  package { 'debsecan':
ensure => present,
  }
  file_line { 'disable_debsecan_mails':
path  => '/etc/default/debsecan',
line  => 'REPORT=false',
match => '^REPORT=.*',
  }
  file { '/usr/sbin/debsecan-apt-priority':
source => 'puppet:///modules/profile/debsecan-apt-priority',
mode   => '0555',
  }
  file { '/etc/apt/apt.conf.d/99debsecan':
content => @(EOF),
APT::Update::Pre-Invoke { "/usr/sbin/debsecan-apt-priority"; };
EOF
  }
}


Bug#987317: Package is missing the AGPLv3 license

2021-04-21 Thread Louis-Philippe Véronneau
Package: src:supysonic
Version: 0.6.2+ds-1
Owner: po...@debian.org

As pointed by ansgar, this package currently does not include the AGPLv3
license in d/copyright and it should.

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987316: initscripts: tmpfs has wrong size

2021-04-21 Thread Roger Lynn
Package: initscripts
Version: 2.96-6
Severity: normal
X-Debbugs-Cc: ro...@rilynn.me.uk

Hi,

I think this bug is not the same as #688412 because /etc/fstab is NOT involved
here.

As shown in the configuration files below, I have configured RAMTMP with the
default size settings.

tmpfs(5) says:
   TMPFS_SIZE
  Maximum  size  for  all tmpfs filesystems if no specific size is
  provided.  The default is 20%VM (20% of virtual memory,  includ‐
  ing  swap  space).  If no value is provided here, the kernel de‐
  fault (50% RAM) will be used.

I find this confusing, because the default in /etc/defaults/tmpfs is:
#TMPFS_SIZE=20%VM

Which is commented out, so presumably the default is for the kernel default to
be used, which should give me 50 % or 2 GB of my 4 GB of RAM:
$ free
   totalusedfree  shared  buff/cache   available
Mem: 396  264432  6665121524 3033500 3435280
Swap:8388604   19784 8368820

However my tmpfs is only 775 MB:
$ df
Filesystem 1K-blocks  Used Available Use% Mounted on
...
tmpfs 792880 0792880   0% /dev/shm
...
tmpfs 792880   856792024   1% /tmp

Which appears to be only 20 % of my physical RAM.

Have I misunderstood something or is there a bug here? This is a recent
Bullseye installation.

Thanks,

Roger


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

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages initscripts depends on:
ii  lsb-base  11.1.0
ii  sysv-rc   2.96-6

Versions of packages initscripts recommends:
ii  e2fsprogs  1.46.2-1
ii  psmisc 23.4-2

initscripts suggests no packages.

-- Configuration Files:
/etc/default/tmpfs changed:
RAMTMP=yes


-- no debconf information


Bug#987315: fwlogwatch: systemd unit with wrong PID file to monitor

2021-04-21 Thread François Cerbelle


Package: fwlogwatch
Version: 1.4-2+b1
Severity: important

Dear Maintainer,

when installed with default choices, service is disabled in
/etc/default/fwlogwatch. Systemd tries to start it but the unit returns
explicitely 1, systemd understands that it had to start it but failed
immediately

when installed with the service enabled, systemd tries to start
fwlogwatch, the process creates the /run/fwlogwatch.pid file (as
explained in the config file), but the systemd unit monitors another
file (bad copy/paste) : htpdate.pid

Changing the unit file to monitor the right PID filename makes
everything fine when the service is enabled. 

I did not find a way to have everything fine (systemd not complaining)
when the service is disabled (in /etc/default/fwlogwatch and/or in
debconf/dpkg-reconfigure).

Thanks a lot for your work.


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

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

Versions of packages fwlogwatch depends on:
ii  debconf [debconf-2.0] 1.5.75
ii  init-system-helpers   1.60
ii  libc6 2.31-11
ii  libcrypt1 1:4.4.18-2
ii  lsb-base  11.1.0
ii  msmtp-mta [mail-transport-agent]  1.8.11-2
ii  rsyslog [system-log-daemon]   8.2102.0-2
ii  zlib1g1:1.2.11.dfsg-2

fwlogwatch recommends no packages.

fwlogwatch suggests no packages.

-- debconf information:
  fwlogwatch/respond: no
* fwlogwatch/cron_parameters: -N -m 20 -z
  fwlogwatch/notify: no
  fwlogwatch/email: root@localhost
  fwlogwatch/buildconfig: true
* fwlogwatch/realtime: true
* fwlogwatch/cron_email: root

-- 
François - 21 rue d'Eaubonne - 95580 Margency
Free : +33 6 03 01 55 12
http://www.cerbelle.net



Bug#983896: [Pkg-raspi-maintainers] Bug#983896: Bug#983896: raspi-firmware: please link /boot/firmware/*.txt to /etc/raspi-firmware/*.txt

2021-04-21 Thread Diederik de Haas
On woensdag 21 april 2021 11:11:43 CEST Holger Levsen wrote:
> whats the diff between /etc/default/raspi-firmware
> and /etc/default/raspi-extra-cmdline ?

The latter is similar to /boot/[firmware/]cmdline.txt on RPi systems which in 
turn gets added to the kernel command line (/proc/cmdline).
I'm about to propose we just add it to /etc/default/raspi-firmware. That way 
one can add comments to that file to explain f.e. why you add those parameters 
and I personally find it confusing that it's a separate file (which I have to 
look up every time).

https://salsa.debian.org/debian/raspi-firmware/-/blob/master/debian/kernel/
postinst.d/z50-raspi-firmware#L185
Shows it's just gets added while processing the raspi-firmware configuration 
script.

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


Bug#975227: syncmaildir: diff for NMU version 1.3.0-1.1

2021-04-21 Thread David Bremner
Control: tags 975227 + patch
Control: tags 975227 + pending

Dear maintainer,

I've prepared an NMU for syncmaildir (versioned as 1.3.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

David
diff -Nru syncmaildir-1.3.0/debian/changelog syncmaildir-1.3.0/debian/changelog
--- syncmaildir-1.3.0/debian/changelog	2018-03-17 13:13:46.0 -0300
+++ syncmaildir-1.3.0/debian/changelog	2021-04-21 11:05:47.0 -0300
@@ -1,3 +1,13 @@
+syncmaildir (1.3.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert some 'grep foo bar | wc -l' to 'grep -c foo bar' in test
+suite.  Bug fix: "FTBFS: running client-server/02-move-mail: .grep:
+log.s2c: binary file matches", thanks to Lucas Nussbaum (Closes:
+#975227).
+
+ -- David Bremner   Wed, 21 Apr 2021 11:05:47 -0300
+
 syncmaildir (1.3.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru syncmaildir-1.3.0/debian/patches/replace-use-of-grep--wc-with-grep--c-for.patch syncmaildir-1.3.0/debian/patches/replace-use-of-grep--wc-with-grep--c-for.patch
--- syncmaildir-1.3.0/debian/patches/replace-use-of-grep--wc-with-grep--c-for.patch	1969-12-31 20:00:00.0 -0400
+++ syncmaildir-1.3.0/debian/patches/replace-use-of-grep--wc-with-grep--c-for.patch	2021-04-21 11:05:47.0 -0300
@@ -0,0 +1,186 @@
+From: David Bremner 
+Date: Wed, 21 Apr 2021 08:16:11 -0300
+X-Dgit-Generated: 1.3.0-1.1 6d7213c4f0646e9a896aa3acc16c886914bdd01d
+Subject: Replace use of "grep | wc" with grep -c for binary files.
+
+The latter actually reports a number of matches on stdout, making the
+tests pass.
+
+---
+
+--- syncmaildir-1.3.0.orig/tests.d/client-server/02-move-mail
 syncmaildir-1.3.0/tests.d/client-server/02-move-mail
+@@ -9,7 +9,7 @@ msync 2
+ 
+ test_eq Mail target/Mail 
+ 
+-X=`grep '^MOVE ' log.s2c | wc -l`
++X=`grep -c '^MOVE ' log.s2c`
+ assert $X 1 "missing MOVE in s2c"
+ 
+ X=`grep '^COMMIT$' log.c2s | wc -l`
+--- syncmaildir-1.3.0.orig/tests.d/client-server/03-copy-mail
 syncmaildir-1.3.0/tests.d/client-server/03-copy-mail
+@@ -9,7 +9,7 @@ msync 2
+ 
+ test_eq Mail target/Mail 
+ 
+-X=`grep '^COPY ' log.s2c | wc -l`
++X=`grep -c '^COPY ' log.s2c`
+ assert $X 1 "missing COPY in s2c"
+ 
+ X=`grep '^GET ' log.c2s | wc -l`
+--- syncmaildir-1.3.0.orig/tests.d/client-server/04-replace-header
 syncmaildir-1.3.0/tests.d/client-server/04-replace-header
+@@ -9,7 +9,7 @@ msync 2
+ 
+ test_eq Mail target/Mail 
+ 
+-X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
++X=`grep -c '^REPLACEHEADER ' log.s2c`
+ assert $X 1 "missing REPLACEHEADER in s2c"
+ 
+ X=`grep '^GETHEADER ' log.c2s | wc -l`
+--- syncmaildir-1.3.0.orig/tests.d/client-server/05-replace-header-fail
 syncmaildir-1.3.0/tests.d/client-server/05-replace-header-fail
+@@ -11,7 +11,7 @@ msync 2
+ 
+ test_eq target/Mail.old target/Mail 
+ 
+-X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
++X=`grep -c '^REPLACEHEADER ' log.s2c`
+ assert $X 1 "missing REPLACEHEADER in s2c"
+ 
+ X=`grep '^GETHEADER ' log.c2s | wc -l`
+--- syncmaildir-1.3.0.orig/tests.d/client-server/06-replace-header-already-ok
 syncmaildir-1.3.0/tests.d/client-server/06-replace-header-already-ok
+@@ -10,7 +10,7 @@ test_eq Mail target/Mail
+ msync 2
+ 
+ test_eq Mail target/Mail 
+-X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
++X=`grep -c '^REPLACEHEADER ' log.s2c`
+ assert $X 1 "missing REPLACEHEADER in s2c"
+ 
+ X=`grep '^GETHEADER ' log.c2s | wc -l`
+--- syncmaildir-1.3.0.orig/tests.d/client-server/08-copy-mail-already-ok
 syncmaildir-1.3.0/tests.d/client-server/08-copy-mail-already-ok
+@@ -10,7 +10,7 @@ msync 2
+ 
+ test_eq Mail target/Mail 
+ 
+-X=`grep '^COPY ' log.s2c | wc -l`
++X=`grep -c '^COPY ' log.s2c`
+ assert $X 1 "missing COPY in s2c"
+ 
+ X=`grep '^GET ' log.c2s | wc -l`
+--- syncmaildir-1.3.0.orig/tests.d/client-server/10-delete-already-done
 syncmaildir-1.3.0/tests.d/client-server/10-delete-already-done
+@@ -10,7 +10,7 @@ msync 2
+ 
+ test_eq Mail target/Mail 
+ 
+-X=`grep '^DELETE ' log.s2c | wc -l`
++X=`grep -c '^DELETE ' log.s2c`
+ assert $X 1 "missing DELETE in s2c"
+ 
+ X=`grep '^COMMIT$' log.c2s | wc -l`
+--- syncmaildir-1.3.0.orig/tests.d/client-server/12-skip-add-already-there
 syncmaildir-1.3.0/tests.d/client-server/12-skip-add-already-there
+@@ -10,7 +10,7 @@ msync 2
+ 
+ test_eq Mail target/Mail 
+ 
+-X=`grep '^ADD ' log.s2c | wc -l`
++X=`grep -c '^ADD ' log.s2c`
+ assert $X 1 "missing ADD in s2c"
+ 
+ X=`grep '^GET ' log.c2s | wc -l`
+--- syncmaildir-1.3.0.orig/tests.d/client-server/14-skip-copy-already-there-copy-only
 syncmaildir-1.3.0/tests.d/client-server/14-skip-copy-already-there-copy-only
+@@ -14,7 +14,7 @@ rm Mail/cur/$C
+ 
+ test_eq Mail target/Mail 
+ 
+-X=`grep '^COPY ' log.s2c | wc -l`
++X=`grep -c '^COPY ' log.s2c`
+ assert $X 1 "missing COPY in s2c"
+ 
+ X=`grep '^GET ' log.c2s | wc -l`
+--- syncmaildir-1.3.0.orig/tests.d/client-server/18-copybody
 

Bug#987314: libabsl20200923: symbolizer miscomputes Thumb function bounds on armhf/armel

2021-04-21 Thread Benjamin Barenblat
Package: libabsl20200923
Version: 0~20200923.3-2
Tags: upstream fixed-upstream pending

The Abseil symbolizer has an off-by-one error when computing bounds for
Thumb functions. This can cause it to symbolize incorrectly in binaries
that contain both ARM and Thumb functions.


signature.asc
Description: PGP signature


Bug#987313: Patched source code should be advertised, as per the AGPLv3

2021-04-21 Thread Louis-Philippe Véronneau
Package: supysonic
Version: 0.6.2+ds-1
Owner: po...@debian.org

Supysonic is AGPLv3 licensed and as such, the patched source code Debian
uses (https://salsa.debian.org/python-team/packages/supysonic) should be
what is shown on the web page, not the upstream one.

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987312: please allow ignoring recommends/suggests

2021-04-21 Thread Marc Haber
Package: debspawn
Version: 0.4.1-1
Severity: wishlist

Hi,

I would like to have a possibility to not install recommends/suggests in
the container, to keep the containers small.

Greetings
Marc


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

Kernel: Linux 5.11.15-zgsrv20080 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debspawn depends on:
ii  debootstrap1.0.123
ii  python33.9.2-3
ii  python3-toml   0.10.1-1
ii  systemd-container  247.3-5
ii  zstd   1.4.8+dfsg-2.1

Versions of packages debspawn recommends:
ii  build-essential  12.9
ii  devscripts   2.21.1

Versions of packages debspawn suggests:
ii  sudo  1.9.5p2-3.0

-- no debconf information



Bug#987311: unblock: pgpool2/4.1.4-3

2021-04-21 Thread Christoph Berg
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pgpool2.

[ Reason ]
The new version fixes a bug which prevents the counter of open
connection from being reduced when a query is canceled.

[ Impact ]
If the bug is not fixed, connection pools will become unavailable.

[ Tests ]
The package passes the "jdbc" smoke tests exercising a connection
through the pool. (The upstream test system is unfortunately quite
involved and doesn't easily run at build time.)

[ Risks ]
The fix is a trivial one-liner.

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

unblock pgpool2/4.1.4-3

Christoph

No differences were encountered between the control files

diff -Nru pgpool2-4.1.4/debian/changelog pgpool2-4.1.4/debian/changelog
--- pgpool2-4.1.4/debian/changelog	2020-10-09 16:48:13.0 +0200
+++ pgpool2-4.1.4/debian/changelog	2021-04-19 17:43:35.0 +0200
@@ -1,3 +1,10 @@
+pgpool2 (4.1.4-3) unstable; urgency=medium
+
+  * Fix connection count when query is canceled. (Closes: #987183,
+upstream #656, git 6d6e4cc3).
+
+ -- Christoph Berg   Mon, 19 Apr 2021 17:43:35 +0200
+
 pgpool2 (4.1.4-2) unstable; urgency=medium
 
   * Bump test-dependency on pg-common for `pg_buildext psql`.
diff -Nru pgpool2-4.1.4/debian/patches/987183 pgpool2-4.1.4/debian/patches/987183
--- pgpool2-4.1.4/debian/patches/987183	1970-01-01 01:00:00.0 +0100
+++ pgpool2-4.1.4/debian/patches/987183	2021-04-19 17:42:41.0 +0200
@@ -0,0 +1,25 @@
+From: Tatsuo Ishii 
+Date: Thu, 29 Oct 2020 20:59:23 + (+0900)
+Subject: Fix connection count when query is canceled.
+X-Git-Tag: V4_1_5~5
+X-Git-Url: http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff_plain;h=6d6e4cc3d7ce0cdfcf9b2b6ea3ac5dc04b366aec
+
+Fix connection count when query is canceled.
+
+Connection counter was not counted down when a query is canceled.
+
+Per bug 656.
+---
+
+diff --git a/src/protocol/child.c b/src/protocol/child.c
+index af1dd50b..47482f61 100644
+--- a/src/protocol/child.c
 b/src/protocol/child.c
+@@ -2302,6 +2302,7 @@ retry_startup:
+ 	{
+ 		cancel_request((CancelPacket *) sp->startup_packet);
+ 		pool_free_startup_packet(sp);
++		connection_count_down();
+ 		return NULL;
+ 	}
+ 
diff -Nru pgpool2-4.1.4/debian/patches/series pgpool2-4.1.4/debian/patches/series
--- pgpool2-4.1.4/debian/patches/series	2020-10-06 15:42:58.0 +0200
+++ pgpool2-4.1.4/debian/patches/series	2021-04-19 17:42:41.0 +0200
@@ -1,2 +1,3 @@
 pgpool2-debian-config.patch
 sbin-paths
+987183


Bug#975227: [PATCH] Replace use of "grep | wc" with grep -c for binary files.

2021-04-21 Thread Antoine Beaupré
LGTM.

On 2021-04-21 08:20:36, David Bremner wrote:
> The latter actually reports a number of matches on stdout, making the
> tests pass.
> ---
>  tests.d/client-server/02-move-mail | 2 +-
>  tests.d/client-server/03-copy-mail | 2 +-
>  tests.d/client-server/04-replace-header| 2 +-
>  tests.d/client-server/05-replace-header-fail   | 2 +-
>  tests.d/client-server/06-replace-header-already-ok | 2 +-
>  tests.d/client-server/08-copy-mail-already-ok  | 2 +-
>  tests.d/client-server/10-delete-already-done   | 2 +-
>  tests.d/client-server/12-skip-add-already-there| 2 +-
>  tests.d/client-server/14-skip-copy-already-there-copy-only | 2 +-
>  tests.d/client-server/18-copybody  | 2 +-
>  tests.d/client-server/19-copybody-already-ok   | 2 +-
>  tests.d/client-server/22-replace   | 2 +-
>  tests.d/client-server/23-replace-aready-ok | 2 +-
>  tests.d/client-server/34-move-fail2| 2 +-
>  tests.d/client-server/35-delete| 2 +-
>  tests.d/client-server/36-move-fail3| 2 +-
>  16 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/tests.d/client-server/02-move-mail 
> b/tests.d/client-server/02-move-mail
> index e3dbd90..7828b69 100644
> --- a/tests.d/client-server/02-move-mail
> +++ b/tests.d/client-server/02-move-mail
> @@ -9,7 +9,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^MOVE ' log.s2c | wc -l`
> +X=`grep -c '^MOVE ' log.s2c`
>  assert $X 1 "missing MOVE in s2c"
>  
>  X=`grep '^COMMIT$' log.c2s | wc -l`
> diff --git a/tests.d/client-server/03-copy-mail 
> b/tests.d/client-server/03-copy-mail
> index 0037531..ec185a2 100644
> --- a/tests.d/client-server/03-copy-mail
> +++ b/tests.d/client-server/03-copy-mail
> @@ -9,7 +9,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^COPY ' log.s2c | wc -l`
> +X=`grep -c '^COPY ' log.s2c`
>  assert $X 1 "missing COPY in s2c"
>  
>  X=`grep '^GET ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/04-replace-header 
> b/tests.d/client-server/04-replace-header
> index 8af6cbb..1ffcaf1 100644
> --- a/tests.d/client-server/04-replace-header
> +++ b/tests.d/client-server/04-replace-header
> @@ -9,7 +9,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
> +X=`grep -c '^REPLACEHEADER ' log.s2c`
>  assert $X 1 "missing REPLACEHEADER in s2c"
>  
>  X=`grep '^GETHEADER ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/05-replace-header-fail 
> b/tests.d/client-server/05-replace-header-fail
> index 8743c24..9599251 100644
> --- a/tests.d/client-server/05-replace-header-fail
> +++ b/tests.d/client-server/05-replace-header-fail
> @@ -11,7 +11,7 @@ msync 2
>  
>  test_eq target/Mail.old target/Mail 
>  
> -X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
> +X=`grep -c '^REPLACEHEADER ' log.s2c`
>  assert $X 1 "missing REPLACEHEADER in s2c"
>  
>  X=`grep '^GETHEADER ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/06-replace-header-already-ok 
> b/tests.d/client-server/06-replace-header-already-ok
> index 1d29c14..c2c0b2f 100644
> --- a/tests.d/client-server/06-replace-header-already-ok
> +++ b/tests.d/client-server/06-replace-header-already-ok
> @@ -10,7 +10,7 @@ test_eq Mail target/Mail
>  msync 2
>  
>  test_eq Mail target/Mail 
> -X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
> +X=`grep -c '^REPLACEHEADER ' log.s2c`
>  assert $X 1 "missing REPLACEHEADER in s2c"
>  
>  X=`grep '^GETHEADER ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/08-copy-mail-already-ok 
> b/tests.d/client-server/08-copy-mail-already-ok
> index 781a109..0e481e5 100644
> --- a/tests.d/client-server/08-copy-mail-already-ok
> +++ b/tests.d/client-server/08-copy-mail-already-ok
> @@ -10,7 +10,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^COPY ' log.s2c | wc -l`
> +X=`grep -c '^COPY ' log.s2c`
>  assert $X 1 "missing COPY in s2c"
>  
>  X=`grep '^GET ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/10-delete-already-done 
> b/tests.d/client-server/10-delete-already-done
> index 926394d..c15603b 100644
> --- a/tests.d/client-server/10-delete-already-done
> +++ b/tests.d/client-server/10-delete-already-done
> @@ -10,7 +10,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^DELETE ' log.s2c | wc -l`
> +X=`grep -c '^DELETE ' log.s2c`
>  assert $X 1 "missing DELETE in s2c"
>  
>  X=`grep '^COMMIT$' log.c2s | wc -l`
> diff --git a/tests.d/client-server/12-skip-add-already-there 
> b/tests.d/client-server/12-skip-add-already-there
> index 0a53a80..38ed3ff 100644
> --- a/tests.d/client-server/12-skip-add-already-there
> +++ b/tests.d/client-server/12-skip-add-already-there
> @@ -10,7 +10,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^ADD ' log.s2c | wc -l`
> +X=`grep -c '^ADD ' log.s2c`
>  assert $X 1 

Bug#987310: ifupdown-extra: Missing "]" in 20static-routes script

2021-04-21 Thread Adoal Xu
Package: ifupdown-extra
Version: 0.31
Severity: normal

Dear Maintainer,

In line 83 of file '/etc/network/if-up.d/20static-routes', a right
bracket is missing. Caused syntax error.
So if static routing is specified in '/etc/network/routes' for some
interface such as ens192, it will be turned into 'blackhole'.
Adding the missing bracket fixes.

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

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

Versions of packages ifupdown-extra depends on:
ii  bind9-host [host]1:9.16.13-1
ii  curl 7.74.0-1.2
ii  dpkg 1.20.7.1
ii  iproute2 5.10.0-4
ii  iputils-arping   3:20210202-1
ii  iputils-ping [ping]  3:20210202-1
ii  lsb-base 11.1.0
ii  ncat 7.91+dfsg1+really7.80+dfsg1-2
ii  net-tools1.60+git20181103.0eebece-1

Versions of packages ifupdown-extra recommends:
ii  ethtool  1:5.9-1
ii  ndisc6   1.0.4-2

ifupdown-extra suggests no packages.

-- Configuration Files:
/etc/network/routes changed [not included]

-- no debconf information



Bug#977299: Fixed in 5.11

2021-04-21 Thread Chris Dos
On Wed, 21 Apr 2021 07:13:49 +0200 Salvatore Bonaccorso  
wrote:
> Hi,
>
> On Tue, Apr 20, 2021 at 01:12:35PM -0600, Chris Dos wrote:
> > Both of these drivers work in 5.11.  Is Debian planning on moving to 5.11 or
> > sticking with 5.10?  If sticking with 5.10 can the bluetooth drivers be
> > patched to include Intel Typhoon Peak?
>
> Debian bullseye will be shipped with a 5.10.y based kernel, later
> uploads will move to 5.12 and later though.
>
> Do you have references to the specfic upstream commits which add the
> support?
>
> Regards,
> Salvatore


The AX210 wireless has been included in the kernel since 5.10-rc7.  So that
one is already done.  The Typhoon Peak Bluetooth was supposed to be added in
5.11.  The only information I've been able to find are the following:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=875e16759005e3bdaa84eb2741281f37ba35b886
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e4e3f73b9f4

This Ubuntu bug had the original details:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1890130

    Chris



Bug#987309: dahdi-dkms: insufficient dkms dependency

2021-04-21 Thread Andreas Beckmann
Package: dahdi-dkms
Version: 2.11.1.0.20170917~dfsg-7.3
Severity: serious
Tags: patch
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 2.11.1.0.20170917~dfsg-7

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails.

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

[...]
  Setting up dahdi-dkms (1:2.11.1.0.20170917~dfsg-7.3~deb11anbe1) ...
  Loading new dahdi-2.11.1.0.20170917~dfsg-7.3~deb11anbe1 DKMS files...
  It is likely that 4.19.0-9-amd64 belongs to a chroot's host
  Building for 4.19.0-16-amd64
  Building initial module for 4.19.0-16-amd64
  Error! Bad return status for module build on kernel: 4.19.0-16-amd64 (x86_64)
  Consult 
/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-7.3~deb11anbe1/build/make.log for 
more information.
  dpkg: error processing package dahdi-dkms (--configure):
   installed dahdi-dkms package post-installation script subprocess returned 
error exit status 10
  dpkg: dependency problems prevent configuration of dahdi-linux:
   dahdi-linux depends on dahdi-dkms | dahdi-source; however:
Package dahdi-dkms is not configured yet.
Package dahdi-source is not installed.
  
  dpkg: error processing package dahdi-linux (--configure):
   dependency problems - leaving unconfigured
  Processing triggers for libc-bin (2.28-10) ...
  Processing triggers for mime-support (3.62) ...
  Errors were encountered while processing:
   dahdi-dkms
   dahdi-linux

In this upgrade path dahdi-dkms was upgraded before dkms.
This is probably related to the compiler used to build the module.
This can be fixed by bumping the dkms dependency s.t. a dkms version
is used that exports the compiler used to build the kernel (and
depended upon by the kernel headers) as CC.

The version is set s.t. it does not block of the current version in sid.
I'll NMU this fix after the current sid version has migrated to testing.


cheers,

Andreas
diff -Nru dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 
dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog
--- dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 2021-04-04 
22:42:52.0 +0200
+++ dahdi-linux-2.11.1.0.20170917~dfsg/debian/changelog 2021-04-21 
10:54:41.0 +0200
@@ -1,3 +1,12 @@
+dahdi-linux (1:2.11.1.0.20170917~dfsg-7.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * dahdi-dkms: Bump dkms dependency to (>= 2.8.4-3~) to reliably use the
+kernel's compiler to compile the module.  (Closes: #-1)
+  * dahdi-dkms: Drop wget dependency. Downloading firmware is disabled.
+
+ -- Andreas Beckmann   Wed, 21 Apr 2021 10:54:41 +0200
+
 dahdi-linux (1:2.11.1.0.20170917~dfsg-7.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru dahdi-linux-2.11.1.0.20170917~dfsg/debian/control 
dahdi-linux-2.11.1.0.20170917~dfsg/debian/control
--- dahdi-linux-2.11.1.0.20170917~dfsg/debian/control   2021-04-02 
22:51:16.0 +0200
+++ dahdi-linux-2.11.1.0.20170917~dfsg/debian/control   2021-04-21 
10:54:41.0 +0200
@@ -18,7 +18,7 @@
 Multi-Arch: foreign
 Depends: ${misc:Depends}, procps, fxload, dahdi-dkms | dahdi-source
 Description: DAHDI telephony interface - Linux userspace parts
- DAHDI (formly Zaptel) is an interface for telephony devices used by e.g.
+ DAHDI (formerly Zaptel) is an interface for telephony devices used by e.g.
  the Asterisk PBX software. The dahdi-* packages provide the kernel
  DAHDI kernel modules and their required setup environment.
  .
@@ -32,7 +32,7 @@
 Depends: ${misc:Depends}, debhelper (>> 4.0), module-assistant (>= 0.8.1), 
bzip2
 Recommends: dahdi-linux
 Description: DAHDI telephony interface - source code for kernel driver
- DAHDI (formly Zaptel) is an interface for telephony devices used by e.g.
+ DAHDI (formerly Zaptel) is an interface for telephony devices used by e.g.
  the Asterisk PBX software. The dahdi-* packages provide the kernel
  DAHDI kernel modules and their required setup environment, as well as
  basic headers for building DAHDI modules and utilities.
@@ -42,10 +42,10 @@
 Package: dahdi-dkms
 Section: kernel
 Architecture: all
-Depends: ${misc:Depends}, dkms, make, libc6-dev, dpkg-dev, gcc, wget, gawk
+Depends: ${misc:Depends}, dkms, make, libc6-dev, dpkg-dev, gcc, gawk, dkms (>= 
2.8.4-3~)
 Recommends: dahdi-linux
 Description: DAHDI telephony interface (dkms kernel driver)
- DAHDI (formly Zaptel) is an interface for telephony devices used by e.g.
+ DAHDI (formerly Zaptel) is an interface for telephony devices used by e.g.
  the Asterisk PBX software. The dahdi-* packages provide the kernel
  DAHDI kernel modules and their required setup environment.
  .


Bug#987297: [Debian-med-packaging] Bug#987297: Dependency to libpth20

2021-04-21 Thread Sascha Steinbiss
Hi Yutaka and Andreas,

thanks for bringing this to our attention. I'll take a look.

Best regards
Sascha

On 21.04.21 08:51, Andreas Tille wrote:
> Hi Yutaka,
> 
> thanks for your verbose explanation.  I think we'll do nothing in
> current freeze time.  But once freeze is over we can deal with this
> quickly.  In case we might forget simply raise severity of the bug
> to create some signal. ;-)
> 
> Kind regards
> 
>  Andreas.
> 



Bug#979075: redshift: diff for NMU version 1.12-4.1

2021-04-21 Thread Adrian Bunk
Control: tags 979075 + patch
Control: tags 979075 + pending

Dear maintainer,

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

cu
Adrian
diff -Nru redshift-1.12/debian/changelog redshift-1.12/debian/changelog
--- redshift-1.12/debian/changelog	2020-12-12 18:43:43.0 +0200
+++ redshift-1.12/debian/changelog	2021-04-21 14:34:47.0 +0300
@@ -1,3 +1,11 @@
+redshift (1.12-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add an empty override_dh_installsystemduser to debian/rules
+to fix double instances caused by dh compat bump. (Closes: #979075)
+
+ -- Adrian Bunk   Wed, 21 Apr 2021 14:34:47 +0300
+
 redshift (1.12-4) unstable; urgency=medium
 
   * Fix AppArmor profile under Wayland (Closes: #977210)
diff -Nru redshift-1.12/debian/rules redshift-1.12/debian/rules
--- redshift-1.12/debian/rules	2020-12-12 18:43:43.0 +0200
+++ redshift-1.12/debian/rules	2021-04-21 14:34:44.0 +0300
@@ -23,3 +23,5 @@
 
 override_dh_installchangelogs:
 	dh_installchangelogs NEWS
+
+override_dh_installsystemduser:


Bug#986622: [Pkg-clamav-devel] Bug#986622: fixes

2021-04-21 Thread Athanasius
  There's also the point that the current buster version is logging:

Apr 18 07:25:31 river freshclam[25421]: Sun Apr 18 07:25:31 2021 -> ^Your 
ClamAV installation is OUTDATED!
Apr 18 07:25:31 river freshclam[25421]: Sun Apr 18 07:25:31 2021 -> ^Local 
version: 0.102.4 Recommended version: 0.103.2
Apr 18 07:25:31 river freshclam[25421]: Sun Apr 18 07:25:31 2021 -> DON'T 
PANIC! Read https://www.clamav.net/documents/upgrading-clamav

once an hour.

So long as any Debian update of the packages both addresses the
outstanding CVEs *and* quiets this logging I'll be happy.
-- 
- Athanasius = Athanasius(at)miggy.org / https://miggy.org/
  GPG/PGP Key: https://miggy.org/gpg-key
   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME



Bug#915687: Fixed

2021-04-21 Thread Aki Tuomi
This has now been fixed in upstream with

https://github.com/dovecot/core/compare/8d84e36e312d523dd93b821e63f16a5a22e77fbf%5E..af41ad228f9a165980e14036a2d8693e27da8ddd.patch

Regards,
Aki Tuomi
Open-Xchange Oy



Bug#987308: cifs-utils: CVE-2021-20208: cifs.upcall kerberos auth leak in container

2021-04-21 Thread Salvatore Bonaccorso
Source: cifs-utils
Version: 2:6.11-2
Severity: important
Tags: security upstream
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14651
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cifs-utils.

CVE-2021-20208[0]:
| A flaw was found in cifs-utils in versions before 6.13. A user when
| mounting a krb5 CIFS file system from within a container can use
| Kerberos credentials of the host. The highest threat from this
| vulnerability is to data confidentiality and integrity.


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-2021-20208
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20208
[1] https://bugzilla.samba.org/show_bug.cgi?id=14651
[2] https://lists.samba.org/archive/samba-technical/2021-April/136467.html
[3] 
https://git.samba.org/cifs-utils.git/?p=cifs-utils.git;a=commit;h=e461afd8cfa6d0781ae0c5c10e89b6ef1ca6da32

Regards,
Salvatore



Bug#975227: [PATCH] Replace use of "grep | wc" with grep -c for binary files.

2021-04-21 Thread David Bremner
The latter actually reports a number of matches on stdout, making the
tests pass.
---
 tests.d/client-server/02-move-mail | 2 +-
 tests.d/client-server/03-copy-mail | 2 +-
 tests.d/client-server/04-replace-header| 2 +-
 tests.d/client-server/05-replace-header-fail   | 2 +-
 tests.d/client-server/06-replace-header-already-ok | 2 +-
 tests.d/client-server/08-copy-mail-already-ok  | 2 +-
 tests.d/client-server/10-delete-already-done   | 2 +-
 tests.d/client-server/12-skip-add-already-there| 2 +-
 tests.d/client-server/14-skip-copy-already-there-copy-only | 2 +-
 tests.d/client-server/18-copybody  | 2 +-
 tests.d/client-server/19-copybody-already-ok   | 2 +-
 tests.d/client-server/22-replace   | 2 +-
 tests.d/client-server/23-replace-aready-ok | 2 +-
 tests.d/client-server/34-move-fail2| 2 +-
 tests.d/client-server/35-delete| 2 +-
 tests.d/client-server/36-move-fail3| 2 +-
 16 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/tests.d/client-server/02-move-mail 
b/tests.d/client-server/02-move-mail
index e3dbd90..7828b69 100644
--- a/tests.d/client-server/02-move-mail
+++ b/tests.d/client-server/02-move-mail
@@ -9,7 +9,7 @@ msync 2
 
 test_eq Mail target/Mail 
 
-X=`grep '^MOVE ' log.s2c | wc -l`
+X=`grep -c '^MOVE ' log.s2c`
 assert $X 1 "missing MOVE in s2c"
 
 X=`grep '^COMMIT$' log.c2s | wc -l`
diff --git a/tests.d/client-server/03-copy-mail 
b/tests.d/client-server/03-copy-mail
index 0037531..ec185a2 100644
--- a/tests.d/client-server/03-copy-mail
+++ b/tests.d/client-server/03-copy-mail
@@ -9,7 +9,7 @@ msync 2
 
 test_eq Mail target/Mail 
 
-X=`grep '^COPY ' log.s2c | wc -l`
+X=`grep -c '^COPY ' log.s2c`
 assert $X 1 "missing COPY in s2c"
 
 X=`grep '^GET ' log.c2s | wc -l`
diff --git a/tests.d/client-server/04-replace-header 
b/tests.d/client-server/04-replace-header
index 8af6cbb..1ffcaf1 100644
--- a/tests.d/client-server/04-replace-header
+++ b/tests.d/client-server/04-replace-header
@@ -9,7 +9,7 @@ msync 2
 
 test_eq Mail target/Mail 
 
-X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
+X=`grep -c '^REPLACEHEADER ' log.s2c`
 assert $X 1 "missing REPLACEHEADER in s2c"
 
 X=`grep '^GETHEADER ' log.c2s | wc -l`
diff --git a/tests.d/client-server/05-replace-header-fail 
b/tests.d/client-server/05-replace-header-fail
index 8743c24..9599251 100644
--- a/tests.d/client-server/05-replace-header-fail
+++ b/tests.d/client-server/05-replace-header-fail
@@ -11,7 +11,7 @@ msync 2
 
 test_eq target/Mail.old target/Mail 
 
-X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
+X=`grep -c '^REPLACEHEADER ' log.s2c`
 assert $X 1 "missing REPLACEHEADER in s2c"
 
 X=`grep '^GETHEADER ' log.c2s | wc -l`
diff --git a/tests.d/client-server/06-replace-header-already-ok 
b/tests.d/client-server/06-replace-header-already-ok
index 1d29c14..c2c0b2f 100644
--- a/tests.d/client-server/06-replace-header-already-ok
+++ b/tests.d/client-server/06-replace-header-already-ok
@@ -10,7 +10,7 @@ test_eq Mail target/Mail
 msync 2
 
 test_eq Mail target/Mail 
-X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
+X=`grep -c '^REPLACEHEADER ' log.s2c`
 assert $X 1 "missing REPLACEHEADER in s2c"
 
 X=`grep '^GETHEADER ' log.c2s | wc -l`
diff --git a/tests.d/client-server/08-copy-mail-already-ok 
b/tests.d/client-server/08-copy-mail-already-ok
index 781a109..0e481e5 100644
--- a/tests.d/client-server/08-copy-mail-already-ok
+++ b/tests.d/client-server/08-copy-mail-already-ok
@@ -10,7 +10,7 @@ msync 2
 
 test_eq Mail target/Mail 
 
-X=`grep '^COPY ' log.s2c | wc -l`
+X=`grep -c '^COPY ' log.s2c`
 assert $X 1 "missing COPY in s2c"
 
 X=`grep '^GET ' log.c2s | wc -l`
diff --git a/tests.d/client-server/10-delete-already-done 
b/tests.d/client-server/10-delete-already-done
index 926394d..c15603b 100644
--- a/tests.d/client-server/10-delete-already-done
+++ b/tests.d/client-server/10-delete-already-done
@@ -10,7 +10,7 @@ msync 2
 
 test_eq Mail target/Mail 
 
-X=`grep '^DELETE ' log.s2c | wc -l`
+X=`grep -c '^DELETE ' log.s2c`
 assert $X 1 "missing DELETE in s2c"
 
 X=`grep '^COMMIT$' log.c2s | wc -l`
diff --git a/tests.d/client-server/12-skip-add-already-there 
b/tests.d/client-server/12-skip-add-already-there
index 0a53a80..38ed3ff 100644
--- a/tests.d/client-server/12-skip-add-already-there
+++ b/tests.d/client-server/12-skip-add-already-there
@@ -10,7 +10,7 @@ msync 2
 
 test_eq Mail target/Mail 
 
-X=`grep '^ADD ' log.s2c | wc -l`
+X=`grep -c '^ADD ' log.s2c`
 assert $X 1 "missing ADD in s2c"
 
 X=`grep '^GET ' log.c2s | wc -l`
diff --git a/tests.d/client-server/14-skip-copy-already-there-copy-only 
b/tests.d/client-server/14-skip-copy-already-there-copy-only
index b5da177..08734a8 100644
--- a/tests.d/client-server/14-skip-copy-already-there-copy-only
+++ 

Bug#987199: closed by Debian FTP Masters (reply to Georges Khaznadar ) (Bug#987199: fixed in kwartz-client 1.9-1)

2021-04-21 Thread Andreas Beckmann

Control: found -1 1.9-1

Hi Georges,
the fix introduced a regression:

6m13.7s DEBUG: Starting command: ['chroot', 
'/srv/piuparts/tmp/tmpxQHTqw', 'dpkg', '--purge', 'kwartz-client']

6m13.9s DUMP:
  (Reading database ... 4791 files and directories currently installed.)
  Purging configuration files for kwartz-client (1.9-1) ...
  cp: cannot stat '/etc/nslcd.conf.before-kwartz': No such file or 
directory

  dpkg: error processing package kwartz-client (--purge):
   installed kwartz-client package post-removal script subprocess 
returned error exit status 1

  Errors were encountered while processing:
   kwartz-client


Andreas



Bug#987307: unblock: nodejs/12.21.0~dfsg-4

2021-04-21 Thread Jérémy Lal
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nodejs

[ Reason ]
Fixing bug #987301: please add Breaks: node-babel-runtime (<< 7)

[ Impact ]
Problem for users having node-babel-runtime when upgrading
from buster to bullseye.

[ Tests ]
Piuparts... see also bug report.

[ Risks ]
Probably none.

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

unblock nodejs/12.21.0~dfsg-4
diff -Nru nodejs-12.21.0~dfsg/debian/changelog 
nodejs-12.21.0~dfsg/debian/changelog
--- nodejs-12.21.0~dfsg/debian/changelog2021-03-19 18:43:52.0 
+0100
+++ nodejs-12.21.0~dfsg/debian/changelog2021-04-21 12:42:46.0 
+0200
@@ -1,3 +1,11 @@
+nodejs (12.21.0~dfsg-4) unstable; urgency=medium
+
+  [ Andreas Beckmann ]
+  * nodejs: Add Breaks: node-babel-runtime (<< 7)
+for smoother upgrades from buster. (Closes: #987301)
+
+ -- Jérémy Lal   Wed, 21 Apr 2021 12:42:46 +0200
+
 nodejs (12.21.0~dfsg-3) unstable; urgency=medium
 
   * Upstream patch fix test-worker-prof (Closes: #985550)
diff -Nru nodejs-12.21.0~dfsg/debian/control nodejs-12.21.0~dfsg/debian/control
--- nodejs-12.21.0~dfsg/debian/control  2021-02-23 19:22:31.0 +0100
+++ nodejs-12.21.0~dfsg/debian/control  2021-04-21 12:40:54.0 +0200
@@ -69,7 +69,7 @@
 Suggests: npm
 Replaces: nodejs-legacy
 Conflicts: nodejs-legacy
-Breaks: node-typescript-types (<< 20210110~)
+Breaks: node-typescript-types (<< 20210110~), node-babel-runtime (<< 7)
 Provides: node-types-node (= ${types:Node})
 Description: evented I/O for V8 javascript - runtime executable
  Node.js is a platform built on Chrome's JavaScript runtime for easily


Bug#983316: openvswitch-switch: Hard-coded log levels, no way to configure them

2021-04-21 Thread Benjamin Drung
Hi,

Am Dienstag, den 23.02.2021, 13:43 -0800 schrieb Ben Pfaff:
> On Mon, Feb 22, 2021 at 12:25:22PM +0100, Benjamin Drung wrote:
> > Package: openvswitch-switch
> > Version: 2.15.0+ds1-2
> > Severity: normal
> > 
> > Hi,
> > 
> > Since we run into a log spam issue (probably upstream bug #135
> > [1]), we
> > want to raise the log level and disable the logging to file (syslog
> > is
> > enough for us).
> > 
> > Sadly `/usr/share/openvswitch/scripts/ovs-ctl` (called by
> > ovsdb-server.service) hard-codes the log levels and has no way to
> > configure them:
> > 
> > ```
> > set "$@" -vconsole:emer -vsyslog:err -vfile:info
> > ```
> > 
> > Please support configuring the log levels via
> > `/etc/default/openvswitch-switch`.
> 
> I think you can do that already in /etc/default/openvswitch-switch
> with
>     OVS_CTL_OPTS='--ovs-vswitchd-options=-vwhatever'
> It can undoubtedly be improved (I'm not sure multiword options will
> work).

Thanks for pointing it out. I tried setting

OVS_CTL_OPTS='--ovsdb-server-options="-vsyslog:warn -vfile:off" --ovs-
vswitchd-options="-vsyslog:warn -vfile:off"'

and that works. So it is possible to configure the log level. What was
lacking was the documentation. Are these options documented somewhere?
I haven't found them. In case they are documented, can
/etc/default/openvswitch-switch mention the location of those (e.g. add
"see man page of XXX")?

> Open vSwitch works pretty hard to not spam log files, so I'd
> encourage
> you to report whatever excessive logging you're seeing to upstream.

That log spamming was already reported upstream by someone else:
https://github.com/openvswitch/ovs-issues/issues/135

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet



Bug#987306: python3-libtorrent: move_storage did not match C++ signature

2021-04-21 Thread Braiam Peguero
Package: python3-libtorrent
Version: 1.2.9-0.2+b2
Severity: important
Tags: patch upstream

Dear Maintainer,

Trying to move a torrent using deluge-console results in the following
error:

ArgumentError
Python argument types in
torrent_handle.move_storage(torrent_handle, str)
did not match C++ signature:
move_storage(libtorrent::torrent_handle {lvalue},
std::__cxx11::basic_string, std::allocator >
path, libtorrent::move_flags_t
flags=libtorrent.move_flags_t.always_replace_files): Traceback (most recent
call last):
  File "/usr/lib/python3/dist-packages/deluge/core/torrent.py", line 1246, in
move_storage
self.handle.move_storage(dest.encode('utf8'), flags=2)
Boost.Python.ArgumentError: Python argument types in
torrent_handle.move_storage(torrent_handle, bytes)
did not match C++ signature:
move_storage(libtorrent::torrent_handle {lvalue},
std::__cxx11::basic_string, std::allocator >
path, libtorrent::move_flags_t
flags=libtorrent.move_flags_t.always_replace_files)


Upstream fixed this issue in patch [1]


[1]:
https://github.com/arvidn/libtorrent/pull/5093/commits/370da7df0a6624333ad92f43f79c8a385d928f48


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

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

Versions of packages python3-libtorrent depends on:
ii  libboost-python1.74.0 [libboost-python1.74.0-py39]  1.74.0-9
ii  libc6   2.31-11
ii  libgcc-s1   10.2.1-6
ii  libssl1.1   1.1.1k-1
ii  libstdc++6  10.2.1-6
ii  libtorrent-rasterbar10  1.2.9-0.2+b2
ii  python3 3.9.2-2

python3-libtorrent recommends no packages.



Bug#986565: unusable with current git

2021-04-21 Thread Damyan Ivanov
Package: git-flow
Version: 1.12.3-2
Followup-For: Bug #986565

Control: reopen -1 1.12.3-2

Sigh. Now git reverted to using /usr/lib again, and git-flow is broken.

Reverting the changes in 1.12.3-2 would fix it.

Reading https://bugs.debian.org/985416 (the bug report in git about changing 
the path), I am left with the impression that the proper fix is to ship 
/usr/bin/git-flow. Perhaps the other scripts need to be in /usr/bin too.


HTH,
Damyan


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

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

Versions of packages git-flow depends on:
ii  git [git-core]  1:2.31.1-1
ii  git-core1:2.15.0~rc0-1

git-flow recommends no packages.

git-flow suggests no packages.

-- no debconf information



Bug#987285: pound FTCBFS: runs cmake for the build architecture

2021-04-21 Thread Carsten Leonhardt
Hi Helmut,

> Source: pound
> Version: 3.0-2
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> pound fails to cross build from source since the 3.0-2 upload to
> unstable, because it does not pass cross flags to cmake. The easiest way
> of doing so - using dh_auto_configure - makes pound cross buildable.
> Please consider applying the attached patch.

thanks for the patch - do you think I should try to get this into
bullseye?

Regards

Carsten



Bug#987273: CVE-2021-21783

2021-04-21 Thread Mattias Ellert
tis 2021-04-20 klockan 20:32 +0200 skrev Moritz Muehlenhoff:
> Package: libgsoap-2.8.104
> Version: 2.8.104-2
> Severity: important
> File: gsoap
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> This was assigned CVE-2021-21783:
> https://talosintelligence.com/vulnerability_reports/TALOS-2021-1245
> 
> Cheers,
>     Moritz  

Hi Moritz.

I can not fully comprehend this bug report.

If I read the CVE-2021-21783 report, it basically says:

  We have noticed that the vulnerability we previously reported
  (CVE-2020-13576) was not fixed. We have therefore resubmitted it.
  We have investigated the following versions:

  Genivia gSOAP 2.8.109
  Genivia gSOAP 2.8.110

However, the fix for CVE-2020-13576 was in gSOAP 2.8.111, so that this
was still present in the two tested versions is expected.

The page for previous CVE-2020-13576 does claim that it was fixed in an
upstream release on 2020-11-20, which corresponds to version 2.8.109.

I do not think this statement is correct. From my understanding of
comparing the reported fault (including code snippets) with the changes
to the source repository, I understand it to have been fixed in version
2.8.111, and not in 2.8.109 as the report claims. Since the reported
fixed version in incorrect I can see why it was reported again.

I think the reason for the wrong fixed version in the previous report
is that the other 4 CVEs reported against gsoap at the same time
(CVE-2020-13574, CVE-2020-13575, CVE-2020-13577 and CVE-2020-13578)
were indeed fixed in version 2.8.109. So someone might just put the
same fixed date on all 5 reports.

The fix for CVE-2020-13576 from version 2.8.111 is already applied as a
patch in the debian package version gsoap/2.8.104-3. And if this new
CVE is indeed a duplicate there is nothing more to fix.

Mattias



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


Bug#987207: podman not running out-of-the-box as root

2021-04-21 Thread Laurent Bigonville

Hello,

So the problem here is, again, linked to the fact that I'm using a test 
SELinux policy that doesn't contain all the needed contexts, so yeah 
it's a mix of configuration issue and the fact that podman is not 
ignoring these errors if SELinux is in permissive. I'll ping upstream again.


So the remaining problem here is iptables command not being installed 
(and the seccomp.json file missing to a lower extend)


Le 21/04/21 à 10:21, Laurent Bigonville a écrit :


Hello,

I just did a minimal test VM and... it indeed works...

I'll investigate why on my machine it's not working.

But, on the test VM, podman still fails because "iptables" is not 
installed, only "nft" is intalled by default now. So there is still a 
problem here.


Le 21/04/21 à 05:02, Reinhard Tartler a écrit :

Control: tag -1 moreinfo

Hi Laurent,

I've downloaded the Bullseye Alpha 3 debian installer and installed 
using kvm to have a super clean new system. Unfortunately, I was 
unable to reproduce the issue that you described below. (I did find 
some issues with rootless podman outside of a gnome-session, but 
that's a different story).


The symptoms sound a lot like described in this upstream bug: 
https://github.com/containers/podman/issues/5721 



Can you please compare your notes with that upstream bug? Can you 
confirm that the 'overlay' kernel module is loaded? (in my test, it 
was loaded automatically). If you still think this is an issue in the 
Debian package, please let me know. I may require your assistance 
with reproducing this issue.


-rt

On Mon, Apr 19, 2021 at 11:54 AM Laurent Bigonville > wrote:


Package: podman
Version: 3.0.1+dfsg1-1
Severity: serious

Hello,

After installing podman, I cannot run it as root out of the box as it
fails with:

ERRO[] [graphdriver] prior storage driver overlay failed:
kernel does not support overlay fs: 'overlay' is not supported
over extfs at "/var/lib/containers/storage/overlay": backing file
system is unsupported for this graph driver
Error: kernel does not support overlay fs: 'overlay' is not
supported over extfs at "/var/lib/containers/storage/overlay":
backing file system is unsupported for this graph driver

Looking at fedora it seems that they have a containers-common package
that ships a default storage.conf file:


https://src.fedoraproject.org/rpms/containers-common/blob/rawhide/f/storage.conf



I see that the debian package is shipping a file in
/usr/share/containers/storage.conf (in the containers-storage
package),
but that file is apparently not read (strace only shows that the
file in
/etc/containers is read) and anyway unlike in fedora:

1) the driver is not set to overlay
2) the file is installed only if the containers-storage package is
installed, which is not done by default.
3) that file is not read anyway, strace only shows that
/etc/containers/storage.conf is read and not
/usr/share/containers/storage.conf, so the file is apparently useless

Shouldn't debian do the same thing than fedora so everything
works OOTB?

As a side note, I can see they are shipping also other files as well,
like the seccomp.json file, using strace, it seems that podman
tries to
read them:

[pid 14835] newfstatat(AT_FDCWD, "/etc/containers/seccomp.json",
0xcee6b8, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid 14835] newfstatat(AT_FDCWD,
"/usr/share/containers/seccomp.json", 0xcee788, 0) = -1
ENOENT (Aucun fichier ou dossier de ce type)

Shouldn't that file be shipped by default too?

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages podman depends on:
ii  conmon                           2.0.25+ds1-1
ii  containernetworking-plugins      0.9.0-1+b3
ii  golang-github-containers-common  0.35.4+ds1-1
ii  init-system-helpers              1.60
ii  libc6                            2.31-11
ii  libdevmapper1.02.1               2:1.02.175-2.1
ii  libgpgme11                       1.14.0-1+b2
ii  libseccomp2                      2.5.1-1
ii  runc                             1.0.0~rc93+ds1-3

Versions of packages podman recommends:
ii  buildah  1.20.0+ds1-1
ii  

Bug#987212: gscan2pdf: visually align 'Threshold before OCR'

2021-04-21 Thread jffry

Committed upstream. Thanks for the patches!



Bug#987253: kolourpaint: Missing most of the icons in left panel

2021-04-21 Thread Yvan Masson

Hi,

Le 20/04/2021 à 14:40, Norbert Preining a écrit :

Hi

On Tue, 20 Apr 2021, Yvan Masson wrote:

In the left panel of KolourPaint, tools like line, square, circle… are by
default normally shown by their icon. However most of the icons seems to be
missing because only the text of the button is shown (see screenshot
attached).


I do see the icons, so that means you might have selected a special set
of icons in the settings application that does not provide all icons.

Try breeze icon, it should show up.

Also, there is an option in the settings application under Appearance,
Application Style, Configure Icons and Toolsbars
that let you hide icons and only show text. Worth checking out.

Thanks for you quick answer. Indeed, I had thi issue under two Debian 
installations : one running Gnome and the other Cinnamon, and 
breeze-icon-theme was not installed on both. Installing this package is 
sufficient to make icons appear in KolourPaint.


Maybe kolourpaint should recommend breeze-icon-theme, or another icon 
theme that contains the required icons?


Regards,
Yvan


Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13





OpenPGP_signature
Description: OpenPGP digital signature


Bug#987305: unblock: nvidia-graphics-drivers-tesla-418/418.197.02-1

2021-04-21 Thread Luca Boccassi
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-nvidia-de...@lists.alioth.debian.org

Please unblock package nvidia-graphics-drivers-tesla-418

The new upstream version 418.197.02 fixes a CVE and a crash in X.org,
both of which affect Bullseye.

X.org crash under certain conditions, and a security vulnerability
(CVE-2021-1076 and #987219) has been found in the kernel driver:
https://nvidia.custhelp.com/app/answers/detail/a_id/5172

The inlined debdiff excludes the binary blobs.

unblock nvidia-graphics-drivers-tesla-418/418.197.02-1

-- 
Kind regards,
Luca Boccassi

diff -Nru --exclude 'NVIDIA*.run' 
nvidia-graphics-drivers-tesla-418-418.181.07/debian/changelog 
nvidia-graphics-drivers-tesla-418-418.197.02/debian/changelog
--- nvidia-graphics-drivers-tesla-418-418.181.07/debian/changelog   
2021-03-12 19:11:00.0 +
+++ nvidia-graphics-drivers-tesla-418-418.197.02/debian/changelog   
2021-04-20 15:15:04.0 +0100
@@ -1,3 +1,23 @@
+nvidia-graphics-drivers-tesla-418 (418.197.02-1) unstable; urgency=medium
+
+  * New upstream Tesla release 418.197.02 (2021-04-19).
+* Fixed CVE-2021-1076.  (Closes: #987219)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+
+ -- Andreas Beckmann   Tue, 20 Apr 2021 16:15:04 +0200
+
+nvidia-graphics-drivers (418.197.02-1) buster; urgency=medium
+
+  * New upstream Tesla release 418.197.02 (2021-04-19).
+* Fixed CVE-2021-1076.  (Closes: #987216)
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+
+  [ Andreas Beckmann ]
+  * nvidia-alternative: Add libnvidia-ml.so slave alternative if
+libnvidia-ml-dev is installed (460.56-2).  (Closes: #984881)
+
+ -- Andreas Beckmann   Tue, 20 Apr 2021 15:01:59 +0200
+
 nvidia-graphics-drivers-tesla-418 (418.181.07-2) unstable; urgency=medium
 
   * Switch to dh-sequence-dkms (460.56-1).
@@ -717,6 +737,19 @@
 
  -- Andreas Beckmann   Sun, 22 Apr 2018 13:59:45 +0200
 
+nvidia-graphics-drivers (390.143-1) UNRELEASED; urgency=medium
+
+  * New upstream legacy branch release 390.143 (2021-04-19).
+* Fixed CVE-2021-1076.
+  https://nvidia.custhelp.com/app/answers/detail/a_id/5172
+- Fixed a bug where vkCreateSwapchain could cause the X Server to crash
+  when an invalid imageFormat was provided.
+- Fixed a driver installation failure on Linux kernel 5.11 release
+  candidates, where the NVIDIA kernel module failed to build with error
+  "fatal error: asm/kmap_types.h: No such file or directory".
+
+ -- Andreas Beckmann   Mon, 19 Apr 2021 22:38:56 +0200
+
 nvidia-graphics-drivers (390.141-1) UNRELEASED; urgency=medium
 
   * New upstream legacy branch release 390.141 (2021-01-07).
diff -Nru --exclude 'NVIDIA*.run' 
nvidia-graphics-drivers-tesla-418-418.181.07/debian/control.md5sum 
nvidia-graphics-drivers-tesla-418-418.197.02/debian/control.md5sum
--- nvidia-graphics-drivers-tesla-418-418.181.07/debian/control.md5sum  
2021-03-12 19:11:00.0 +
+++ nvidia-graphics-drivers-tesla-418-418.197.02/debian/control.md5sum  
2021-04-20 15:15:04.0 +0100
@@ -1,5 +1,5 @@
 2b166b1ac6588e638946982df3fde7df  debian/control
 7e76ad93933bc9855c55a24a0a29739f  debian/control.in
 db12f898b07cdaf431ad34bd68a1662e  debian/gen-control.pl
-c7cc02af2fecdcf0d2be8781c0036133  debian/rules
+1c2e4bda5c346493c1e55efebba869c2  debian/rules
 5c030ac5e276798b2e17c170aa15d998  debian/rules.defs
diff -Nru --exclude 'NVIDIA*.run' 
nvidia-graphics-drivers-tesla-418-418.181.07/debian/rules 
nvidia-graphics-drivers-tesla-418-418.197.02/debian/rules
--- nvidia-graphics-drivers-tesla-418-418.181.07/debian/rules   2021-03-12 
19:11:00.0 +
+++ nvidia-graphics-drivers-tesla-418-418.197.02/debian/rules   2021-04-20 
15:15:04.0 +0100
@@ -169,9 +169,9 @@
sed 's/__NV_VK_ICD__/libGL.so.1/' $< > $@
 
 nv-readme.ids: unpack-stamp
-   sed -e '0,/A. Supported\|APPENDIX A: SUPPORTED/d' \
-   -e '0,/Appendix A. Supported\|APPENDIX A: SUPPORTED/d' \
-   -e '0,/^Below\|APPENDIX B/{/ 0x/s/.*  
0x\([0-9a-fA-F]\{4\}\).*/10de\1/p; /^.\{41\} [0-9a-fA-F]\{4\} /s/^.\{41\} 
\([0-9a-fA-F]\{4\}\) .*/10de\1/p};d' \
+   sed -r  -e '0,/A. Supported|APPENDIX A: SUPPORTED/d' \
+   -e '0,/Appendix A. Supported|APPENDIX A: SUPPORTED/d' \
+   -e '0,/^Below|APPENDIX B/{/ 0x/s/.*  
0x([0-9a-fA-F]{4}).*/10de\1/p; /^(.{41}|.{49}) [0-9a-fA-F]{4} /s/^(.{41}|.{49}) 
([0-9a-fA-F]{4}) .*/10de\2/p};d' \
NVIDIA-Linux/README.txt \
| tr a-f A-F | sort -u > $@
@set -e -x ; \


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


Bug#987252: kolourpaint: does not have a manpage

2021-04-21 Thread Yvan Masson

Hi,

Le 20/04/2021 à 14:41, Norbert Preining a écrit :

Hi


Bullseye's version but also in stable and old-stable). I thought this was
mandatory in Debian.


It is recommended, but not mandatory.

The man page would be trivial, something like the output of -h, so
probably not worth the pain.


OK, in this case I suppose you can close this bug report.

Regards,
Yvan



OpenPGP_signature
Description: OpenPGP digital signature


Bug#987211: gscan2pdf: separate tab for Post-processing options in Scan dialog

2021-04-21 Thread jffry

Committed upstream. Thanks for the patch.



Bug#987304: dgit-repos-server seems to have messed up version demangling from tag2upload git tag

2021-04-21 Thread Wolfgang Silbermayr
Package: dgit-infrastructure
Version: 9.13
Severity: important
X-Debbugs-Cc: wolfg...@silbermayr.at

Line 1109 of the dgit-repos-server script contains this code:

$version =~ y/_\%\#/:~/d;

When running into problems with version numbers containing '~' or ':' I
looked up the version mangling description of DEP-14, and it says for the
reverse transformation of the git tags:

* Each percent (%) is replaced with a colon (:)
* Each underscore (_) is replaced with a tilde (~)
* Each hash (#) is deleted

It seems to me that the mentioned line performs the first to replacements
exactly the other way round.

Using this line of code instead of the original fixes the problem for me:

$version =~ y/_\%\#/~:/d;

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

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

Versions of packages dgit-infrastructure depends on:
ii  chiark-utils-bin   6.1.2+nmu1
ii  git [git-core] 1:2.31.1-1
ii  gpgv   2.2.27-1
ii  libdbd-sqlite3-perl1.66-1+b1
ii  libdpkg-perl   1.20.9
ii  libjson-perl   4.03000-1
ii  liblocale-gettext-perl 1.07-4+b1
ii  perl [libdigest-sha-perl]  5.32.1-3
ii  sqlite33.34.1-3

Versions of packages dgit-infrastructure recommends:
ii  dgit  9.13

dgit-infrastructure suggests no packages.

-- no debconf information



Bug#987303: neutron-common: fails to install: cp: cannot stat '/usr/share/neutron-common/plugins/ml2/ml2_conf.ini': No such file or directory

2021-04-21 Thread Andreas Beckmann
Package: neutron-common
Version: 2:17.1.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up neutron-common (2:17.1.1-3) ...
  cp: cannot stat '/usr/share/neutron-common/plugins/ml2/ml2_conf.ini': No such 
file or directory
  dpkg: error processing package neutron-common (--configure):
   installed neutron-common package post-installation script subprocess 
returned error exit status 1
  Processing triggers for ca-certificates (20210119) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Errors were encountered while processing:
   neutron-common


cheers,

Andreas


neutron-common_2:17.1.1-3.log.gz
Description: application/gzip


Bug#987302: wims-lti: fails to install: ModuleNotFoundError: No module named 'httplib2'

2021-04-21 Thread Andreas Beckmann
Package: wims-lti
Version: 0.4.4.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up wims-lti (0.4.4.1-1) ...
  Warning: The home dir /var/lib/wims-lti you specified already exists.
  Adding system user `lti' (UID 150) ...
  Adding new user `lti' (UID 150) with group `nogroup' ...
  The home directory `/var/lib/wims-lti' already exists.  Not copying from 
`/etc/skel'.
  adduser: Warning: The home directory `/var/lib/wims-lti' does not belong to 
the user you are currently creating.
  Adding group `lti' (GID 150) ...
  Done.
  /var/lib/wims-lti/lti_app/apps.py:22: Warning: Settings 'DEBUG' has not been 
redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#debug
warnings.warn(
  /var/lib/wims-lti/lti_app/apps.py:29: Warning: Settings 'SECRET_KEY' has not 
been redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#secret-key
warnings.warn(
  /var/lib/wims-lti/lti_app/apps.py:36: Warning: Settings 'SERVER_EMAIL' has 
not been redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#server-email
warnings.warn(
  /var/lib/wims-lti/lti_app/apps.py:43: Warning: Settings 'EMAIL_HOST' has not 
been redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#email-host
warnings.warn(
  /var/lib/wims-lti/lti_app/apps.py:50: Warning: Settings 'ADMINS' has not been 
redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#admins
warnings.warn(
  [2021/04/19 22:03:43] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:add_job:445]
 INFO -- Adding job tentatively -- it will be properly scheduled when the 
scheduler starts
  [2021/04/19 22:03:43] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:add_job:445]
 INFO -- Adding job tentatively -- it will be properly scheduled when the 
scheduler starts
  [2021/04/19 22:03:43] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:add_job:445]
 INFO -- Adding job tentatively -- it will be properly scheduled when the 
scheduler starts
  [2021/04/19 22:03:43] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:_real_add_job:886]
 INFO -- Added job "send_back_all_sheets_grades" to job store "default"
  [2021/04/19 22:03:43] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:_real_add_job:886]
 INFO -- Added job "send_back_all_exams_grades" to job store "default"
  [2021/04/19 22:03:43] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:_real_add_job:886]
 INFO -- Added job "check_classes_exists" to job store "default"
  [2021/04/19 22:03:43] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:start:171]
 INFO -- Scheduler started
  
  117 static files copied to '/var/lib/wims-lti/static'.
  /var/lib/wims-lti/lti_app/apps.py:22: Warning: Settings 'DEBUG' has not been 
redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#debug
warnings.warn(
  /var/lib/wims-lti/lti_app/apps.py:29: Warning: Settings 'SECRET_KEY' has not 
been redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#secret-key
warnings.warn(
  /var/lib/wims-lti/lti_app/apps.py:36: Warning: Settings 'SERVER_EMAIL' has 
not been redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#server-email
warnings.warn(
  /var/lib/wims-lti/lti_app/apps.py:43: Warning: Settings 'EMAIL_HOST' has not 
been redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#email-host
warnings.warn(
  /var/lib/wims-lti/lti_app/apps.py:50: Warning: Settings 'ADMINS' has not been 
redefined in wimsLTI/config.py, see 
https://docs.djangoproject.com/fr/2.2/ref/settings/#admins
warnings.warn(
  [2021/04/19 22:03:44] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:add_job:445]
 INFO -- Adding job tentatively -- it will be properly scheduled when the 
scheduler starts
  [2021/04/19 22:03:44] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:add_job:445]
 INFO -- Adding job tentatively -- it will be properly scheduled when the 
scheduler starts
  [2021/04/19 22:03:44] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:add_job:445]
 INFO -- Adding job tentatively -- it will be properly scheduled when the 
scheduler starts
  [2021/04/19 22:03:44] 
[/usr/lib/python3/dist-packages/apscheduler/schedulers/base.py][base.py:_real_add_job:886]
 INFO -- Added job "send_back_all_sheets_grades" to job store "default"
  [2021/04/19 22:03:44] 

Bug#800969: Bug confirmation

2021-04-21 Thread Erich Minderlein

Hi

Bug confirmation. I run a devuan beowulf stable

Trying to a fresh install of ntopng has the same symptoms as described.

BR Erich



Bug#983896: [Pkg-raspi-maintainers] Bug#983896: raspi-firmware: please link /boot/firmware/*.txt to /etc/raspi-firmware/*.txt

2021-04-21 Thread Holger Levsen
Hi Gunnar,

On Wed, Apr 21, 2021 at 01:04:20AM -0500, Gunnar Wolf wrote:
> I don't want to link or copy said files over to /etc, as they would
> break expectations for conffiles (i.e. they will be overwritten on
> upgrade). 

makes sense!

> But I am adding a warning banner to cmdline.txt warning
> about this, and advising the user on how to properly modify it:
> 
> https://salsa.debian.org/debian/raspi-firmware/-/commit/7e4ce0f8c0038162ccd6474e13ef5bb954851a2d
> I will close this bug by the next package upload. I hope this solution
> satisfies you!

yes, it does, this warning would have saved me :) Thank you!

Just one question remains: whats the diff between /etc/default/raspi-firmware
and /etc/default/raspi-extra-cmdline ? Or more importantly: is that diff
explained in those files? (my raspi is powered off atm.)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

We live in a world where teenagers get more and more desperate trying to
convince adults to behave like grown ups.


signature.asc
Description: PGP signature


Bug#929608: pmciscoios can be really helpful

2021-04-21 Thread Václav Ovsík
Fellow maintainer,
please, enable pmciscoios. I can benefit from it too. Our Cisco switches log
with double timestamp… :(

e.g.
 Apr 21 09:16:53 sw-brn02.brn.i.cz 13134: Apr 21 07:16:53.208: 
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/27, changed 
state to up

People want to solve this, so I will now have to rebuild the package. :-(
-- 
Zito



Bug#900821: workaround confirmed

2021-04-21 Thread deepee
Damn, I was wrong!

It is still reproducible - sorry for the confusion.



Bug#900821: workaround confirmed

2021-04-21 Thread deepee
On Sun, 18 Apr 2021 17:37:33 +0200 Salvatore Bonaccorso  
wrote:> On Mon, Dec 14, 2020 at 08:38:02PM +, Florian Kain wrote:
> > Hi all,
> >
> > we were experiencing this bug in a debian 10.4 docker container (FROM 
> > php:apache)
> > it only happens with plain http not with https.
> >
> > I can confirm that workaround from  Stefan Fritsch 
> > by turning EnableMMAP off is working for us!
>
> is this issue still reproducible with recent kernels?
>
> Regards,
> Salvatore

Hi,

it isn't reproducible anymore, at least over here running Debian-Testing:
5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux

Test procedure:
We've disabled the previously mentioned workaround (removed/commented 
EnableMMAP Off) and restarted apache2.

Result:
Previously affected files (mounted via cifs and served by apache2) do not get 
coruppted any more.

Regards,
Dora



Bug#887374: ITP: node-aws-sdk -- Its the official AWS SDK for JavaScript, available for browsers and mobile devices, or Node.js backends

2021-04-21 Thread Pirate Praveen



On 2021, ഏപ്രിൽ 21 1:19:16 PM IST, Andreas Tille  wrote:
>Hi folks,
>
>sorry for the long receiver list of this mail.  As it was discussed[1]
>on debian-ai list about tensorflow dependencies, the package
>node-aws-sdk seems to be needed.  Since there was some work on this
>package in Git[2] I took the freedom to update the packaging to the
>latest upstream version and refresh the packaging to latest standards.
>Thanks to Nilesh Patra the new dependency node-jmespath was packaged
>and uploaded to new queue as well.
>
>Nilesh also pointed out that the node-aws-sdk source also contains some
>ruby code.  I personally can find it only below the dir doc-src but just
>to be sure (and besides to ask for help and cooperation in general) I'd
>like to raise the topic here.  I'm wondering whether there is some
>connection to ruby-aws-sdk.

Only parsejs code is in ruby, which is only used for docs I think. I don't 
think there is a connection to ruby-aws-sdk. We should create ruby-parsejs only 
if we are actually going to use it.

>Any comments are welcome.
>
>Kind regards
>
>  Andreas.
>
>
>[1] https://lists.debian.org/debian-ai/2021/04/msg0.html
>[2] https://salsa.debian.org/js-team/node-aws-sdk
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Bug#987207: podman not running out-of-the-box as root

2021-04-21 Thread Laurent Bigonville

Hello,

I just did a minimal test VM and... it indeed works...

I'll investigate why on my machine it's not working.

But, on the test VM, podman still fails because "iptables" is not 
installed, only "nft" is intalled by default now. So there is still a 
problem here.


Le 21/04/21 à 05:02, Reinhard Tartler a écrit :

Control: tag -1 moreinfo

Hi Laurent,

I've downloaded the Bullseye Alpha 3 debian installer and installed 
using kvm to have a super clean new system. Unfortunately, I was 
unable to reproduce the issue that you described below. (I did find 
some issues with rootless podman outside of a gnome-session, but 
that's a different story).


The symptoms sound a lot like described in this upstream bug: 
https://github.com/containers/podman/issues/5721 



Can you please compare your notes with that upstream bug? Can you 
confirm that the 'overlay' kernel module is loaded? (in my test, it 
was loaded automatically). If you still think this is an issue in the 
Debian package, please let me know. I may require your assistance with 
reproducing this issue.


-rt

On Mon, Apr 19, 2021 at 11:54 AM Laurent Bigonville > wrote:


Package: podman
Version: 3.0.1+dfsg1-1
Severity: serious

Hello,

After installing podman, I cannot run it as root out of the box as it
fails with:

ERRO[] [graphdriver] prior storage driver overlay failed:
kernel does not support overlay fs: 'overlay' is not supported
over extfs at "/var/lib/containers/storage/overlay": backing file
system is unsupported for this graph driver
Error: kernel does not support overlay fs: 'overlay' is not
supported over extfs at "/var/lib/containers/storage/overlay":
backing file system is unsupported for this graph driver

Looking at fedora it seems that they have a containers-common package
that ships a default storage.conf file:


https://src.fedoraproject.org/rpms/containers-common/blob/rawhide/f/storage.conf



I see that the debian package is shipping a file in
/usr/share/containers/storage.conf (in the containers-storage
package),
but that file is apparently not read (strace only shows that the
file in
/etc/containers is read) and anyway unlike in fedora:

1) the driver is not set to overlay
2) the file is installed only if the containers-storage package is
installed, which is not done by default.
3) that file is not read anyway, strace only shows that
/etc/containers/storage.conf is read and not
/usr/share/containers/storage.conf, so the file is apparently useless

Shouldn't debian do the same thing than fedora so everything works
OOTB?

As a side note, I can see they are shipping also other files as well,
like the seccomp.json file, using strace, it seems that podman
tries to
read them:

[pid 14835] newfstatat(AT_FDCWD, "/etc/containers/seccomp.json",
0xcee6b8, 0) = -1 ENOENT (Aucun fichier ou dossier de ce type)
[pid 14835] newfstatat(AT_FDCWD,
"/usr/share/containers/seccomp.json", 0xcee788, 0) = -1 ENOENT
(Aucun fichier ou dossier de ce type)

Shouldn't that file be shipped by default too?

Kind regards,
Laurent Bigonville

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages podman depends on:
ii  conmon                           2.0.25+ds1-1
ii  containernetworking-plugins      0.9.0-1+b3
ii  golang-github-containers-common  0.35.4+ds1-1
ii  init-system-helpers            

  1.60
ii  libc6                

            2.31-11
ii  libdevmapper1.02.1            

   2:1.02.175-2.1
ii  libgpgme11              

         1.14.0-1+b2
ii  libseccomp2              

        2.5.1-1
ii  runc                

             1.0.0~rc93+ds1-3


Versions of packages podman recommends:
ii  buildah  1.20.0+ds1-1
ii  fuse-overlayfs 1.4.0-1
ii  golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b4
ii  slirp4netns  1.0.1-2
ii  tini 0.19.0-1
ii  uidmap 1:4.8.1-1

Versions of packages podman suggests:
ii  containers-storage  1.24.8+dfsg1-1+b1
ii  docker-compose      1.25.0-1

-- no debconf information



--
regards,
    Reinhard


Bug#887374: ITP: node-aws-sdk -- Its the official AWS SDK for JavaScript, available for browsers and mobile devices, or Node.js backends

2021-04-21 Thread Andreas Tille
Hi folks,

sorry for the long receiver list of this mail.  As it was discussed[1]
on debian-ai list about tensorflow dependencies, the package
node-aws-sdk seems to be needed.  Since there was some work on this
package in Git[2] I took the freedom to update the packaging to the
latest upstream version and refresh the packaging to latest standards.
Thanks to Nilesh Patra the new dependency node-jmespath was packaged
and uploaded to new queue as well.

Nilesh also pointed out that the node-aws-sdk source also contains some
ruby code.  I personally can find it only below the dir doc-src but just
to be sure (and besides to ask for help and cooperation in general) I'd
like to raise the topic here.  I'm wondering whether there is some
connection to ruby-aws-sdk.

Any comments are welcome.

Kind regards

  Andreas.


[1] https://lists.debian.org/debian-ai/2021/04/msg0.html
[2] https://salsa.debian.org/js-team/node-aws-sdk

-- 
http://fam-tille.de



  1   2   >