Bug#985946: tomboy-ng: FTBFS on ppc64el

[David Bannon]

Wow Frédéric, thats given me something to think about !


On 27/3/21 2:12 am, Frédéric Bonnard wrote:
> Package: src:tomboy-ng
> Version: 0.32-1
> tomboy fails to build on ppc64el :


"ppc64el" ?  "endian little" ?  Is that the same as ppc64le  ?   As in
IBM Power8 ? I do have a history with IBM Power systems, once managed a
couple of largeish BlueGene machines. But a long time ago. I now have no
hope of getting direct access to P8 hardware. FPC 320 does apparently
support ppc64le and maybe I can cross compile ?

But sooner or later I'd have to use MiniCloud and bring X back over ssh.
Brazil to Australia ?  Wow, thats going to be fun. 

Now, Lazarus, and in this case, I mean LCL, does not offer any PPC64le
support at all. But you seem to have installed some LCL at least so I
suspect I should be able to solve the KControls issue that you hit just
with an understanding of what the OS offers.  I expect there will be #
defines there that think they are looking at an old Mac PPC and thats
sure not going to work.

So, its possible, the question is, is it practical ?

Personally, I'd consider it pretty cool but I have to ask, is anyone
using IBM Power8 desktop systems ?

Davo


> https://buildd.debian.org/status/fetch.php?pkg=tomboy-ng=ppc64el=0.32-1=1612358331=0
>
>
> Regards,
>
>
> F.

Bug#969174: firefox: FF80 broke webext-* add-ons on existing profiles and new profiles after three restarts

[Antoine Le Gonidec]

On Thu, 25 Mar 2021 01:54:53 +0100 Christoph Anton Mitterer 
 wrote:

Anyway, it seems with FF87, Mozilla blessed people with further
goodness and the old bug is also back again... at least I see add-ons
like ublock or no-script ineffective, even though their icon is
displayed this time...

Firefox 87.0-1 here, from Debian Sid repositories.
The following add-ons installed from Debian repositories seem to work as 
expected:
- webext-ublock-origin-firefox 1.33.0+dfsg-1
- webext-umatrix 1.4.0+dfsg-1

Requests that are supposed to be blocked are indeed blocked according to 
Firefox network inspection tool.

Bug#985848: RFS: xpenguins/3.2.1-1 -- little penguins walk on your windows

[Adam Borowski]

On Wed, Mar 24, 2021 at 03:06:53PM -0700, Micheal Waltz wrote:
>  * Package name: xpenguins
>Version : 3.2.1-1

>  xpenguins (3.2.1-1) unstable; urgency=medium
>  .
>* New upstream version 3.2.1
>* Update standards to 4.5.1 and compat to 13

Hi!
Isn't the package supposed to go to experimental?  We're in the hard freeze,
and unstable is closed for changes that are not small targetted fixes.

Stuff from 3.X branch is already there:

xpenguins  | 2.2-11| unstable
xpenguins  | 3.1.0-1   | experimental


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#985969: libvirt: Build with libssh

[Bastian Germann]

Source: libvirt
Severity: normal

Using SSH keyfile authentication with libssh2 will fail for most file 
formats because libssh2 is built with gcrypt instead of OpenSSL (see 
#668271). As long as that is not resolved, please build with libssh 
instead, which has an OpenSSL version in Debian.


Thanks,
Bastian

Bug#668271: libssh2-1: The libssh2 has several limitations when configured --with-libgcrypt. Please do not use libgcrypt.

[Bastian Germann]

On Tue, 10 Apr 2012 17:26:46 +0200 Mikhail Gusarov 
 wrote:

apt-rdepends -r libssh2-1 lists at least 2556 packages, so enabling
OpenSSL would require all GPL-ed reverse-depends to add a clause to
their license that allows the package in question to be linked against
OpenSSL.

According to GPL usage statistics and amount of subpackages amongst the
reverse-depends, it amounts to ~500 upstream projects to change their
license.

Once it is done, I will definitely change the libssh2 backend.


Hi,

there is no requirement of an OpenSSL clause anymore.
FTP Masters have reconsidered the use of OpenSSL and it can be used by
GPL software now with invoking the system library exception.

See the last comments on #924937.

It would be very appreciated if you could switch to building with 
OpenSSL before full bullseye freeze!


Thanks,
Bastian

Bug#985928: vc4.ko brings unusable ALSA sinks

[Ryutaroh Matsumoto]

From: Ryutaroh Matsumoto 
Subject: vc4.ko brings unusable ALSA sinks
Date: Fri, 26 Mar 2021 17:15:40 +0900 (JST)
> Touching vc4-hdmi-[01] too many times makes the kernel unstable,
> and shutting down often needs several minutes.
> /usr/bin/pulseaudio in its default setting touches all available  ALSA sinks
> and causes the above inconvenience.
> I mainly use HDMI audio output, and 

In my last email, a pointed reproducing procedure should have been given:

0. Assume an RPi4B and a high resolution HDMI display.
1. Install pulseaudio on a sensible distro with the upstream kernel and systemd,
e.g.  https://raspi.debian.net
2. Make a non-root user and login as that user.
3. Run the following script by the non-root user:
#!/bin/sh
set -x
while true; do
  systemctl --user status pulseaudio
  pacmd list-sinks
  pacmd exit
  systemctl --user restart pulseaudio
done

Then every command in the above script gets stuck or fails.

I also prepared an SD card image that can reproduce the reported symptom
on RPi4B 8GB at http://153.240.174.134:64193/tmp/sdimage8GB.img.xz
(268,112,012 bytes).

Best regards, Ryutaroh

Bug#985968: RFS: streamlink/2.1.1-1~exp1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 2.1.1.

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

It builds those binary packages:

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_2.1.1-1~exp1.dsc

Changes since the last upload to unstable:
streamlink (2.1.1-1~exp1) experimental; urgency=medium

  * New upstream version 2.1.1
  * Update patches
  * d/copyright: update years to 2021
  * d/patches: add patch to include .removed file in build (required by tests)
  * d/streamlink.manpages: update manpage build location

 -- Alexis Murzeau   Fri, 26 Mar 2021 23:09:46 +0100



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















signature.asc
Description: OpenPGP digital signature

Bug#985967: freeradius: Fails to start with permission denied when configuring to use privileged ports

[Thore Kruess]

Package: freeradius
Version: 3.0.21+dfsg-2+b2
Severity: important
X-Debbugs-Cc: th...@selfnet.de

Good evening,

after a test upgrade of my running buster configuration to bullseye I
can no longer start freeradius. 

Mar 26 23:46:35 radius-user-dev-1 radiusd[14718]: Failed binding to dhcp
interface eth0 address 192.168.178.58 port 67 bound to server dhcp:
Permission denied
Mar 26 23:46:35 radius-user-dev-1 radiusd[14718]:
/etc/freeradius/3.0/sites-enabled/selfnet-dhcp[41]: Error binding to
port for 192.168.178.58 port 67
Mar 26 23:46:35 radius-user-dev-1 systemd[1]: freeradius.service: Main
process exited, code=exited, status=1/FAILURE

I assume this is related to the changes in the systemd unit so I added

cat /etc/systemd/system/freeradius.service.d/override.conf
[Service]
CapabilityBoundingSet = CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CAP_NET_BROADCAST CAP_NET_RAW CAP_SETUID CAP_SETGID CAP_CHOWN
CAP_DAC_OVERRIDE

systemd show confirms this parameter to be set, but I see the same error
as above.

Best regards,
Thore

-- 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-5-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 freeradius depends on:
ii  freeradius-common  3.0.21+dfsg-2
ii  freeradius-config  3.0.21+dfsg-2+b2
ii  libc6  2.31-10
ii  libcrypt1  1:4.4.17-1
ii  libct4 1.2.3-1
ii  libfreeradius3 3.0.21+dfsg-2+b2
ii  libgdbm6   1.19-2
ii  libpam0g   1.4.0-7
ii  libperl5.325.32.1-3
ii  libreadline8   8.1-1
ii  libsqlite3-0   3.34.1-3
ii  libssl1.1  1.1.1j-1
ii  libsystemd0247.3-3
ii  libtalloc2 2.3.1-2+b1
ii  libwbclient0   2:4.13.5+dfsg-1
ii  lsb-base   11.1.0

Versions of packages freeradius recommends:
ii  freeradius-utils  3.0.21+dfsg-2+b2

Versions of packages freeradius suggests:
pn  freeradius-krb5
pn  freeradius-ldap
pn  freeradius-mysql   
ii  freeradius-postgresql  3.0.21+dfsg-2+b2
ii  freeradius-python3 3.0.21+dfsg-2+b2
pn  snmp   

-- no debconf information

Bug#978674: python3-build: Fails to work unless pip is installed

[Sergio Durigan Junior]

Control: severity -1 serious
Control: tags -1 + help

On Sunday, January 17 2021, Martina Ferrari wrote:

> On 17/01/2021 01:06, Sergio Durigan Junior wrote:
>
>> Thanks for the bug report, Martina.
>> Yeah, this is strange.  I don't think it should require pip, and
>> after
>> installing python3-pip here and re-running /usr/bin/pyproject-build I
>> noticed that it (obviously) invokes pip and downloads several things,
>> which IMO is a no-no.
>
> Yeah, that's bad.
>
>> The reason I packaged python3-build is because check-manifest started
>> depending on it.  I'm thinking about removing the
>> /usr/bin/pyproject-build program and just shipping the library.  Do you
>> think it could work?  (Sorry, I'm not a PEP-517 expert).
>
> Honestly, I don't know much about it either.. I'd suggest discussing
> it with the python-modules team? I guess somebody there would know
> what to do.

I'm marking this bug as serious because I don't think we want a clearly
broken package in bullseye.

I don't have much time to work on it right now, so I'm tagging this bug
as "help" and would appreciate if someone could take another look and
check if it's possible to fix it, or if it even makes sense having this
package in Debian, given that python-build seems to depend on
downloading things via pip and all...

The only reverse-dependency of python3-build is check-manifest, which is
another package I've uploaded, and nothing really depends on it, so I'm
fine if nobody steps up to fix this bug and both packages are excluded
from bullseye.

Thank you,

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


signature.asc
Description: PGP signature

Bug#985963: debuerreotype: uses debian-archive-keyring in autopkgtests without real dependency

[Tianon Gravi]

tags 985963 + pending
thanks

On Fri, 26 Mar 2021 at 15:45, Gianfranco Costamagna
 wrote:
> Hello, looks like the debian/tests/stretch is using the keyring but the 
> package has only a recommends on that dependency.
> This makes the autopkgtest fail when apt is configured with 
> --no-install-recommends.
>
> I see two solutions:
> 1) make the debian-archive-keyring a real runtime dependency (from 
> recommends) in control file
> 2) add the dependency on debian/tests/control.
>
> Since I think this is not a real dependency, I propose solution 2 for the 
> issue:

Agreed, thanks!  Committed to Git [1], pending the next upload.

[1]: 
https://github.com/debuerreotype/debian-debuerreotype/commit/349027dd77b24effecb9574fd61c40e81f283a74

However, I'm not sure I agree with "Severity: serious" (or even
whether this is worth an upload during the deep state of bullseye's
freeze), given that it only occurs in a non-standard configuration and
only applies to the tests (and does not render the package otherwise
unusable in any functional way).  Thoughts?

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#985966: pcp: pmda postgresql not installed

[Jehan-Guillaume de Rorthais]

Package: pcp
Version: 4.3.2+really4.3.1-0.1
Severity: normal

Dear Maintainer,

Using version "4.3.2+really4.3.1" from stable, the postgresql pmda and
pmlogconf files are not installed. The only postgresql related file included in
the package is the pmdapostgresql manpage.

According to the configure.ac, postgresql pmda is only build/installed if
psycopg2 is detected on the system, but it does not appear in Build-Depends.

Note that the package for pcp 5.2.6 in testing is not affected and has
python3-psycopg2 as build dependency.

Rebuilding the package after installing psycopg2 fixes the issue.

Regards,

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

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

Versions of packages pcp depends on:
ii  gawk  1:4.2.1+dfsg-1
ii  libc6 2.28-10
ii  libncurses6   6.1+20181013-2+deb10u2
ii  libpapi5.75.7.0+dfsg-2
ii  libpcp-gui2   4.3.2+really4.3.1-0.1
ii  libpcp-mmv1   4.3.2+really4.3.1-0.1
ii  libpcp-pmda-perl  4.3.2+really4.3.1-0.1
ii  libpcp-pmda3  4.3.2+really4.3.1-0.1
ii  libpcp-trace2 4.3.2+really4.3.1-0.1
ii  libpcp-web1   4.3.2+really4.3.1-0.1
ii  libpcp3   4.3.2+really4.3.1-0.1
ii  libpfm4   4.10.1+git10-gd2a5b56-1
ii  libreadline7  7.0-5
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  procps2:3.3.15-2
ii  python3   3.7.3-1
ii  python3-pcp   4.3.2+really4.3.1-0.1

pcp recommends no packages.

Versions of packages pcp suggests:
ii  libpcp-import-perl  4.3.2+really4.3.1-0.1
ii  pcp-gui 4.3.2+really4.3.1-0.1

-- Configuration Files:
/etc/pcp/pmcd/pmcd.conf changed:
root1   pipebinary  /var/lib/pcp/pmdas/root/pmdaroot
pmcd2   dso pmcd_init   /var/lib/pcp/pmdas/pmcd/pmda_pmcd.so
proc3   pipebinary  /var/lib/pcp/pmdas/proc/pmdaproc -d 3
pmproxy 4   dso pmproxy_init/var/lib/pcp/pmdas/mmv/pmda_mmv.so
xfs 11  pipebinary  /var/lib/pcp/pmdas/xfs/pmdaxfs -d 11
linux   60  pipebinary  /var/lib/pcp/pmdas/linux/pmdalinux
mmv 70  dso mmv_init/var/lib/pcp/pmdas/mmv/pmda_mmv.so
kvm 95  pipebinary  /var/lib/pcp/pmdas/kvm/pmdakvm -d 95
postgresql  110 pipebinary  python3 
/var/lib/pcp/pmdas/postgresql/pmdapostgresql.python
jbd2122 dso jbd2_init   /var/lib/pcp/pmdas/jbd2/pmda_jbd2.so
[access]
disallow ".*" : store;
disallow ":*" : store;
allow "local:*" : all;


-- no debconf information

Bug#985965: speechd-up: initscript speechd-up, action "start" failed.

[Bardot Jerome]

Package: speechd-up
Version: 0.5~20110719-10
Severity: normal
X-Debbugs-Cc: bardot.jer...@gmail.com

Dear Maintainer,

LC_ALL=C aptitude upgrade
The following partially installed packages will be configured:
  speechd-up
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up speechd-up (0.5~20110719-10) ...
Starting Interface between speakup and speech-dispatcher : speechd-up[Sat Mar
27 00:08:24 2021] speechd: Configuration has been read from "/etc/speechd-
up.conf"
Starting speechd-up...
To work, speechd-up needs speakup and speakup_soft modules.
They are loaded automatically. If you don't want, type
rmmod speakup speakup_soft
 failed!
invoke-rc.d: initscript speechd-up, action "start" failed.
dpkg: error processing package speechd-up (--configure):
 installed speechd-up package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
 speechd-up
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up speechd-up (0.5~20110719-10) ...
Starting Interface between speakup and speech-dispatcher : speechd-up[Sat Mar
27 00:08:28 2021] speechd: Configuration has been read from "/etc/speechd-
up.conf"
Starting speechd-up...
To work, speechd-up needs speakup and speakup_soft modules.
They are loaded automatically. If you don't want, type
rmmod speakup speakup_soft
 failed!
invoke-rc.d: initscript speechd-up, action "start" failed.
dpkg: error processing package speechd-up (--configure):
 installed speechd-up package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
 speechd-up

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

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

Versions of packages speechd-up depends on:
ii  libc6  2.31-10
ii  libdotconf01.3-0.3
ii  libspeechd20.10.2-2
ii  lsb-base   11.1.0
ii  speech-dispatcher  0.10.2-2

speechd-up recommends no packages.

speechd-up suggests no packages.

Bug#985887: gscan2pdf: saves b scanned pages in inverted mode

[Francesco Potortì]

>Please start gscan2pdf from the command line:
>
>  gscan2pdf --log=log
>
>reproduce the problem, quit, and post the input image, log file and the 
>resulting PDF.

I scanned the same a4 sheet twice, first in color mode, then in bw
mode.  The two scans appear ok in the gscan2pdf windows.  However, the
resulting pdf has the second page in inverted mode.

After exiting anf closing th elog, gsca2pdf dumped a 508MB core.

You find the log and the pdf at
http://fly.isti.cnr.it/tmp/gscan2pdf

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

Bug#985964: ITP: librdata -- C/C++ library to manipulate GNU R data frames.

[Filippo Rusconi]

Package: wnpp
Severity: wishlist
Owner: Filippo Rusconi 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: librdata
  Version : 0.1.0
  Upstream Author : Evan Miller
* URL : https://github.com/WizardMac/librdata
* License : MIT/X
  Programming Lang: C, C++
  Description : C/C++ library to manipulate GNU R data frames.

 Originally part of ReadStat, librdata is a small C library
 for reading and writing R data frames.
 . 
 Features:
 . 
  - Read both RData and RDS formats
  - Read compressed files (requires bzip2, zlib, and lzma)
  - Write factors, timestamps, logical vectors, and more

This library has become a dependency for the package xtpcpp that I maintain in
my laboratory. Although the version number seems very low, the library actually
performs well and satisfactorily for our use.

-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

Bug#985963: debuerreotype: uses debian-archive-keyring in autopkgtests without real dependency

[Gianfranco Costamagna]

Source: debuerreotype
Version: 0.10-2
Severity: serious
Justification: breaks autopkgtests when recommended packages are not installed 
by default
tags: patch


Hello, looks like the debian/tests/stretch is using the keyring but the package 
has only a recommends on that dependency.
This makes the autopkgtest fail when apt is configured with 
--no-install-recommends.

I see two solutions:
1) make the debian-archive-keyring a real runtime dependency (from recommends) 
in control file
2) add the dependency on debian/tests/control.

Since I think this is not a real dependency, I propose solution 2 for the issue:

--- debuerreotype-0.10/debian/changelog 2021-02-25 21:56:24.0 +0100
+++ debuerreotype-0.10/debian/changelog 2021-03-26 23:36:13.0 +0100
@@ -1,3 +1,9 @@
+debuerreotype (0.10-3) UNRELEASED; urgency=medium
+
+  * Depend on debian-archive-keyring for autopkgtests to succeed (Closes: #-1)
+
+ -- Gianfranco Costamagna   Fri, 26 Mar 2021 
23:36:13 +0100
+
 debuerreotype (0.10-2) unstable; urgency=medium
 
   [ Tianon Gravi ]
diff -Nru debuerreotype-0.10/debian/tests/control 
debuerreotype-0.10/debian/tests/control
--- debuerreotype-0.10/debian/tests/control 2021-02-25 19:54:53.0 
+0100
+++ debuerreotype-0.10/debian/tests/control 2021-03-26 23:35:49.0 
+0100
@@ -1,5 +1,6 @@
 Tests: stretch
 Depends: ca-certificates,
+ debian-archive-keyring,
  debootstrap,
  debuerreotype,
  diffoscope,

Let me know if this sounds good for you too, and thanks for maintaining the 
package!

Gianfranco

Bug#985957: usrmerge has 47.3MB of dependencies

[Dimitri John Ledkov]

On Fri, 26 Mar 2021 at 20:58, Marco d'Itri  wrote:
>
> On Mar 26, Dimitri John Ledkov  wrote:
>
> > Is it possible to rewrite the code to only use perl-base? without the
> > full perl?
> Probably it would not be too hard to reimplement what File::Find::Rule
> does and remove these dependencies. Maybe by running find(1).
>

It actually is kind of nice, and I don't think that's the largest culprit.

> > Or maybe even pure dash or C?
> Hard to believe.
>

I mean a boy can dream right?! =)

> > Can we vendor the needed perl bits, and then remove them from disk if
> > the conversion was successful?
> I am not sure how much space this would save, do you want to try? Add:
>
> use lib "/usr/lib/usrmerge/lib/";
>
> and then start copying the dependencies to the directory until it
> works... (Also, there is App::FatPacker.)
>
> I do not know about Ubuntu, but I do not think that a self-modifying
> package would be be following Debian policy.
>

I ran strace to try to figure out which files are used from
perl-modules, which are not from perl-base. I think it's just this:

openat(AT_FDCWD, "/usr/share/perl/5.32/Fatal.pm", O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl/5.32/File/Find.pm", O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl/5.32/Tie/RefHash.pm", O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl/5.32/autodie.pm", O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl/5.32/autodie/Scope/Guard.pm",
O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl/5.32/autodie/Scope/GuardStack.pm",
O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl/5.32/autodie/Util.pm", O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl/5.32/if.pm", O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl5/File/Find/Rule.pm", O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl5/Number/Compare.pm", O_RDONLY|O_CLOEXEC)
openat(AT_FDCWD, "/usr/share/perl5/Text/Glob.pm", O_RDONLY|O_CLOEXEC)

I don't know what is the correct process to follow here. For example,
could the 5.32 things be promoted from modules to perl-base?

Not sure why "if.pm" is used.

I will see if I can vendor all of the above and thus make usrmerge be
installable with just perl-base. Probably as an Ubuntu only change,
cause yeah vendoring things like that sounds like embedded copies of
code against the Debian Policy.

> > Can we add a usrmerge-completed package, which is empty, but ensures
> > in preinst that the system is usrmerged? That way in minimal
> > containers said package will be preinstalled by default
> > satifying/providing usrmerge.
> Sure: since you apparently have a design in mind, could you provide
> a rough patch?
> Which packages do you think would depend on it?
>

In Ubuntu we use metapackages, hence in Ubuntu to ensure that all
systems upon upgrade are converted. I wanted to make ubuntu-minimal to
depend on usrmerge. However, that exploded the size of the minimal
tarballs/containers with just apt & dpkg and nothing else.

I was thinking to have a package called: usrmerged

Which Conflicts/Replaces/Provides: usrmerge, is empty, has no deps,
and in the preinst tests that the system is usrmerged. That way
ubuntu-minimal would be able to depend on usrmerge | usrmerged => with
fresh installs having no extra deps, whilst systems that try to
upgrade will eventually install usrmerge.

> > At the moment, I'm trying to make usrmerge required such that systems
> > that upgrade get it installed, but it is becomming problematic on the
> > minimal containers. Especially, since after installation its no longer
> > needed.
> I am all for improving Debian and Ubuntu to make them optimal for
> building tiny containers, but I am not sure that it is a good idea to
> do this by spending time adding complexity and bugs to usrmerge which is
> not even supposed to be installed on them since it is only needed for
> the one time conversion.

Yeah that. I'm now experimenting with makeing ubuntu-minimal recommend
usrmerge; such that it gets installed on upgrades, but not on fresh
installs (which are usrmerged anyway). Maybe that will be good enough
and will then require no minimization surgery to usrmerge.

-- 
Regards,

Dimitri.

Bug#985962: spamassassin: arbitrary code execution via malicious rule configuration files

[Noah Meyerhans]

Source: spamassassin
Version: 3.4.2-1+deb10u2
Severity: grave
Tags: security patch upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

CVE-2020-1946
Quoting from https://www.openwall.com/lists/oss-security/2021/03/24/3 :

In Apache SpamAssassin before 3.4.5, malicious rule configuration
(.cf) files can be configured to run system commands without any
output or errors. With this, exploits can be injected in a number of
scenarios.  In addition to upgrading to SA version 3.4.5, users
should only use update channels or 3rd party .cf files from trusted
places.

The fix was silently added to the 3.4 branch prior to 3.4.5~pre1 being
packaged for Debian, so it is already present in unstable and bullseye.

Buster remains exposed.

noah

Bug#980963: dpkg: Please add ARC architecture

[Vineet Gupta]

On 3/4/21 3:56 PM, Vineet Gupta wrote:
>> Also just to make sure, the GNU triplets are:
>>
>>    arc-linux-gnu
>>    arceb-linux-gnu
>> No ABI modifiers (stuff like “eabi”) for the libc part (“gnu“) right?
>
> Actually it seems we are missing hardfloat here: ARC glibc/gcc support 
> it very well and should be default for any reasonable performance.
>
> So I think we should add
>     arc-linux-gnuhf
>     arceb-linux-gnuhf
>
> BTW I have oce question: where does one select what default toggles to 
> build the entire software stack with (say -mcpu etc). Does this rely 
> on toolchain driver default to DRTH. One of my problems with 
> rebootstrap was gcc driver defaulting to our legacy cpu. I've cured it 
> there (and planning to upstream the gcc driver patch).

So here's the lay of the land, apologies for the long email, and if 
some/most of below is not directly relevant to dpkg bug, but I'll 
provide the background so we are all on same page.

We've had 3 revisions of the ISA and ensuing multiple processors in last 
15 years:

ISA Implementations/Processors (Linux capable)
-- ---
ARCompact    ARC700
ARCv2    HS38x/HS48x
ARCv3:32-bit  HS58MP
ARCv3:64-bit  HS68MP

- ARCompact is legacy and no new development needed including debian port.
- Code for one ISA is not compatible with priors, mainly due to addition 
of new instructions. In fact given the configurability of the ISA itself 
(for better or worse), one could end up 2 non-compatible variants of 
same ISA (think double load/store instructions in ARCv2). But the port 
can assume the all encompassing super-set of the ISA as baseline.
- ARCv3 is currently under development / pre-production but should be 
kept in mind as it is knocking on the door already.

In terms of the ABI critical flavors: there's little/big endian and 
soft/hard-float.
- Again big endian debian is not needed - mainly because of number of 
customer engagements and resourcing needed to support it
- ARCv2 hard-float ABI is same as soft - FPU shares the same register 
file so the calling conventions are same. However the triplet is 
different arc-linux-gnuhf [1] as libraries for hard won't run on a 
soft-float system due to lack of emulation etc.
- ARCv3 does have a dedicated FP register file so there's soft and hard ABIs

So given all of this, I'd like to propose ARCv2 port with hard-float as 
baseline. We don't bother with Big-endian. A soft-float would be 
desirable for debugging and fall-back but not necessary from feature pov.

I'm open to port names as maintainers feel appropriate - but stick with 
current triplets arc-gnu-linux / arc-gnu-linuxhf for ARCv2.
For ARCv3, we could have arc64* / arc32*

Please let me know if this makes sense.

Once we agree, we can start off with requesting changes to GNU config 
project.

Thx,
-Vineet

[1] I don't see the arc hf explicitly @ 
https://git.savannah.gnu.org/cgit/config.git/tree/testsuite/config-sub.data

Bug#985961: RFP: elpa-ednc -- Emacs Desktop Notification Center

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: elpa-ednc
  Version : 0.1
  Upstream Author : Simon Nicolussi 
* URL : https://github.com/sinic/ednc
* License : GPL-3+
  Programming Lang: Emacs-Lisp
  Description : Emacs Desktop Notification Center

The Emacs Desktop Notification Center (EDNC) is an Emacs package
written in pure Lisp that implements a Desktop Notifications
service according to the freedesktop.org specification. EDNC
aspires to be a small, but flexible drop-in replacement of
standalone notification daemons.

Bug#981088: pacemaker: crm shell can't be executed due to a library error

[Markus Koschany]

I'm dropping the bug submitter from CC because I believe the discussion is no
longer relevant for him.

Am Freitag, den 26.03.2021, 21:08 +0100 schrieb wf...@niif.hu:
> Markus Koschany  writes:
[...]
> > Yes, exactly. There should be a versioned dependency on
> > pacemaker-cli-utils.
> 
> What kind of versioned dependency?  What's your source?  I don't
> maintain crmsh, so I'm not familiar with its requirements.

One could add a versioned dependency like that 

pacemaker-cli-utils (>= 1.1.24-0+deb9u1) and then tighten this version to
whatever version is the latest for each distribution. Since you are not the
maintainer of crmsh, this is a bit inconvenient to maintain and there is a
better solution.


> I wonder if pacemaker Recommending the same version of
> pacemaker-cli-utils would have helped here...  probably not.
> Switching to Depends isn't unreasonable, but not compelling either.

You could change the Recommends to pacemaker-cli-utils (= ${source:Version})
which would have prevented the problem. This is probably the simplest solution.

> 
> > Pacemaker works fine, there was just a corner case when some packages
> > were put on hold hence my suggestion to tighten the dependency.
> 
> You needn't put anything on hold to reproduce this problem.  Just
> install pacemaker-cli-utils from stretch, then upgrade libpe-status10
> from stretch-security, and crm_mon can't start anymore.  Surely it isn't
> a common scenario, and any affected users are probably past this by now,
> but this is the gist of the problem.  We may leave it at there, though.

This scenario is unrealistic because you would install pacemaker-cli-utils also
from stretch-security because of the pinning priority. Under normal conditions
an upgrade of pacemaker would pull in all needed dependencies in Stretch. As I
said the problem here was that dependencies were intentionally put on hold by
the bug submitter.


> > We usually don't change package names in oldstable releases. In this
> > case there were no other reverse-dependencies which had to be
> > rebuilt. If there were any we would just rebuilt affected packages.
> 
> I see.  This still risks breaking software built by the user, because it
> violates Policy 8.1: "The run-time shared library must be placed in a
> package whose name changes whenever the SONAME of the shared library
> changes."  

Stretch is a LTS release now and we have to weigh our options. Normally we
don't upgrade packages to the latest upstream release but try to find targeted
fixes. This didn't work in case of pacemaker. Next we try to assess how
disrupting a new upstream release would be and if the security fixes outweigh
possible regressions. In this case it was more important to fix the security
vulnerabilities in pacemaker. Changing the package name was not really
necessary because there are no reverse-dependencies. All those libraries are
part of the same source package.

> Anyway, we have to find out if there's anything to do here.

I don't think there is anything to do in Stretch for now.

Regards,

Markus



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

Bug#985957: usrmerge has 47.3MB of dependencies

[Marco d'Itri]

On Mar 26, Dimitri John Ledkov  wrote:

> Is it possible to rewrite the code to only use perl-base? without the
> full perl?
Probably it would not be too hard to reimplement what File::Find::Rule 
does and remove these dependencies. Maybe by running find(1).

> Or maybe even pure dash or C?
Hard to believe.

> Can we vendor the needed perl bits, and then remove them from disk if
> the conversion was successful?
I am not sure how much space this would save, do you want to try? Add:

use lib "/usr/lib/usrmerge/lib/";

and then start copying the dependencies to the directory until it 
works... (Also, there is App::FatPacker.)

I do not know about Ubuntu, but I do not think that a self-modifying 
package would be be following Debian policy.

> Can we add a usrmerge-completed package, which is empty, but ensures
> in preinst that the system is usrmerged? That way in minimal
> containers said package will be preinstalled by default
> satifying/providing usrmerge.
Sure: since you apparently have a design in mind, could you provide 
a rough patch?
Which packages do you think would depend on it?

> At the moment, I'm trying to make usrmerge required such that systems
> that upgrade get it installed, but it is becomming problematic on the
> minimal containers. Especially, since after installation its no longer
> needed.
I am all for improving Debian and Ubuntu to make them optimal for 
building tiny containers, but I am not sure that it is a good idea to 
do this by spending time adding complexity and bugs to usrmerge which is 
not even supposed to be installed on them since it is only needed for 
the one time conversion.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#985960: debci: ANSI codes passed through the web interface

[Adam Borowski]

Package: debci
Severity: normal

Hi!
We generally expect build/autopkgtest log output to be plain text -- but
a lot of new-fangled build/test systems decorate it with colors.  Also,
optimizing long runs of spaces into horizontal cursor movement is not
unheard of.

Such pretty-printing got more popular these days, as common CI services
such as Travis do support colors.

debci webpages currently pass such escapes as unprintables to a http
browser, one example:
https://ci.debian.net/data/autopkgtest/testing/arm64/d/diaspora-installer/11276425/log.gz


To fix that, you could filter the logs through a converter such as ansi2html
(if colors are welcome) or ansi2txt (if not).

As discussed on IRC, it would be far cheaper to do such a conversion
on-the-fly when a particular log is requested, as the vast majority of
logs never get read.

Bug#981088: pacemaker: crm shell can't be executed due to a library error

[wferi]

Markus Koschany  writes:

> Am Freitag, den 26.03.2021, 16:37 +0100 schrieb wf...@niif.hu:
>
>> Thorsten Rehm  writes:
>> 
>>> In my opinion the crmsh package should be more strict with the
>>> pacemaker-cli-utils package
>> 
>> Sorry for not looking into this sooner.  What do you mean by being
>> "more strict"?  Does crmsh require a specific version of
>> pacemaker-cli-utils to function correctly?
>
> Yes, exactly. There should be a versioned dependency on
> pacemaker-cli-utils.

What kind of versioned dependency?  What's your source?  I don't
maintain crmsh, so I'm not familiar with its requirements.

>> While that's possible, I don't think it has anything to do with your
>> problem, which is that crm_mon requires the libpe_status.so.10 shared
>> library, but that is not provided by the 1.1.24-0+deb9u1 version of
>> libpe-status10.  Because it switched to providing libpe_status.so.16
>> instead.  The library changed SONAME, but the package name did not
>> change, which is forbidden.  The same applies to libpengine10.
>> 
>> Markus, I know introducing new packages through the security channel
>> is highly unusual, but is it entirely impossible?  Or can you
>> recommend some other solution?
>
> In my opinion this issue has been resolved in Stretch. It's up to you
> if you want to tighten the dependency on pacemaker-cli-utils in
> unstable releases but we don't need to change that in Stretch right
> now.

I wonder if pacemaker Recommending the same version of
pacemaker-cli-utils would have helped here...  probably not.
Switching to Depends isn't unreasonable, but not compelling either.

> Pacemaker works fine, there was just a corner case when some packages
> were put on hold hence my suggestion to tighten the dependency.

You needn't put anything on hold to reproduce this problem.  Just
install pacemaker-cli-utils from stretch, then upgrade libpe-status10
from stretch-security, and crm_mon can't start anymore.  Surely it isn't
a common scenario, and any affected users are probably past this by now,
but this is the gist of the problem.  We may leave it at there, though.

> We usually don't change package names in oldstable releases. In this
> case there were no other reverse-dependencies which had to be
> rebuilt. If there were any we would just rebuilt affected packages.

I see.  This still risks breaking software built by the user, because it
violates Policy 8.1: "The run-time shared library must be placed in a
package whose name changes whenever the SONAME of the shared library
changes."  Anyway, we have to find out if there's anything to do here.
-- 
Thanks,
Feri

Bug#985670: CVE-2020-27781 CVE-2020-27839

[Thomas Goirand]

On 3/25/21 7:11 PM, Salvatore Bonaccorso wrote:
> Source: ceph
> Source-Version: 14.2.18-1
> 
> On Mon, Mar 22, 2021 at 11:17:02AM +0100, Moritz Muehlenhoff wrote:
>> On Mon, Mar 22, 2021 at 10:11:29AM +0100, Thomas Goirand wrote:
>>> On 3/21/21 7:59 PM, Moritz Muehlenhoff wrote:
 Package: ceph
 Severity: important
 Tags: security
 X-Debbugs-Cc: Debian Security Team 

 CVE-2020-27781
 https://bugs.launchpad.net/manila/+bug/1904015
 https://bugzilla.redhat.com/show_bug.cgi?id=1900109
 https://github.com/ceph/ceph/commit/1b8a634fdcd94dfb3ba650793fb1b6d09af65e05
  (octopus)
 https://github.com/ceph/ceph/commit/7e3e4e73783a98bb07ab399438eb3aab41a6fc8b
  (nautilus)
 https://github.com/ceph/ceph/commit/956ceb853a58f6b6847b31fac34f2f0228a70579
  (luminous)

 CVE-2020-27839
 https://tracker.ceph.com/issues/44591
 https://github.com/ceph/ceph/pull/38259
 https://github.com/ceph/ceph/commit/23f2604d6f9ac16779b4ac43aab6e4e434f2e8ec

 Cheers,
 Moritz 

>>>
>>> Hi Moritz,
>>>
>>> To me, these issues were fixed in 14.2.16, which is already in
>>> unstable/bullseye, and aslo in Buster backports. It matches what I have
>>> in memory (but I'm not 100% sure).
>>>
>>> I tried applying the above patches, and that's how it felt too.
>>
>> I can confirm that CVE-2020-27781 is fixed in sid, 
>> 7e3e4e73783a98bb07ab399438eb3aab41a6fc8b
>> landed in v14.2.16 and thus in unstable. I've updated the Security Tracker.
>>
>> But CVE-2020-27839 was fixed in the nautilus branch in 
>> 843b2e9cd4cb996165d1818ebff125f1414f90c5
>> which only ended up in v14.2.17 and is thus missing in unstable/testing. 
>> Right?
> 
> And so adressed it looks with the 14.2.18-1 upload to unstable,
> marking the bug as such fixed.
> 
> Regards,
> Salvatore

Yeah, and I forgot to close the bug... :/

I'll upload to Backports soon...

Thomas

Bug#985958: [pre-approval] unblock: spip/3.2.11-2

[David Prévot]

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

Please unblock package spip

[ Reason ]
Upstream just released a new minor version to improve PHP 7.4 compat
(latest version already improved PHP 7.3 compat). Since Bullseye ship
with PHP 7.4, including those fixes should avoid future issues (I had
to backport a PHP 7.3 compatibility issue with a buster-security upload
already to fix a serious issue with plugins handling).

[ Impact ]
On top of fixing possible problems, this update avoids filling the
web server error.log due to multiple warnings and deprecation notices.

[ Tests ]
I only tested the package manually, but I’m keeping an eye on upstream
issues that may arise about this new release.

[ Risks ]
It’s a leaf, non-key package. Even if there are various changes, they
are mostly trivial.

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

[ Other info ]
I’ve filtered the debdiff with the following command (excluding getid3
changes because the package depends on an already up to date php-getid3
rather than the version vendored in, and some documentation), but the
result is still big, sorry:

 61 files changed, 647 insertions(+), 334 deletions(-)

  git diff debian/3.2.9-1 --ignore-all-space --ignore-blank-lines | \
  filterdiff --exclude=*/plugins-dist/medias/lib/getid3/* \
  --exclude=*NEWS --exclude=*README.md > /tmp/spip_ign_filtered.diff

unblock spip/3.2.11-2
diff --git a/CHANGELOG.TXT b/CHANGELOG.TXT
index d9db953dec..f69be25c84 100644
--- a/CHANGELOG.TXT
+++ b/CHANGELOG.TXT
@@ -1,3 +1,99 @@
+SPIP-Core v3.2.10 -> v3.2.11 (26 March 2021)
+
+
+b52a4a5b3 | cedric   | 2021-03-12 | twitterbot est aussi notre ami pour le laisser scraper l'url qu'on veut touitter (fil)
+58d5d6190 | cedric   | 2021-02-15 | Report de https://git.spip.net/spip-contrib-outils/securite/commit/e7b571681a92eb40edda24b45dc472e113c1 qui fix #4..
+6611fd50b | cedric   | 2021-02-15 | Report de https://git.spip.net/spip-contrib-outils/securite/commit/3eccaf41426d4f3c8f28b50d81e12fbe5f8af4c2
+62d33c975 | marcimat | 2021-03-26 | Notice-- : Attribut sans ses quotes... (realet)
+
+
+
+SPIP-Core v3.2.9 -> v3.2.10 (26 mars 2021)
+---
+
+0b1bd0542 | marcimat  | 2018-09-05 | Compat PHP 7.x : Scorie résiduelle du passage à mysqli. Mais ces fonctions ne semblent plus utilisées.
+7621a660a | marcimat  | 2021-03-19 | Retour partiel sur 31df72005 pour compat PHP 5.4 ...
+4de4b3c34 | marcimat  | 2021-03-19 | Correction deprecated php 7.4 : ordre de join inversé.
+0ea620c9a | marcimat  | 2018-09-05 | Tickets #4059 et #4138 : meilleure compat PHP 7.2
+f69b39c9e | marcimat  | 2021-03-18 | Suppression du fichier .gitattributes inutile.
+a54ab9a89 | rastapopoulos | 2021-03-14 | Backport de 2e55e3a60e à la main car plus dans le même fichier en 3.3.
+bdc53dcc9 | marcimat  | 2021-03-11 | Lorsqu'on déclare un traitement à un champ de rubrique, tel que `$table_des_traitements['DEMO']['rubriques'] = ...`, c..
+510983b09 | cedric| 2021-03-09 | Fix https://core.spip.net/issues/4442 : le vieux parseur xml a la main (qu'il faudrait virer) ne tolerait pas l'utilis..
+31df72005 | marcimat  | 2021-03-05 | Suite de e11b28be4 : plus éviter une fatale en PHP 8 si unicode2charset cherche à utiliser un charset inexistant
+00c2038da | marcimat  | 2021-03-05 | Correction d'une Fatale Suite à 27e4f1bcc. C'est sport mais le commit ajoute des accents dans le squelettes prive/sque..
+e380b0afd | cy.altern | 2021-03-04 | report a4cdf3b633
+916b67198 | marcimat  | 2021-03-04 | Ticket #4348 : Compat PHP 7.4 (deprecated curly braces array)
+910c245ea | marcimat  | 2020-03-26 | Compat PHP 7.4 : éviter une notice lorsque la pagination ne trouve aucune entrée.
+1b5549e51 | marcimat  | 2019-08-26 | Ticket #4348 : Compat PHP 7.4 (notice).
+c5492ea3e | marcimat  | 2019-08-26 | Ticket #4348 : Compat PHP 7.4 (deprecated curly braces array)
+da6dfc068 | marcimat  | 2019-08-26 | Ticket #4348 : Compat PHP 7.4, Trying to access array offset on value of type null.
+db1814dc5 | marcimat  | 2019-08-25 | Compat PHP 7.4, Deprecated:  Array and string offset access syntax with curly braces (Francky)
+330eb930f | marcimat  | 2019-06-17 | Ticket #4348 : Correction pour PHP 7.4 (Left-associative ternary operator deprecation)
+130ada180 | marcimat  | 2018-02-09 | Compatibilité PHP 7.2 : create_function => function xxx each => key, current, next
+8075d79f2 | marcimat  | 2017-12-11 |  Ticket #4059 : Compat PHP 7.2, remplacer un create_function.
+061107f80 | marcimat  | 2017-12-11 | Ticket #4059 : Compat PHP 7.2, remplacer des create_function.
+af94fa5d9 | marcimat  | 2017-12-11 | Ticket #4059 : Compat PHP 7.2, remplacer des 

Bug#985959: calibre: please mark autopkgtest as superficial

[Paul Gevers]

Source: calibre
Version: 5.14.0+dfsg-1
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue

Hi Maintainer,

Your package has an autopkgtest, great. However, I noticed that the test
coverage is very limited. Because of the way the results of autopkgtests
are used in Debian to influence migration, the Release Team demands [1]
such tests to be marked as superficial.

Paul

[1] https://release.debian.org/bullseye/rc_policy.txt 6(a)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985957: usrmerge has 47.3MB of dependencies

[Dimitri John Ledkov]

Package: usrmerge
Version: 23
Severity: important

Dear Maintainer,

In minimal chroot/container scenarios usrmerge has a huge amount of
dependencies, doubling the total size of the container.

# apt install usrmerge --no-install-recommends
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libfile-find-rule-perl libnumber-compare-perl libperl5.32 libtext-glob-perl 
perl perl-modules-5.32
Suggested packages:
  perl-doc libterm-readline-gnu-perl | libterm-readline-perl-perl make 
libtap-harness-archive-perl
Recommended packages:
  netbase
The following NEW packages will be installed:
  libfile-find-rule-perl libnumber-compare-perl libperl5.32 libtext-glob-perl 
perl perl-modules-5.32 usrmerge
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 7085 kB of archives.
After this operation, 47.3 MB of additional disk space will be used.

That is not acceptable for the tiny containers.

Is it possible to rewrite the code to only use perl-base? without the
full perl? Or maybe even pure dash or C?

Can we vendor the needed perl bits, and then remove them from disk if
the conversion was successful?

Can we add a usrmerge-completed package, which is empty, but ensures
in preinst that the system is usrmerged? That way in minimal
containers said package will be preinstalled by default
satifying/providing usrmerge.

At the moment, I'm trying to make usrmerge required such that systems
that upgrade get it installed, but it is becomming problematic on the
minimal containers. Especially, since after installation its no longer
needed.

Regards,

Dimitri.

Bug#788176: diodon logs copious sensitive information to zeitgeist and does not clear it

[Oliver Sauder]

Thanks Sam for reporting this.

This is actually not fully related to the original report of this issue
as it is a bug that `Clear` method does not completely remove clipboard
content from the Zeitgeist database as I agree it really should.

As discussed on the upstream issue [0] I will look into this and will
track the progress there.

[0] https://bugs.launchpad.net/diodon/+bug/1921507

Bug#985935: Actual debdiff

[Salvatore Bonaccorso]

Hi

The correct debdiff is attached.

Regards,
Salvatore
diff -Nru ldb-2.2.0/debian/changelog ldb-2.2.0/debian/changelog
--- ldb-2.2.0/debian/changelog  2020-11-18 20:33:02.0 +0100
+++ ldb-2.2.0/debian/changelog  2021-03-26 19:52:18.0 +0100
@@ -1,3 +1,17 @@
+ldb (2:2.2.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * ldb_dn: avoid head corruption in ldb_dn_explode (CVE-2020-27840)
+(Closes: #985936)
+  * pytests: move Dn.validate test to ldb
+  * ldb/attrib_handlers casefold: stay in bounds (CVE-2021-20277)
+(Closes: #985935)
+  * ldb: add tests for ldb_wildcard_compare
+  * ldb tests: ldb_match tests with extra spaces
+  * ldb: Remove tests from ldb_match_test that do not pass
+
+ -- Salvatore Bonaccorso   Fri, 26 Mar 2021 19:52:18 +0100
+
 ldb (2:2.2.0-3) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru 
ldb-2.2.0/debian/patches/CVE-2020-27840-ldb_dn-avoid-head-corruption-in-ldb_d.patch
 
ldb-2.2.0/debian/patches/CVE-2020-27840-ldb_dn-avoid-head-corruption-in-ldb_d.patch
--- 
ldb-2.2.0/debian/patches/CVE-2020-27840-ldb_dn-avoid-head-corruption-in-ldb_d.patch
 1970-01-01 01:00:00.0 +0100
+++ 
ldb-2.2.0/debian/patches/CVE-2020-27840-ldb_dn-avoid-head-corruption-in-ldb_d.patch
 2021-03-26 13:47:14.0 +0100
@@ -0,0 +1,104 @@
+From: Douglas Bagnall 
+Date: Fri, 11 Dec 2020 16:32:25 +1300
+Subject: CVE-2020-27840 ldb_dn: avoid head corruption in ldb_dn_explode
+Origin: 
https://git.samba.org/?p=samba.git;a=commitdiff;h=dbb3e65f7e382adf5fa6a6afb3d8684aca3f201a
+Bug: https://bugzilla.samba.org/show_bug.cgi?id=14595
+Bug-Debian: https://bugs.debian.org/985936
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-27840
+
+A DN string with lots of trailing space can cause ldb_dn_explode() to
+put a zero byte in the wrong place in the heap.
+
+When a DN string has a value represented with trailing spaces,
+like this
+
+ "CN=foo   ,DC=bar"
+
+the whitespace is supposed to be ignored. We keep track of this in the
+`t` pointer, which is NULL when we are not walking through trailing
+spaces, and points to the first space when we are. We are walking with
+the `p` pointer, writing the value to `d`, and keeping the length in
+`l`.
+
+ "CN=foo   ,DC= "   ==>   "foo   "
+^  ^ ^
+t  p d
+   --l---
+
+The value is finished when we encounter a comma or the end of the
+string. If `t` is not NULL at that point, we assume there are trailing
+spaces and wind `d and `l` back by the correct amount. Then we switch
+to expecting an attribute name (e.g. "CN"), until we get to an "=",
+which puts us back into looking for a value.
+
+Unfortunately, we forget to immediately tell `t` that we'd finished
+the last value, we can end up like this:
+
+ "CN=foo   ,DC= "   ==>""
+^  ^^
+t  pd
+l=0
+
+where `p` is pointing to a new value that contains only spaces, while
+`t` is still referring to the old value. `p` notices the value ends,
+and we subtract `p - t` from `d`:
+
+ "CN=foo   ,DC= "   ==>  ? ""
+^   ^^
+t   pd
+  l ~= SIZE_MAX - 8
+
+At that point `d` wants to terminate its string with a '\0', but
+instead it terminates someone else's byte. This does not crash if the
+number of trailing spaces is small, as `d` will point into a previous
+value (a copy of "foo" in this example). Corrupting that value will
+ultimately not matter, as we will soon try to allocate a buffer `l`
+long, which will be greater than the available memory and the whole
+operation will fail properly.
+
+However, with more spaces, `d` will point into memory before the
+beginning of the allocated buffer, with the exact offset depending on
+the length of the earlier attributes and the number of spaces.
+
+What about a longer DN with more attributes? For example,
+"CN=foo ,DC= ,DC=example,DC=com" -- since `d` has moved out of
+bounds, won't we continue to use it and write more DN values into
+mystery memory? Fortunately not, because the aforementioned allocation
+of `l` bytes must happen first, and `l` is now huge. The allocation
+happens in a talloc_memdup(), which is by default restricted to
+allocating 256MB.
+
+So this allows a person who controls a string parsed by ldb_dn_explode
+to corrupt heap memory by placing a single zero byte at a chosen
+offset before the allocated buffer.
+
+An LDAP bind request can send a string DN as a username. This DN is
+necessarily parsed before the password is checked, so an attacker does
+not need proper credentials. The attacker can easily cause a denial of
+service and we cannot rule out more subtle attacks.
+
+The immediate solution is to reset `t` to NULL when a comma is

Bug#985935: ldb: diff for NMU version 2:2.2.0-3.1

[Salvatore Bonaccorso]

Control: tags 985935 + patch
Control: tags 985935 + pending
Control: tags 985936 + patch
Control: tags 985936 + pending

Hi Mathieu and Debian Samba maintainers,

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

Please if possible do double check because the real tests I could do
with it is the testsuite, which I accordingly expanded, but needed to
revert wo cases as we do not have "ldb_match: trailing chunk must
match end of string".

Regards,
Salvatore
diff -Nru ldb-2.2.0/debian/changelog ldb-2.2.0/debian/changelog
--- ldb-2.2.0/debian/changelog	2020-11-18 20:33:02.0 +0100
+++ ldb-2.2.0/debian/changelog	2021-03-26 19:00:09.0 +0100
@@ -1,3 +1,17 @@
+ldb (2:2.2.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * ldb_dn: avoid head corruption in ldb_dn_explode (CVE-2020-27840)
+(Closes: #985936)
+  * pytests: move Dn.validate test to ldb
+  * ldb/attrib_handlers casefold: stay in bounds (CVE-2021-20277)
+(Closes: #985935)
+  * ldb: add tests for ldb_wildcard_compare
+  * ldb tests: ldb_match tests with extra spaces
+  * ldb: Remove tests from ldb_match_test that do not pass
+
+ -- Salvatore Bonaccorso   Fri, 26 Mar 2021 19:00:09 +0100
+
 ldb (2:2.2.0-3) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru ldb-2.2.0/debian/patches/CVE-2020-27840-ldb_dn-avoid-head-corruption-in-ldb_d.patch ldb-2.2.0/debian/patches/CVE-2020-27840-ldb_dn-avoid-head-corruption-in-ldb_d.patch
--- ldb-2.2.0/debian/patches/CVE-2020-27840-ldb_dn-avoid-head-corruption-in-ldb_d.patch	1970-01-01 01:00:00.0 +0100
+++ ldb-2.2.0/debian/patches/CVE-2020-27840-ldb_dn-avoid-head-corruption-in-ldb_d.patch	2021-03-26 19:00:09.0 +0100
@@ -0,0 +1,104 @@
+From: Douglas Bagnall 
+Date: Fri, 11 Dec 2020 16:32:25 +1300
+Subject: CVE-2020-27840 ldb_dn: avoid head corruption in ldb_dn_explode
+Origin: https://git.samba.org/?p=samba.git;a=commitdiff;h=dbb3e65f7e382adf5fa6a6afb3d8684aca3f201a
+Bug: https://bugzilla.samba.org/show_bug.cgi?id=14595
+Bug-Debian: https://bugs.debian.org/985936
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2020-27840
+
+A DN string with lots of trailing space can cause ldb_dn_explode() to
+put a zero byte in the wrong place in the heap.
+
+When a DN string has a value represented with trailing spaces,
+like this
+
+ "CN=foo   ,DC=bar"
+
+the whitespace is supposed to be ignored. We keep track of this in the
+`t` pointer, which is NULL when we are not walking through trailing
+spaces, and points to the first space when we are. We are walking with
+the `p` pointer, writing the value to `d`, and keeping the length in
+`l`.
+
+ "CN=foo   ,DC= "   ==>   "foo   "
+^  ^ ^
+t  p d
+   --l---
+
+The value is finished when we encounter a comma or the end of the
+string. If `t` is not NULL at that point, we assume there are trailing
+spaces and wind `d and `l` back by the correct amount. Then we switch
+to expecting an attribute name (e.g. "CN"), until we get to an "=",
+which puts us back into looking for a value.
+
+Unfortunately, we forget to immediately tell `t` that we'd finished
+the last value, we can end up like this:
+
+ "CN=foo   ,DC= "   ==>""
+^  ^^
+t  pd
+l=0
+
+where `p` is pointing to a new value that contains only spaces, while
+`t` is still referring to the old value. `p` notices the value ends,
+and we subtract `p - t` from `d`:
+
+ "CN=foo   ,DC= "   ==>  ? ""
+^   ^^
+t   pd
+  l ~= SIZE_MAX - 8
+
+At that point `d` wants to terminate its string with a '\0', but
+instead it terminates someone else's byte. This does not crash if the
+number of trailing spaces is small, as `d` will point into a previous
+value (a copy of "foo" in this example). Corrupting that value will
+ultimately not matter, as we will soon try to allocate a buffer `l`
+long, which will be greater than the available memory and the whole
+operation will fail properly.
+
+However, with more spaces, `d` will point into memory before the
+beginning of the allocated buffer, with the exact offset depending on
+the length of the earlier attributes and the number of spaces.
+
+What about a longer DN with more attributes? For example,
+"CN=foo ,DC= ,DC=example,DC=com" -- since `d` has moved out of
+bounds, won't we continue to use it and write more DN values into
+mystery memory? Fortunately not, because the aforementioned allocation
+of `l` bytes must happen first, and `l` is now huge. The allocation
+happens in a talloc_memdup(), which is by default restricted to
+allocating 256MB.
+
+So this allows a person who 

Bug#985956: Installation Report - Bullseye 2021-03-15

[Butch Kemper]

Package: installation-reports 

Boot method: SSD built with Rufus using this installation guide:

 https://www.raspberrypi.org/forums/viewtopic.php?f=50=282839

Image version: Debian 11 ARM64 net install ISO 
   Debian-testing-arm64-netinst.iso 2021-03-15 04:03

Date: 2021-03-25 1109

Machine: Raspberry Pi 
Processor: Broadcom BCM2711 - Quad-core Cortex-A72 (ARM v8) 64-bit SoC
Memory: 4GB
Partitions: 
FilesystemType 1K-blocks   Used Available Use% Mounted on
udev  devtmpfs   1438812  0   1438812   0% /dev
tmpfs tmpfs   297504536296968   1% /run
/dev/sda4 ext4   1883580   3724   1765836   1% /
/dev/sda5 ext4   3764408 961688   2591008  28% /usr
tmpfs tmpfs  1487504  0   1487504   0% /dev/shm
tmpfs tmpfs 5120  0  5120   0% /run/lock
/dev/sda8 ext4  99027088 241836  93708724   1% /var
/dev/sda7 ext4   1883580 44   1769516   1% /home
/dev/sda6 ext4   1883580 72   1769488   1% /usr/local
/dev/sda2 ext4   3764408 118432   3434264   4% /boot
/dev/sda1 vfat391408 342172 49236  88% /boot/efi
tmpfs tmpfs   297500  0297500   0% /run/user/1000

Output of lspci -knn (or lspci -nn): Command produces no output  here is the 
output from lsusb-tv:

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/4p, 5000M
   ID 1d6b:0003 Linux Foundation 3.0 root hub
   |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
   ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, 
ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s 
bridge
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
   ID 1d6b:0002 Linux Foundation 2.0 root hub
   |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
   ID 2109:3431 VIA Labs, Inc. Hub
   |__ Port 3: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
   ID 1c4f:0002 SiGma Micro Keyboard TRACER Gamma Ivory
   |__ Port 3: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
   ID 1c4f:0002 SiGma Micro Keyboard TRACER Gamma Ivory

Base System Installation Checklist: 
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it 
Initial boot:   [o] 
Detect network card:[e] 
Configure network:  [e] 
Detect media:   [o] 
Load installer modules: [o] 
Detect hard drives: [o] 
Partition hard drives:  [o] 
Install base system:[o] 
Clock/timezone setup:   [o] 
User/password setup:[o] 
Install tasks:  [o] 
Install boot loader:[o] 
Overall install:[o] 

Comments/Problems: Other than the not detecting the builtin ethernet adapter, 
the installation went okay.  The result of the install was a functioning system 
which when booted would detect and initialize the ethernet adapter.

When the Install process failed to find a dhcp server, I used Alt-F2 to 
activate a console and searched through the syslog for the error.  I found that 
the module mdio-bcm-unimac.ko failed to load.  When the newly built system was 
booted, I copied mdio-bcm-unimac.ko from 
/lib/modules/5.10.0-5-arm64/kernel/drivers/net/mdio to a usb stick.  

I rebuilt the SSD using Rufus and started the installation process from the 
beginning.  When the network setup failed to find the dhcp server, I opened the 
Alt-F2 console, mounted the usb stick, copied the mdio-bcm-unimac.ko module to
/lib/modules/5.10.0-5-arm64/kernel/drivers/net/mdio, and then issued the 
command insmod to install the module in the kernel.

I used  Alt-F1 to return to the installation process and selected go-back to 
restart the network configuration process.  The network adapter was 
initialized, the dhcp server found, and the installation was completed 
successfully.

This problem has been present in the Bullseye Weekly Builds: 2021-03-01, 
2021-03-08, and 2021-03-15.

The problem summary is: mdio-bcm-unimac.ko module is not installed in the 
kernel.

The problem solution is: install the mdio-bcm-unimac.ko module in the kernel.

   

Bug#985955: fscrypt reports of bad pam configuration

[Alexander Kudrevatykh]

Package: fscrypt
Version: 0.2.9-1+b2
Severity: important

Dear Maintainer,

both stable and unstable versions of fscrypt does not work at all
both of them report same error when I try to setup encrypted directory

[ERROR] fscrypt encrypt: user keyring for "kudrale" is not linked into
the session keyring

This is usually the result of a bad PAM configuration. Either correct
the problem in your PAM stack, enable
pam_keyinit.so, or run "keyctl link @u @s".

1. libpam-fscrypt is just suggested package and fscrypt should work
without pam configured at all
2. when libpam-fscrypt installed it does not work either

I'm using gnome desktop environment if it important

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

Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 fscrypt depends on:
ii  libc6 2.28-10
ii  libpam0g  1.3.1-5

fscrypt recommends no packages.

Versions of packages fscrypt suggests:
ii  libpam-fscrypt  0.2.9-1+b2

-- no debconf information

Bug#985858: Fails to start with seccomp violation (eventfd2)

[kpcyrd]

hey,

if you don't mind please go ahead.

Thank you!

Bug#985931: golang-github-aryann-difflib-dev --

[Peymaneh Nejad]

Hi,

Am 26.03.21 um 18:48 schrieb Nilesh Patra:

Hi,

As I said on debian-go@l.d.o [1] as well, the name of the source package
should "NOT" have -dev suffxed however, binary package "must" have
-dev suffixed


Ah, thanks, I got the -dev suffix thing mixed up quite a bit :D


please fix your debian/ dir

 accordingly.

Done.


I fixed it above for the ITP subject.

Thank you!



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985954: libvirt: [alpha guest] IDE controllers are unsupported for this QEMU binary or machine type

[Thorsten Glaser]

Package: libvirt0
Version: 7.0.0-3
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

libvirt pretends Alpha guests don’t use IDE:

Unable to complete install: 'unsupported configuration: IDE controllers are 
unsupported for this QEMU binary or machine type'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createvm.py", line 2001, in 
_do_async_install
installer.start_install(guest, meter=meter)
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 701, in 
start_install
domain = self._create_guest(
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 649, in 
_create_guest
domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib/python3/dist-packages/libvirt.py", line 4366, in createXML
raise libvirtError('virDomainCreateXML() failed')
libvirt.libvirtError: unsupported configuration: IDE controllers are 
unsupported for this QEMU binary or machine type

Looking at the Qemu model, however, IDE is the default (and working
when using the command line), whereas SCSI causes trouble (sym0:
unexpected disconnect).


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

Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libvirt0 depends on:
ii  libacl1  2.2.53-10
ii  libapparmor1 2.13.6-9
ii  libaudit11:3.0-2
ii  libc62.31-10
ii  libcap-ng0   0.7.9-2.2+b1
ii  libcurl3-gnutls  7.74.0-1.1
ii  libgcc-s110.2.1-6
ii  libglib2.0-0 2.66.8-1
ii  libgnutls30  3.7.1-1
ii  libnl-3-200  3.4.0-1+b1
ii  libnuma1 2.0.12-1+b1
ii  libsasl2-2   2.1.27+dfsg-2.1
ii  libselinux1  3.1-3
ii  libssh2-11.9.0-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libyajl2 2.1.0-3

Versions of packages libvirt0 recommends:
pn  lvm2  

libvirt0 suggests no packages.

-- no debconf information

Bug#985953: tracker-store: tracker-store consumes 100% of one core permanently

[gpe92]

Package: tracker
Version: 2.3.6-2
Severity: important
File: tracker-store

Dear Maintainer,

Since few days tracker-store consumes 100% of one core permanently.
tracker status returns that all indexations are done.


LANG=C tracker status
Currently indexed: 206245 files, 9746 folders
Remaining space on database partition: 276.2?GB (14.03%)
All data miners are idle, indexing complete


In /var/log/messages there are these two messages in loop:


Mar 26 18:52:00 reveillon tracker-store[26364]: Source ID 2 was not found when 
attempting to remove it
Mar 26 18:52:01 reveillon tracker-extract[23547]: There was an error pushing 
metadata: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient 
disconnected from message bus without replying


BR


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

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

Versions of packages tracker depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  dconf-gsettings-backend [gsettings-backend]   0.38.0-2
ii  libc6 2.31-10
ii  libglib2.0-0  2.66.7-2
ii  libglib2.0-bin2.66.7-2
ii  libicu67  67.1-6
ii  libsqlite3-0  3.34.1-3
ii  libstemmer0d  2.1.0-1
ii  libtracker-control-2.0-0  2.3.6-2
ii  libtracker-sparql-2.0-0   2.3.6-2
ii  shared-mime-info  2.0-1

Versions of packages tracker recommends:
ii  tracker-miner-fs  2.3.5-2

tracker suggests no packages.

-- no debconf information

Bug#985931: golang-github-aryann-difflib-dev --

[Nilesh Patra]

control: retitle -1 ITP: golang-github-aryann-difflib -- go library for diffing 
two sequences of text

Hi,

As I said on debian-go@l.d.o [1] as well, the name of the source package
should "NOT" have -dev suffxed however, binary package "must" have
-dev suffixed -- please fix your debian/ dir
accordingly.
I fixed it above for the ITP subject.

Also please note that the subject of ITP includes also a brief
description.

[1]: https://lists.debian.org/debian-go/2021/03/msg00022.html

Cheers,
Nilesh

Bug#985952: quota: quota.service is installed disabled and needs After=local-fs.target

[Dennis Filder]

Package: quota
Version: 4.04-2+deb10u1
Architecture: amd64
Severity: normal
Tags: patch
X-Debbugs-CC: d.fil...@web.de

I created a new filesystem and specified to use quota in /etc/fstab,
but didn't run quotacheck -c as I expected this to happen anyway on
reboot.  However, systemd's unit quotaon.service failed with:

  quotaon[883]: quotaon: cannot find /path/to/filesystem/aquota.group on 
/dev/mapper/vg-lv [/path/to/filesystem]
  quotaon[883]: quotaon: cannot find /path/to/filesystem/aquota.user on 
/dev/mapper/vg-lv [/path/to/filesystem]
  systemd[1]: quotaon.service: Main process exited, code=exited, 
status=2/INVALIDARGUMENT

I know that during boot /usr/share/quota/quota-initial-check.sh should
have been invoked through quota.service to fix that, but running
"systemctl is-enabled quota.service" prints "disabled" (this is on a
system installed from DVD, so no upgrade logic was ever involved).
Running "systemctl preset quota.service" then created the symlink
/etc/systemd/system/sysinit.target.wants/quota.service to
/lib/systemd/system/quota.service.  If the vendor preset for
quota.service is "enabled" then that symlink should have been created
during package installation, no?  Otherwise the preset should be
changed to "disabled" and README.Debian should explain why it is not
enabled by default.

I know with absolute certainty that I never deleted that symlink.  My
etckeeper logs don't show it either for the commit made when
installing "quota" and "quotatool":

  # etckeeper vcs show --name-only 86e432a|grep quota
  +quota 4.04-2+deb10u1 amd64
  +quotatool 1:1.6.2-5 amd64
  cron.daily/quota
  default/quota
  init.d/quota
  init.d/quotarpc
  quotagrpadmins
  quotatab
  warnquota.conf

Running the following command prints nothing either:

  find /var/lib/systemd/deb-systemd-helper-enabled -name '*quota*'

Maybe you forgot to call deb-systemd-helper/dh_systemd_enable in a
maintscript?

After enabling quota.service manually and rebooting, the service
started, but the quota files were still not created.  There is a file
/var/lib/quota/new whose creation date is equal to that of the
etckeeper commit from installing quota, but
/usr/share/quota/quota-initial-check.sh should have deleted it long
ago.  I think quota.service needs an After= in its Unit section on
either var.mount or local-fs.target, otherwise /var/lib/quota/new has
no effect if /var is a mountpoint (which it is in my case) and mounted
after quota.service has run.  With that change in place the quota
files were created correctly on the next reboot.

Of course, one could also argue that it is the user's obligation to
ensure correct ordering here as he's the one controlling the mount
units, but that approach doesn't scale well since most mount units are
generated from /etc/fstab.  Adding an After=local-fs.target sounds
like the best solution to me personally as it ensures that mountpoints
defined in /etc/fstab have been established.  Non-generated mount
units will need to specify an explicit Before=quota.service which they
easily can, thus making this a reasonable demand.

The attached patch also adds some checks to quota-initial-check.sh to
make troubleshooting easier, but you may have to adjust it a bit.

Regards,
Dennis.

N.B.: Looking at quotarpc.service I wonder if the Wants= on
rpcbind.service should actually be a BindsTo= instead, or can
rpc.rquotad function at all without rpcbind?  The rpcbind manpage
says: "All RPC servers must be restarted if rpcbind is restarted."  If
you decide to switch to a BindsTo= then
ConditionFileIsExecutable=/sbin/rpcbind should be dropped as well as
it would either occlude or duplicate the dependency relation between
both units.


quota.patch.gz
Description: application/gzip

Bug#985951: upnp-router-control: New upstream version since February 2021

[jim_p]

Package: upnp-router-control
Version: 0.2-1.2+b1
Severity: minor
Tags: upstream
X-Debbugs-Cc: pitsior...@gmail.com

Dear Maintainer,

Earlier, I noticed that upnp-router-control was removed from the repo 1+ year
ago. I had installed it a couple of years ago in order to troubleshoot some
connection issues I had and I can say it helped me a bit.
Then I went to its launchpad page to check if it is still developed from
upstream and saw that a new version (0.3) was released a month ago, with the
port to gtk3 being the most important new feature. A new version after 10 YEARS
of inactivity!
So, can you please bring it back to the repo after the freeze?

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

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

Versions of packages upnp-router-control depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-10
ii  libcairo21.16.0-5
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.7-2
ii  libgssdp-1.0-3   1.0.5-0+deb10u1
ii  libgtk2.0-0  2.24.33-1
ii  libgupnp-1.0-4   1.0.5-0+deb10u1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3

upnp-router-control recommends no packages.

upnp-router-control suggests no packages.

Bug#985825: do not remove useful packages due to political issues, please

[Holger Levsen]

On Fri, Mar 26, 2021 at 04:14:14AM +0100, Matija Nalis wrote:
> After all, we still have several "reiserfs" named packages in Debian
> main, and one should well argue that Hans Reiser actions were much bigger
> atrocity than RMS-based one.

thank you for that input!
 
> Perhaps check-dfsg-status might be good binary name (akin to
> check-support-status from debian-security-support package) if you are
> looking for non-controversial and easier to understand name.

and thank you very much for this idea. I'm considering it!

> Please do contact release team ASAP to check about what renaming
> possibilities are available, and in what timeframes.

I'm in contact with them.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

The greatest danger in times of turbulence is not the turbulence;
it is to act with yesterdays logic. (Peter Drucker)


signature.asc
Description: PGP signature

Bug#985946: patch proposal

[Frédéric Bonnard]

Here is a patch proposal which fixes the build.
The patch header details the issue and the possible workaround.
Regards,

F.


--- a/buildit.bash
+++ b/buildit.bash
@@ -156,6 +156,9 @@
 CPU="i386"
 fi
 TARGET="$CPU-$OS"
+if [ "$CPU" = "powerpc64le" ]; then
+CPU="powerpc64"
+fi
 CheckFPC
 CheckLazBuild
 CheckForQt5
@@ -193,12 +196,12 @@
 
 FPCHARD=" -Cg  -k-pie -k-znow "
 FPCKOPT=" -MObjFPC -Scgi -Cg -O1 -g -gl -l -vewnibq -vh- -Fi$K_DIR"
-FPCKUNITS=" -Fu$LAZ_DIR/packager/units/$TARGET 
-Fu$LAZ_DIR/components/lazutils/lib/$TARGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/buildintf/units/$TARGET 
-Fu$LAZ_DIR/components/freetype/lib/$TARGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/lib/$TARGET -Fu$LAZ_DIR/lcl/units/$TARGET 
-Fu$LAZ_DIR/lcl/units/$TARGET/$WIDGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$TARGET/$WIDGET 
-Fu$LAZ_DIR/components/lazcontrols/lib/$TARGET/$WIDGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/ideintf/units/$TARGET/$WIDGET 
-Fu$LAZ_DIR/components/printers/lib/$TARGET/$WIDGET"
-FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/tdbf/lib/$TARGET/$WIDGET -Fu. 
-FUlib/$TARGET"
+FPCKUNITS=" -Fu$LAZ_DIR/packager/units/$CPU-$OS 
-Fu$LAZ_DIR/components/lazutils/lib/$CPU-$OS"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/buildintf/units/$CPU-$OS 
-Fu$LAZ_DIR/components/freetype/lib/$CPU-$OS"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/lib/$CPU-$OS -Fu$LAZ_DIR/lcl/units/$CPU-$OS 
-Fu$LAZ_DIR/lcl/units/$CPU-$OS/$WIDGET"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$CPU-$OS/$WIDGET 
-Fu$LAZ_DIR/components/lazcontrols/lib/$CPU-$OS/$WIDGET"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/ideintf/units/$CPU-$OS/$WIDGET 
-Fu$LAZ_DIR/components/printers/lib/$CPU-$OS/$WIDGET"
+FPCKUNITS="$FPCKUNITS -Fu$LAZ_DIR/components/tdbf/lib/$CPU-$OS/$WIDGET -Fu. 
-FUlib/$TARGET"
 
 RUNIT="$COMPILER $EXCLUDEMESSAGE $FPCKOPT  $FPCHARD   $FPCKUNITS kmemo.pas"
 
@@ -210,7 +213,7 @@
 # exit
 
 
-if [ ! -e "$K_DIR/lib/$CPU-$OS/kmemo.o" ]; then
+if [ ! -e "$K_DIR/lib/$TARGET/kmemo.o" ]; then
echo "ERROR failed to build KControls, exiting..."
K_DIR=""
exit 1
@@ -254,15 +257,15 @@
 OPT1="-MObjFPC -Scghi -CX -Cg -O3 -XX -Xs -l -vewnibq $EXCLUDEMESSAGE 
-Fi$SOURCE_DIR/lib/$TARGET"
 
 UNITS="$UNITS -Fu$K_DIR/lib/$TARGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/tdbf/lib/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/printers/lib/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/lazcontrols/lib/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/lazutils/lib/$TARGET"
-UNITS="$UNITS -Fu$LAZ_DIR/components/ideintf/units/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$TARGET/$WIDGET"
-UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$TARGET"
-UNITS="$UNITS -Fu$LAZ_DIR/packager/units/$TARGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/tdbf/lib/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/printers/lib/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/cairocanvas/lib/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/lazcontrols/lib/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/components/lazutils/lib/$CPU-$OS"
+UNITS="$UNITS -Fu$LAZ_DIR/components/ideintf/units/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$CPU-$OS/$WIDGET"
+UNITS="$UNITS -Fu$LAZ_DIR/lcl/units/$CPU-$OS"
+UNITS="$UNITS -Fu$LAZ_DIR/packager/units/$CPU-$OS"
 
 UNITS="$UNITS -Fu$SOURCE_DIR/"
 UNITS="$UNITS -FU$SOURCE_DIR/lib/$TARGET/" 


signature.asc
Description: PGP signature

Bug#985950: network-console: Should tell user to disable public key auth when having too many ssh private keys

[Julien Rabier]

Package: network-console
Severity: normal
Tags: d-i

Hi,

I had trouble connecting to the installer because my ssh client was trying to 
authenticate using all of my ssh private keys before password auth.
As i had too many keys, this lead to a "Too many authentication failures" 
message followed by a disconnection.

network-console module should indicate to be careful of this and use -o 
PubkeyAuthentication=no.

Regards,
Julien


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

Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

Bug#985173: pacemaker-resource-agents: missing Breaks+Replaces: pacemaker (<< 2)

[wferi]

Hi Andreas,

Sorry for not responding sooner, some mail forwarding problem
intervened.  Looks like there's another serious problem with the
security upload breaking the buster upgrade path, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981088.  I haven't
asked the Security Team yet, but if that problem can be solved through
the security channel, then maybe this one could be as well?  I mean a
hypothetical 1.1.24-0+deb9u2 upload would (besides introducing the new
binary packages for the new SONAMEs to fix #981088) also move
/usr/lib/ocf/resource.d/pacemaker/ifspeed from pacemaker into
pacemaker-resource-agents, fixing the buster upgrade.  Do you think that
would work out well?  Or should we push this change regardless into
buster and unstable and bullseye?

(I understand that introducing libpe-status16 wouldn't fix the damage
already done by 1.1.24-0+deb9u2, and the workaround (upgrading
pacemaker-cli-utils) is easy and already happened anyway in most of the
cases.  So we could also follow the tactic of leaving stretch-security
alone, and tighten Breaks+Replaces in buster and beyond as you
implemented here.)
-- 
Thanks,
Feri

Bug#923500: (No Subject)

[greengrasseyes]

Hi,

I upgraded snapd from the stable channel today. It does seem as if more
confinement is now activated because of an error I am now getting with
bitcoin-core. The error is Error: Unable to open settings file
/home/user/.bitcoin/settings.json.tmp for writing. I checked the
permissions with the snap store and home access, network access and
network-bind are all turn on. I also tried turning them off and turning
it back on but same error still came up. I saw this post from someone
else that seems to have a similar issue
https://unix.stackexchange.com/questions/640560/does-snap-partial-confinement-override-user-set-permissions.

I am using debian buster.

Kernel: 4.19.0-8-amd64

type: snapd
snap-id:  I removed this for privacy reasons. I was not sure if it
was a private id or not.
tracking: latest/stable
refresh-date: today at 04:04 EDT
channels:
   latest/stable:2.49.1 2021-03-24 (11402) 33MB -
   latest/candidate: 2.49.1 2021-03-12 (11402) 33MB -
   latest/beta:  2.49.1 2021-03-08 (11402) 33MB -
   latest/edge:  2.49.1+git965.g1ba2a34 2021-03-25 (11565) 33MB -
installed:  2.49.1(11402) 33MB snapd

snap debug confinement
partial

snap debug sandbox-features
apparmor: kernel:caps kernel:domain kernel:file kernel:mount
kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace
kernel:query kernel:rlimit kernel:signal parser:unsafe policy:default
support-level:partial
confinement-options:  classic devmode
dbus: mediated-bus-access
kmod: mediated-modprobe
mount:layouts mount-namespace per-snap-persistency
per-snap-profiles per-snap-updates per-snap-user-profiles
stale-base-invalidation
seccomp:  bpf-actlog bpf-argument-filtering kernel:allow
kernel:errno kernel:kill_process kernel:kill_thread kernel:log
kernel:trace kernel:trap
udev: tagging


snap connections bitcoin-core
InterfacePlug  Slot   Notes
desktop  bitcoin-core:desktop  :desktop   -
home bitcoin-core:home :home  manual
network  bitcoin-core:network  :network   manual
network-bind bitcoin-core:network-bind :network-bind  manual
removable-media  bitcoin-core:removable-media  -  -
unity7   bitcoin-core:unity7   :unity7-
x11  bitcoin-core:x11  :x11   -

Bug#985949: chromium keeps vsyncing to 48Hz

[Raibo Quadrofus]

Package: chromium
Version: 89.0.4389.90-1
Severity: normal
X-Debbugs-Cc: raibo.quadro...@gmail.com

Dear Maintainer,

First, I am not sure if this is the correct way to report. As this is
possibly an upstream issue? However some places seam to suggest
reporting even standard bugs to distro bugtracker.

The issue is that Chromium seems to keep trying to run at 48Hz on my
system in this configuration. I am using an NVIDIA Card on GNOME on
Xorg. This issue doesn't happen with Chromium when I use my laptop's integrated
display with intel GPU on either X or Xwayland. Real refresh rate is
144hz. It clearly doesn't look smooth at all, and things like testufo
claim 48hz. Other apps run at the correct refresh rate.

I also couldn't find anyone else with this problem online.

Also, recently I used Arch Linux, with basically the exact same
configuration (same Desktop environment, DE version, NVIDIA Drivers),
and I didn't have this problem with chromium. 

I also tried the Chromium flatpak from Flathub. The issue also doesn't
exist. Its only in the deb package on Debian for me.

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

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

Versions of packages chromium depends on:
ii  chromium-common  89.0.4389.90-1
ii  libasound2   1.2.4-1.1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatomic1   10.2.1-6
ii  libatspi2.0-02.38.0-2
ii  libavcodec58 7:4.3.2-0+deb11u1
ii  libavformat587:4.3.2-0+deb11u1
ii  libavutil56  7:4.3.2-0+deb11u1
ii  libc62.31-10
ii  libcairo21.16.0-5
ii  libcups2 2.3.3op2-3
ii  libdbus-1-3  1.12.20-2
ii  libdrm2  2.4.104-1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat12.2.10-2
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgbm1  20.3.4-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.7-2
ii  libgtk-3-0   3.24.24-3
ii  libharfbuzz0b2.7.4-1
ii  libicu67 67.1-6
ii  libjpeg62-turbo  1:2.0.6-4
ii  libjsoncpp24 1.9.4-4
ii  liblcms2-2   2.12~rc1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libopenjp2-7 2.4.0-3
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpulse014.2-2
ii  libre2-9 20210201+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.7.0-2
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxrandr2   2:1.5.1-1
ii  libxshmfence11.3-1
ii  libxslt1.1   1.1.34-4
ii  zlib1g   1:1.2.11.dfsg-2

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

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

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

Versions of packages chromium-common recommends:
ii  chromium-sandbox   89.0.4389.90-1
ii  fonts-liberation   1:1.07.4-11
ii  gnome-shell [notification-daemon]  3.38.4-1
ii  libgl1-mesa-dri20.3.4-1
ii  libu2f-udev1.1.10-3
ii  notification-daemon3.20.0-4
ii  system-config-printer  1.5.14-1
ii  upower 0.99.11-2

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

-- no debconf information

Bug#981088: pacemaker: crm shell can't be executed due to a library error

[Markus Koschany]

Hello Feri,

Am Freitag, den 26.03.2021, 16:37 +0100 schrieb wf...@niif.hu:
> Control: reassign -1 libpe-status10 1.1.24-0+deb9u1
> Control: severity -1 serious
> 
> Thorsten Rehm  writes:
> 
> > In my opinion the crmsh package should be more strict with the
> > pacemaker-cli-utils package
> 
> Sorry for not looking into this sooner.  What do you mean by being "more
> strict"?  Does crmsh require a specific version of pacemaker-cli-utils
> to function correctly?

Yes, exactly. There should be a versioned dependency on pacemaker-cli-utils. 

> 
> While that's possible, I don't think it has anything to do with your
> problem, which is that crm_mon requires the libpe_status.so.10 shared
> library, but that is not provided by the 1.1.24-0+deb9u1 version of
> libpe-status10.  Because it switched to providing libpe_status.so.16
> instead.  The library changed SONAME, but the package name did not
> change, which is forbidden.  The same applies to libpengine10.
> 
> Markus, I know introducing new packages through the security channel is
> highly unusual, but is it entirely impossible?  Or can you recommend
> some other solution?

In my opinion this issue has been resolved in Stretch. It's up to you if you
want to tighten the dependency on pacemaker-cli-utils in unstable releases but
we don't need to change that in Stretch right now. Pacemaker works fine, there
was just a corner case when some packages were put on hold hence my suggestion
to tighten the dependency.

We usually don't change package names in oldstable releases. In this case there
were no other reverse-dependencies which had to be rebuilt. If there were any
we would just rebuilt affected packages.

Regards,

Markus




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

Bug#985948: libubootenv-tool: Debug lines from fw_printenv break RAUC

[Paul Jena]

Package: libubootenv-tool
Version: 0.3-1
Severity: grave

Hello,

there are compatibility problems with RAUC and the libubootenv-tool package.

RAUC requires the fw_setenv and fw_printenv utilites to interact with the
u-boot-environment. After Installing the libubootenv-tool package to get 
fw_printenv 
and fw_setenv, RAUC didnt work properly. i.e.:

$ rauc status
...
=== Bootloader ===
Activated: (null) ((null)) <-- should look like "Activated: rootfs.0 (A)
...

The reason for this is that RAUC is not able to parse the output of 
fw_printenv with the added debug message "Environment OK, copy 0":

$ fw_printenv BOOT_ORDER
Environment OK, copy 0
BOOT_ORDER=B A

After building a fw_printenv that doesnt print the Debug Mesaage the Rauc 
worked properly again.
(I looked into the source code of libubootenv and saw that passing the NDEBUG 
compiler flag
supresses the Debugging Messages:
https://salsa.debian.org/debian/libubootenv/-/blob/master/src/uboot_env.c#L946)
i.e:

$ fw_printenv BOOT_ORDER 
BOOT_ORDER=B A

$ rauc status
...
=== Bootloader ===
Activated: rootfs.1 (B)
...

Perhaps it is desirable that libubootenv-tool provides output similiar to the 
native
u-boot envtools to support compability, by building it in downstream with the 
NDEBUG
compiler flag. 

Paul Jena

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

Kernel: Linux 4.14.184-rt84-stable-16216-gdf370847d809 (SMP w/4 CPU threads; PR>
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libubootenv-tool depends on:
ii  libc6   2.31-9
ii  libubootenv0.1  0.3-1
ii  zlib1g  1:1.2.11.dfsg-2

libubootenv-tool recommends no packages.

libubootenv-tool suggests no packages.

-- no debconf information

Bug#985947: CVE-2021-28543

[Moritz Muehlenhoff]

Package: varnish-modules
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

https://varnish-cache.org/security/VSV6.html
Patch: 
https://github.com/varnish/varnish-modules/commit/2c120e576ebb73bc247790184702ba58dc0afc39

Cheers,
Moritz  

Bug#955208: [Pkg-rust-maintainers] Bug#955208: Bug#955208: Bug#955208: rustc: rustup is not available on Debian

[Ximin Luo]

Ah fair enough. Thanks for the additional detail.

Lack of signature checking is a bit annoying. It seems they have an open issue 
about it: https://github.com/rust-lang/rustup/issues/2028

X

Matt Corallo:
> I was just trying to ensure that the trust chain was correct here as some of 
> the earlier comments seemed confused - unlike most other things that install 
> software in $HOME, rustup doesn't fetch source (and optionally compile it), 
> it just fetches binaries from the same source that provides rustup itself. 
> Last I checked, it didn't even have signatures on them, only, as you note, 
> checking via X509 root CAs. If people want to use that (and package it), of 
> course.
> 
> Matt
> 
> On 3/26/21 10:19, Ximin Luo wrote:
>> Not sure what your purpose is with your comment. Nobody is asking you to 
>> package it. If somebody else wants to, this doesn't affect you, you don't 
>> have to install it.
>>
>> Packaging 3rd party software in general gives the user a trust chain from 
>> Debian trust keys to that software, rather than e.g. via HTTPS X509 root CAs.
>>
>> Lots of package managers are packaged in Debian that install other software 
>> into $HOME, such as cargo itself, opam, cabal, gem, pypi, etc etc etc.
>>
>> X
>>
>> Matt Corallo:
>>> What is the use-case for rustup being packaged? rustup is just a thin 
>>> wrapper around downloading binaries from a third party, so why not just 
>>> download it from the same third-party? It is geared at installing things in 
>>> the local users' home directory anyway.
>>>
>>> Packaging rustup doesn't address the many limitations of rustup's rustc vs 
>>> Debian's (excellently-packaged) rustc (eg cross-language LTO, LLVM plugins, 
>>> etc).
>>>
>>> Matt
>>>
>>> On Sat, 4 Apr 2020 01:19:59 +0100 Ximin Luo  wrote:
 Hi all,

 I agree that rustup should be in Debian. Achieving this is currently 
 blocked on either of these two issues:

 - https://github.com/rust-lang/rustup/issues/835 OR
 - https://salsa.debian.org/rust-team/debcargo/-/merge_requests/22

 If you want to help, achieving either of these would help to unblock 
 progress.

 X

 Ralph Giles:
> I would also like to start off with a Debian-packaged rustup rather
> than having to install it from upstream.
>> It's been discussed before, but I think no one was pursuaded to start
> maintaining a package. IIRC one issue was that rustup likes to update
> itself. You'd need to check how difficult it would be to have the
> system rustup always just install any updates in the user's .cargo
> subtree, without trying to write to the root filesytem. The user's
> local version would then take precedence through the normal PATH
> setting.
>> I think there was also some concern about support over the lifetime of
> a debian release, should upstream change their API sufficiently to stop
> the packaged version working.
>>    -r
>> On Sat, 2020-03-28 at 14:04 +0100, Martin Monperrus wrote:
>> Package: rustc
>> Version: 1.40.0+dfsg1-5
>> Severity: normal
>>
>> Dear Awesome Rust Debian Maintainers,
>>
>> I notice that rustup is not packaged for Debian. One option is to go
>> through
>> snap (https://snapcraft.io/install/rustup/debian) but native packages
>> are
>> preferable.
>>
>> Since rustup is used by many projects, it would be great to have it
>> natively on
>> Debian:
>>
>> apt-get install rustup
>>
>> What do you think?
>>
>> Best regards,
>>
>> --Martin
>>
>>
>>
>>
>>
>> -- System Information:
>> Debian Release: bullseye/sid
>>>
>>> ___
>>> Pkg-rust-maintainers mailing list
>>> pkg-rust-maintain...@alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
>>
>>
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#981088: pacemaker: crm shell can't be executed due to a library error

[wferi]

Control: reassign -1 libpe-status10 1.1.24-0+deb9u1
Control: severity -1 serious

Thorsten Rehm  writes:

> In my opinion the crmsh package should be more strict with the
> pacemaker-cli-utils package

Sorry for not looking into this sooner.  What do you mean by being "more
strict"?  Does crmsh require a specific version of pacemaker-cli-utils
to function correctly?

While that's possible, I don't think it has anything to do with your
problem, which is that crm_mon requires the libpe_status.so.10 shared
library, but that is not provided by the 1.1.24-0+deb9u1 version of
libpe-status10.  Because it switched to providing libpe_status.so.16
instead.  The library changed SONAME, but the package name did not
change, which is forbidden.  The same applies to libpengine10.

Markus, I know introducing new packages through the security channel is
highly unusual, but is it entirely impossible?  Or can you recommend
some other solution?
-- 
Thanks,
Feri

Bug#985946: tomboy-ng: FTBFS on ppc64el

[Frédéric Bonnard]

Package: src:tomboy-ng
Version: 0.32-1
Control: tags -1 ftbfs

--

Dear maintainer,
tomboy fails to build on ppc64el :
https://buildd.debian.org/status/fetch.php?pkg=tomboy-ng=ppc64el=0.32-1=1612358331=0


Regards,


F.


signature.asc
Description: PGP signature

Bug#985942: kodi: Cannot shutdown computer from kodi

[Vasyl Gello]

Hi Libor!

> Since this week (i think), I cannot shutdown/restart computer from kodi.

Please attach kodi.log in private message (to avoid hostname / IP exposure) & 
also /var/log/{apt,dpkg}/*.log
Lets see what has broken upowerd.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy

[Santiago Ruano Rincón]

Control: forwarded -1 https://github.com/libcgroup/libcgroup/issues/12
Control: tags -1 + upstream

On Tue, 28 Apr 2020 15:22:35 +0900 Ryutaroh Matsumoto 
 wrote:
> Package: cgroup-tools
> Version: 0.41-10
> Severity: normal
> Tags: wontfix
> User: pkg-systemd-maintain...@lists.alioth.debian.org
> Usertags: cgroupv2
> 
> Dear Maintainer,
> 
> It does not work in the cgroup2 / unified hierarchy. It gives
> 
> # lssubsys
> # lscgroup
> cgroups can't be listed: Cgroup is not mounted
> 
> Best regards, Ryutaroh Matsumoto
> 
> 
> -- Package-specific info:
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages cgroup-tools depends on:
> ii  libc6   2.30-4
> ii  libcgroup1  0.41-10
> 
> cgroup-tools recommends no packages.
> 
> cgroup-tools suggests no packages.
> 
> -- no debconf information
> 
> 


signature.asc
Description: PGP signature

Bug#985945: ITP: nthash -- recursive hash function for hashing all possible k-mers in a DNA/RNA sequence

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-Cc: debian-de...@lists.debian.org, nil...@debian.org

* Package name: nthash
  Version : 2.2.0-1
  Upstream Author : Hamid Mohamadi
* URL : https://github.com/bcgsc/ntHash
* License : Expat
  Programming Lang: C++
  Description : recursive hash function for hashing all possible k-mers in 
a DNA/RNA sequence

This contains:

1) nttest binary which has options for evaluating
runtimes and uniformity for different hashing methods.

2) header-only binary containing the
 necessary files for implementing nthash function.

I intend to maintain this package

Bug#985944: reportbug: Multiple headphones mic's usb or stereo ports not working.

[Les]

Package: reportbug
Version: 7.10.3
Severity: important
X-Debbugs-Cc: lesleyjad...@gmail.com

Dear Maintainer,

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

   * What led up to the situation? Upgrade the linux kernel and the new kernel 
broke the external mic input (both USB and stereo jacks).
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Tried different headsets with built-in mics (i.e. mics in 
the headset)
   * What was the outcome of this action?  Still no sound from the headset mic 
- the listener couldn't hear me.
   * What outcome did you expect instead?  Expected the headset mic to function 
and for the listener to hear me.

-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/les/.reportbugrc:
reportbug_version "7.10.3"
mode novice
ui text
email "lesleyjad...@gmail.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

-- 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-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages 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 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs-bin-common   
ii  exim4-daemon-light [mail-transport-agent]  4.94-15
ii  file   1:5.39-3
ii  gnupg  2.2.27-1
pn  python3-urwid  
pn  reportbug-gtk  
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

Bug#955208: [Pkg-rust-maintainers] Bug#955208: Bug#955208: rustc: rustup is not available on Debian

[Matt Corallo]

I was just trying to ensure that the trust chain was correct here as some of the earlier comments seemed confused - 
unlike most other things that install software in $HOME, rustup doesn't fetch source (and optionally compile it), it 
just fetches binaries from the same source that provides rustup itself. Last I checked, it didn't even have signatures 
on them, only, as you note, checking via X509 root CAs. If people want to use that (and package it), of course.


Matt

On 3/26/21 10:19, Ximin Luo wrote:

Not sure what your purpose is with your comment. Nobody is asking you to 
package it. If somebody else wants to, this doesn't affect you, you don't have 
to install it.

Packaging 3rd party software in general gives the user a trust chain from 
Debian trust keys to that software, rather than e.g. via HTTPS X509 root CAs.

Lots of package managers are packaged in Debian that install other software 
into $HOME, such as cargo itself, opam, cabal, gem, pypi, etc etc etc.

X

Matt Corallo:

What is the use-case for rustup being packaged? rustup is just a thin wrapper 
around downloading binaries from a third party, so why not just download it 
from the same third-party? It is geared at installing things in the local 
users' home directory anyway.

Packaging rustup doesn't address the many limitations of rustup's rustc vs 
Debian's (excellently-packaged) rustc (eg cross-language LTO, LLVM plugins, 
etc).

Matt

On Sat, 4 Apr 2020 01:19:59 +0100 Ximin Luo  wrote:

Hi all,

I agree that rustup should be in Debian. Achieving this is currently blocked on 
either of these two issues:

- https://github.com/rust-lang/rustup/issues/835 OR
- https://salsa.debian.org/rust-team/debcargo/-/merge_requests/22

If you want to help, achieving either of these would help to unblock progress.

X

Ralph Giles:

I would also like to start off with a Debian-packaged rustup rather
than having to install it from upstream.

It's been discussed before, but I think no one was pursuaded to start

maintaining a package. IIRC one issue was that rustup likes to update
itself. You'd need to check how difficult it would be to have the
system rustup always just install any updates in the user's .cargo
subtree, without trying to write to the root filesytem. The user's
local version would then take precedence through the normal PATH
setting.

I think there was also some concern about support over the lifetime of

a debian release, should upstream change their API sufficiently to stop
the packaged version working.

   -r
On Sat, 2020-03-28 at 14:04 +0100, Martin Monperrus wrote:
Package: rustc
Version: 1.40.0+dfsg1-5
Severity: normal

Dear Awesome Rust Debian Maintainers,

I notice that rustup is not packaged for Debian. One option is to go
through
snap (https://snapcraft.io/install/rustup/debian) but native packages
are
preferable.

Since rustup is used by many projects, it would be great to have it
natively on
Debian:

apt-get install rustup

What do you think?

Best regards,

--Martin





-- System Information:
Debian Release: bullseye/sid


___
Pkg-rust-maintainers mailing list
pkg-rust-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers

Bug#985943: buster-pu: package node-hosted-git-info/2.7.1-1+deb10u1

[Yadd]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org

[ Reason ]
node-hosted-git-info is vulnerable to RegExp Denial of Service

[ Impact ]
Medium security risk

[ Tests ]
Upstream test still pass with this patch

[ Risks ]
Trivial change

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
shortcutMatch regex is cut in two piece:
 - a more simple regexp
 - a distinc change to remove .git suffix

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index b4038a0..f8baeef 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-hosted-git-info (2.7.1-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Fix ReDoS risk (Closes: CVE-2021-23362)
+
+ -- Yadd   Fri, 26 Mar 2021 15:17:21 +0100
+
 node-hosted-git-info (2.7.1-1) unstable; urgency=medium
 
   * New upstream version 2.7.1
diff --git a/debian/patches/CVE-2021-23362.patch 
b/debian/patches/CVE-2021-23362.patch
new file mode 100644
index 000..cadac62
--- /dev/null
+++ b/debian/patches/CVE-2021-23362.patch
@@ -0,0 +1,28 @@
+Description: avoid ReDoS
+Author: nlf 
+Origin: upstream, https://github.com/npm/hosted-git-info/commit/bede0dc3
+Bug: https://snyk.io/vuln/SNYK-JS-HOSTEDGITINFO-1088355
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2021-03-26
+
+--- a/index.js
 b/index.js
+@@ -42,7 +42,7 @@
+ isGitHubShorthand(giturl) ? 'github:' + giturl : giturl
+   )
+   var parsed = parseGitUrl(url)
+-  var shortcutMatch = url.match(new 
RegExp('^([^:]+):(?:(?:[^@:]+(?:[^@]+)?@)?([^/]*))[/](.+?)(?:[.]git)?($|#)'))
++  var shortcutMatch = url.match(/^([^:]+):(?:[^@]+@)?(?:([^/]*)\/)?([^#]+)/)
+   var matches = Object.keys(gitHosts).map(function (gitHostName) {
+ try {
+   var gitHostInfo = gitHosts[gitHostName]
+@@ -56,7 +56,7 @@
+   var defaultRepresentation = null
+   if (shortcutMatch && shortcutMatch[1] === gitHostName) {
+ user = shortcutMatch[2] && decodeURIComponent(shortcutMatch[2])
+-project = decodeURIComponent(shortcutMatch[3])
++project = decodeURIComponent(shortcutMatch[3].replace(/\.git$/, ''))
+ defaultRepresentation = 'shortcut'
+   } else {
+ if (parsed.host && parsed.host !== gitHostInfo.domain && 
parsed.host.replace(/^www[.]/, '') !== gitHostInfo.domain) return
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..cc0f664
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2021-23362.patch

Bug#985942: kodi: Cannot shutdown computer from kodi

[Libor Klepáč]

Package: kodi
Version: 2:19.0+dfsg1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,
after few weeks running kodi on bullseye, shutting down computer from kodi 
stopped working.

I run kodi from ~/.xsession using autologin in lightdm autogreeter, using 
dedicated user.

Few weeks ago i upgraded from buster to bullseye, to get kodi 19.
Everything was working ok.

Since this week (i think), I cannot shutdown/restart computer from kodi.

Trying to fix it:
- - I switched from running kodi to kodi-standalone in .xsession.
- - I switched from running default session to kodi.session (using 
autologin-session=kodi in lightdm config)
- - I noticed that lightdm suggests upower and accountsservices, i installed it.
- - I disable plymouth (by taking out "splash" from grub arguments), which i 
enabled recently.
- - I tried to provide polkit file from 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863483 , 
https://forum.kodi.tv/showthread.php?tid=165707

After every change, i rebooted. Still no luck shutting down the computer from 
kodi.

Sometimes, it just quits kodi, but it is started again by lightdm.

Thanks,
Libor

-BEGIN PGP SIGNATURE-

iQJJBAEBCAAzFiEEPGZVVU37tFmB0TQv8O+MbsKfR44FAmBd8mMVHGxpYm9yLmts
ZXBhY0BiY29tLmN6AAoJEPDvjG7Cn0eO/UsQAJzGTARtaGXy2HYbRV4XvuezogW2
4mRnIojvj/dMdUEg4nyb3m/Lehn3YL8IqPM+kA3ebAE5tmPDEw2+Db1G7J1d+ecF
4S6F9KiderXg5dKfk8Zk4esnBkFyAHEVpfFZAKHpeT0ApIHdlw5w9GZgqKhjHc5B
v0TPy9JKOj+zsZFYdMKX4v374VHmDLWuPM+PBnDuzI91tTOW2FGy4JcwvMwxnrId
cbIF3LqmRUJRTCw3JWspmTDDZ5nwRjHuDE41RNqOyLrAVq+CpmTWvE+giRhRvXZE
+PnboDyCMxcTqQUYl7H6Cs9iGxRpAdd80r60gVMOKFTtXfEqN7kNXBM364gcxIqx
ZcYOraujFLaolte25BxTdeB6Rr3XbgHhiSv0nKzN43h2NulhclaCwUvnjhPvQJx6
A47Ya2PnGzv7NdQP9nwgY4BQFeTpzUXMMRJtlyBtWAeV9kCqUpOhtYDEJpiLA65r
yC0P7/oCmf3s4XKS3J1mhIELq5lkdz86nJLmll4YDrXqUhTkn6Ajc6xhTA9eUDAj
GjQ9XRXlbLB+MDHX9IQ6ShhwGaMCXkYc8nLdCFJm7qC4bpFqgEHsra+CqGRNy8TD
TS/1qTQgqSCY+c2i6ZncCTM8J4fash5rN2xwWuQnQOL8wjjGWSBGydhKWGHRm1Gb
B2UzC6HT19S8kKM5
=uGNg
-END PGP SIGNATURE-

Bug#955208: [Pkg-rust-maintainers] Bug#955208: Bug#955208: rustc: rustup is not available on Debian

[Ximin Luo]

Not sure what your purpose is with your comment. Nobody is asking you to 
package it. If somebody else wants to, this doesn't affect you, you don't have 
to install it.

Packaging 3rd party software in general gives the user a trust chain from 
Debian trust keys to that software, rather than e.g. via HTTPS X509 root CAs.

Lots of package managers are packaged in Debian that install other software 
into $HOME, such as cargo itself, opam, cabal, gem, pypi, etc etc etc.

X

Matt Corallo:
> What is the use-case for rustup being packaged? rustup is just a thin wrapper 
> around downloading binaries from a third party, so why not just download it 
> from the same third-party? It is geared at installing things in the local 
> users' home directory anyway.
> 
> Packaging rustup doesn't address the many limitations of rustup's rustc vs 
> Debian's (excellently-packaged) rustc (eg cross-language LTO, LLVM plugins, 
> etc).
> 
> Matt
> 
> On Sat, 4 Apr 2020 01:19:59 +0100 Ximin Luo  wrote:
>> Hi all,
>>
>> I agree that rustup should be in Debian. Achieving this is currently blocked 
>> on either of these two issues:
>>
>> - https://github.com/rust-lang/rustup/issues/835 OR
>> - https://salsa.debian.org/rust-team/debcargo/-/merge_requests/22
>>
>> If you want to help, achieving either of these would help to unblock 
>> progress.
>>
>> X
>>
>> Ralph Giles:
>> > I would also like to start off with a Debian-packaged rustup rather
>> > than having to install it from upstream.
>> > > It's been discussed before, but I think no one was pursuaded to start
>> > maintaining a package. IIRC one issue was that rustup likes to update
>> > itself. You'd need to check how difficult it would be to have the
>> > system rustup always just install any updates in the user's .cargo
>> > subtree, without trying to write to the root filesytem. The user's
>> > local version would then take precedence through the normal PATH
>> > setting.
>> > > I think there was also some concern about support over the lifetime of
>> > a debian release, should upstream change their API sufficiently to stop
>> > the packaged version working.
>> > >  -r
>> > > On Sat, 2020-03-28 at 14:04 +0100, Martin Monperrus wrote:
>> >> Package: rustc
>> >> Version: 1.40.0+dfsg1-5
>> >> Severity: normal
>> >>
>> >> Dear Awesome Rust Debian Maintainers,
>> >>
>> >> I notice that rustup is not packaged for Debian. One option is to go
>> >> through
>> >> snap (https://snapcraft.io/install/rustup/debian) but native packages
>> >> are
>> >> preferable.
>> >>
>> >> Since rustup is used by many projects, it would be great to have it
>> >> natively on
>> >> Debian:
>> >>
>> >> apt-get install rustup
>> >>
>> >> What do you think?
>> >>
>> >> Best regards,
>> >>
>> >> --Martin
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> -- System Information:
>> >> Debian Release: bullseye/sid
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#788176: diodon logs copious sensitive information to zeitgeist and does not clear it

[Sam Watkins]

I had a look in my zeitgeist activity.sqlite just now, and found 526MB of 
"activity" stored in the clear, including a whole lot of information which I do 
not want to be logged: at least three of my main passwords including my main 
server password, URLs of porn I have downloaded, whole files and other large 
chunks of text I have copy-pasted, commands I've entered in bash with history 
turned off, etc.

Chrome and bash do not appear to be doing this. After investigating a little 
more, it appears that Clipit aka Diodon saves everything I copy-paste to 
Zeitgeist, and it is not cleared from the "text" table when I press clear in 
the applet. I don't know if this is intentional or a bug, but it is 
user-hostile, and I feel that it is a major privacy and security concern.

I used commands like the following to check what has been logged.

> cd ~/.local/share/zeitgeist
> sqlite3 activity.sqlite
> select * from text where value like '%pass%' and length(value) < 1000; -- put 
> a bit of one of your passwords between %s in the query
> select * from text where value like '%porn%' and length(value) < 1000; -- smut
> select * from text where (value like '%mp4' or value like '%jpg' or value 
> like '%torrent') and length(value) < 1000; -- media / smut / torrents
> select * from text where length(value) > 1000;  -- large copy/paste or files

I wrote some more about this issue on AskUbuntu: 
https://askubuntu.com/a/1326275/81260

Bug#985659: petsc3.14-doc: broken symlinks: /usr/share/doc/petsc3.14-doc/html/_static/*.js -> ../../../../sphinx/themes/basic/static/*.js

[Drew Parsons]

Source: petsc
Followup-For: Bug #985659

Yeah, the sphinx/dh_sphinxdoc infrastructure seems somewhat flakey
(and we really need someone to help reinvigorate mathjax)

lintian is particularly unhelpful about it, complaining one way about
sphinx dependencies, then when you make the suggested change it
complains a different way about the same thing.

It's complicated further in petsc since the source tarball provides
prebuilt docs, which may explain why dh_sphinxdoc is not fully filling
fields automatically. It's not actually so straightforward to
regenerate their docs from scratch.

Bug#985941: libcgicc3: wrong file length if file upload via POST as "multipart/form-data"

[Romeyke, Andreas]

Package: libcgicc3
Version: 3.2.19-0.2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

   If you upload a file via POST as "multipart/form-data" to a C++ program
compiled with libcgicc3, the transmitted file length is 2 bytes too short.


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

I have attached two files that can be used to reproduce the problem. The C++
file must be compiled with 'g++ test_file_upload_post_cgicc.cpp -lcgicc'. With
the attached perl test file you can trigger the problem. Then evaluate the
output of the debug.* files (generated by CGI) and compare it with the file 
that was uploaded. In
the Perl test this is 4bytes large.
I

   * What was the outcome of this action?

The file is shortened by 2 bytes, see debug.* files.

   * What outcome did you expect instead?

The file should have thesame length as original.


With best regards

Andreas 



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

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

Versions of packages libcgicc3 depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

libcgicc3 recommends no packages.

libcgicc3 suggests no packages.

-- no debconf information

--
team member “long-term preservation“

Saxon State- and University Library Dresden (SLUB)
Department 2 (IT), Division 2.3 (infrastructure and digital long-term 
preservation) 
Zellescher Weg 18 | 01069 Dresden
phone: +49 351 4677 763
E-Mail: andreas.rome...@slub-dresden.de 
http://www.slub-dresden.de/ | @slubdresden



validate.t
Description: validate.t
/* Minimal test example to check if fileupload
  via POST and content-type "multipart/form-data"
  works as expected
  2021 by Andreas Romeyke 
*/
#include 
#include 
using namespace std;
using namespace cgicc;
int main( int argc, char* argv[] ) {
Cgicc cgi;
const CgiEnvironment& env = cgi.getEnvironment();
string request = env.getRequestMethod();
if(
("PUT" == request) ||
("POST" == request)
) {
if (0 == env.getContentLength()) {
cerr << ("CONTENT_LENGTH is empty") << endl;
exit(EXIT_FAILURE);
}
const string expected_content_type = "multipart/form-data";
string shortend_content_type = env.getContentType().substr(0, 
expected_content_type.length() );
if (shortend_content_type.compare(expected_content_type)) {
cerr << "CONTENT_TYPE is not '" << expected_content_type << "', but 
(shortend: '" << shortend_content_type << "') '" << env.getContentType() << "'";
exit(EXIT_FAILURE);
}
const_file_iterator file;
file = cgi.getFile( "pdffile" );
if (file != cgi.getFiles().end()) { // file exists
ofstream f( "debug.uploaded" );
file->writeToStream(f);
f.close();
ofstream debug ("debug.log");
debug << "contentlen=" << env.getContentLength() << endl;
debug << "len=" << file->getDataLength() << endl;
debug.close();
} else { // file does not exist
cerr << "required 'pdffile' not transmitted, got:" << endl;
for (auto file : cgi.getFiles()) {
cerr << "DEBUG FILENAME=" << file.getFilename() << endl;
cerr << "DEBUG NAME=" << file.getName() << endl;
cerr << "DEBUG DATATYPE=" << file.getDataType() << endl;
cerr << "DEBUG DATALEN=" << file.getDataLength() << endl;
cerr << "--" << endl;
}
return EXIT_FAILURE;
}
// end routing
return EXIT_SUCCESS;
}
}

Bug#985940: appstream-glib: fails to validate appdata starting with non-ascii characters

[Evangelos Ribeiro Tzaras]

Source: appstream-glib
Severity: normal

Dear Maintainer,

while running reprotest on salsa CI my package chatty [0]
failed to build during the locale variation with the russian locale [1].

It has been pointed out to me that non-ascii characters are not
handled correctly when it comes to checking for sentence case.
The offending code was identified here [2].

[0] https://salsa.debian.org/DebianOnMobile-team/chatty
[1] https://salsa.debian.org/DebianOnMobile-team/chatty/-/jobs/1536009#L2992[2] 
https://sources.debian.org/src/appstream-glib/0.7.18-1/libappstream-glib/as-app-validate.c/?hl=203#L135

-- 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: arm64, i386

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

Bug#984394: vlc: ftbfs with GCC-11

[Sebastian Ramacher]

Control: tags -1 fixed-upstream upstream

On 2021-03-03 16:18:29, Matthias Klose wrote:
> Package: src:vlc
> Version: 3.0.12-2
> Severity: normal
> Tags: sid bookworm
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-11
> 
> [This bug is not targeted to the upcoming bullseye release]
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.
> 
> The full build log can be found at:
> http://people.debian.org/~doko/logs/20210228/filtered/gcc11/vlc_3.0.12-2_unstable_gcc11.log
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++ 
> 
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-11/porting_to.html
> 
> GCC 11 defaults to the GNU++17 standard.  If your package installs
> header files in /usr/include, please don't work around C++17 issues
> by choosing a lower C++ standard for the package build, but fix these
> issues to build with the C++17 standard.
> 
> [...]
> libtool: link: echo "{ global:" > .libs/libmpgv_plugin.ver
> libtool: link:  cat .libs/libmpgv_plugin.exp | sed -e "s/\(.*\)/\1;/" >> 
> .libs/libmpgv_plugin.ver
> libtool: link:  echo "local: *; };" >> .libs/libmpgv_plugin.ver
> libtool: link:  gcc -shared  -fPIC -DPIC  demux/mpeg/.libs/mpgv.o   
> -Wl,-rpath -Wl,/<>/src/.libs ../compat/.libs/libcompat.a 
> ../src/.libs/libvlccore.so  -g -O2 -fstack-protector-strong -O3 -Wl,-z 
> -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,defs   -Wl,-soname -Wl,libmpgv_plugin.so 
> -Wl,-version-script -Wl,.libs/libmpgv_plugin.ver -o .libs/libmpgv_plugin.so
> libtool: link: ( cd ".libs" && rm -f "libmpgv_plugin.la" && ln -s 
> "../libmpgv_plugin.la" "libmpgv_plugin.la" )
> ../doltcompile gcc -DHAVE_CONFIG_H -I. -I..  
> -DMODULE_STRING=\"$(p="demux/playlist/b4s.lo"; p="${p##*/}"; p="${p#lib}"; 
> p="${p%_plugin*}"; p=$(echo "$p"|sed 's/-/_/g'); p="${p%.lo}"; echo "$p")\" 
> -D__PLUGIN__  -I./access -I./codec -I../include -I../include -Wdate-time 
> -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security   -Wall -Wextra 
> -Wsign-compare -Wundef -Wpointer-arith -Wvolatile-register-var 
> -Wformat-security -Wbad-function-cast -Wwrite-strings -Wmissing-prototypes 
> -Werror-implicit-function-declaration -Winit-self -Wlogical-op -Wshadow=local 
> -pipe -fvisibility=hidden -O3 -fno-math-errno -funsafe-math-optimizations 
> -fno-rounding-math -fno-signaling-nans -fcx-limited-range -funroll-loops 
> -fomit-frame-pointer -c -o demux/playlist/b4s.lo demux/playlist/b4s.c
> ../doltcompile gcc -DHAVE_CONFIG_H -I. -I..  
> -DMODULE_STRING=\"$(p="demux/playlist/dvb.lo"; p="${p##*/}"; p="${p#lib}"; 
> p="${p%_plugin*}"; p=$(echo "$p"|sed 's/-/_/g'); p="${p%.lo}"; echo "$p")\" 
> -D__PLUGIN__  -I./access -I./codec -I../include -I../include -Wdate-time 
> -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security   -Wall -Wextra 
> -Wsign-compare -Wundef -Wpointer-arith -Wvolatile-register-var 
> -Wformat-security -Wbad-function-cast -Wwrite-strings -Wmissing-prototypes 
> -Werror-implicit-function-declaration -Winit-self -Wlogical-op -Wshadow=local 
> -pipe -fvisibility=hidden -O3 -fno-math-errno -funsafe-math-optimizations 
> -fno-rounding-math -fno-signaling-nans -fcx-limited-range -funroll-loops 
> -fomit-frame-pointer -c -o demux/playlist/dvb.lo demux/playlist/dvb.c
> ../doltcompile gcc -DHAVE_CONFIG_H -I. -I..  
> -DMODULE_STRING=\"$(p="demux/playlist/ifo.lo"; p="${p##*/}"; p="${p#lib}"; 
> p="${p%_plugin*}"; p=$(echo "$p"|sed 's/-/_/g'); p="${p%.lo}"; echo "$p")\" 
> -D__PLUGIN__  -I./access -I./codec -I../include -I../include -Wdate-time 
> -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security   -Wall -Wextra 
> -Wsign-compare -Wundef -Wpointer-arith -Wvolatile-register-var 
> -Wformat-security -Wbad-function-cast -Wwrite-strings -Wmissing-prototypes 
> -Werror-implicit-function-declaration -Winit-self -Wlogical-op -Wshadow=local 
> -pipe -fvisibility=hidden -O3 -fno-math-errno -funsafe-math-optimizations 
> -fno-rounding-math -fno-signaling-nans -fcx-limited-range -funroll-loops 
> 

Bug#985939: ITP: wiredpanda -- logic circuits simulator

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: wiredpanda
  Version : v3.0.0
  Upstream Author : Davi Morales, Fábio Cappabianco, Lucas Lellis, Rodrigo 
Torres and Vinícius Miguel
* URL : https://github.com/GIBIS-UNIFESP/wiRedPanda
* License : GPL-3.0
  Programming Lang: C++
  Description : Logic circuits simulator

WiRed Panda is a free software designed to help students to learn about logic 
circuits and simulate them in an easy and friendly way.

The main features of the software are:

  * works on Windows, macOS and Linux;
  * Real time logic simulation;
  * User-friendly interface;
  * It's intuitive and easy to use;
  * Export your work as an image or a PDF.

--
Regards
Sudip

Bug#985927: uif: fails to start since iptables have been relocated to /usr/sbin/

[Mike Gabriel]

Package: uif
Version: 1.1.9-2
Severity: grave

The uif script fails to load on systems with still separate /(s)bin  
and /usr/(s)bin folders.


The iptables executables have recently beem moved from /sbin/ to  
/usr/sbin/. The uif init script and the uif Perl script both have  
those /sbin/ locations hard-coded.


This needs to be turned into something more flexible.

Mike
--

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

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



pgpZuZZBaIHpP.pgp
Description: Digitale PGP-Signatur

Bug#985925: uif: won't start up, if the mail command is missing on the system

[Mike Gabriel]

Package: uif
Severity: important
Version: 1.1.9-2

On a freshly installed desktop machine (i.e. one without so many  
network services), I just discovered that the uif service refuses to  
start if the mail command is not installed.


Mike
--

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

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



pgphuYMXL7FLl.pgp
Description: Digitale PGP-Signatur

Bug#985938: syncthing-discosrv: cannot set more than one option in STDISCOSRV_OPTS variable

[Simone Rossetto]

Package: syncthing-discosrv
Version: 1.0.0~ds1-1+b11
Severity: normal
Tags: patch

Dear Maintainer,

In file syncthing-discosrv.service the variable STDISCOSRV_OPTS is written with
braces and this prevents setting more than one startup option because they are
passed to stdiscosrv as a single option.

Please remove braces around STDISCOSRV_OPTS from 

  ExecStart=/usr/bin/stdiscosrv ${STDISCOSRV_OPTS}


Thanks
Simone


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

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

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

syncthing-discosrv recommends no packages.

syncthing-discosrv suggests no packages.

-- no debconf information

Bug#985937: RFS: p4c/1.2.0+g202103261112~c8d09d-1 [ITP]

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: p4c
Version: 1.2.0+g202103261112~c8d09d-1
Upstream Author:
  * URL: https://github.com/p4lang/p4c 
  * License: Apache
  * Section: devel

p4c is a new, alpha-quality reference compiler for the P4 programming
language. It supports both P4-14 and P4-16; you can find more
information about P4 here and the specifications for both versions of
the language in http://p4.org. p4c is modular; it provides a standard
frontend and midend which can be combined with a target-specific backend
to create a complete P4 compiler. The goal is to make adding new
backends easy.

"p4c " builds these binary packages:

  * p4lang-p4c - p4c p4lang project compiler

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/p4c/p4c_1.2.0+g202103261112~c8d09d-1.dsc
 


More information about "p4c " can be
obtained from https://github.com/p4lang/p4c
.

Most recent changelog entry:

p4c (1.2.0+g202103261112~c8d09d-1ppa1) unstable; urgency=medium

  * Self-made package

-- Thomas Dreibholz > Fri, 26 Mar 2021
12:12:44 +0100

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 SimulaMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985935: ldb: CVE-2021-20277

[Salvatore Bonaccorso]

Source: ldb
Version: 2:2.2.0-3
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14655
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ldb.

CVE-2021-20277[0]:
| Out of bounds read in AD DC LDAP server

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-20277
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20277
[1] https://bugzilla.samba.org/show_bug.cgi?id=14655
[2] https://www.samba.org/samba/security/CVE-2021-20277.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#985936: ldb: CVE-2020-27840

[Salvatore Bonaccorso]

Source: ldb
Version: 2:2.2.0-3
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugzilla.samba.org/show_bug.cgi?id=14595
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ldb.

CVE-2020-27840[0]:
| Heap corruption via crafted DN strings

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-27840
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27840
[1] https://bugzilla.samba.org/show_bug.cgi?id=14595
[2] https://www.samba.org/samba/security/CVE-2020-27840.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#931785: release-notes: bullseye: security suite renamed to bullseye-security (from buster/updates)

[Justin B Rye]

Justin B Rye wrote:
> It looks good, but I'd just made a note to myself that we might also
> want to mention this in upgrading.dbk where it discusses editing APT
> sources.  Hoping to send in some patches tomorrow.

Better late than never.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index 669a32bb..b26fb656 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -344,6 +344,17 @@ $ apt-forktracer | sort
 
   
 
+  
+The security section
+
+  For APT source lines referencing the security archive, the format
+  has changed slightly along with the release name, going from
+  buster/updates to
+  bullseye-security; see
+  .
+
+  
+
   
 The proposed-updates section
 

Bug#985931: golang-github-aryann-difflib-dev --

[Peymaneh Nejad]

Oh, I am sorry.
Seems i did not include ITP in the subject line. Looking into fixing that



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984938: avahi-daemon: local DoS by event-busy-loop from writing long lines to /run/avahi-daemon/socket

[Riccardo Schirone]

I have requested a CVE through Red Hat.

I'm proposing a patch upstream[1].
Additional details about the flaw at [2].

[1] https://github.com/lathiat/avahi/pull/330
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1939614#c3

Thanks,
-- 
Riccardo Schirone
Red Hat -- Product Security
Email: rschi...@redhat.com
PGP-Key ID: CF96E110


signature.asc
Description: PGP signature

Bug#985934: chromium: Built in update feature appears to be enabled

[Dominic Hargreaves]

Package: chromium
Version: 89.0.4389.82-1
Severity: important
Tags: security

I got an orange "Update" prompt near the omnibar today, as usual when
a separately packaged Chrome installation wants to update itself. But
this is not expected behaviour from the Debian packaged Chromium. I tried
clicking on it and it appeared to go through the motions and restarted
itself (very quickly, such that I don't think it can have actually done
any updates).

The browser is still running from /usr/lib/chromium/chromium (and isn't
running as root).

At the very least, this is confusing to the users who be misled into
thinking that their browser has had secuirity fixes applied when it
hasn't. And at worst, it's somehow managing to download code from the
internet and run it.

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

Kernel: Linux 5.10.0-3-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common  89.0.4389.82-1
ii  libasound2   1.2.4-1.1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatomic1   10.2.1-6
ii  libatspi2.0-02.38.0-2
ii  libavcodec58 7:4.3.2-0+deb11u1
ii  libavformat587:4.3.2-0+deb11u1
ii  libavutil56  7:4.3.2-0+deb11u1
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libcups2 2.3.3op2-3
ii  libdbus-1-3  1.12.20-2
ii  libdrm2  2.4.104-1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat12.2.10-2
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgbm1  20.3.4-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.7-2
ii  libgtk-3-0   3.24.24-3
ii  libharfbuzz0b2.7.4-1
ii  libicu67 67.1-6
ii  libjpeg62-turbo  1:2.0.6-2
ii  libjsoncpp24 1.9.4-4
ii  liblcms2-2   2.12~rc1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libopenjp2-7 2.4.0-3
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpulse014.2-2
ii  libre2-9 20210201+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.7.0-2
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxrandr2   2:1.5.1-1
ii  libxshmfence11.3-1
ii  libxslt1.1   1.1.34-4
ii  zlib1g   1:1.2.11.dfsg-2

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

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

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

Versions of packages chromium-common recommends:
ii  chromium-sandbox 89.0.4389.82-1
ii  fonts-liberation 1:1.07.4-11
ii  libgl1-mesa-dri  20.3.4-1
pn  libu2f-udev  
ii  notification-daemon  3.20.0-4
ii  system-config-printer1.5.14-1
ii  upower   0.99.11-2
ii  xfce4-notifyd [notification-daemon]  0.6.2-1

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

-- no debconf information

Bug#985933: RFS: p4lang-pi/0.1.0+g202103250946~827907-1 [ITP]

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "p4lang-pi
":

  * Package name: p4lang-pi
Version: 0.1.0+g202103250946~827907-1
Upstream Author: Antonin Bas mailto:anto...@barefootnetworks.com>>
  * URL: https://github.com/p4lang/PI 
  * License: Apache-2.0
  * Section: net

Protocol Independent API (PI or P4 Runtime) defines a set of APIs that
allow interacting with entities defined in a P4 program.

"p4lang-pi " builds these binary packages:

  * p4lang-pi-bin - Implementation framework of a P4Runtime server
(binaries)
  * p4lang-pi-dev - Implementation framework of a P4Runtime server
(development files)
  * p4lang-pi - Implementation framework of a P4Runtime server (metapackage)
  * p4lang-pi-libs - Implementation framework of a P4Runtime server
(libraries)
  * python-p4lang-pi - Implementation framework of a P4Runtime server
(Python libraries)

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/p4lang-pi/p4lang-pi_0.1.0+g202103250946~827907-1.dsc
 


More information about "p4lang-pi " can be
obtained from https://github.com/p4lang/PI .

Most recent changelog entry:

p4lang-pi (0.1.0+g202103250946~827907-1ppa1) unstable; urgency=medium

  * Self-made package

-- Thomas Dreibholz > Thu, 25 Mar 2021
10:46:15 +0100

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 SimulaMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985932: openstack-trove should not be included in Bullseye

[Thomas Goirand]

Package: openstack-trove
Version: 1:13.0.0-1
Severity: serious

Hi,

I never really tried Trove myself, and therefore, I would prefer if it was not
part of Bullseye. It will still be available from the unofficial repository
of OpenStack (osbpo.debian.net, accessible with extrepo).

Cheers,

Thomas Goirand (zigo)

Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andrius Merkys]

Hi Andreas,

On 2021-03-25 09:39, Andreas Beckmann wrote:
> On 24/03/2021 22.59, Andrius Merkys wrote:
>> However, I am not sure how to proceed next. In principle I could tinker
>> with maintscripts, but I am not sure how to instruct piuparts to pick my
>> .deb instead of what is already present in bullseye.
> 
> There is '--distupgrade-to-testdebs-from /path/to/Packages-and-.debs'

I managed to figure out a working set of command line options myself,
but thanks :)

> I see you applied the fix I suggested ;-) Sorry, didn't find time yet to
> look at this and try something.

No problem - I got an opportunity to learn something new.

> dpkg stating that both relative and absolute values work as $old_target
> is correct in most cases. Simplified, the check is
> 
> if [ $(readlink $pathname) = $old_target ] || [ $(readlink -f $pathname)
> = $old_target ]; then ... fi
> which did not work in your case because readlink returned the absolute
> path in both cases, but $old_target was relative and thus never matched.
> (But I vaguely remember a case where the relative link gave better
> results as well, so absolute is not the perfect solution.)

This sounds complicated. It would be nice to have the logic documented
somewhere, for example dpkg-maintscript-helper(1), also explaining the
use case for relative link.

> BTW: every time you add more information to a bug it will reset the
> AUTORM timer.

I came to this conclusion purely from a bunch of observations, but thank
you for confirming this!

Many thanks,
Andrius

Bug#985931: golang-github-aryann-difflib-dev --

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-aryann-difflib-dev
  Version : 0.0~git20170710.e206f87-1
  Upstream Author : Aryan Naraghi
* URL : https://github.com/aryann/difflib
* License : Expat
  Programming Lang: Go
  Description : simple library for diffing two sequences of text.

  Further information:
  I intend to apply for the gsoc project "packaging caddy for debian"[1].
  This is a build-dependency of caddy[2] that I am packaging as an application 
task.


  [1] https://wiki.debian.org/SummerOfCode2021/Projects/PackagingCaddy
  [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890



OpenPGP_signature
Description: OpenPGP digital signature

Bug#930099: pyxdg: CVE-2019-12761

[Andreas Beckmann]

On Sun, 18 Oct 2020 15:02:50 +0200 Salvatore Bonaccorso 
 wrote:

close 930099 0.26-1


Should this be fixed in stretch and buster, too?

Right now jessie-lts has a higher version than stretch(-lts),
"breaking" upgrades.

 pyxdg | 0.25-4| jessie   | source
 pyxdg | 0.25-4| stretch  | source
 pyxdg | 0.25-4+deb8u1 | jessie-security  | source
 pyxdg | 0.25-5| buster   | source
 pyxdg | 0.27-2| bullseye | source
 pyxdg | 0.27-2| sid  | source


Andreas

Bug#985914: xdg-desktop-portal-kde: should be Multi-Arch: foreign, so it satisfies steam:i386 Recommends

[Simon McVittie]

Control: retitle -1 xdg-desktop-portal-kde: should be Multi-Arch: foreign, so 
it satisfies steam:i386 Recommends
Control: reassign -1 xdg-desktop-portal-kde
Control: affects -1 + steam
Control: tags -1 + patch

On Thu, 25 Mar 2021 at 17:49:42 -0500, Boyd Stephen Smith Jr. wrote:
> steam:i386 has a recommendation for xdg-desktop-portal-backend:i386
...
> xdg-desktop-portal-kde fails to satisfy the dependency.
> 
> xdg-dekstop-portal-kde:i385 conflicts (via libkf5services-bin) with my 64-bit
> KDE Plasma environemtn.
..
> Maybe this is not properly a steam bug, and should be handled by
> xdg-dekstop-portal-kde source package instead.

Yes, I think this is something for xdg-desktop-portal-kde to
solve. It should almost certainly be Multi-Arch: foreign, like
xdg-desktop-portal-gtk is, so that xdg-desktop-portal-kde:amd64
can simultaneously satisfy the dependencies of (for example) both
flatpak:amd64 and steam:i386.

xdg-desktop-portal users like Flatpak and Steam communicate with the
portal (and, indirectly, its backends) via an architecture-independent
D-Bus interface, so it doesn't matter if their architectures don't
match. This is exactly the use-case for which Multi-Arch: foreign was
designed.

Untested patch:
https://salsa.debian.org/qt-kde-team/kde/xdg-desktop-portal-kde/-/merge_requests/7

> But, I do think stream
> architecture-dependent dependency is a big part of why this isn't working so
> well for me.

Sorry, there is no change to steam that can solve this. As long
as xdg-desktop-portal-kde is Multi-Arch: no (the default), the dpkg
dependency system does not provide a way for steam to declare a dependency
on "xdg-desktop-portal-kde of any architecture".

Workaround: install xdg-desktop-portal:amd64 and
xdg-desktop-portal-kde:amd64, and either leave steam's Recommends on
xdg-desktop-portal-backend unsatisfied, or install xdg-desktop-portal-gtk
as well (any architecture, but preferably amd64).

In a KDE/Plasma environment, xdg-desktop-portal should still prefer to use
xdg-desktop-portal-kde (as a result of the XDG_CURRENT_DESKTOP environment
variable) even if xdg-desktop-portal-gtk is also installed, so you should
still get KDE-style UIs rather than GTK/GNOME-style UIs while running a
KDE/Plasma session.

smcv

Bug#985930: duplicate lines in symbols files

[Matthias Klose]

Package: src:gpsd
Version: 3.22-2

it looks like there are many duplicate lines in symbols files.

Bug#985929: lavacli: Provide an updated lavacli for buster

[Corentin Noël]

Package: lavacli
Version: 0.9.5-1
Severity: wishlist

Dear Maintainer,

The lavacli tool has some useful fixes in latest versions (I'm
especially interested in the credential leaks that have been fixed in
https://git.lavasoftware.org/lava/lavacli/-/commit/72b98993348861132f0fd59238d94b1f5fa0d0c6
 ) and provides some useful new
features.

Would one of the maintainer be interested in backporting a more recent
lavacli to buster?

Thanks for all

Bug#981166: support origin pins based on path

[duck]

Quack,

Sorry for the lag.

On 2021-01-27 21:01, Julian Andres Klode wrote:


So effectively, what you are asking for is to allow origin to pin based
on the path, not just the hostname, like we allow for apt_auth.conf.


I need to way to securely restrict sources, so that a custom source for 
a handful of packages is not going to touch anything else on my system.
From a security point of view that's not sufficient of course but I 
would like to avoid a project adding a custom build of some lib to 
workaround a problem or other such situation.
Since o= is taken from the repo metadata it's clearly not a good fit, so 
I tried with the origin, and if I do not use acng that's working fine.


Unless you could suggest anything else with the current features it 
would be nice to add path support. It could totally be another keyword, 
I can adapt to the syntax you prefer.



It's possible to do this in 2.x since we have an extensible cache API
with private pointers where we could store an extended origin, without
breaking existing uses of origin.


:-)


Arguably we could also hack up a solution for acng's hack, but that
feels like the wrong approach.


I'm not sure how other caches handle the HTTPS case but yes clearly 
there's no reason to add dirty hacks.


Regards.
\_o<

--
Marc Dequènes

Bug#892058: Your Debian key is expiring

[Santiago Ruano Rincón]

Hello Felix,

El 23/03/21 a las 12:47, Felix Lechner escribió:
...
> Please keep in mind that the Debian folks in charge of the keyring
> update it only once a month. That usually happens on the 24th of each
> month. It it just a few days away.
> 
> If you like this service, please leave a favorable comment here [2].
> Thank you!

Extending my key's expiring date was in my ToDo list (this time). I indeed like
this service. I think gpg key should have expiring dates, but that
implies that Debian contributors should remember to renew them on time.
This service helps to avoid being blocked to make our debian duties.

Thanks,

 -- S


signature.asc
Description: PGP signature

Bug#985926: bind9: cannot create /run/named

[Ondřej Surý]

Hi Marc,

is there anything wrong with your systemd-tmpfiles?

$ cat /usr/lib/tmpfiles.d/named.conf
d /run/named 0775 root bind - -

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org

> On 26. 3. 2021, at 9:19, Marc Dequènes (duck)  wrote:
> 
> Package: bind9
> Version: 1:9.16.11-2~bpo10+1
> 
> Quack,
> 
> I got these errors at startup:
> Mar 26 08:51:46 Orfeo named[14057]: couldn't mkdir '/run/named': Permission 
> denied
> Mar 26 08:51:46 Orfeo named[14057]: generating session key for dynamic DNS
> Mar 26 08:51:46 Orfeo named[14057]: couldn't mkdir '/run/named': Permission 
> denied
> Mar 26 08:51:46 Orfeo named[14057]: could not create /run/named/session.key
> Mar 26 08:51:46 Orfeo named[14057]: failed to generate session key for 
> dynamic DNS: permission denied
> 
> and apparmor is unhappy:
> type=AVC msg=audit(1616745106.778:13945868): apparmor="DENIED" 
> operation="mkdir" profile="named" name="/run/named/" pid=14057 
> comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=102 ouid=102
> type=AVC msg=audit(1616745106.778:13945869): apparmor="DENIED" 
> operation="mkdir" profile="named" name="/run/named/" pid=14057 
> comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=102 ouid=102
> 
> Creating the directory _after_ changing user is clearly a problem that should 
> be fixed in Bind, so changing the apparmor profile would not help.
> 
> I added this in the service file:
> ExecStartPre=/bin/mkdir -p /run/named
> ExecStartPre=/bin/chown bind: /run/named
> 
> and it works now:
> # ls -la /run/named/
> total 8
> drwxr-xr-x  2 bind bind   80 Mar 26 09:06 .
> drwxr-xr-x 40 root root 1300 Mar 26 09:06 ..
> -rw-r--r--  1 bind bind6 Mar 26 09:06 named.pid
> -rw---  1 bind bind  102 Mar 26 09:06 session.key
> 
> but of course the directory is not cleaned when the service stops.
> 
> I think the best would be to reconsider this PR at least partially and run 
> the service directly as `bind` user:
>  https://salsa.debian.org/dns-team/bind9/-/merge_requests/1
> 
> I would suggest using `RuntimeDirectory` to create/cleanup the directory 
> automagically.
> 
> Regards.
> \_o<
> 
> --
> Marc Dequènes
> 



signature.asc
Description: Message signed with OpenPGP

Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1

[Salvatore Bonaccorso]

On Fri, Mar 26, 2021 at 09:12:08AM +0100, Salvatore Bonaccorso wrote:
> Hi Arnaud,
> 
> On Fri, Jul 31, 2020 at 10:20:12AM +0200, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Mon, Mar 30, 2020 at 10:08:50PM +0100, Adam D. Barratt wrote:
> > > Hi,
> > > 
> > > On Sat, 2019-10-12 at 11:41 +0200, Julien Cristau wrote:
> > > > Control: tag -1 - moreinfo
> > > > Control: tag -1 + confirmed
> > > > 
> > > > On Thu, Aug 08, 2019 at 02:47:55PM +0700, Arnaud Rebillout wrote:
> > > > > The debdiff attached brings in an upstream patch to fix
> > > > > CVE-2019-1020014, hence closes #933801.
> > > > > 
> > > > > This is my first contribution to Debian Stable, please check for
> > > > > beginners mistake ;)
> > > > > 
> > > > Please go ahead with the upload.
> > > 
> > > Ping on that.
> > 
> > Friendly ping on that.
> 
> As there was a go ahead from the SRMs,  could you do the update or
> were some problems encountered with the update?

Looks that the collabora address is not anymore valid and mail
bounced. Let me try directy arna...@debian.org.

Regards,
Salvatore

Bug#945578: buster-pu: package libapache2-mod-auth-openidc/2.3.10.2-1

[Salvatore Bonaccorso]

Hi Moritz,

On Fri, Jul 31, 2020 at 10:25:13AM +0200, Salvatore Bonaccorso wrote:
> Hi Moritz,
> 
> On Tue, Jan 28, 2020 at 10:43:25PM +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Wed, 2019-11-27 at 11:18 +0100, Moritz Schlarb wrote:
> > > Fixes CVE-2019-14857 (Open redirect in logout url when using URLs
> > > with backslashes) by improving validation of the post-logout URL
> > > parameter (backported from upstream, see 
> > > https://salsa.debian.org/debian/libapache2-mod-
> > > auth-openidc/commit/17e31b94a71ef02d1417bee6b0ef7b7379b40375)
> > > 
> > 
> > Please go ahead; sorry for the delay.
> 
> Friendly ping on the acknowledgement from Adam. Moritz did you
> recieved it? Can you upload for the 10.6 point release?

Friendly ping for the inclusion in the 10.10 point release. Did you
got the above conversation?

Regards,
Salvatore

Bug#985926: bind9: cannot create /run/named

[duck]

Package: bind9
Version: 1:9.16.11-2~bpo10+1

Quack,

I got these errors at startup:
Mar 26 08:51:46 Orfeo named[14057]: couldn't mkdir '/run/named': 
Permission denied
Mar 26 08:51:46 Orfeo named[14057]: generating session key for dynamic 
DNS
Mar 26 08:51:46 Orfeo named[14057]: couldn't mkdir '/run/named': 
Permission denied
Mar 26 08:51:46 Orfeo named[14057]: could not create 
/run/named/session.key
Mar 26 08:51:46 Orfeo named[14057]: failed to generate session key for 
dynamic DNS: permission denied


and apparmor is unhappy:
type=AVC msg=audit(1616745106.778:13945868): apparmor="DENIED" 
operation="mkdir" profile="named" name="/run/named/" pid=14057 
comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=102 
ouid=102
type=AVC msg=audit(1616745106.778:13945869): apparmor="DENIED" 
operation="mkdir" profile="named" name="/run/named/" pid=14057 
comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=102 
ouid=102


Creating the directory _after_ changing user is clearly a problem that 
should be fixed in Bind, so changing the apparmor profile would not 
help.


I added this in the service file:
ExecStartPre=/bin/mkdir -p /run/named
ExecStartPre=/bin/chown bind: /run/named

and it works now:
# ls -la /run/named/
total 8
drwxr-xr-x  2 bind bind   80 Mar 26 09:06 .
drwxr-xr-x 40 root root 1300 Mar 26 09:06 ..
-rw-r--r--  1 bind bind6 Mar 26 09:06 named.pid
-rw---  1 bind bind  102 Mar 26 09:06 session.key

but of course the directory is not cleaned when the service stops.

I think the best would be to reconsider this PR at least partially and 
run the service directly as `bind` user:

  https://salsa.debian.org/dns-team/bind9/-/merge_requests/1

I would suggest using `RuntimeDirectory` to create/cleanup the directory 
automagically.


Regards.
\_o<

--
Marc Dequènes

Bug#983110: buster-pu: package ipmitool/1.8.18-6 (CVE-2020-5208)

[Salvatore Bonaccorso]

Hi Thomas,

On Wed, Mar 17, 2021 at 07:01:35PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2021-02-20 at 22:43 +0100, Thomas Goirand wrote:
> > On 2/19/21 8:38 PM, Salvatore Bonaccorso wrote:
> > > Thanks for preparing this update! For the buster update, please
> > > adjust
> > > the target distribution to 'buster'.
> > > 
> > > Regards,
> > > Salvatore
> > 
> > Sure. I just attached the debdiff that I prepared for buster-
> > security,
> > without rebuilding. I'll rebuild accordingly when I get the go-head
> > from
> > Adam or Julien.
> 
> Please go ahead (with the distribution changed as noted).

Did you saw the acknowledgement from Adam? If so can you do the
upload? It will be missed for 10.9 now but so we still can have the
fix in the 10.10 point release.

Regards,
Salvatore

Bug#985924: pmacct FTCBFS: fails finding mysql

[Helmut Grohne]

Source: pmacct
Version: 1.7.6-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pmacct fails to cross build from source, because it uses mysql_config
and mysql_config fundamentally cannot be made to work during cross
builds. A better solution is pkg-config and that actually works. Please
consider applying the attached patch to try pkg-config before
mysql_config. Doing so makes pmacct cross buildable.

Helmut
--- pmacct-1.7.6.orig/configure.ac
+++ pmacct-1.7.6/configure.ac
@@ -374,18 +374,19 @@
 AC_MSG_CHECKING(whether to enable MySQL support)
 AC_ARG_ENABLE(mysql,
   [  --enable-mysql   Enable MySQL support (default: no)],
-  [ case "$enableval" in
-  yes)
+  [ AS_CASE(["$enableval"],
+  [yes],[
 AC_MSG_RESULT(yes)
 
-dnl no pkg-config support for MySQL
-AC_CHECK_PROG([MYSQL_CONFIG], [mysql_config], [mysql_config], [no])
-if test "x${MYSQL_CONFIG}" = "xno"; then
-  AC_MSG_ERROR([ERROR: missing mysql_config program])
-fi
+PKG_CHECK_MODULES([MYSQL],[mysqlclient],,[
+  AC_CHECK_PROG([MYSQL_CONFIG], [mysql_config], [mysql_config], [no])
+  if test "x${MYSQL_CONFIG}" = "xno"; then
+AC_MSG_ERROR([ERROR: missing mysql_config program])
+  fi
 
-MYSQL_CFLAGS=`$MYSQL_CONFIG --cflags`
-MYSQL_LIBS=`$MYSQL_CONFIG --libs`
+  MYSQL_CFLAGS=`$MYSQL_CONFIG --cflags`
+  MYSQL_LIBS=`$MYSQL_CONFIG --libs`
+])
 
 dnl version check not enforced with a AC_MSG_ERROR for now
 AX_LIB_MYSQL(5.6.3)
@@ -410,11 +411,10 @@
 AC_CHECK_LIB([numa], [numa_bind], [], [AC_MSG_ERROR([
   ERROR: missing libnuma. Requirement for building MySQL.
 ])])
-;;
-  no)
+  ],
+  [no],[
 AC_MSG_RESULT(no)
-;;
-  esac ],
+  ])],
   [
 AC_MSG_RESULT(no)
   ]

Bug#941901: buster-pu: package octavia/3.0.0-3

[Salvatore Bonaccorso]

Hi,

On Sun, Nov 10, 2019 at 05:08:54PM +0100, Thomas Goirand wrote:
> On 11/9/19 2:31 PM, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Mon, 2019-10-07 at 14:35 +0200, Thomas Goirand wrote:
> >> Since Buster was frozen, I worked quite a long time on Octavia, and
> >> was
> >> able to make the octavia-agent work properly, as well as building an
> >> Octavia base image using Debian only stuff [1]. It works super well
> >> using the next version of OpenStack, ie: Stein, while Buster has
> >> Rocky.
> >>
> >> Though I'd like to be able to provide a working Amphorae image using
> >> only stuff from Buster, if possible. This is what this update is
> >> about.
> >>
> > 
> > Please go ahead.
> > 
> > Regards,
> > 
> > Adam
> 
> Hi Adam,
> 
> On top of what you already approved, I'd like to also add what's in this
> commit:
> 
> https://salsa.debian.org/openstack-team/services/octavia/commit/25eb5debecfc53e3394ca9d5dcf2bc01c563915f
> 
> The reason is, instead of adding so many things when building the
> Octavia virtual machine image, it makes a lot of sense to instead push
> all of this in the Debian package. At the time of writing the package
> for Buster, I had no experience with this, though that's how I am
> building the image using Sid these days.
> 
> When we have these in the Octavia package, then building the official
> Buster image for Octavia will be super simple, and will integrate easily
> in the cloud team's scripts. Hopefully, we can publish such an Octavia
> image right after the next Buster point release.
> 
> I've uploaded the above. If you think that's not reasonable changes,
> please reject the package and let me know, then we can decide what you
> think can go in the Buster package and what shouldn't (though I really
> think all of the above is better suited in the package than in the image
> build script).

What is the status here? Should the package be rejected and only the
original changes included or should be the additional changes accepted
as well?

Regards,
Salvatore

Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1

[Salvatore Bonaccorso]

Hi Arnaud,

On Fri, Jul 31, 2020 at 10:20:12AM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, Mar 30, 2020 at 10:08:50PM +0100, Adam D. Barratt wrote:
> > Hi,
> > 
> > On Sat, 2019-10-12 at 11:41 +0200, Julien Cristau wrote:
> > > Control: tag -1 - moreinfo
> > > Control: tag -1 + confirmed
> > > 
> > > On Thu, Aug 08, 2019 at 02:47:55PM +0700, Arnaud Rebillout wrote:
> > > > The debdiff attached brings in an upstream patch to fix
> > > > CVE-2019-1020014, hence closes #933801.
> > > > 
> > > > This is my first contribution to Debian Stable, please check for
> > > > beginners mistake ;)
> > > > 
> > > Please go ahead with the upload.
> > 
> > Ping on that.
> 
> Friendly ping on that.

As there was a go ahead from the SRMs,  could you do the update or
were some problems encountered with the update?

Regards,
Salvatore

Bug#985895: Any volunter to write a test for bamclipper?

[Nilesh Patra]

On Fri, 26 Mar 2021 at 02:48, Andreas Tille  wrote:

> I'll do so for every package I'm touching and would have probably done
> soon for this package.  However, what I would love even more if someone
> would fix inject-into-salsa-git to approach this automatically.
>

I wonder if there is a central way to do this. We should probably ask once
the other teams who did this?

Bug#985782: unblock: cif2cell/2.0.0a1+dfsg-4

[Andrius Merkys]

On 2021-03-25 22:05, Ivo De Decker wrote:
> On Tue, Mar 23, 2021 at 02:48:01PM +0200, Andrius Merkys wrote:
>> I am seeking unblocking of cif2cell/2.0.0a1+dfsg-4.
> The deadline for packages that are not testing has passed. Sorry.

I see. Thank you for information, and sorry for the noise.

Best,
Andrius

Bug#933637: Bug#933636: CVE-2019-14934

[Salvatore Bonaccorso]

Hi Francois,

On Fri, Jul 31, 2020 at 10:18:23AM +0200, Salvatore Bonaccorso wrote:
> Hi Francois,
> 
> On Mon, Feb 10, 2020 at 03:59:22PM -0800, Francois Marier wrote:
> > On 2020-02-07 at 10:14:24, Salvatore Bonaccorso wrote:
> > > > It looks OK to me. Tagging moreinfo until there's a final diff.
> > > 
> > > Friendly ping, any news? (It's too late now for the upcoming point
> > > release though).
> > 
> > It's still on my list, but not a very high priority. Definitely won't happen
> > until at least after the Ubuntu 20.04 Debian merge deadline.
> 
> It would now be too late for the 10.5 buster point release, but do you
> found time to finalize the debdiff for review for SRM? Then we might
> target for 10.6.

There are in meanwhile one more CVE which might be included. They are
at this time CVE-2019-14267, CVE-2020-9549, CVE-2019-14934 and
CVE-2020-20740 which are all marked no-dsa or unimportant (with
negligible security impact), but maybe if you still would like to fix
those for buster, we can close this report and then open a new one
with a revisited debdiff?

What do you think?

Regards,
Salvatore

Bug#979592: RFS: openrct2/0.3.3+ds-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2

[Andrius Merkys]

On 2021-03-25 20:47, Mathias Gibbens wrote:
>   Thank you Andrius! I appreciate the time you've taken to sponsor my
> packages.
> 
>   I've pushed a signed tag to each repository.
> 
>   As new releases are made, or if there's any feedback from ftpmasters,
> I'll contact you directly.

Thank you Mathias for your contribution!

Best,
Andrius