Bug#989371: Update

2021-07-20 Thread Meredith Howard
I ran into this issue as well, and was temporarily banned from an IRC
net because irssi was in a loop reconnecting with various usernames. 
The attempts with real usernames alerted the admins but I think this sat
for several days disclosing process memory on my behalf.

This is fixed for bullseye coming up but is still a concern for buster
and stretch right now.



Bug#991103: unblock: collectd/5.12.0-7 (pre-approval)

2021-07-20 Thread Kentaro Hayashi
Control: tags -1 - moreinfo

On Sat, 17 Jul 2021 20:28:05 +0200 Sebastian Ramacher  
wrote:
> Control: tags -1 moreinfo confirmed
> 
snip
> ACK, please go ahead and remove the moreinfo tag once the new version is
> available in unstable.

Done.



Bug#991339: Unable to access battery features from tlp package

2021-07-20 Thread laalaa laalaa
Package: release-notes
Severity: normal


Hello,

Battery status and features cannot be accessed from Lenovo / Thinkpad
notebook via tlp package in Bullseye. This is due required kernel module have
not been merged to new linux kernel.

Reference from tlp author: https://linrunner.de/tlp/faq/battery.html

Cheers,

Alan


Bug#991336: unblock: freedombox/21.4.4

2021-07-20 Thread James Valleroy
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package freedombox

[ Reason ]

freedombox 21.4.4 is a fix for #991292.

The freedombox dist-upgrade feature normally sets an apt-mark hold on
the freedombox package, to prevent the system from becoming
unreachable. The hold is set and removed within a try/finally block.

However, it is possible that the upgrade process is killed before it
is completed, and that the hold is left on the freedombox package.

To recover from this state, we can check for a hold that is
incorrectly left on the package. We just need to distinguish when the
package is temporarily held during upgrade, or purposely held by
administrator. We use a flag written to disk to indicate that a hold
was placed by freedombox upgrade script.

Here are the specific changes:

* action_utils: Separate function to hold freedombox package
* action_utils: Use flag to indicate freedombox package has been held
* upgrades: Check for held freedombox package in manual update
* upgrades: Check for held freedombox package daily
* action_utils: Don't print when unholding freedombox package

[ Impact ]

The impact is that if FreedomBox users rely on the automatic
dist-upgrade feature, there is a chance that after it completes, they
will need to manually remove the hold on the freedombox package.

[ Tests ]

I tested the following:

1. A hold placed on the freedombox package by the freedombox upgrade
script (indicated by flag on disk) will eventually be removed.

2. A hold on the freedombox package by system administrator (no flag
on disk) will not be removed.

3. All applications available through FreedomBox can be installed, and
no hold is left on freedombox package.

4. Package upgrades using unattended-upgrades are not impacted.

[ Risks ]

The code is fairly understandable and has been thoroughly tested in a
FreedomBox system. No other packages are affected.

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


unblock freedombox/21.4.4


-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmD3TsUWHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICI3iD/9dSmDucHyok7iBIK/V9Z0aKsd3
0TwhR8el9UCpjqMprn9UkXDjwG5IPXWdRYe8KkShApeWTsxMY/3KrPirUa/1D4Hn
9bJiG//MTee8myeN3rYOC2WUupnm9Q0B4jvBBTo9rBGbRddu3nVfSTf6MLgRBKyB
K+B4sJZE732JWbfGIw9e7sufKGHiXq1P3I+r/9LhVhvaOKMyQFHZgxT5I7KYJs0y
usKRuwWValA9PSd2WVBPji3iJh5/w7HQKFmSsRR3H+xZ0jfR+x+e3bCj/jziR2ju
86U7yDVFfv8n/7JtwHm410GAd1ZgNYh45boPDTRONNGMU+NoukkWN/tbLI5hv5qs
D9ftf0bYaYfJIBDWrKDea+1EGJUR9ZZKXTnwPoQxrQl5PhLSrDlgmH5/69Kqrli6
DQHBOtlxeortq92OwPHA4uUL2STL9p6G7+qGD61qI7OLZr1le8EQ/yooXg6cO7yq
t4Tg7+kKWgRyTzn5uuLhO+mqBUK0+PFEeWyfXaZVOtGjmydZJDgBSMszq5pckwYG
9HEYPp6GH+W2LvWdZvuHZ5sAV8XG7xR7oHCAa8DP1YJko8yAK3IBHHz3mEznEttC
TytO0YRlYG85P4mOiQaYpJXWLFR18opBkvoDFPhh2WWGParETHx5pyb34MDMU/Dt
MfKQ3AT/LOFLvwyBOA==
=xLE8
-END PGP SIGNATURE-
diff -Nru freedombox-21.4.3/actions/packages freedombox-21.4.4/actions/packages
--- freedombox-21.4.3/actions/packages  2021-07-07 10:32:34.0 -0400
+++ freedombox-21.4.4/actions/packages  2021-07-16 09:07:51.0 -0400
@@ -18,9 +18,8 @@
 import apt_inst
 import apt_pkg
 from plinth import cfg
-from plinth.action_utils import apt_hold, run_apt_command
-
-LOCK_FILE = '/var/lib/dpkg/lock'
+from plinth.action_utils import (apt_hold_freedombox, is_package_manager_busy,
+ run_apt_command)
 
 logger = logging.getLogger(__name__)
 
@@ -93,7 +92,7 @@
 extra_arguments += ['-o', 'Dpkg::Options::=--force-confmiss']
 
 subprocess.run(['dpkg', '--configure', '-a'])
-with apt_hold():
+with apt_hold_freedombox():
 run_apt_command(['--fix-broken', 'install'])
 returncode = run_apt_command(['install'] + extra_arguments +
  arguments.packages)
@@ -115,12 +114,10 @@
 
 
 def subcommand_is_package_manager_busy(_):
-"""Return whether package manager is busy.
-This command uses the `lsof` command to check whether the dpkg lock file
-is open which indicates that the package manager is busy"""
-try:
-subprocess.check_output(['lsof', LOCK_FILE])
-except subprocess.CalledProcessError:
+"""Check whether package manager is busy.
+
+An exit code of zero indicates that package manager is busy."""
+if not is_package_manager_busy():
 sys.exit(-1)
 
 
diff -Nru freedombox-21.4.3/actions/upgrades freedombox-21.4.4/actions/upgrades
--- freedombox-21.4.3/actions/upgrades  2021-07-07 10:32:34.0 -0400
+++ freedombox-21.4.4/actions/upgrades  2021-07-16 09:07:51.0 -0400
@@ -14,9 +14,10 @@
 import sys
 import time
 
-from plinth.action_utils import (apt_hold, debconf_set_selections,
-

Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye

2021-07-20 Thread Axel Beckert
Control: tag -1 + unreproducible

Hi,

Axel Beckert wrote:
> > I'm more than willing to look into it again and fix it once we
> > identify the reason.
> 
> I'm also still intending to dig deeper here, but due to constraints at
> work can't promise that I'll manage that dist-upgrade before the
> full-freeze, sorry.

Did that dist-upgrade now and for some reason it did just passthrough
without issue around webext*. Here's the hardcopy of upgrading all
chromium* and all (non-thunderbird) webext-* packages in one go:

Performing actions...
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of chromium (90.0.4430.212-1~deb10u1 ’ 90.0.4430.212-1) 
 b1 - #990079 - chromium: Update Chromium to 91.0.4472.114
Summary:
 chromium(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] y
Reading changelogs... Done
(Reading database ... 627294 files and directories currently installed.)
Preparing to unpack .../chromium_90.0.4430.212-1_amd64.deb ...
Unpacking chromium (90.0.4430.212-1) over (90.0.4430.212-1~deb10u1) ...
Preparing to unpack .../chromium-common_90.0.4430.212-1_amd64.deb ...
Unpacking chromium-common (90.0.4430.212-1) over (90.0.4430.212-1~deb10u1) ...
Preparing to unpack .../chromium-sandbox_90.0.4430.212-1_amd64.deb ...
Unpacking chromium-sandbox (90.0.4430.212-1) over (90.0.4430.212-1~deb10u1) ...
Preparing to unpack .../chromium-driver_90.0.4430.212-1_amd64.deb ...
Unpacking chromium-driver (90.0.4430.212-1) over (90.0.4430.212-1~deb10u1) ...
Preparing to unpack .../chromium-shell_90.0.4430.212-1_amd64.deb ...
Unpacking chromium-shell (90.0.4430.212-1) over (90.0.4430.212-1~deb10u1) ...
(Reading database ... 627295 files and directories currently installed.)
Removing libicu63:amd64 (63.1-6+deb10u1) ...
Removing libjsoncpp1:amd64 (1.7.4-3) ...
Removing libre2-5:amd64 (20190101+dfsg-2) ...
Removing libvpx5:amd64 (1.7.0-3+deb10u1) ...
(Reading database ... 627257 files and directories currently installed.)
Preparing to unpack .../0-webext-browserpass_3.7.2-1+b3_amd64.deb ...
Unpacking webext-browserpass (3.7.2-1+b3) over (2.0.22-2) ...
Preparing to unpack .../1-webext-form-history-control_2.5.1.0-1_all.deb ...
Unpacking webext-form-history-control (2.5.1.0-1) over (2.3.0.0+dfsg-1) ...
Preparing to unpack .../2-webext-https-everywhere_2021.1.27-1_all.deb ...
Unpacking webext-https-everywhere (2021.1.27-1) over (2019.1.31-2) ...
Preparing to unpack .../3-webext-privacy-badger_2020.10.7-1_all.deb ...
Unpacking webext-privacy-badger (2020.10.7-1) over (2019.2.19-1) ...
Preparing to unpack .../4-webext-proxy-switcher_0.3.9-1.1_all.deb ...
Unpacking webext-proxy-switcher (0.3.9-1.1) over (0.3.9-1) ...
Preparing to unpack .../5-webext-treestyletab_3.5.20-1_all.deb ...
Unpacking webext-treestyletab (3.5.20-1) over (2.7.23-1) ...
Setting up webext-form-history-control (2.5.1.0-1) ...
Setting up webext-privacy-badger (2020.10.7-1) ...
Setting up webext-proxy-switcher (0.3.9-1.1) ...
Setting up chromium-sandbox (90.0.4430.212-1) ...
Setting up webext-browserpass (3.7.2-1+b3) ...
Removing obsolete conffile 
/etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json ...
Setting up webext-https-everywhere (2021.1.27-1) ...
Setting up webext-treestyletab (3.5.20-1) ...
Setting up chromium-common (90.0.4430.212-1) ...
Setting up chromium (90.0.4430.212-1) ...
Setting up chromium-driver (90.0.4430.212-1) ...
Setting up chromium-shell (90.0.4430.212-1) ...
Processing triggers for mailcap (3.69) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for libc-bin (2.31-12) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for flwm (1.02+git2015.10.03+7dbb30-7) ...
xfwm4-settings from /usr/share/applications/lxqt-xfwm-settings.desktop cannot 
be found in $PATH, skipping at 
/usr/share/flwm/generate-flwm-menu-from-desktop-files line 125.
xfwm4-workspace-settings from 
/usr/share/applications/lxqt-xfwm-workspaces.desktop cannot be found in $PATH, 
skipping at /usr/share/flwm/generate-flwm-menu-from-desktop-files line 125.
xfwm4-tweaks-settings from /usr/share/applications/lxqt-xfwmtweaks.desktop 
cannot be found in $PATH, skipping at 
/usr/share/flwm/generate-flwm-menu-from-desktop-files line 125.
[master 431ef37] committing changes in /etc made by "aptitude -u"
 3 files changed, 13 insertions(+), 12 deletions(-)
 delete mode 100644 
chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json
 create mode 100644 
chromium/native-messaging-hosts/com.github.browserpass.native.json
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -
Scanning processes...
Scanning candidates... [=   

  

Bug#991338: ftp-ssl: uploading with TLS fails after transfer

2021-07-20 Thread Matija Nalis
Package: ftp-ssl
Version: 0.17.34+0.2-5.1
Severity: normal
Tags: patch
X-Debbugs-Cc: mnalis-debian...@voyager.hr

Dear Maintainer,

   * What led up to the situation?

Trying to upload to vsftpd server (3.0.3-12) with ftp-ssl using TLS.

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

Uploading via plaintext FTP works normally. Tryed changing vsftpd options - did 
not help.
Fixing the ftp-ssl code helped.

   * What was the outcome of this action?

File uploads, but returns error "426 Failure reading network stream."

   * What outcome did you expect instead?

File uploads cleanly, without errors.

here is example transaction:

tekko% date > test.txt
tekko% ls -l test.txt
-rw-r--r-- 1 test test 30 Jul 21 02:34 test.txt
tekko% ftp-ssl -z secure ftp.example.org
Connected to ftp.example.org.
220 Welcome to VSFTPD
Name (ftp.example.org:test): test
234 Proceed with negotiation.
[SSL Cipher TLS_AES_256_GCM_SHA384]
200 PBSZ set to 0.
200 PROT now Private.
[Encrypted data transfer.]
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> passive
Passive mode on.
ftp> put test.txt
local: test.txt remote: test.txt
227 Entering Passive Mode (195,190,136,132,242,251).
150 Ok to send data.
426 Failure reading network stream.
30 bytes sent in 0.00 secs (770.9705 kB/s)
ftp> dir test.txt
227 Entering Passive Mode (195,190,136,132,240,196).
150 Here comes the directory listing.
-rw-r--r--1 ftp  ftp30 Jul 21 02:35 test.txt
226 Directory send OK.
ftp>

I've looked up the ftp-ssl source, as well the official docs and did some 
debugging.

Problem seems to be that ftp-ssl is closing file descriptor before doing 
SSL_shutdown(),
thus losing unsent SSL data, which vsftpd then complains about. 

So when SSL_shutdown() does run in ftp-ssl code, it then returns -1 as socket
is already gone.  According to the docs at 
https://linux.die.net/man/3/ssl_shutdown, 
client should first call SSL_shutdown() (if needed twice), and only then should 
the 
socket be closed.  Attached patch does so as documentation directs, and thus 
fixes 
the problem for me - uploads now finish with regular "226 Transfer complete."


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ftp-ssl depends on:
ii  libc6  2.31-12
ii  libedit2   3.1-20191231-2+b1
ii  libssl1.1  1.1.1k-1
ii  netbase6.3

ftp-ssl recommends no packages.

ftp-ssl suggests no packages.

-- no debconf information
--- netkit-ftp-ssl-0.17.34+0.2/ftp/ftp.c.orig   2021-07-21 02:59:00.0 
+0200
+++ netkit-ftp-ssl-0.17.34+0.2/ftp/ftp.c2021-07-21 02:59:30.632103435 
+0200
@@ -947,18 +947,20 @@
INTON;
}
INTOFF;
-   (void) fclose(dout);
-   dout = NULL;
 
 #ifdef USE_SSL
if (ssl_data_active_flag && (ssl_data_con!=NULL)) {
-   SSL_shutdown(ssl_data_con);
+   fflush(dout);
+   if (SSL_shutdown(ssl_data_con) == 0) SSL_shutdown(ssl_data_con);
SSL_free(ssl_data_con);
ssl_data_active_flag=0;
ssl_data_con=NULL;
}
 #endif /* USE_SSL */
 
+   (void) fclose(dout);
+   dout = NULL;
+
/* closes data as well, so discard it */
data = -1;
INTON;


Bug#989103: pulseaudio crashes on startup

2021-07-20 Thread sean dwyer

Hi,

I tried to use this patch and rebuild the package, it fails because the 
main patch has fuzz and quilt refresh doesn't change anything. This 
needs urgent attention, even if users are using udev-detect like myself, 
they are still catching this bug.


Sean

--
I love deadlines. I love the whooshing noise they make as they go by.



Bug#991297: rtw_8821ce does not work in debian 11

2021-07-20 Thread Michele Bucca
Il mar 20 lug 2021, 15:13 Ben Hutchings  ha scritto:

> Control: reassign -1 src:linux 5.10.40-1
> Control: tag -1 fixed-upstream
>
> On Tue, 2021-07-20 at 10:11 +0200, Michele Bucca wrote:
> > Package: firmware-realtek
> > Version 20210315-2
> >
> > I'm testing debian bullseye and I've noticed that despite the firmware
> > of the wireless card Realtek RTL8821ce being added to the package, it
> > is still not working.
> >
> > I downloaded the ISO debian-live-blsy-DI-rc2-amd64-xfce+nonfree.iso from
> >
> >
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2-live+nonfree/amd64/iso-hybrid/debian-live-blsy-DI-rc2-amd64-xfce+nonfree.iso
> >
> > and when I boot the system the Wireless card is not detected by Network
> Manager.
> >
> > if I type dmesg -l err in the terminal I get the following error message:
> >
> > [8.123230] rtw_8821ce :03:00.0: rfe 2 isn't supported
> [...]
>
> This means the driver doesn't support this variant of the hardware.
> It's not a firmware problem.
>
> That appears to be fixed in 5.12 by:
>
> commit 5d6651fe85837b11564a2e2c3c6279c057d078d6
> Author: Guo-Feng Fan 
> Date:   Tue Feb 2 13:50:12 2021 +0800
>
> rtw88: 8821c: support RFE type2 wifi NIC
>
> but that may depend on other changes.
>
> Ben.
>

Will this fix be ported to bullseye?

Michele.

-- 
> Ben Hutchings
> Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
> in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'
>


Bug#986856: RFP: dangerzone -- Take potentially dangerous PDFs, office documents, or images and convert them to a safe PDF

2021-07-20 Thread Peymaneh Nejad

Hello Antoine,

I'd like to package this application.


It seems like it also requires Docker, which we now have in Debian,
but that might be a problem for shipping with stable in the long term.

A better approach for upstream might be to use podman, or manage
containers itself, with bubblewrap or firejail or equivalent.Its recent release 
(0.2.1) is now based on podman.



I'd be happy to comaintain this in Debian with the Python team.
Before finding your RFP I thought of proposing to maintain it under umbrella of 
the privacy pkg team, but that also makes sense. Could also imagine 
(co)maintaining it.


I have done some initial packaging[1], but I think it should definitely ship 
with an autopkgtest at least for the cli binaries that are included. Hope I can 
look into that next month, but since testing is frozen anyway I think there is 
no hurry


kind regards,
Peymaneh

[1] https://salsa.debian.org/peymaneh/dangerzone



OpenPGP_signature
Description: OpenPGP digital signature


Bug#991325: unblock: systemd/247.3-6

2021-07-20 Thread Cyril Brulebois
Salvatore Bonaccorso  (2021-07-20):
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: car...@debian.org,k...@debian.org,bi...@debian.org
> Control: tags -1 d-i
> 
> Hi,
> 
> Please unblock package systemd
> 
> [ Reason ]
> The upload fixes CVE-2021-33910, which for buster was fixed via
> DSA-4942-1, 
> https://lists.debian.org/debian-security-announce/2021/msg00125.html 
> which can result in denial of service, crashing systemd and so the
> entire system.
> 
> [ Impact ]
> CVE-2021-33910 needs to be fixed in all suites.
> 
> [ Tests ]
> The testsuite on one hand, and specifically the fixes needed for
> CVE-2021-33910.
> 
> [ Risks ]
> The changes has been tested by various vendors in preparation of the
> security advisories. No regression spotted in the automated testsuite
> nor while manually testing.
> 
> [ 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 ]
> Needs a d-i ack as well, kibi is aded in X-Debbugs-CC.
> 
> unblock systemd/247.3-6

Falls under the same “whatever is needed” mentioned earlier on IRC: feel
free to let it migrate as soon as required.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#991337: pulseaudio: Pulseaudio craches on start with SegFault error

2021-07-20 Thread Mikhail Vereshchagin
Subject: pulseaudio: Pulseaudio craches on start with SegFault error
Package: pulseaudio
Version: 14.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
Probably, some daily dist-upgrade.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to reinstall alsa and pulseaudio, tried to downgrade to the version
in stable branch, to upgrade to newer version in experimental branch.
   * What was the outcome of this action?
Nothing has helped me.
   * What outcome did you expect instead?

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


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable'), (500,
'testing-security'), (500, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 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 pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1:1.2.2-dmo2
ii  libc62.31-12
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2
ii  libgcc-s110.2.1-6
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.2-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-1
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-5
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.3-5
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.2-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-2
ii  libpam-systemd [logind]  247.3-5
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  4.0-2
pn  pavumeter
ii  udev 247.3-5

-- no debconf information

$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: nvidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: nvidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: nvidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: nvidia [HDA NVidia], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: nvidia [HDA NVidia], device 10: HDMI 4 [HDMI 4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: nvidia [HDA NVidia], device 11: HDMI 5 [HDMI 5]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: nvidia [HDA NVidia], device 12: HDMI 6 [HDMI 6]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: USB [E-MU 0202 | USB], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Generic [HD-Audio Generic], device 0: ALC892 Analog [ALC892 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


$ pulseaudio -v
I: [pulseaudio] main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation
not permitted
I: [pulseaudio] main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation
not permitted
I: [pulseaudio] core-util.c: Successfully gained nice level -11.
I: [pulseaudio] main.c: This is PulseAudio 14.2
I: [pulseaudio] main.c: Page size is 4096 bytes
I: [pulseaudio] main.c: Machine ID is 580a7497c5e24616b441919d089608b6.
I: [pulseaudio] main.c: Using runtime directory /run/user/1000/pulse.
I: [pulseaudio] main.c: Using state directory /home/misha/.config/pulse.
I: [pulseaudio] main.c: Using modules directory /usr/lib/pulse-14.2/modules.
I: [pulseaudio] main.c: Running in system mode: no
W: [pulseaudio] pid.c: Stale PID file, overwriting.
I: [pulseaudio] main.c: System supports high resolution timers
I: [pulseaudio] cpu-x86.c: CPU flags: CMOV MMX SSE SSE2 SSE3 SSSE3 SSE4_1
SSE4_2 MMXEXT
I: [pulseaudio] svolume_mmx.c: Initialising MMX optimized volume functions.
I: [pulseaudio] remap_mmx.c: Initialising MMX optimized remappers.
I: [pulseaudio] svolume_sse.c: Initialising SSE2 optimized volume functions.
I: [pulseaudio] remap_sse.c: Initialising 

Bug#990956: uploading lintian-brush to testing-proposed-updates

2021-07-20 Thread Jelmer Vernooij
tags 990956 -moreinfo
thanks

On Tue, Jul 20, 2021 at 10:46:12PM +0200, Paul Gevers wrote:
> On 20-07-2021 00:29, Jelmer Vernooij wrote:
> >> Still not promising anything, but what would be the proposed change in
> >> t-p-u?
> > Please find attached the proposed change. Please note that it only
> > affects the testsuite.
> 
> That last note was what I was hoping for. Under the assumption that the
> upload happens soon (we're hopefully close to releasing), please go
> ahead. Please remove the moreinfo tag once the upload happened.
Done, thanks. Hopefully this looks alright.

Cheers,

Jelmer


signature.asc
Description: PGP signature


Bug#990368: Supertuxkart has proprietary data

2021-07-20 Thread Reiner Herrmann
I have asked the release team in #991335 for pre-approval of a
upstream tarball repack which removes the non-free karts, includes the
suggested patches by upstream and will either clarify the remaining open
copyright questions or replace the assets with alternatives.
I'm currently in contact with an upstream contributor working with
others on the license questions.

Kind regards,
  Reiner


signature.asc
Description: PGP signature


Bug#991335: unblock: supertuxkart (pre-approval)

2021-07-20 Thread Reiner Herrmann
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release team,

this is a request for pre-approval of a supertuxkart upload.

The upstream tarball of supertuxkart 1.2+ds-2 currently includes data
files that are not free (#990368). Additionaly the d/copyright file is
lacking license information for a few additional resources (only data files).

To fix this bug, the two non-free karts will get removed from the upstream
tarball. But as removal of these files would cause a regression in online
multiplayer games, upstream provided two patches (+1 patch that fixes a
memory leak in one of these patches) that keep network compatibility with
other players intact.

Additionaly I'm currently in contact with an upstream contributor who is
investigating the remaining copyright/license issues.
To fix them, the plan is to amend d/copyright where possible
(investigations are currently ongoing), or to replace unknown/non-free files
with free alternatives.

I noticed that supertuxkart is marked for autoremoval on August 3rd
currently, which is probably after the bullseye release.
Does this mean supertuxkart 1.2+ds-2 will be part of bullseye and can
then still be fixed by a stable-proposed-update? Or does the upload
and migration to bullseye have to happen before July 31st?

Below is the full list of files that would get removed from the upstream
tarball:

data/karts/beastie/beastie-icon.png
data/karts/beastie/beastie.spm
data/karts/beastie/beastie_kart_colorizationMask.png
data/karts/beastie/beastie_kart_diffuse.png
data/karts/beastie/beastie_kart_gloss.png
data/karts/beastie/beastie_kart_leftDoor.png
data/karts/beastie/beastie_kart_leftDoor_colorizationMask.png
data/karts/beastie/beastie_kart_leftDoor_gloss.png
data/karts/beastie/beastie_n_kart_wheel_colorizationMask.png
data/karts/beastie/beastie_n_kart_wheel_diffuse.png
data/karts/beastie/beastie_n_kart_wheel_gloss.png
data/karts/beastie/beastie_shadow.png
data/karts/beastie/beastie_texture.png
data/karts/hexley/hexley.spm
data/karts/hexley/hexley_dashboard_diffuse.png
data/karts/hexley/hexley_dashboard_gloss.png
data/karts/hexley/hexley_diffuse.png
data/karts/hexley/hexley_gloss.png
data/karts/hexley/hexley_kart_Normal.png
data/karts/hexley/hexley_kart_colorizationMask.png
data/karts/hexley/hexley_kart_diffuse.png
data/karts/hexley/hexley_kart_frontGlass.png
data/karts/hexley/hexley_kart_gloss.png
data/karts/hexley/hexley_shadow.png
data/karts/hexley/hexley_wheel_Normal.png
data/karts/hexley/hexley_wheel_colorizationMask.png
data/karts/hexley/hexley_wheel_diffuse.png
data/karts/hexley/hexley_wheel_gloss.png
data/karts/hexley/hexley_window.png
data/karts/hexley/hexleyicon.png
data/karts/hexley/hexleyicon32.png

Attached are the mentioned upstream patches.

Kind regards,
  Reiner
From 851290d4c866130abb22ee61114016378af4cb45 Mon Sep 17 00:00:00 2001
From: Benau 
Date: Sun, 18 Jul 2021 00:49:49 +0800
Subject: [PATCH] Add code to generate official karts list

---
 data/official_karts.xml  |  21 ++
 sources.cmake|   2 +-
 src/karts/official_karts.cpp | 128 +++
 src/karts/official_karts.hpp |  20 ++
 src/main.cpp |   9 +++
 5 files changed, 179 insertions(+), 1 deletion(-)
 create mode 100644 data/official_karts.xml
 create mode 100644 src/karts/official_karts.cpp
 create mode 100644 src/karts/official_karts.hpp

diff --git a/data/official_karts.xml b/data/official_karts.xml
new file mode 100644
index 000..671aadf369e
--- /dev/null
+++ b/data/official_karts.xml
@@ -0,0 +1,21 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/sources.cmake b/sources.cmake
index d4f28ae4de4..ba4868d717e 100644
--- a/sources.cmake
+++ b/sources.cmake
@@ -1,5 +1,5 @@
 # Modify this file to change the last-modified date when you add/remove a file.
-# This will then trigger a new cmake run automatically.
+# This will then trigger a new cmake run automatically. 
 file(GLOB_RECURSE STK_HEADERS RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} "src/*.hpp")
 file(GLOB_RECURSE STK_SOURCES RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} "src/*.cpp")
 file(GLOB_RECURSE STK_SHADERS RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} "data/shaders/*")
diff --git a/src/karts/official_karts.cpp b/src/karts/official_karts.cpp
new file mode 100644
index 000..c8d7b9f38b7
--- /dev/null
+++ b/src/karts/official_karts.cpp
@@ -0,0 +1,128 @@
+#include "karts/official_karts.hpp"
+
+#include "karts/kart_properties_manager.hpp"
+#include "io/file_manager.hpp"
+#include "io/xml_node.hpp"
+#include "karts/kart_model.hpp"
+#include "karts/kart_properties.hpp"
+#include "utils/file_utils.hpp"
+#include "utils/log.hpp"
+#include "utils/vec3.hpp"
+
+#include 
+#include 
+#include 
+#include 
+
+namespace OfficialKarts
+{
+// 
+struct OfficialKart
+{

Bug#991334: monit: Race condition on reboot timestamp checks

2021-07-20 Thread Guillem Jover
Package: monit
Version: 1:5.27.2-1
Severity: serious
Forwarded: 
https://bitbucket.org/tildeslash/monit/pull-requests/110/use-an-epsilon-when-doing-the-reboot-boot

Hi!

On Linux the current method to retrieve the boot timestamp is racy,
which means that the reboot checks (the daemon start delay), and the
state machinery can be affected. The former is an annoyance as monit
will not respond to commands during the set amount of time. But the
latter means that services set to «onreboot nostart» and managed f.ex.
by a HA system will lose their state on «monit restart», which can be
rather bad.

I notice that Hurd patch modifies the Linux _getStartTime()
implementation making it need way more syscalls, which can exacerbate
this problem, and IMO should be either reverted for bullseye, or
modified so that the Hurd has its own sysdep file with that change.

I'm attaching the patch I've submitted upstream, which fixes the
problem for us.

To reproduce I added a Log_debug() entry to see the exact timestamps,
but this can be easily seen anyway by adding a start delay and
checking whether the delay gets skipped or taken into account after
each «service monit restart».

Thanks,
Guillem
From dc50d6cca9a69922f75f98fe73d95bb2f1067cfa Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 20 Jul 2021 20:40:54 +0200
Subject: [PATCH] Use an epsilon when doing the reboot boot timestamp
 comparisons

At least on Linux, the current method to retrieve the boot timestamp is
racy, as we first fetch the system uptime (seconds since the epoch),
then subtract that from the current time. But if between these two
syscalls a new or more seconds elapse, then the result can change
depending on the invocation compared to the stored state. This is
trivial to trigger at least on a VirtualBox machine.

To avoid this problem we refactor the reboot checks to use
State_reboot(), and change it to use a small epsilon value, either
positive or negative, to account for a possible mismatch in the
current timestamp or the state one.
---
 src/state.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/state.c b/src/state.c
index 05c3b64e..986202b7 100644
--- a/src/state.c
+++ b/src/state.c
@@ -243,7 +243,7 @@ static void _updateStart(Service_T S, int nstart, int ncycle) {
 
 
 static void _updateMonitor(Service_T S, Monitor_State monitor) {
-if (systeminfo.booted == booted || S->onreboot == Onreboot_Laststate) {
+if (!State_reboot() || S->onreboot == Onreboot_Laststate) {
 // Monit reload or restart within the same boot session OR persistent state => restore the monitoring state
 if (monitor == Monitor_Not)
 S->monitor = Monitor_Not;
@@ -664,6 +664,9 @@ void State_restore() {
 
 
 bool State_reboot() {
-return systeminfo.booted == booted ? false : true;
+/* We need to use a small epsilon when comparing the boot timestamps,
+ * as at least on Linux its gathering is racy and can diverge from the
+ * real boot timestamp. */
+return abs(systeminfo.booted - booted) < 2 ? false : true;
 }
 
-- 
2.32.0



Bug#991331: sendmail: CVE-2021-3618

2021-07-20 Thread Andreas Beckmann

Control: fixed -1 8.16.1-1
Control: tag -1 + help

On 20/07/2021 22.21, Moritz Mühlenhoff wrote:

https://alpaca-attack.com/ affects sendmail. It was fixed in
the latest 3.16.1 release:


https://bugzilla.redhat.com/show_bug.cgi?id=1975623#c13

Huzaifa S. Sidhpurwala 2021-06-29 05:11:36 UTC

Sendmail:

"Sendmail only detects HTTP requests at the very start of a connection. 
If STARTTLS is used, the first command inside the connection can bensent 
by the attacker, bypassing the detection"

Sendmail fixed a bug to detect HTTP requests when STARTTLS is used in 8.16

As per the release notes:

SECURITY: If sendmail tried to reuse an SMTP session which had
already been closed by the server, then the connection
cache could have invalid information about the session.
One possible consequence was that STARTTLS was not
used even if offered.  This problem has been fixed
by clearing out all relevant status information
when a closed session is encountered.

(there are no specific references since sendmail 8.16.1 was released in 
July 2020, long before alpaca-attack got disclosed to interested parties:

2020-10-20: Initial contact with [...] author of TLS standard [...]
...
2021-02-20: Initial contact with all affected application servers (FTP, 
Email).

...
2021-06-09: Public disclosure.)

+help: I'm hoping that someone backports this fix to 8.15.x, possibly
https://bugzilla.redhat.com/show_bug.cgi?id=1975650


Andreas



Bug#990897: unblock: linux/5.10.46-1

2021-07-20 Thread Paul Gevers
Hi Salvatore,

On 20-07-2021 20:05, Salvatore Bonaccorso wrote:
> We do not have yet the signed packages that said, but once present
> ideally the package get's aged as well to have fixes asap in bullseye.

As asked on IRC: IIUC it's best to wait until all binaries are in and
migrate the set right? So including the linux-signed-(amd64|arm64|i386)
binaries.

I've added the unblocks and urgents for linux-signed-* and all *but* the
urgent for linux. If the answer is: let's migrate as they get in,
please, any RT member, urgent linux. If the set arrives before I'm back
on line, please, urgent linux.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#991333: Backport Raspberry PI POE hat fan support from mainline

2021-07-20 Thread Mathieu Chouquet-Stringer
Package: linux-image-arm64
Version: 5.10.40-1~bpo10+1

Hello,

A raspberry pi can be powered with a poe hat
(https://www.raspberrypi.org/products/poe-hat/). Until recently the
fan driver for the hat wasn't in mainline but that changes when support
got merged into 5.13:
https://lore.kernel.org/linux-clk/20210312122454.24480-1-nsaenzjulie...@suse.de/

Here's the relevant commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=37f00ab4a003f371f81e0eae76cf372f06dec780

Without this driver, the fan doesn't spin at all and the raspberry runs
from hot to very hot (to the point I can make it overheat by loading it
too much).

Do you think it'd be doable to backport it to 5.10?

Regards,

-- 
Mathieu Chouquet-Stringer
The sun itself sees not till heaven clears.
 -- William Shakespeare --



Bug#991320: flameshot crashing on startup

2021-07-20 Thread Dennis Filder
X-Debbugs-CC: allan grossman 

On Tue, Jul 20, 2021 at 02:54:26PM -0500, allan wrote:
> Setting checkForUpdates=false resolved the issue.  Thanks, Dennis  :)

Okay, that is good to know.  I personally feel like that option should
be set to false by default in Debian (don't the pop-ups annoy the hell
out of people?).

Of course the segfault as a problem remains, but that is upstream's
issue.

Also I suspect I know why I couldn't reproduce this: I sit behind a
proxy, so maybe Qt's networking code behaves differently then.  There
is a lot going on in the strace log, but the crash happened after the
hostname for api.github.com was resolved.

Regards.



Bug#990956: uploading lintian-brush to testing-proposed-updates

2021-07-20 Thread Paul Gevers
Control: tags -1 confirmed moreinfo

On 20-07-2021 00:29, Jelmer Vernooij wrote:
>> Still not promising anything, but what would be the proposed change in
>> t-p-u?
> Please find attached the proposed change. Please note that it only
> affects the testsuite.

That last note was what I was hoping for. Under the assumption that the
upload happens soon (we're hopefully close to releasing), please go
ahead. Please remove the moreinfo tag once the upload happened.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#991332: Liquidsoap is searching at the wrong place for pervasives script libraries

2021-07-20 Thread Christoph Zimmermann
Package: liquidsoap
Version: 1.4.3

Liquidsoap is searching at the wrong place for pervasives script
libraries

The Debian package puts them into:
  /usr/share/liquidsoap/libs

Liquidsoap is expecting them at:
  /usr/share/liquidsoap/1.4.1/libs


Here is a short script to replicate it:
  #!/usr/bin/liquidsoap
  # load a playlist file
  stream = playlist("/home/music")
  # output the playlist to icecast
  source = output.icecast(%mp3, host="localhost", port=8000,
   mount="listen.m3u", password="mypassword")
  mksafe(source(stream))

Then ran the check against the liq file:
  liquidsoap --check ./radio.liq

and you should get the following output:

  At line 9, char 7: the variable mksafe used here has not been
  previously defined.



Bug#991331: sendmail: CVE-2021-3618

2021-07-20 Thread Moritz Mühlenhoff
Source: sendmail
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for sendmail.

https://alpaca-attack.com/ affects sendmail. It was fixed in
the latest 3.16.1 release:
https://marc.info/?l=sendmail-announce=159394546814125=2

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-3618
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3618

Please adjust the affected versions in the BTS as needed.



Bug#991329: vsftpd: CVE-2021-3618

2021-07-20 Thread Moritz Mühlenhoff
Source: vsftpd
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for vsftpd.

https://alpaca-attack.com/ affects vsftpd. It was fixed in the 3.0.4
release, these should be the relevant parts of 
https://security.appspot.com/vsftpd/Changelog.txt:

* Close the control connection after 10 unknown commands pre-login.
* Reject any TLS ALPN advertisement that's not 'ftp'.
* Add ssl_sni_hostname option to require a match on incoming SNI hostname.

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-3618
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3618

Please adjust the affected versions in the BTS as needed.



Bug#991330: octave-zeromq: missing build dependency on pkg-config

2021-07-20 Thread Adrian Bunk
Source: octave-zeromq
Version: 1.5.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=octave-zeromq=experimental

...
checking for pkg-config... no
checking for libzmq... no
configure: error: octave zeromq package requires zeromq library

error: pkg: error running the configure script for zeromq.
error: called from
configure_make at line 93 column 9
install at line 198 column 7
pkg at line 568 column 9
/usr/share/dh-octave/install-pkg.m at line 43 column 1
dh_auto_install: error: octave --no-gui --no-history --silent --no-init-file 
--no-window-system /usr/share/dh-octave/install-pkg.m returned exit code 1
make: *** [debian/rules:5: binary-arch] Error 25



Bug#991328: nginx: CVE-2021-3618

2021-07-20 Thread Moritz Mühlenhoff
Source: nginx
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,
https://alpaca-attack.com/ affects Nginx, the patch is at
http://hg.nginx.org/nginx/rev/ec1071830799

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-3618
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3618

Please adjust the affected versions in the BTS as needed.



Bug#991327: racket: CVE-2021-32773

2021-07-20 Thread Moritz Mühlenhoff
Source: racket
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for racket.

CVE-2021-32773[0]:
| Racket is a general-purpose programming language and an ecosystem for
| language-oriented programming. In versions prior to 8.2, code
| evaluated using the Racket sandbox could cause system modules to
| incorrectly use attacker-created modules instead of their intended
| dependencies. This could allow system functions to be controlled by
| the attacker, giving access to facilities intended to be restricted.
| This problem is fixed in Racket version 8.2. A workaround is
| available, depending on system settings. For systems that provide
| arbitrary Racket evaluation, external sandboxing such as containers
| limit the impact of the problem. For multi-user evaluation systems,
| such as the `handin-server` system, it is not possible to work around
| this problem and upgrading is required.

https://github.com/racket/racket/security/advisories/GHSA-cgrw-p7p7-937c

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-32773
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32773

Please adjust the affected versions in the BTS as needed.



Bug#945229: pinfo exits if lynx is not found

2021-07-20 Thread Oliver Schode
Package: pinfo
Version: 0.6.13-1.1
Followup-For: Bug #945229

Yes, but with a clean exit you're even lucky, hit on a broken manpage
link (it line breaks on all with a hyphen in it) and it's crashing
without even resetting your terminal, which is a bit rude but a
different issue. There is a setting for it in pinforc: HTTPVIEWER. Lynx
is just the tentative default. Looks like a reasonable choice when pinfo
was cooked up, it's been in Debian for 20 years. These days maybe
something like w3m might fare slightly better, but a lot of people don't
even have a text browser anymore. I use links. About the best one could
do I suppose is replacing it with 'sensible-browser' or 'www-browser',
it's what we have it for.

This is still a solid info browser though.


Oliver



Bug#991320: flameshot crashing on startup

2021-07-20 Thread allan
Setting checkForUpdates=false resolved the issue.  Thanks, Dennis  :)



Bug#991320: flameshot crashing on startup

2021-07-20 Thread Dennis Filder
X-Debbugs-CC: allan grossman 

On Tue, Jul 20, 2021 at 02:16:16PM -0500, allan wrote:
> apt log shows qt libraries updated three days ago - these wouldn't
> have made it to Bullseye yet.
>
> Start-Date: 2021-07-17  08:52:52
> Requested-By: wizard (1000)
> Install: libqt5quickwidgets5:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtquick-window2:amd64 (5.15.2+dfsg-6, automatic), sox:amd64
> (14.4.2+git20190427-2, automatic), qml-module-qt-labs-settings:amd64
> (5.15.2+dfsg-6, automatic), qml-module-qtmultimedia:amd64 (5.15.2-3,
> automatic), libqt5multimediaquick5:amd64 (5.15.2-3, automatic),
> libsox3:amd64 (14.4.2+git20190427-2, automatic), mystiq:amd64
> (20.03.23-2), qml-module-qt-labs-folderlistmodel:amd64 (5.15.2+dfsg-6,
> automatic), libsox-fmt-alsa:amd64 (14.4.2+git20190427-2, automatic),
> libqt5multimediawidgets5:amd64 (5.15.2-3, automatic),
> qml-module-qtquick-privatewidgets:amd64 (5.15.2-2, automatic),
> libsox-fmt-base:amd64 (14.4.2+git20190427-2, automatic),
> qml-module-qtquick2:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtquick-dialogs:amd64 (5.15.2-2, automatic),
> libqt5qmlworkerscript5:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtqml:amd64 (5.15.2+dfsg-6, automatic)
> End-Date: 2021-07-17  08:52:58

All those libraries are on my system already.  I think this late in
the freeze some libraries get fast-tracked into testing on request.

> Backtrace:
> /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction7setTextERK7QString+0x5)[0x7fd8dbd48005]
> flameshot(+0x5e267)[0x55efcb2b6267]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(_ZN21QNetworkAccessManager8finishedEP13QNetworkReply+0x42)[0x7fd8dc2b6ad2]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(+0x44e17)[0x7fd8dc2b7e17]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(+0xa08b8)[0x7fd8dc3138b8]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x291)[0x7fd8db249ff1]
> ...

The only reason for flameshot to touch the network (which it
presumably does here) is to check for updates.  Try setting
"checkForUpdates" to "false" in ~/.config/flameshot/flameshot.ini --
maybe this will preclude the codepath in question from being taken.
Let us know if this fixes it for you -- if not, then I don't really
see what more could be done here.  Maybe running

strace -s2048 -f -e 'trace=%net' -o /tmp/flameshot.strace flameshot

will reveal what network facility it tries to contact before it crashes.

Regards,
Dennis.



Bug#991324: micro-httpd: systemd install dependency fails if binding to IP other than 0.0.0.0

2021-07-20 Thread Sudip Mukherjee
Hi Martin-Éric,

On Tue, Jul 20, 2021 at 6:51 PM Martin-Éric Racine
 wrote:
>
> Package: micro-httpd
> Version: 20051212-15.1
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> The dependencies in the systemd files that currently ship with micro-httpd 
> only work if micro-httpd is bound to 0.0.0.0 as shipped. If it's bound to 
> another IP address, systemd will report a failure to launch micro-httpd, 
> because all network interfaces are not up yet, so the IP we're trying to bind 
> to hasn't been assigned to any interface yet.

Thanks for using micro-httpd and testing. Will attend to this one and
also the earlier one that you have raised after the freeze is over.


-- 
Regards
Sudip



Bug#991122: unblock: varnish/6.5.2-1

2021-07-20 Thread Stig Sandbeck Mathisen
On Mon, Jul 19, 2021 at 10:06:37PM +0200, Graham Inggs wrote:
> On Mon, 19 Jul 2021 at 13:00, Stig Sandbeck Mathisen  wrote:
> > Attached is the diff. Changes are the upstream bugfix, as well as two
> > commits in the packaging repository:
> 
> Thanks.  Please go ahead and upload to unstable, then remove the moreinfo tag
> once it has built.

Hello Graham,

Thanks, will do.

-- 
Stig Sandbeck Mathisen



Bug#981783: dh: Call dh_fixperms before dh_strip_nondeterminism

2021-07-20 Thread Niels Thykier
On Wed, 3 Feb 2021 21:17:28 +0100 Christoph Berg  wrote:
> Re: Niels Thykier
> > This is controlled by the dh-strip-nondeterminism package.  Reassigning
> > accordingly.
> 
> > >dh_strip_nondeterminism
> > > dh_strip_nondeterminism: warning: Ignoring unwritable file: 
> > > pljava-1.6.2.jar
> > >dh_compress
> > >dh_fixperms
> 
> Hmm, I guess the problem is that dh_s_nd wants to run before
> dh_compress, but I want it to run after dh_fixperms.
> 
> Can we switch the ordering of dh_compress and dh_fixperms?
> 
> Christoph
> 
> 

Interestingly, I got #982457 filed against debhelper asking for
dh_fixperms being called "as late as possible".  I guess that "kind of"
conflicts with your wish (depending on the exact definition of "as late
as possible").

Sadly, I do not have a clear view what the "perfect" order would be for
these helpers at the moment.  Anyway, I have added your remark to
#982457 with this email, so I remember to consider dh_compress in the
relative order of dh_fixperms.

Thanks,
~Niels



Bug#991326: ITP: enrich --decodes ANSI escapes before processing

2021-07-20 Thread Sakirnth Nagarasa
Package: wnpp
Severity: wishlist
Owner: Sakirnth Nagarasa 

* Package name: enrich
Upstream Author   : Sorin Sbarnea
* URL : https://github.com/pycontribs/enrich
* License : MIT
Description   : decodes ANSI escapes before processing

 Extends Rich Console to detect if original text already had ANSI
escapes and decodes it before processing it. This solves the case where
printing output captured from other processes that contained ANSI
escapes would brake.

Greetings
Sakirnth



Bug#991320: flameshot crashing on startup

2021-07-20 Thread allan
apt log shows qt libraries updated three days ago - these wouldn't
have made it to Bullseye yet.

Start-Date: 2021-07-17  08:52:52
Requested-By: wizard (1000)
Install: libqt5quickwidgets5:amd64 (5.15.2+dfsg-6, automatic),
qml-module-qtquick-window2:amd64 (5.15.2+dfsg-6, automatic), sox:amd64
(14.4.2+git20190427-2, automatic), qml-module-qt-labs-settings:amd64
(5.15.2+dfsg-6, automatic), qml-module-qtmultimedia:amd64 (5.15.2-3,
automatic), libqt5multimediaquick5:amd64 (5.15.2-3, automatic),
libsox3:amd64 (14.4.2+git20190427-2, automatic), mystiq:amd64
(20.03.23-2), qml-module-qt-labs-folderlistmodel:amd64 (5.15.2+dfsg-6,
automatic), libsox-fmt-alsa:amd64 (14.4.2+git20190427-2, automatic),
libqt5multimediawidgets5:amd64 (5.15.2-3, automatic),
qml-module-qtquick-privatewidgets:amd64 (5.15.2-2, automatic),
libsox-fmt-base:amd64 (14.4.2+git20190427-2, automatic),
qml-module-qtquick2:amd64 (5.15.2+dfsg-6, automatic),
qml-module-qtquick-dialogs:amd64 (5.15.2-2, automatic),
libqt5qmlworkerscript5:amd64 (5.15.2+dfsg-6, automatic),
qml-module-qtqml:amd64 (5.15.2+dfsg-6, automatic)
End-Date: 2021-07-17  08:52:58

GDK_BACKEND=x11 flameshot still segfaulted.  I'm running X11.

catchsegv was too big for a bug report so I attached it to email.
*** Segmentation fault
Register dump:

 RAX:    RBX: 55efcb346160   RCX: 55efccfe6010
 RDX: 0004   RSI: 7ffed987dbb0   RDI: 
 RBP: 7ffed987dbc0   R8 : 55efcd1e84e0   R9 : 0020
 R10: 0006   R11: 0006   R12: 7ffed987dbb0
 R13: 7ffed987db90   R14: 55efcd0b67f8   R15: 7ffed987db98
 RSP: 7ffed987db00

 RIP: 7fd8dbd48005   EFLAGS: 00010206

 CS: 0033   FS:    GS: 

 Trap: 000e   Error: 0004   OldMask:    CR2: 0008

 FPUCW: 037f   FPUSW:    TAG: 7fd8
 RIP: dae37fd8   RDP: dbbe8140

 ST(0)     ST(1)  
 ST(2)     ST(3)  
 ST(4)     ST(5)  b000
 ST(6)  d000   ST(7) d000 d000
 mxcsr: 1fa0
 XMM0:  61697320 XMM1:  61697320
 XMM2:  61697320 XMM3:  61697320
 XMM4:  61697320 XMM5:  61697320
 XMM6:  61697320 XMM7:  61697320
 XMM8:  61697320 XMM9:  61697320
 XMM10: 61697320 XMM11: 61697320
 XMM12: 61697320 XMM13: 61697320
 XMM14: 61697320 XMM15: 61697320

Backtrace:
/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction7setTextERK7QString+0x5)[0x7fd8dbd48005]
flameshot(+0x5e267)[0x55efcb2b6267]
/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
/lib/x86_64-linux-gnu/libQt5Network.so.5(_ZN21QNetworkAccessManager8finishedEP13QNetworkReply+0x42)[0x7fd8dc2b6ad2]
/lib/x86_64-linux-gnu/libQt5Network.so.5(+0x44e17)[0x7fd8dc2b7e17]
/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
/lib/x86_64-linux-gnu/libQt5Network.so.5(+0xa08b8)[0x7fd8dc3138b8]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x291)[0x7fd8db249ff1]
/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x7f)[0x7fd8dbd4c15f]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0x12a)[0x7fd8db21dfca]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x171)[0x7fd8db220a01]
/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x305e93)[0x7fd8db275e93]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x25b)[0x7fd8da050e6b]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x52118)[0x7fd8da051118]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2f)[0x7fd8da0511cf]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5f)[0x7fd8db27551f]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x12b)[0x7fd8db21c98b]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x90)[0x7fd8db224c00]
flameshot(+0x3f9f6)[0x55efcb2979f6]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7fd8daa6dd0a]
flameshot(+0x41c8a)[0x55efcb299c8a]

Memory map:

55efcb258000-55efcb289000 r--p  08:11 12324114 /usr/bin/flameshot
55efcb289000-55efcb2f3000 r-xp 00031000 08:11 12324114 /usr/bin/flameshot
55efcb2f3000-55efcb33b000 r--p 0009b000 08:11 12324114 /usr/bin/flameshot
55efcb33b000-55efcb346000 r--p 000e2000 08:11 12324114 /usr/bin/flameshot
55efcb346000-55efcb347000 rw-p 000ed000 08:11 12324114 /usr/bin/flameshot
55efccfe6000-55efcd2c4000 rw-p  00:00 

Bug#991176: openstack-toaster: piuparts buster -> bullseye upgrade test fails restarting rabbitmq-server

2021-07-20 Thread Thomas Goirand
On 7/16/21 4:09 PM, Andreas Beckmann wrote:
> Package: openstack-toaster
> Version: 0.31
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + openstack-toaster rabbitmq-server
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'buster'.
> It installed fine in 'buster', then the upgrade to 'bullseye' fails.

Hi Andreas,

Thanks for this bug report.

According to the log, this looks like dealing with rabbitmq + Erlang
stuff: RabbitMQ is waiting on the Erlang "epmd" daemon, which isn't
responding. So probably the issue is in epmd rather than in Rabbit
itself? Hard to tell without a big of investigations (which I
unfortunately don't have time to do right now, but I will try to find
the time soonish...).

IMO, this is too late to be fixed in time for Bullseye.

Also, I'm not sure this is a very interesting bug report to work on.
These packages were mostly useful when I was using them with a
package-only based CI, which I'm not really using these days. I probably
will remove these packages from Bookworm.

Cheers,

Thomas Goirand (zigo)



Bug#990990: unblock: libcgroup/2.0

2021-07-20 Thread Thomas Goirand
On 7/19/21 3:07 PM, Santiago Ruano Rincón wrote:
> On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers  wrote:
>> Hi,
>>
>> On 12-07-2021 18:45, Michael Biebl wrote:
>>> This was already discussed in
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022
>>>
>>> My takeaway from that discussion was, that rdeps of cgroup-tools, would
>>> itself have to be made cgroupv2 aware, especially OpenStack and its
>>> components.
>>
>> That resembles my understanding of that discussion too.
> 
> Mine too.
> 
> zigo, are there any news from openstack about this?

There is no way that Cinder and Nova produce a patch for OpenStack
Victoria (the release in Bullseye), which was released 9 months ago.
They are *planning* to use Cgroups v2 right now, but I'm not even sure
it's going to be ready for next version in October.

>>> Have those rdeps been tested successfully with libcgroup/cgroup-tools
>>> from experimental?
>>
>> I'm not in favor of doing this transition now.
>>
> 
> Please, keep in mind this comment, made before the release of 2.0:
> "we are planning something for next week. The version number will
> probably be 2.0 - with expectation that the v2 cycle will have
> continously breaking ABI. When we are happy where it is, we will push
> out v3 which will then maintain ABI through its lifetime."
> https://github.com/libcgroup/libcgroup/issues/12#issuecomment-825816328

This means that probably, it's best that Bullseye continues to support
Cgroups v1 (which isn't the case currently if we don't allow libcgroup
2.0 in).

On 7/19/21 11:48 PM, Adrian Bunk wrote:
> Based on soname and package name, the libcgroup1 in experimental
> claims to be ABI compatible with the library in buster.
> Changes in bookworm would be a normal library transition.
>
> OpenStack uses cgroup-tools, which is the only reason why libcgroup
> stayed in bullseye at all.
> My suggestion was basically asking whether 2.0 would be better for
> using with the version of OpenStack in bullseye, this is similar to
> your question to Thomas above.
>
> If cgroup-tools in *bookworm* would be incompatible with OpenStack in
> bullseye, this could be resolved with Breaks on the bullseye versions
> of cinder-common/nova-compute - this is irrelevant for discussing
> which version of libcgroup to ship in bullseye.

Maybe I'm not understanding fully, though what I think I've read in this
discussion, is that libcgroup in experimental makes it possible to use
cgcreate / cgset without any additional kernel command line parameters
(please let me know if I'm mistaking). On the OpenStack side, that's the
only thing which is needed. Cinder isn't using any library directly,
they just use the cgroup userland binaries. As for Nova, I'm not even
sure it's doing anything but using features from Qemu/Libvirt (this
would have to be checked). At least, doing a "grep -r cgcreate" in the
Nova source code returns nothing.

Cheers,

Thomas Goirand (zigo)



Bug#991320: flameshot crashing on startup

2021-07-20 Thread Dennis Filder
X-Debbugs-CC: allan grossman 

On Tue, Jul 20, 2021 at 01:16:39PM -0500, allan wrote:
> This has only been broken for a couple of days - there's a strong
> possibility that whatever broke it hasn't made it to Bullseye yet.
> This appears to be an upstream bug because a Manjaro user running same
> version of flameshot and Qt is experiencing same behavior and as
> mentioned, it broke a couple of days ago.

When exactly did it break and what packages did you install that could
have made it break?  /var/log/apt/history.log should have the answer.

Again: Does running flameshot with GDK_BACKEND=x11 fix it for you --
yes or no?  Do you run wayland or xorg?

Also, you say it crashes.  How does it crash?  Segfault?  What is the
exact message?  What is the output if you run it like this?:

catchsegv flameshot

You have to give us something to work with.



Bug#991325: unblock: systemd/247.3-6

2021-07-20 Thread Salvatore Bonaccorso
Hi,

On Tue, Jul 20, 2021 at 08:03:17PM +0200, Salvatore Bonaccorso wrote:
>   [x] attach debdiff against the package in testing

... or rather not ... attached.

Regards,
Salvatore
diff -Nru systemd-247.3/debian/changelog systemd-247.3/debian/changelog
--- systemd-247.3/debian/changelog  2021-04-12 20:21:24.0 +0200
+++ systemd-247.3/debian/changelog  2021-07-13 19:29:24.0 +0200
@@ -1,3 +1,13 @@
+systemd (247.3-6) unstable; urgency=high
+
+  * Non-maintainer upload (acked by maintainers)
+  * unit-name: generate a clear error code when converting an overly long fs
+path to a unit name
+  * basic/unit-name: do not use strdupa() on a path (CVE-2021-33910)
+  * basic/unit-name: adjust comments
+
+ -- Salvatore Bonaccorso   Tue, 13 Jul 2021 19:29:24 +0200
+
 systemd (247.3-5) unstable; urgency=medium
 
   * udev-udeb: setup /dev/fd, /dev/std{in,out,err} symlinks.
diff -Nru systemd-247.3/debian/patches/basic-unit-name-adjust-comments.patch 
systemd-247.3/debian/patches/basic-unit-name-adjust-comments.patch
--- systemd-247.3/debian/patches/basic-unit-name-adjust-comments.patch  
1970-01-01 01:00:00.0 +0100
+++ systemd-247.3/debian/patches/basic-unit-name-adjust-comments.patch  
2021-07-13 19:29:07.0 +0200
@@ -0,0 +1,38 @@
+From cbcea9f517bfe79b019fcec5c364952ea33d24f2 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= 
+Date: Wed, 23 Jun 2021 11:52:56 +0200
+Subject: basic/unit-name: adjust comments
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+We already checked for "too long" right above…
+---
+ src/basic/unit-name.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/basic/unit-name.c b/src/basic/unit-name.c
+index a22763443fdd..1deead74588b 100644
+--- a/src/basic/unit-name.c
 b/src/basic/unit-name.c
+@@ -528,7 +528,7 @@ int unit_name_from_path(const char *path, const char 
*suffix, char **ret) {
+ if (strlen(s) >= UNIT_NAME_MAX) /* Return a slightly more descriptive 
error for this specific condition */
+ return -ENAMETOOLONG;
+ 
+-/* Refuse this if this got too long or for some other reason didn't 
result in a valid name */
++/* Refuse if this for some other reason didn't result in a valid name 
*/
+ if (!unit_name_is_valid(s, UNIT_NAME_PLAIN))
+ return -EINVAL;
+ 
+@@ -562,7 +562,7 @@ int unit_name_from_path_instance(const char *prefix, const 
char *path, const cha
+ if (strlen(s) >= UNIT_NAME_MAX) /* Return a slightly more descriptive 
error for this specific condition */
+ return -ENAMETOOLONG;
+ 
+-/* Refuse this if this got too long or for some other reason didn't 
result in a valid name */
++/* Refuse if this for some other reason didn't result in a valid name 
*/
+ if (!unit_name_is_valid(s, UNIT_NAME_INSTANCE))
+ return -EINVAL;
+ 
+-- 
+2.32.0
+
diff -Nru 
systemd-247.3/debian/patches/basic-unit-name-do-not-use-strdupa-on-a-path.patch 
systemd-247.3/debian/patches/basic-unit-name-do-not-use-strdupa-on-a-path.patch
--- 
systemd-247.3/debian/patches/basic-unit-name-do-not-use-strdupa-on-a-path.patch 
1970-01-01 01:00:00.0 +0100
+++ 
systemd-247.3/debian/patches/basic-unit-name-do-not-use-strdupa-on-a-path.patch 
2021-07-13 19:29:07.0 +0200
@@ -0,0 +1,64 @@
+From bae2f0d1109a8c75a7fb89ae6b8d1b6ef8dfab16 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= 
+Date: Wed, 23 Jun 2021 11:46:41 +0200
+Subject: basic/unit-name: do not use strdupa() on a path
+
+The path may have unbounded length, for example through a fuse mount.
+
+CVE-2021-33910: attacked controlled alloca() leads to crash in systemd and
+ultimately a kernel panic. Systemd parses the content of /proc/self/mountinfo
+and each mountpoint is passed to mount_setup_unit(), which calls
+unit_name_path_escape() underneath. A local attacker who is able to mount a
+filesystem with a very long path can crash systemd and the whole system.
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1970887
+
+The resulting string length is bounded by UNIT_NAME_MAX, which is 256. But we
+can't easily check the length after simplification before doing the
+simplification, which in turns uses a copy of the string we can write to.
+So we can't reject paths that are too long before doing the duplication.
+Hence the most obvious solution is to switch back to strdup(), as before
+7410616cd9dbbec97cf98d75324da5cda2b2f7a2.
+---
+ src/basic/unit-name.c | 13 +
+ 1 file changed, 5 insertions(+), 8 deletions(-)
+
+diff --git a/src/basic/unit-name.c b/src/basic/unit-name.c
+index 284a77348316..a22763443fdd 100644
+--- a/src/basic/unit-name.c
 b/src/basic/unit-name.c
+@@ -378,12 +378,13 @@ int unit_name_unescape(const char *f, char **ret) {
+ }
+ 
+ int unit_name_path_escape(const char *f, char **ret) {
+-char *p, *s;
++

Bug#991320: flameshot crashing on startup

2021-07-20 Thread Boyuan Yang
在 2021-07-20星期二的 13:16 -0500,allan写道:
> This has only been broken for a couple of days - there's a strong
> possibility that whatever broke it hasn't made it to Bullseye yet.
> This appears to be an upstream bug because a Manjaro user running same
> version of flameshot and Qt is experiencing same behavior and as
> mentioned, it broke a couple of days ago.

This is exactly the merit of release freeze -- anyway, you may check what has
been updated in unstable in the past few days. Please let me know if you have
any findings.

As the packager, I would be targeting on flameshot 0.10.0 when the freeze is
over and it would be meaningful if we could analyze whether it's still broken
with new release then.

Thanks,
Boyuan Yang

> On Tue, Jul 20, 2021 at 11:54 AM Dennis Filder  wrote:
> > 
> > X-Debbugs-CC: allan grossman 
> > 
> > I can't reproduce this under current Bullseye KDE/xorg -- flameshot
> > behaves absolutley normally.  It could be a Wayland issue, and
> > flameshot's Wayland support is apparently still experimental.
> > 
> > Let us know if running flameshot like so fixes this for you:
> > 
> >     GDK_BACKEND=x11 flameshot
> > 
> > Regards,
> > Dennis Filder


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


Bug#991320: flameshot crashing on startup

2021-07-20 Thread allan
More information.

Qt5 updates on these machines was installed three days ago; since I
update daily I'm fairly certain these updates haven't made it to
Bullseye yet.



Bug#991320: flameshot crashing on startup

2021-07-20 Thread allan
This has only been broken for a couple of days - there's a strong
possibility that whatever broke it hasn't made it to Bullseye yet.
This appears to be an upstream bug because a Manjaro user running same
version of flameshot and Qt is experiencing same behavior and as
mentioned, it broke a couple of days ago.

On Tue, Jul 20, 2021 at 11:54 AM Dennis Filder  wrote:
>
> X-Debbugs-CC: allan grossman 
>
> I can't reproduce this under current Bullseye KDE/xorg -- flameshot
> behaves absolutley normally.  It could be a Wayland issue, and
> flameshot's Wayland support is apparently still experimental.
>
> Let us know if running flameshot like so fixes this for you:
>
> GDK_BACKEND=x11 flameshot
>
> Regards,
> Dennis Filder



-- 
we see things not as they are, but as we are.
 -- anais nin



Bug#990897: unblock: linux/5.10.46-1

2021-07-20 Thread Salvatore Bonaccorso
Control: retitle -1 unblock: linux/5.10.46-2

On Sun, Jul 11, 2021 at 10:35:15PM +0200, Paul Gevers wrote:
> Control: tags -1 d-i
> 
> Hi,
> 
> On 10-07-2021 22:15, Salvatore Bonaccorso wrote:
> > Hi release team, hi Cyril (specifically for d-i)
> 
> So, let's add him (via d-boot) in.
> 
> > Please unblock package linux
> > 
> > It contained a rebase of the 5.10.y series to 5.10.46 upstream and
> > included the following changes relevant to add additional HW support
> > and bugfxes. The upstream import to 5.10.46 contained fixes for
> > various CVEs.
> 
> Ack.

This now needs to be 5.10.46-2 which includes most notably the fix for
CVE-2021-33909, which could lead to a local privilege escalation, see
DSA 4941-1.

We do not have yet the signed packages that said, but once present
ideally the package get's aged as well to have fixes asap in bullseye.

Regards,
Salvatore



Bug#991319: unblock: qutebrowser/2.0.2-2

2021-07-20 Thread Florian Bruhin
Hi,

I'm the upstream for qutebrowser. Thanks Axel for taking care of this!

On Thu, Jul 15, 2021 at 03:24:12AM +0200, Axel Beckert wrote:
> The upload adds a patch which updates the pointers to qutebrowser's
> IRC channel which — like many other projects — recently had to change
> from Freenode to Libera.Chat due to a hostile takeover of the prject's
> IRC channel on Freenode.

Indeed - for more context:
https://blog.qutebrowser.org/qutebrowser-moving-to-libera-chat.html

> According to upstream, from time to time people still join the
> project's old channel on Freenode. It is suspected that outdated links
> in packaged versions of qutebrowser are one source for this.

At least that's what people told me when I asked them how they found the
old channel. I do not know how many of them are using Debian stable,
compared to Ubuntu or other distributions not shipping the latest
upstream release.

Still, at some point I'd like to leave the old channel without having to
redirect people to the proper place (I can't set the topic, because I
lost my admin access to the old channel as part of Freenode's actions).

> Author: Axel Beckert 
> Description: Update IRC links to Libera Chat
>  Based on a patch by Florian Bruhin 
> Forwarded: not-needed

For context, I suggested a patch which only patches the asciidoc files,
while the release tarballs ship HTML files.

I've taken a quick look at the diff, looks good to me.

Florian

-- 
m...@the-compiler.org | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature


Bug#991325: unblock: systemd/247.3-6

2021-07-20 Thread Salvatore Bonaccorso
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: car...@debian.org,k...@debian.org,bi...@debian.org
Control: tags -1 d-i

Hi,

Please unblock package systemd

[ Reason ]
The upload fixes CVE-2021-33910, which for buster was fixed via
DSA-4942-1, 
https://lists.debian.org/debian-security-announce/2021/msg00125.html 
which can result in denial of service, crashing systemd and so the
entire system.

[ Impact ]
CVE-2021-33910 needs to be fixed in all suites.

[ Tests ]
The testsuite on one hand, and specifically the fixes needed for
CVE-2021-33910.

[ Risks ]
The changes has been tested by various vendors in preparation of the
security advisories. No regression spotted in the automated testsuite
nor while manually testing.

[ 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 ]
Needs a d-i ack as well, kibi is aded in X-Debbugs-CC.

unblock systemd/247.3-6

Regards,
Salvatore



Bug#991324: micro-httpd: systemd install dependency fails if binding to IP other than 0.0.0.0

2021-07-20 Thread Martin-Éric Racine
Package: micro-httpd
Version: 20051212-15.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The dependencies in the systemd files that currently ship with micro-httpd only 
work if micro-httpd is bound to 0.0.0.0 as shipped. If it's bound to another IP 
address, systemd will report a failure to launch micro-httpd, because all 
network interfaces are not up yet, so the IP we're trying to bind to hasn't 
been assigned to any interface yet.

What I currently have:

/etc/systemd/system/micro-httpd@.service
  
***
[Unit]
Description=micro-httpd
Documentation=man:micro-httpd(8)

[Service]
User=nobody
Group=www-data
ExecStart=-/usr/sbin/micro-httpd /home/perkelix/public_html
StandardInput=socket
***

/etc/systemd/system/micro-httpd.socket  
 
***
[Unit]
Description=micro-httpd
Documentation=man:micro-httpd(8)

[Socket]
ListenStream=172.16.1.2:8080
Accept=true

[Install]
WantedBy=sockets.target
***

The interface with 172.16.1.2 is only present later during boot after ifupdown 
stanzas in /etc/network/interfaces have been executed. The [Install] therefore 
probably needs a WantedBy other than sockets e.g. network-online or similar.
 
- -- System Information:
Debian Release: 10.10
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages micro-httpd depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  netcat-traditional   1.10-41.1
ii  systemd-sysv 241-7~deb10u8

micro-httpd recommends no packages.

Versions of packages micro-httpd suggests:
pn  micro-proxy  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmD3CqwACgkQrh+Cd8S0
17YJIRAAkHhkZV4DRsw4sFAxmWtx3D2CpZpuVAuRym2Fkl57WUyTV+g8ajoHPxWc
8RyMlLeShyhe2mCyAPF6xOfa1cIWdqaYBBQrvuZTVCsjd9f9U8WBAvWhW9se2FhZ
cPxLZOph+US908R3DtFn3PXK+jf+CnZhyi7FRwm9MyGOhPPAp6ELitJ+Ik1rOvRc
Z940Sr9Y4627yxK0oQ4Z8uAoMaHwoUM5jbbS0l5FwOsLH8Xi43LwlDmwi+YrWaFd
rhPWBdpc6nz9ZwYre6rFVZ855Po0gjalLIMP3AyztsIJaEWgkVZj7SGJzt1NoZyX
0ZEdlxCb445/gk3WGVgAHfYaiDMWXvWT0GRs0MWRf5MIzrK5FDvmrCBS1G4F8SeU
DYe26xCq/VSjMyt4pToIzF+a+JEaKQT3NzxN5GJ7XyCpqG5a24objqAHcPFkh8Si
0IaHHMyxPaAnilk3ygPn7FsddwPnffjLVGzMfdFttIUYxiRFq1soQSTdskGf0Zv8
HN+IVfba05QVAj3vWOF6rL3YV0vVSBEIFXAZHOSqHdItuG0aHtfJsbBYb0jybpmO
sHDvgxaaEf/8wHRQeh1yKv6s4yHuRJiaBbGs1D7Emrpy2/3VRPxOnRNQ8EnnU8HG
eBAJg0EXTGHorc84ys32G2N1wcf3Pl6PmP/TF06EoM46BEQyj7g=
=aR3O
-END PGP SIGNATURE-



Bug#985468: msmtp: Upload to DELAYED/2 for bullseye

2021-07-20 Thread Felix Lechner
Control: tags -1 + pending

Hi,

Today I uploaded the non-maintainer version 1.8.11-2.1 to the
DELAYED/2 queue for unstable. [1] The purpose was to bring msmtpd in
bullseye into conformance with RFC821, which states that "Commands and
replies are not case sensitive." [2] (Later standards such as RFC5321
employ similar language.)

The upload will close this bug, which I marked pending.

The upstream commit 7dcf that was cherry-picked here was accepted
upstream over a year ago. [3] The debdiff showing the changes in the
new source package was copied to the bottom of this message.

Thank you for maintaining msmtp in Debian!

Kind regards,
Felix Lechner

[1] https://ftp-master.debian.org/deferred.html
[2] https://tools.ietf.org/html/rfc821
[3] 
https://github.com/marlam/msmtp-mirror/commit/7dcfd522efc13fde4df448d834bc6ba2b205

* * *

diff -Nru msmtp-1.8.11/debian/changelog msmtp-1.8.11/debian/changelog
--- msmtp-1.8.11/debian/changelog   2020-08-20 07:24:11.0 -0700
+++ msmtp-1.8.11/debian/changelog   2021-03-18 09:01:45.0 -0700
@@ -1,3 +1,12 @@
+msmtp (1.8.11-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick 7dcf from upstream for the bullseye release. Brings
+msmtp into conformance with RFC821, which states that "Commands and
+replies are not case sensitive." (Closes #985468)
+
+ -- Felix Lechner   Thu, 18 Mar 2021 09:01:45 -0700
+
 msmtp (1.8.11-2) unstable; urgency=medium

   * Fix build options to re-enable TLS support via GnuTLS, IDN and SASL.
diff -Nru 
msmtp-1.8.11/debian/patches/7dcfd522efc13fde4df448d834bc6ba2b205-adjusted.diff
msmtp-1.8.11/debian/patches/7dcfd522efc13fde4df448d834bc6ba2b205-adjusted.diff
--- 
msmtp-1.8.11/debian/patches/7dcfd522efc13fde4df448d834bc6ba2b205-adjusted.diff
 1969-12-31 16:00:00.0 -0800
+++ 
msmtp-1.8.11/debian/patches/7dcfd522efc13fde4df448d834bc6ba2b205-adjusted.diff
 2021-03-18 09:01:45.0 -0700
@@ -0,0 +1,70 @@
+Description: Cherry-pick 7dcf from upstream for bullseye, adjusted
+Author: Felix Lechner 
+Origin: 
https://github.com/marlam/msmtp-mirror/commit/7dcfd522efc13fde4df448d834bc6ba2b205.diff
+Bug: https://github.com/marlam/msmtp-mirror/issues/45
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/msmtpd.c
 b/src/msmtpd.c
+@@ -26,6 +26,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -186,18 +187,18 @@ int msmtpd_session(FILE* in, FILE* out,
+ fprintf(out, "220 localhost ESMTP msmtpd\r\n");
+ if (read_smtp_cmd(in, buf, SMTP_BUFSIZE) != 0)
+ return 1;
+-if (strncmp(buf, "EHLO ", 5) != 0 && strncmp(buf, "HELO ", 5) != 0) {
++if (strncasecmp(buf, "EHLO ", 5) != 0 && strncasecmp(buf, "HELO
", 5) != 0) {
+ fprintf(out, "500 Expected EHLO or HELO\r\n");
+ return 1;
+ }
+ fprintf(out, "250 localhost\r\n");
+ if (read_smtp_cmd(in, buf, SMTP_BUFSIZE) != 0)
+ return 1;
+-if (strncmp(buf, "MAIL FROM:", 10) != 0 && strcmp(buf, "QUIT") != 0) {
++if (strncasecmp(buf, "MAIL FROM:", 10) != 0 && strcasecmp(buf,
"QUIT") != 0) {
+ fprintf(out, "500 Expected MAIL FROM: or QUIT\r\n");
+ return 1;
+ }
+-if (strcmp(buf, "QUIT") == 0) {
++if (strcasecmp(buf, "QUIT") == 0) {
+ fprintf(out, "221 Bye\r\n");
+ return 0;
+ }
+@@ -235,19 +236,19 @@ int msmtpd_session(FILE* in, FILE* out,
+ return 1;
+ }
+ if (!recipient_was_seen) {
+-if (strncmp(buf, "RCPT TO:", 8) != 0) {
++if (strncasecmp(buf, "RCPT TO:", 8) != 0) {
+ fprintf(out, "500 Expected RCPT TO:\r\n");
+ free(cmd);
+ return 1;
+ }
+ } else {
+-if (strncmp(buf, "RCPT TO:", 8) != 0 && strcmp(buf,
"DATA") != 0) {
++if (strncasecmp(buf, "RCPT TO:", 8) != 0 &&
strcasecmp(buf, "DATA") != 0) {
+ fprintf(out, "500 Expected RCPT TO: or DATA\r\n");
+ free(cmd);
+ return 1;
+ }
+ }
+-if (strcmp(buf, "DATA") == 0) {
++if (strcasecmp(buf, "DATA") == 0) {
+ break;
+ } else {
+ if (get_addr(buf + 8, addrbuf, 0, ) != 0) {
+@@ -302,7 +303,7 @@ int msmtpd_session(FILE* in, FILE* out,
+ fprintf(out, "250 Ok, mail was piped\r\n");
+ if (read_smtp_cmd(in, buf, SMTP_BUFSIZE) != 0)
+ return 0; /* ignore missing QUIT */
+-if (strcmp(buf, "QUIT") != 0) {
++if (strcasecmp(buf, "QUIT") != 0) {
+ fprintf(out, "500 Expected QUIT\r\n");
+ return 1;
+ }
diff -Nru msmtp-1.8.11/debian/patches/series msmtp-1.8.11/debian/patches/series
--- msmtp-1.8.11/debian/patches/series  2020-04-23 07:36:12.0 -0700
+++ msmtp-1.8.11/debian/patches/series  2021-03-18 09:01:45.0 -0700
@@ -1 +1,2 @@
+7dcfd522efc13fde4df448d834bc6ba2b205-adjusted.diff
 

Bug#991320: flameshot crashing on startup

2021-07-20 Thread Dennis Filder
X-Debbugs-CC: allan grossman 

I can't reproduce this under current Bullseye KDE/xorg -- flameshot
behaves absolutley normally.  It could be a Wayland issue, and
flameshot's Wayland support is apparently still experimental.

Let us know if running flameshot like so fixes this for you:

GDK_BACKEND=x11 flameshot

Regards,
Dennis Filder



Bug#990566: dovecot: CVE-2021-33515 CVE-2021-29157 CVE-2020-28200

2021-07-20 Thread Salvatore Bonaccorso
Hi Noah,

[sorry for lack of reply to the previous mail, busy with other stuff]

On Tue, Jul 20, 2021 at 08:03:12AM -0700, Noah Meyerhans wrote:
> On Mon, Jul 19, 2021 at 08:21:45AM -0700, Noah Meyerhans wrote:
> > > > CVE-2021-33515[0]:
> > > > | The submission service in Dovecot before 2.3.15 allows STARTTLS
> > > > | command injection in lib-smtp. Sensitive information can be redirected
> > > > | to an attacker-controlled address.
> > > > 
> > > > https://dovecot.org/pipermail/dovecot-news/2021-June/000462.html
> > > > https://www.openwall.com/lists/oss-security/2021/06/28/2
> > > > 
> > > > 
> > > > CVE-2021-29157[1]:
> > > > | Dovecot before 2.3.15 allows ../ Path Traversal. An attacker with
> > > > | access to the local filesystem can trick OAuth2 authentication into
> > > > | using an HS256 validation key from an attacker-controlled location.
> > > > | This occurs during use of local JWT validation with the posix fs
> > > > | driver.
> > > > 
> > > > https://dovecot.org/pipermail/dovecot-news/2021-June/000461.html
> > > > https://www.openwall.com/lists/oss-security/2021/06/28/1
> 
> Ubuntu has released fixes for these, and I've been able to incorporate
> their backports into the current bullseye packages. [1]

Ack, very nice.

> > > > CVE-2020-28200[2]:
> > > > | The Sieve engine in Dovecot before 2.3.15 allows Uncontrolled Resource
> > > > | Consumption, as demonstrated by a situation with a complex regular
> > > > | expression for the regex extension.
> > > > 
> > > > https://dovecot.org/pipermail/dovecot-news/2021-June/000460.html
> > > > https://www.openwall.com/lists/oss-security/2021/06/28/3
> 
> This change is quite a bit more disruptive, as it basically would
> require backporting the entire Sieve resource accounting framework.  Per
> a comment on Ubuntu's tracker, this is not practical to backport. [2]  I
> agree with this assessment.  I'd be much more inclined to update to the
> latest upstream release and deal with any compatibility issues rather
> than try backporting this functionality, if we decide we really need it.
> 
> I will be uploading 1:2.3.13+dfsg1-2 to sid with fixes for the first two
> CVEs in the near term.  Will investigate a similar fix for buster via
> the next point release.  Will follow up with the release teams to get
> the updated packages into the archive.

Thanks this sound sensible!

Regards,
Salvatore



Bug#983369: linphone-desktop: chat msgs and (missed) incoming calls dates are wrong

2021-07-20 Thread Dennis Filder
Control: tag -1 confirmed
X-Debbugs-CC: David Pirotte 

On linphone-users others posted similar reports.  I can reproduce this
by setting my timezone from +0200 to -0400.

I'll try to look into it after the freeze ends.

Regards.



Bug#991322: wiki.debian.org: Template for "Debian Release"

2021-07-20 Thread Robbi Nespu

Package: wiki.debian.org
Severity: wishlist

Dear Maintainer,

* What led up to the situation?
Read here https://lists.debian.org/debian-user/2021/07/msg00881.html
For summary, IMHO https://wiki.debian.org/Debian 
 should have a template so it will be uniform and important point are 
keep as basic information on this wiki page. A comment inside template 
also can be put to say what should not be put here.



* What exactly did you do (or not do) that was effective (or ineffective)?
I proposing https://wiki.debian.org/Debian 
should have template that contain this "standard source.list" information.
My suggestion is to put on FAQ like 
https://wiki.debian.org/DebianBuster?action=diff=34=35



* What was the outcome of this action?
https://wiki.debian.org/Debian is central 
reference and having "standard source.list" is useful



* What outcome did you expect instead?
1st, no more add-revert-add-revert issue on same changes
2nd, more useful standard information for everyone to refer

--
Robbi Nespu 
D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
https://robbinespu.gitlab.io | https://mstdn.social/@robbinespu



Bug#966262: [Pkg-kde-extras] Bug#966262: please drop `qemu' from Depends

2021-07-20 Thread Diederik de Haas
On zaterdag 25 juli 2020 17:12:54 CEST Michael Tokarev wrote:
> The goal is to remove `qemu' binary metapackage

https://tracker.debian.org/pkg/qtemu shows that qtemu was removed from 
testing/unstable/experimental on 22/23 December *2016* and only oldstable has 
the package.

So I don't know what this bug is supposed to achieve.

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


Bug#991321: unblock: dovecot/1:2.3.13+dfsg1-2

2021-07-20 Thread Noah Meyerhans
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dovecot

[ Reason ]

Dovecot 1:2.3.13+dfsg1-2 includes two targeted security fixes and no other
changes.  The relevant section of debian/changelog is:

dovecot (1:2.3.13+dfsg1-2) unstable; urgency=high

  * Import upstream fixes for security issues (Closes: #990566):
- CVE-2021-29157: Path traversal issue allowing an attacker with
  access to the local filesystem can trick OAuth2 authentication into
  using an HS256 validation key from an attacker-controlled location
- CVE-2021-33515: Sensitive information could be redirected to an
  attacker-controlled address because of a STARTTLS command injection
  bug in the submission service

 -- Noah Meyerhans   Tue, 20 Jul 2021 08:05:19 -0700

[ Impact ]

We release bullseye with known security issues and will likely need to fix them
in a subsequent point release.

[ Tests ]

I've done basic functionality testing.  Additionally, the fixes are backported
from upstream's changes and are already included in Ubuntu's security archive,
so they've gotten reasonable test coverage at that level.  I do not have
reproducers for the security issues, so I have been unable to verify
experimentally that the problems have been fixed.

[ Risks ]

Code changes are reasonably straightforward, and as mentioned are already
deployed elsewhere.  Further, they impact what I believe to be less common
features of dovecot, meaning that even in the worst-case scenario, impact is
likely to be limited to a small number of users.

[ 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 ]

n/a

unblock dovecot/1:2.3.13+dfsg1-2
diff -Nru dovecot-2.3.13+dfsg1/debian/changelog 
dovecot-2.3.13+dfsg1/debian/changelog
--- dovecot-2.3.13+dfsg1/debian/changelog   2021-01-25 23:38:17.0 
+
+++ dovecot-2.3.13+dfsg1/debian/changelog   2021-07-20 15:05:19.0 
+
@@ -1,3 +1,15 @@
+dovecot (1:2.3.13+dfsg1-2) unstable; urgency=high
+
+  * Import upstream fixes for security issues (Closes: #990566):
+- CVE-2021-29157: Path traversal issue allowing an attacker with
+  access to the local filesystem can trick OAuth2 authentication into
+  using an HS256 validation key from an attacker-controlled location
+- CVE-2021-33515: Sensitive information could be redirected to an
+  attacker-controlled address because of a STARTTLS command injection
+  bug in the submission service
+
+ -- Noah Meyerhans   Tue, 20 Jul 2021 08:05:19 -0700
+
 dovecot (1:2.3.13+dfsg1-1) unstable; urgency=medium
 
   [ Christian Göttsche ]
diff -Nru dovecot-2.3.13+dfsg1/debian/patches/CVE-2021-29157.patch 
dovecot-2.3.13+dfsg1/debian/patches/CVE-2021-29157.patch
--- dovecot-2.3.13+dfsg1/debian/patches/CVE-2021-29157.patch1970-01-01 
00:00:00.0 +
+++ dovecot-2.3.13+dfsg1/debian/patches/CVE-2021-29157.patch2021-07-19 
22:09:38.0 +
@@ -0,0 +1,134 @@
+Description: fix incorrectly escapes kid and azp fields in JWT tokens
+Origin: 
https://launchpadlibrarian.net/544092180/dovecot_1%3A2.3.13+dfsg1-1ubuntu1_1%3A2.3.13+dfsg1-1ubuntu1.1.diff.gz
+
+--- a/src/lib-dict-extra/dict-fs.c
 b/src/lib-dict-extra/dict-fs.c
+@@ -67,8 +67,37 @@ static void fs_dict_deinit(struct dict *
+   i_free(dict);
+ }
+ 
++/* Remove unsafe paths */
++static const char *fs_dict_escape_key(const char *key)
++{
++  const char *ptr;
++  string_t *new_key = NULL;
++  /* we take the slow path always if we see potential
++ need for escaping */
++  while ((ptr = strstr(key, "/.")) != NULL) {
++  /* move to the first dot */
++  const char *ptr2 = ptr + 1;
++  /* find position of non-dot */
++  while (*ptr2 == '.') ptr2++;
++  if (new_key == NULL)
++  new_key = t_str_new(strlen(key));
++  str_append_data(new_key, key, ptr - key);
++  /* if ptr2 is / or end of string, escape */
++  if (*ptr2 == '/' || *ptr2 == '\0')
++  str_append(new_key, "/...");
++  else
++  str_append(new_key, "/.");
++  key = ptr + 2;
++  }
++  if (new_key == NULL)
++  return key;
++  str_append(new_key, key);
++  return str_c(new_key);
++}
++
+ static const char *fs_dict_get_full_key(struct fs_dict *dict, const char *key)
+ {
++  key = fs_dict_escape_key(key);
+   if (str_begins(key, DICT_PATH_SHARED))
+   return key + strlen(DICT_PATH_SHARED);
+   else if (str_begins(key, DICT_PATH_PRIVATE)) {
+--- a/src/lib-oauth2/oauth2-jwt.c
 b/src/lib-oauth2/oauth2-jwt.c
+@@ -250,6 +250,34 @@ oauth2_jwt_copy_fields(ARRAY_TYPE(oauth2
+   }
+ }
+ 
++/* Escapes '/' and '%' in identifier to %hex */

Bug#991320: flameshot crashing on startup

2021-07-20 Thread allan
Correction.

"flameshot &" is in openbox autostart, "flameshot gui -p
/home/username/temp" is mapped to hotkey in ~/.config/openbox/rc.xml -
this configuration has been working for more than a year.

On Tue, Jul 20, 2021 at 10:18 AM allan grossman  wrote:
>
> Package: flameshot
> Version: 0.9.0+ds1-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: wizard10...@gmail.com
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> Have flameshot gui -p /home/username/temp set in openbox autostart.  Mapped 
> hotkeys were not responding.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> This probably isn't a flameshot bug but I'm not sure where it goes - 
> flameshot crashes when started in openbox autostart or from terminal session 
> and have duplicated the error on two Sid machines.  If you execute 
> "dbus-update-activation-environment DISPLAY XAUTHORITY" flameshot gui will 
> start for about half a second and then crash, which is better than running in 
> a terminal session where it won't display GUI at all before crashing.
>
>* What was the outcome of this action?
>
> flameshot still not working.
>
>* What outcome did you expect instead?
>
> Expected flameshot to run as normal  :)
>
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable
>   APT policy: (1001, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages flameshot depends on:
> ii  hicolor-icon-theme0.17-2
> ii  libc6 2.31-13
> ii  libfmt7   7.1.3+ds1-5
> ii  libgcc-s1 10.2.1-6
> ii  libqt5core5a  5.15.2+dfsg-9
> ii  libqt5dbus5   5.15.2+dfsg-9
> ii  libqt5gui55.15.2+dfsg-9
> ii  libqt5network55.15.2+dfsg-9
> ii  libqt5svg55.15.2-3
> ii  libqt5widgets55.15.2+dfsg-9
> ii  libspdlog1 [libspdlog1-fmt7]  1:1.8.1+ds-2.1
> ii  libstdc++610.2.1-6
>
> flameshot recommends no packages.
>
> Versions of packages flameshot suggests:
> ii  ca-certificates  20210119
> ii  openssl  1.1.1k-1
>
> -- no debconf information



-- 
we see things not as they are, but as we are.
 -- anais nin



Bug#991320: flameshot crashing on startup

2021-07-20 Thread allan grossman
Package: flameshot
Version: 0.9.0+ds1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: wizard10...@gmail.com

Dear Maintainer,

   * What led up to the situation?

Have flameshot gui -p /home/username/temp set in openbox autostart.  Mapped 
hotkeys were not responding.
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

This probably isn't a flameshot bug but I'm not sure where it goes - flameshot 
crashes when started in openbox autostart or from terminal session and have 
duplicated the error on two Sid machines.  If you execute 
"dbus-update-activation-environment DISPLAY XAUTHORITY" flameshot gui will 
start for about half a second and then crash, which is better than running in a 
terminal session where it won't display GUI at all before crashing.
 
   * What was the outcome of this action?

flameshot still not working.
   
   * What outcome did you expect instead?

Expected flameshot to run as normal  :)
   

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

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

Versions of packages flameshot depends on:
ii  hicolor-icon-theme0.17-2
ii  libc6 2.31-13
ii  libfmt7   7.1.3+ds1-5
ii  libgcc-s1 10.2.1-6
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5dbus5   5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5network55.15.2+dfsg-9
ii  libqt5svg55.15.2-3
ii  libqt5widgets55.15.2+dfsg-9
ii  libspdlog1 [libspdlog1-fmt7]  1:1.8.1+ds-2.1
ii  libstdc++610.2.1-6

flameshot recommends no packages.

Versions of packages flameshot suggests:
ii  ca-certificates  20210119
ii  openssl  1.1.1k-1

-- no debconf information



Bug#990566: dovecot: CVE-2021-33515 CVE-2021-29157 CVE-2020-28200

2021-07-20 Thread Noah Meyerhans
On Mon, Jul 19, 2021 at 08:21:45AM -0700, Noah Meyerhans wrote:
> > > CVE-2021-33515[0]:
> > > | The submission service in Dovecot before 2.3.15 allows STARTTLS
> > > | command injection in lib-smtp. Sensitive information can be redirected
> > > | to an attacker-controlled address.
> > > 
> > > https://dovecot.org/pipermail/dovecot-news/2021-June/000462.html
> > > https://www.openwall.com/lists/oss-security/2021/06/28/2
> > > 
> > > 
> > > CVE-2021-29157[1]:
> > > | Dovecot before 2.3.15 allows ../ Path Traversal. An attacker with
> > > | access to the local filesystem can trick OAuth2 authentication into
> > > | using an HS256 validation key from an attacker-controlled location.
> > > | This occurs during use of local JWT validation with the posix fs
> > > | driver.
> > > 
> > > https://dovecot.org/pipermail/dovecot-news/2021-June/000461.html
> > > https://www.openwall.com/lists/oss-security/2021/06/28/1

Ubuntu has released fixes for these, and I've been able to incorporate
their backports into the current bullseye packages. [1]

> > > CVE-2020-28200[2]:
> > > | The Sieve engine in Dovecot before 2.3.15 allows Uncontrolled Resource
> > > | Consumption, as demonstrated by a situation with a complex regular
> > > | expression for the regex extension.
> > > 
> > > https://dovecot.org/pipermail/dovecot-news/2021-June/000460.html
> > > https://www.openwall.com/lists/oss-security/2021/06/28/3

This change is quite a bit more disruptive, as it basically would
require backporting the entire Sieve resource accounting framework.  Per
a comment on Ubuntu's tracker, this is not practical to backport. [2]  I
agree with this assessment.  I'd be much more inclined to update to the
latest upstream release and deal with any compatibility issues rather
than try backporting this functionality, if we decide we really need it.

I will be uploading 1:2.3.13+dfsg1-2 to sid with fixes for the first two
CVEs in the near term.  Will investigate a similar fix for buster via
the next point release.  Will follow up with the release teams to get
the updated packages into the archive.

noah

1.  https://launchpad.net/ubuntu/+source/dovecot/1:2.3.13+dfsg1-1ubuntu1.1
2.  https://ubuntu.com/security/cve-2020-28200



Bug#991313: unblock: qutebrowser/2.0.2-2

2021-07-20 Thread Axel Beckert
Hi Adrian,

Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package qutebrowser
> 
>   * Apply patch to update documentation with regards to the #qutebrowser
> IRC channel having moved from Freenode to Libera.Chat.
> (change by Axel Beckert)
> 
> Documentation-only change.

Huh? I thought I filed an unblock request last week already. Hmmm.
Can't find it in the BTS. Oh, fuck, my local postfix daemon was no
more running. So thanks for writing one, too!

So there will show up a proper, full unblock request arrive soon.
Sorry for not having noticed that it didn't go out before the full
freeze. :-(

Will merge them once it arrived in the BTS.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#991319: unblock: qutebrowser/2.0.2-2

2021-07-20 Thread Axel Beckert
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@debian.org, reichw...@b1-systems.de, m...@fritzreichwald.de, 
m...@the-compiler.org

Dear Release Team,

please unblock package qutebrowser/2.0.2-2.

It is a pure documentation update related to the Freenode f*ckup.

[ Reason ]

The upload adds a patch which updates the pointers to qutebrowser's
IRC channel which — like many other projects — recently had to change
from Freenode to Libera.Chat due to a hostile takeover of the prject's
IRC channel on Freenode.

[ Impact ]

According to upstream, from time to time people still join the
project's old channel on Freenode. It is suspected that outdated links
in packaged versions of qutebrowser are one source for this.

So if we don't get this tiny documentation update into Bullseye, the
Freenode f*ckup will just last longer for this project and were
continue to feed the new, hostile Freenode owners.

[ Tests ]

* I started qutebrowser, opened qute://help/, checked the IRC links.

* I viewed the man page, searched for "freenode" (not present) and "IRC"
  to verify that the IRC references are updated in there, too.

* I used qutebrowser as usually for about a day.

* A debdiff on the .changes file (i.e. the resulting .deb files only
  showed version field changes"

  $ debdiff /…/pbuilder/result/qutebrowser_2.0.2-{1,2}_amd64.changes
  File lists identical (after any substitutions)
  
  Control files of package qutebrowser: lines which differ (wdiff format)
  ---
  Version: [-2.0.2-1-] {+2.0.2-2+}
  
  Control files of package qutebrowser-qtwebengine: lines which differ (wdiff 
format)
  
---
  Depends: libqt5webenginecore5 (>= 5.12), python3-pyqt5.qtwebengine (>= 5.12), 
qutebrowser (= [-2.0.2-1)-] {+2.0.2-2)+}
  Version: [-2.0.2-1-] {+2.0.2-2+}
  
  Control files of package qutebrowser-qtwebkit: lines which differ (wdiff 
format)
  

  Depends: python3-pyqt5.qtwebkit (>= 5.12), libqt5webkit5 (>= 5.212), 
qutebrowser (= [-2.0.2-1)-] {+2.0.2-2)+}
  Version: [-2.0.2-1-] {+2.0.2-2+}

* diffoscope /…/pbuilder/result/qutebrowser_2.0.2-{1,2}_all.deb
  (i.e. the .deb file where the changed files are in) only showed
  expected changes:

  * The updated parts of the documentation
  * One new changelog entry (expected as well :-).
  * Version number changes (qutebrowser and debhelper, the latter from
13.3.3 to 13.3.4, so no big gap either)
  * Timestamps

[ Risks ]

Very low:

* Leaf package

* Only asciidoc source files (for the man page), one SVG vector image
  (XML) and HTML files are touched by the added patch.

* It's a simple patch updating a few lines of documentation. The
  standalone patch is attached as well as the full source debdiff.

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

[ Other info ]

I deliberately _only_ patched the SVG/XML version of the cheatsheet
image, _not_ the PNG version of it as that would have added a 1.7 MB
binary patch or an additional file plus changes in e.g.
debian/qutebrowser.install. (Both variants were discussed between
Debian packagers and upstream. Given the time shortly before the
full-freeze, we've chosen the simplest variant with the drawback of
not patching each occurrence, but leaving out one deliberately.)

So please…

unblock qutebrowser/2.0.2-2

Thanks in advance!
diff -Nru qutebrowser-2.0.2/debian/changelog qutebrowser-2.0.2/debian/changelog
--- qutebrowser-2.0.2/debian/changelog  2021-02-05 04:27:06.0 +0100
+++ qutebrowser-2.0.2/debian/changelog  2021-07-14 02:38:48.0 +0200
@@ -1,3 +1,10 @@
+qutebrowser (2.0.2-2) unstable; urgency=medium
+
+  * Apply patch to update documentation with regards to the #qutebrowser
+IRC channel having moved from Freenode to Libera.Chat.
+
+ -- Axel Beckert   Wed, 14 Jul 2021 02:38:48 +0200
+
 qutebrowser (2.0.2-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru 
qutebrowser-2.0.2/debian/patches/0001-Update-IRC-links-to-Libera-Chat.patch 
qutebrowser-2.0.2/debian/patches/0001-Update-IRC-links-to-Libera-Chat.patch
--- qutebrowser-2.0.2/debian/patches/0001-Update-IRC-links-to-Libera-Chat.patch 
1970-01-01 01:00:00.0 +0100
+++ qutebrowser-2.0.2/debian/patches/0001-Update-IRC-links-to-Libera-Chat.patch 
2021-07-14 02:38:48.0 +0200
@@ -0,0 +1,74 @@
+Author: Axel Beckert 
+Description: Update IRC links to Libera Chat
+ Based on a patch by Florian Bruhin 
+Forwarded: not-needed
+
+--- a/doc/qutebrowser.1.asciidoc
 b/doc/qutebrowser.1.asciidoc
+@@ -152,8 +152,8 @@
+ https://lists.schokokeks.org/mailman/listinfo.cgi/qutebrowser
+ * Announce-only mailinglist: 

Bug#991312: [EXTERNAL] Bug#991312: Acknowledgement (mini-dinstall: "incoming_permissions" parse value as decimal and not octal)

2021-07-20 Thread Oron Peled
Two comments:
 * Version "0.7.0+nmu2" marks local build of "0.7.0" with patches
 * The patch attached to the bug report was created by:
 Volodymyr Sarkisian 

Thanks,

--
Oron Peled


Bug#991318: unblock: munin/2.0.67-2

2021-07-20 Thread Holger Levsen
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package munin 2.0.67-2 as it fixes a serious bug with a oneline 
fix:

$ debdiff munin_2.0.67-1.dsc munin_2.0.67-2.dsc
diff -Nru munin-2.0.67/debian/changelog munin-2.0.67/debian/changelog
--- munin-2.0.67/debian/changelog   2021-02-26 13:24:19.0 +0100
+++ munin-2.0.67/debian/changelog   2021-07-20 14:40:08.0 +0200
@@ -1,3 +1,11 @@
+munin (2.0.67-2) unstable; urgency=medium
+
+  [ Kentaro Hayashi ]
+  * debian/munin-node.service: ensure /run/munin directory exists.
+Closes: #990371.
+
+ -- Holger Levsen   Tue, 20 Jul 2021 14:40:08 +0200
+
 munin (2.0.67-1) unstable; urgency=medium
 
   [ Holger Levsen ]
diff -Nru munin-2.0.67/debian/munin-node.service 
munin-2.0.67/debian/munin-node.service
--- munin-2.0.67/debian/munin-node.service  2021-01-17 23:34:32.0 
+0100
+++ munin-2.0.67/debian/munin-node.service  2021-07-20 14:39:29.0 
+0200
@@ -7,6 +7,7 @@
 EnvironmentFile=-/etc/default/munin-node
 Type=notify
 Restart=always
+RuntimeDirectory=munin
 ExecStart=/usr/sbin/munin-node --foreground $DAEMON_ARGS
 PIDFile=/run/munin/munin-node.pid
 # Plugins like "smart_" require access to devices


I've uploaded it and just saw the source package appear in unstable, though it
hasn't been built yet.

unblock munin/2.0.67-2

Thanks for your work on bullseye!


-- 
cheers,
Holger

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

No future.


signature.asc
Description: PGP signature


Bug#991317: unblock: klaus/1.5.2-4

2021-07-20 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package klaus

  * Fix 500 when authentication is required. Closes: #987951
  (and trivial packaging changes documented in d/changelog)
(changes by Jelmer Vernooij)

One-line fix for basic/digest authentication.

(1.5.2-3 is missing in d/changelog, the changes it originally
 documented were already in 1.5.2-1)
diff -Nru klaus-1.5.2/debian/changelog klaus-1.5.2/debian/changelog
--- klaus-1.5.2/debian/changelog2020-07-20 01:15:41.0 +0300
+++ klaus-1.5.2/debian/changelog2021-07-11 22:32:42.0 +0300
@@ -1,3 +1,19 @@
+klaus (1.5.2-4) unstable; urgency=medium
+
+  * Source-only upload.
+
+ -- Jelmer Vernooij   Sun, 11 Jul 2021 20:32:42 +0100
+
+klaus (1.5.2-2) unstable; urgency=low
+
+  * Set Rules-Requires-Root: no.
+  * Fix field name typo in debian/upstream/metadata (Repository-Browser =>
+Repository-Browse).
+  * Update watch file format version to 4.
+  * Fix 500 when authentication is required. Closes: #987951
+
+ -- Jelmer Vernooij   Wed, 05 May 2021 16:38:43 +0100
+
 klaus (1.5.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru klaus-1.5.2/debian/control klaus-1.5.2/debian/control
--- klaus-1.5.2/debian/control  2020-07-20 01:15:41.0 +0300
+++ klaus-1.5.2/debian/control  2021-07-11 22:32:42.0 +0300
@@ -8,6 +8,7 @@
 Vcs-Git: https://salsa.debian.org/jelmer/klaus.git
 Vcs-Browser: https://salsa.debian.org/jelmer/klaus
 Build-Depends: debhelper-compat (= 12)
+Rules-Requires-Root: no
 
 Package: klaus
 Architecture: all
diff -Nru klaus-1.5.2/debian/patches/01_httpauth 
klaus-1.5.2/debian/patches/01_httpauth
--- klaus-1.5.2/debian/patches/01_httpauth  2020-07-20 01:15:41.0 
+0300
+++ klaus-1.5.2/debian/patches/01_httpauth  2021-07-11 22:32:42.0 
+0300
@@ -3,7 +3,7 @@
 index 000..82860d0
 --- /dev/null
 +++ b/klaus/httpauth.py
-@@ -0,0 +1,197 @@
+@@ -0,0 +1,198 @@
 +"""
 +Copyright (c) 2012 Jonas Haag . License: ISC
 +
@@ -138,7 +138,8 @@
 +'401 Authentication Required',
 +[('WWW-Authenticate', make_www_authenticate_header(self.realm))],
 +)
-+return ['401 - Authentication Required']
++html = '401 - Authentication Required'
++return [html if PY2 else html.encode()]
 +
 +
 +class DigestFileHttpAuthMiddleware(BaseHttpAuthMiddleware):
diff -Nru klaus-1.5.2/debian/upstream/metadata 
klaus-1.5.2/debian/upstream/metadata
--- klaus-1.5.2/debian/upstream/metadata2020-07-20 01:15:41.0 
+0300
+++ klaus-1.5.2/debian/upstream/metadata2021-07-11 22:32:42.0 
+0300
@@ -2,4 +2,3 @@
 Bug-Submit: https://github.com/jonashaag/klaus/issues/new
 Repository: https://github.com/jonashaag/klaus.git
 Repository-Browse: https://github.com/jonashaag/klaus
-Repository-Browser: https://github.com/jonashaag/klaus
diff -Nru klaus-1.5.2/debian/watch klaus-1.5.2/debian/watch
--- klaus-1.5.2/debian/watch2020-07-20 01:15:41.0 +0300
+++ klaus-1.5.2/debian/watch2021-07-11 22:32:42.0 +0300
@@ -1,2 +1,2 @@
-version=3
-https://pypi.debian.net/klaus/klaus-(.*).tar.gz
+version=4
+https://pypi.debian.net/klaus klaus-(.*).tar.gz


Bug#991270: unblock: suricata/6.0.1-3

2021-07-20 Thread Sascha Steinbiss
tags 991270 - moreinfo
thanks

Hi Graham,

[...]
> Please go ahead and upload to unstable, then remove the moreinfo tag
> once it has built.

Done. 6.0.1-3 is now built in unstable on all of the official archs that
the previous version was built on.

Cheers
Sascha



OpenPGP_signature
Description: OpenPGP digital signature


Bug#991316: clamav: Freshclam exhaust diff download quotas before switching to full downloads

2021-07-20 Thread Jean-Michel Vourgère
Package: clamav
Version: 0.103.2+dfsg-0+deb10u1
Severity: normal

Dear Maintainer,

Clamav no longer download updates on my server.

I am in a situation where I get message:
Incremental update failed, trying to download daily.cvd

However, freshclam tried so hard to download the diff that I get quick
out every time from the mirror with the error:

Tue Jul 20 15:45:49 2021 -> ^Can't download daily.cvd from 
https://database.clamav.net/daily.cvd
Tue Jul 20 15:45:49 2021 -> ^FreshClam received error code 429 from the ClamAV 
Content Delivery Network (CDN).
Tue Jul 20 15:45:49 2021 -> This means that you have been rate limited by the 
CDN.
Tue Jul 20 15:45:49 2021 ->  1. Run FreshClam no more than once an hour to 
check for updates.
Tue Jul 20 15:45:49 2021 -> FreshClam should check DNS first to see if an 
update is needed.
Tue Jul 20 15:45:49 2021 ->  2. If you have more than 10 hosts on your network 
attempting to download,
Tue Jul 20 15:45:49 2021 -> it is recommended that you set up a private 
mirror on your network using
Tue Jul 20 15:45:49 2021 -> cvdupdate (https://pypi.org/project/cvdupdate/) 
to save bandwidth on the
Tue Jul 20 15:45:49 2021 -> CDN and your own network.
Tue Jul 20 15:45:49 2021 ->  3. Please do not open a ticket asking for an 
exemption from the rate limit,
Tue Jul 20 15:45:49 2021 -> it will not be granted.
Tue Jul 20 15:45:49 2021 -> ^You are on cool-down until after: 2021-07-20 
19:45:49
Tue Jul 20 15:45:49 2021 -> *Current working dir is /var/lib/clamav/
Tue Jul 20 15:45:49 2021 -> *check_for_new_database_version: Local copy of main 
found: main.cld.
Tue Jul 20 15:45:49 2021 -> *query_remote_database_version: main.cvd version 
from DNS: 61
Tue Jul 20 15:45:49 2021 -> main database available for update (local version: 
59, remote version: 61)

See attached full log.

I expected freshclam to give up retrying patching the database and switch
to full download *before* hitting the rate limitation. Every time it gives up 
and
switch to full download, it is too late and the full download fails too.

As a result, freshclam is totally broken here.

-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
ConcurrentDatabaseReload = "yes"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertBrokenMedia disabled
AlertEncrypted disabled
StructuredCCOnly disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled

Bug#991297: rtw_8821ce does not work in debian 11

2021-07-20 Thread Ben Hutchings
Control: reassign -1 src:linux 5.10.40-1
Control: tag -1 fixed-upstream

On Tue, 2021-07-20 at 10:11 +0200, Michele Bucca wrote:
> Package: firmware-realtek
> Version 20210315-2
> 
> I'm testing debian bullseye and I've noticed that despite the firmware
> of the wireless card Realtek RTL8821ce being added to the package, it
> is still not working.
> 
> I downloaded the ISO debian-live-blsy-DI-rc2-amd64-xfce+nonfree.iso from
> 
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2-live+nonfree/amd64/iso-hybrid/debian-live-blsy-DI-rc2-amd64-xfce+nonfree.iso
> 
> and when I boot the system the Wireless card is not detected by Network 
> Manager.
> 
> if I type dmesg -l err in the terminal I get the following error message:
> 
> [8.123230] rtw_8821ce :03:00.0: rfe 2 isn't supported
[...]

This means the driver doesn't support this variant of the hardware. 
It's not a firmware problem.

That appears to be fixed in 5.12 by:

commit 5d6651fe85837b11564a2e2c3c6279c057d078d6
Author: Guo-Feng Fan 
Date:   Tue Feb 2 13:50:12 2021 +0800

rtw88: 8821c: support RFE type2 wifi NIC

but that may depend on other changes.

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'


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


Bug#991315: ITP: python-immutabledict -- immutable wrapper around dictionaries (fork of frozendict)

2021-07-20 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: python-immutabledict -- immutable wrapper around dictionaries 
(fork of frozendict)
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-immutabledict
  Version : 2.1.0
  Upstream Author : Copyright: Corentin Garcia 
* URL : https://github.com/corenting/immutabledict/
* License : MIT
  Programming Lang: Python
  Description : immutable wrapper around dictionaries (fork of frozendict)
 Immutabledict implements the complete mapping interface and can be
 used as a drop-in replacement for dictionaries where immutability is
 desired. The immutabledict constructor mimics dict, and all of the
 expected interfaces (iter, len, repr, hash, getitem) are provided. Note
 that an immutabledict does not guarantee the immutability of its values,
 so the utility of hash method is restricted by usage.
 .
 The only difference is that the copy() method of immutable takes variable
 keyword arguments, which will be present as key/value pairs in the new,
 immutable copy.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/debian/python-immutabledict



Bug#991313: unblock: qutebrowser/2.0.2-2

2021-07-20 Thread Adrian Bunk
On Tue, Jul 20, 2021 at 04:23:24PM +0300, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package qutebrowser
> 
>   * Apply patch to update documentation with regards to the #qutebrowser
> IRC channel having moved from Freenode to Libera.Chat.
> (change by Axel Beckert)
> 
> Documentation-only change.

And with attachment.

cu
Adrian
diff -Nru qutebrowser-2.0.2/debian/changelog qutebrowser-2.0.2/debian/changelog
--- qutebrowser-2.0.2/debian/changelog  2021-02-05 05:27:06.0 +0200
+++ qutebrowser-2.0.2/debian/changelog  2021-07-14 03:38:48.0 +0300
@@ -1,3 +1,10 @@
+qutebrowser (2.0.2-2) unstable; urgency=medium
+
+  * Apply patch to update documentation with regards to the #qutebrowser
+IRC channel having moved from Freenode to Libera.Chat.
+
+ -- Axel Beckert   Wed, 14 Jul 2021 02:38:48 +0200
+
 qutebrowser (2.0.2-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru 
qutebrowser-2.0.2/debian/patches/0001-Update-IRC-links-to-Libera-Chat.patch 
qutebrowser-2.0.2/debian/patches/0001-Update-IRC-links-to-Libera-Chat.patch
--- qutebrowser-2.0.2/debian/patches/0001-Update-IRC-links-to-Libera-Chat.patch 
1970-01-01 02:00:00.0 +0200
+++ qutebrowser-2.0.2/debian/patches/0001-Update-IRC-links-to-Libera-Chat.patch 
2021-07-14 03:38:48.0 +0300
@@ -0,0 +1,74 @@
+Author: Axel Beckert 
+Description: Update IRC links to Libera Chat
+ Based on a patch by Florian Bruhin 
+Forwarded: not-needed
+
+--- a/doc/qutebrowser.1.asciidoc
 b/doc/qutebrowser.1.asciidoc
+@@ -152,8 +152,8 @@
+ https://lists.schokokeks.org/mailman/listinfo.cgi/qutebrowser
+ * Announce-only mailinglist: 
mailto:qutebrowser-annou...@lists.qutebrowser.org[] /
+ https://lists.schokokeks.org/mailman/listinfo.cgi/qutebrowser-announce
+-* IRC: irc://irc.freenode.org/#qutebrowser[`#qutebrowser`] on
+-https://freenode.net/[Freenode]
++* IRC: irc://irc.libera.chat/#qutebrowser[`#qutebrowser`] on
++https://libera.chat/[Libera Chat]
+ * Github: https://github.com/qutebrowser/qutebrowser
+ 
+ == AUTHOR
+--- a/misc/cheatsheet.svg
 b/misc/cheatsheet.svg
+@@ -2570,7 +2570,7 @@
+  id="flowPara5604"
+  
style="font-size:13.8667px;line-height:1.25;font-family:sans-serif;stroke-width:1.06667">Website:
 https://www.qutebrowser.org/ IRC:
 #qutebrowser on FreenodeIRC:
 #qutebrowser on Libera ChatMailinglist:
 qutebrow...@lists.qutebrowser.org
+ 
+ 
+ 
+-Join the IRC channel #qutebrowser on
+-https://freenode.net/;>Freenode
+-(https://webchat.freenode.net/?channels=#qutebrowser;>webchat).
++Join the IRC channel #qutebrowser on
++https://libera.chat/;>Libera Chat
++(https://web.libera.chat/#qutebrowser;>webchat).
+ 
+ 
+ 
+--- a/qutebrowser/html/doc/index.html
 b/qutebrowser/html/doc/index.html
+@@ -866,9 +866,9 @@
+ Getting help
+ 
+ You can get help in the IRC channel
+-#qutebrowser on
+-http://freenode.net/;>Freenode
+-(https://webchat.freenode.net/?channels=#qutebrowser;>webchat), 
or by writing a
++#qutebrowser on
++https://libera.chat/;>Libera Chat
++(https://web.libera.chat/#qutebrowser;>webchat), or by writing a
+ message to the
+ https://lists.schokokeks.org/mailman/listinfo.cgi/qutebrowser;>mailinglist
 at
+ mailto:qutebrow...@lists.qutebrowser.org;>qutebrow...@lists.qutebrowser.org.
+--- a/qutebrowser/html/doc/quickstart.html
 b/qutebrowser/html/doc/quickstart.html
+@@ -939,9 +939,9 @@
+ 
+ 
+ 
+-Chat via the IRC channel: #qutebrowser on
+-https://freenode.net/;>Freenode
+-(https://webchat.freenode.net/?channels=#qutebrowser;>webchat)
++Chat via the IRC channel: #qutebrowser on
++https://libera.chat/;>Libera Chat
++(https://web.libera.chat/#qutebrowser;>webchat)
+ 
+ 
+ 
diff -Nru qutebrowser-2.0.2/debian/patches/series 
qutebrowser-2.0.2/debian/patches/series
--- qutebrowser-2.0.2/debian/patches/series 2021-02-05 01:50:57.0 
+0200
+++ qutebrowser-2.0.2/debian/patches/series 2021-07-14 03:36:35.0 
+0300
@@ -1 +1,2 @@
 replace-external-merch-images-with-links.patch
+0001-Update-IRC-links-to-Libera-Chat.patch


Bug#991314: unblock: progress-linux/20210101-2

2021-07-20 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package progress-linux

  * Adding initial Brazilian Portuguese debconf translations from Jorge
Neto  and Adriano Rafael Gomes
 (Closes: #986501).
  * Adding initial Spanish debconf translations from Camaleón
 (Closes: #987667).
(changes by Daniel Baumann)

Translation-only change.
diff -Nru progress-linux-20210101/debian/changelog 
progress-linux-20210101/debian/changelog
--- progress-linux-20210101/debian/changelog2021-02-09 16:53:47.0 
+0200
+++ progress-linux-20210101/debian/changelog2021-07-18 10:14:43.0 
+0300
@@ -1,3 +1,14 @@
+progress-linux (20210101-2) sid; urgency=medium
+
+  * Uploading to sid.
+  * Adding initial Brazilian Portuguese debconf translations from Jorge
+Neto  and Adriano Rafael Gomes
+ (Closes: #986501).
+  * Adding initial Spanish debconf translations from Camaleón
+ (Closes: #987667).
+
+ -- Daniel Baumann   Sun, 18 Jul 2021 
09:14:43 +0200
+
 progress-linux (20210101-1) sid; urgency=medium
 
   * Uploading to sid.
diff -Nru progress-linux-20210101/debian/po/es.po 
progress-linux-20210101/debian/po/es.po
--- progress-linux-20210101/debian/po/es.po 1970-01-01 02:00:00.0 
+0200
+++ progress-linux-20210101/debian/po/es.po 2021-07-18 10:14:02.0 
+0300
@@ -0,0 +1,67 @@
+# Spanish debconf translation of progress-linux
+# Copyright (C) 2021 Camaleón 
+# This file is distributed under the same license as the progress-linux 
package.
+msgid ""
+msgstr ""
+"Project-Id-Version: progress-linux\n"
+"Report-Msgid-Bugs-To: progress-li...@packages.debian.org\n"
+"POT-Creation-Date: 2019-11-18 17:31+0100\n"
+"PO-Revision-Date: 2021-04-16 17:45+0200\n"
+"Last-Translator: Camaleón \n"
+"Language-Team: Debian Spanish \n"
+"Language: es\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: title
+#. Description
+#: ../progress-linux.templates:1001
+msgid "Progress Linux: Setup"
+msgstr "Progress Linux: Configuración"
+
+#. Type: multiselect
+#. Description
+#: ../progress-linux.templates:2001
+msgid "setup apt archives:"
+msgstr "configurar archivos apt:"
+
+#. Type: multiselect
+#. Description
+#: ../progress-linux.templates:2001
+msgid "Please select the apt archives to setup."
+msgstr "Por favor, indique los archivos apt que desea configurar."
+
+#. Type: multiselect
+#. Description
+#: ../progress-linux.templates:3001
+msgid "setup apt archive areas:"
+msgstr "configurar áreas del archivo apt:"
+
+#. Type: multiselect
+#. Description
+#: ../progress-linux.templates:3001
+msgid "Please select the apt archive areas to setup."
+msgstr "Por favor, indique las áreas del archivo apt que desea configurar."
+
+#. Type: string
+#. Description
+#: ../progress-linux.templates:4001
+msgid "enter apt mirror:"
+msgstr "introduzca la réplica de apt:"
+
+#. Type: string
+#. Description
+#: ../progress-linux.templates:4001
+msgid "Please specify the mirror to download packages from."
+msgstr "Por favor, indique la réplica desde donde descargar los paquetes."
+
+#. Type: string
+#. Description
+#: ../progress-linux.templates:4001
+msgid ""
+"If unsure, leave empty which will use the default mirror (https://deb.;
+"progress-linux.org/packages)."
+msgstr ""
+"Si no está seguro, puede dejarlo en blanco y se utilizará la réplica "
+"predeterminada («https://deb.progress-linux.org/packages»)."
diff -Nru progress-linux-20210101/debian/po/pt_BR.po 
progress-linux-20210101/debian/po/pt_BR.po
--- progress-linux-20210101/debian/po/pt_BR.po  1970-01-01 02:00:00.0 
+0200
+++ progress-linux-20210101/debian/po/pt_BR.po  2021-07-18 10:13:09.0 
+0300
@@ -0,0 +1,74 @@
+# Brazilian Portuguese debconf translation of progress-linux
+# Copyright (C) 2019 Jorge Neto 
+# Copyright (C) 2019 Adriano Rafael Gomes 
+# This file is distributed under the same license as the progress-linux 
package.
+msgid ""
+msgstr ""
+"Project-Id-Version: progress-linux\n"
+"Report-Msgid-Bugs-To: progress-li...@packages.debian.org\n"
+"POT-Creation-Date: 2019-11-18 17:31+0100\n"
+"PO-Revision-Date: 2019-12-20 14:36-0300\n"
+"Last-Translator: Jorge Neto  \n"
+"Language-Team: Brazilian Portuguese \n"
+"Language: pt_BR\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=2; plural=(n > 1);\n"
+
+#. Type: title
+#. Description
+#: ../progress-linux.templates:1001
+msgid "Progress Linux: Setup"
+msgstr "Progress Linux: Configuração"
+
+#. Type: multiselect
+#. Description
+#: ../progress-linux.templates:2001
+msgid "setup apt archives:"
+msgstr "configurar repositórios do apt:"
+
+#. Type: multiselect
+#. Description
+#: ../progress-linux.templates:2001
+msgid "Please select the apt archives to setup."
+msgstr "Por favor, selecione os repositórios do apt para configurar."
+
+#. Type: multiselect
+#. 

Bug#991313: unblock: qutebrowser/2.0.2-2

2021-07-20 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package qutebrowser

  * Apply patch to update documentation with regards to the #qutebrowser
IRC channel having moved from Freenode to Libera.Chat.
(change by Axel Beckert)

Documentation-only change.



Bug#991312: mini-dinstall: "incoming_permissions" parse value as decimal and not octal

2021-07-20 Thread Oron Peled
Package: mini-dinstall
Version: 0.7.0+nmu2
Severity: normal
Tags: patch

Dear Maintainer,

I've installed "mini-dinstall" on "bullseye" (which brought version 0.7.0)
I found out that my "incoming/" folder became inaccessible:
  - I've used permissions of 0755, to allow access from web-server scripts
  - The real permissions were very different
  - I found out the value (0755 or 0o755) was always interpreted as decimal.
  - As a workaround, I've set the value to 493 (which is decimal for 0755)

Analysing the code and testing demonstrated the followin:
  - It seems the breakage happened in commit dc580be8
  - In "mini-dinstall", line 247 of original code the parsing changed:
From:
   incoming_permissions = int(configp.get('DEFAULT', 
'incoming_permissions'), 8)
To:
   incoming_permissions = configp.getint('DEFAULT', 'incoming_permissions')
  - I.e: the convertion to base-8 was removed
  - But "ConfigParser.getint() does not handle number base.
  - This changed happend ~3 years ago, but "buster" had older version, so we
didn't notice this until now.

Fixing this is just one line (attaching a patch)

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

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

Versions of packages mini-dinstall depends on:
ii  apt-utils2.2.4
ii  python3  3.9.2-3
ii  python3-apt  2.2.1

Versions of packages mini-dinstall recommends:
ii  gpgv  2.2.27-2

Versions of packages mini-dinstall suggests:
ii  debian-keyring  2021.06.25

-- no debconf information
>From cd06abde9961b7d49a31664f8e2c1866ef560c39 Mon Sep 17 00:00:00 2001
From: Volodymyr Sarkisian 
Date: Tue, 20 Jul 2021 14:19:54 +0300
Subject: [PATCH] Fixed CBLOS-64905: mini-dinstall now uses octal permissions
 format

---
 debian/changelog | 7 +++
 mini-dinstall| 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index bf9c70c..97deb96 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mini-dinstall (0.7.0+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix CBLOS-64905: octal permissions representation now works again
+
+ -- Volodymyr Sarkisian   Tue, 20 Jul 2021 14:14:55 
+0300
+
 mini-dinstall (0.7.0+nmu1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/mini-dinstall b/mini-dinstall
index b0753fb..3d59358 100755
--- a/mini-dinstall
+++ b/mini-dinstall
@@ -249,7 +249,8 @@ else:
 sys.exit(1)
 
 if configp.has_option('DEFAULT', 'incoming_permissions'):
-incoming_permissions = configp.getint('DEFAULT', 'incoming_permissions')
+# Falling back to octal permissions representation
+incoming_permissions = int(configp.get('DEFAULT', 'incoming_permissions'), 
8)
 
 do_mkdir(toplevel_directory)
 dinstall_subdir = os.path.join(toplevel_directory, dinstall_subdir)
-- 
2.20.1



Bug#991311: manpages-fr-dev: French documentation translation update

2021-07-20 Thread Lucien Gentis
Package: manpages-fr-dev
Version: N/A
Severity: wishlist
Tags: patch l10n

Dear Maintainer,



*** patch-update.txt
Please find attached the French translation update, proofread by the
debian-l10n-french mailing list contributors.


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

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
# French translation of manpages
# This file is distributed under the same license as the manpages-l10n package.
# Copyright © of this file:
# Christophe Blaess , 1996-2003.
# Stéphan Rafin , 2002.
# Thierry Vignaud , 1999, 2002.
# François Micaux, 2002.
# Alain Portal , 2003-2008.
# Jean-Philippe Guérard , 2005-2006.
# Jean-Luc Coulon (f5ibh) , 2006-2007.
# Julien Cristau , 2006-2007.
# Thomas Huriaux , 2006-2008.
# Nicolas François , 2006-2008.
# Florentin Duneau , 2006-2010.
# Simon Paillard , 2006.
# Denis Barbier , 2006, 2010.
# David Prévot , 2010-2012, 2014.
# Frédéric Hantrais , 2013, 2014.
# Lucien Gentis , 2021.
msgid ""
msgstr ""
"Project-Id-Version: perkamon\n"
"POT-Creation-Date: 2020-03-15 09:45+01:00\n"
"PO-Revision-Date: 2021-07-07 14:39+0200\n"
"Last-Translator: Lucien Gentis \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Poedit 2.2.1\n"

#. type: TH
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "STRING"
msgstr "STRING"

#. type: TH
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "2019-03-06"
msgstr "6 mars 2019"

#. type: TH
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "Linux Programmer's Manual"
msgstr "Manuel du programmeur Linux"

#. type: SH
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "NAME"
msgstr "NOM"

#. type: Plain text
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
msgid ""
"stpcpy, strcasecmp, strcat, strchr, strcmp, strcoll, strcpy, strcspn, "
"strdup, strfry, strlen, strncat, strncmp, strncpy, strncasecmp, strpbrk, "
"strrchr, strsep, strspn, strstr, strtok, strxfrm, index, rindex - string "
"operations"
msgstr ""
"stpcpy, strcasecmp, strcat, strchr, strcmp, strcoll, strcpy, strcspn, "
"strdup, strfry, strlen, strncat, strncmp, strncpy, strncasecmp, strpbrk, "
"strrchr, strsep, strspn, strstr, strtok, strxfrm, index, rindex - Opérations "
"sur les chaînes de caractères"

#. type: SH
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "SYNOPSIS"
msgstr "SYNOPSIS"

#. type: Plain text
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
msgid "B<#include Estrings.hE>"
msgstr "B<#include Estrings.hE>"

#. type: TP
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "BIB<, const char *>IB<);>"
msgstr "BIB<, const char *>IB<);>"

#. type: Plain text
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
msgid "Compare the strings I and I ignoring case."
msgstr "Comparer les chaînes I et I sans tenir compte de la casse."

#. type: TP
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "BIB<, const char *>IB<, size_t 
>IB<);>"
msgstr "BIB<, const char *>IB<, size_t 
>IB<);>"

#. type: Plain text
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
msgid ""
"Compare the first I bytes of the strings I and I ignoring case."
msgstr ""
"Comparer les I premiers octets des chaînes I et I sans tenir "
"compte de la casse."

#. type: TP
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "BIB<, int >IB<);>"
msgstr "BIB<, int >IB<);>"

#. type: Plain text
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
msgid ""
"Return a pointer to the first occurrence of the character I in the string "
"I."
msgstr ""
"Renvoyer un pointeur sur la première occurrence du caractère I dans la "
"chaîne I."

#. type: TP
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "BIB<, int >IB<);>"
msgstr "BIB<, int >IB<);>"

#. type: Plain text
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
msgid ""
"Return a pointer to the last occurrence of the character I in the string "
"I."
msgstr ""
"Renvoyer un pointeur sur la dernière occurrence du caractère I dans la "
"chaîne I."

#. type: TP
#: archlinux debian-buster debian-unstable 

Bug#991310: unblock: libnet-freedb-perl/0.10-2

2021-07-20 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libnet-freedb-perl

  * Add a patch to change the default host from the defunct
freedb.freedb.org to gnudb.gnudb.org.
(change by gregor herrmann)

autopkgtest for libnet-freedb-perl/0.10-2: amd64: Pass, arm64: Pass, armhf: 
Pass, i386: Pass, ppc64el: Pass
diff -Nru libnet-freedb-perl-0.10/debian/changelog 
libnet-freedb-perl-0.10/debian/changelog
--- libnet-freedb-perl-0.10/debian/changelog2015-12-01 23:24:47.0 
+0200
+++ libnet-freedb-perl-0.10/debian/changelog2021-07-16 21:53:11.0 
+0300
@@ -1,3 +1,11 @@
+libnet-freedb-perl (0.10-2) unstable; urgency=medium
+
+  * Add a patch to change the default host from the defunct
+freedb.freedb.org to gnudb.gnudb.org.
+Thanks to Adrian Bunk for the bug report. (Closes: #991089)
+
+ -- gregor herrmann   Fri, 16 Jul 2021 20:53:11 +0200
+
 libnet-freedb-perl (0.10-1) unstable; urgency=medium
 
   * Team upload
diff -Nru 
libnet-freedb-perl-0.10/debian/patches/replace_freedb_with_gnudb.patch 
libnet-freedb-perl-0.10/debian/patches/replace_freedb_with_gnudb.patch
--- libnet-freedb-perl-0.10/debian/patches/replace_freedb_with_gnudb.patch  
1970-01-01 02:00:00.0 +0200
+++ libnet-freedb-perl-0.10/debian/patches/replace_freedb_with_gnudb.patch  
2021-07-16 21:53:11.0 +0300
@@ -0,0 +1,52 @@
+Description: replace default host freedb.freedb.org with gnudb.gnudb.org.
+ Also remove reference to inaccessible documentation, and fix the non-online
+ test which checks for the default host.
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/991089
+Author: gregor herrmann 
+Last-Update: 2021-07-16
+Forwarded: https://rt.cpan.org/Ticket/Display.html?id=137752
+Bug: https://rt.cpan.org/Ticket/Display.html?id=137752
+
+--- a/FreeDB.pm
 b/FreeDB.pm
+@@ -7,7 +7,7 @@
+ use File::Temp;
+ 
+ has hostname   => (is => 'ro', default => $ENV{HOSTNAME} // 
'unknown');
+-has remote_host=> (is => 'rw', default => 'freedb.freedb.org');
++has remote_host=> (is => 'rw', default => 'gnudb.gnudb.org');
+ has remote_port=> (is => 'rw', default => 8880);
+ has user   => (is => 'rw', default => $ENV{USER} // 
'unknown');
+ has timeout=> (is => 'rw', default => 120);
+@@ -449,7 +449,7 @@
+ 
+ 
+ new() creates and returns a new Net::FreeDB object that is connected
+-to either the given host or freedb.freedb.org as default.
++to either the given host or gnudb.gnudb.org as default.
+ 
+ =item lscat
+ 
+@@ -723,10 +723,6 @@
+ giving the correct drive number will return in an
+ accurate return.
+ 
+-=head1 Resources
+-The current version of the CDDB Server Protocol can be
+-found at: http://ftp.freedb.org/pub/freedb/latest/CDDBPROTO
+-
+ =head1 AUTHOR
+ David Shultz Edshu...@cpan.orge
+ Peter Pentchev Er...@ringlet.nete
+--- a/t/00-basic.t
 b/t/00-basic.t
+@@ -10,7 +10,7 @@
+ ok($freedb->hostname eq 'unknown', 'Error setting hostname');
+ }
+ 
+-ok($freedb->remote_host eq 'freedb.freedb.org', 'Error setting default host');
++ok($freedb->remote_host eq 'gnudb.gnudb.org', 'Error setting default host');
+ 
+ ok($freedb->remote_port == 8880, 'Error setting default port');
+ 
diff -Nru libnet-freedb-perl-0.10/debian/patches/series 
libnet-freedb-perl-0.10/debian/patches/series
--- libnet-freedb-perl-0.10/debian/patches/series   1970-01-01 
02:00:00.0 +0200
+++ libnet-freedb-perl-0.10/debian/patches/series   2021-07-16 
21:53:11.0 +0300
@@ -0,0 +1 @@
+replace_freedb_with_gnudb.patch


Bug#991185: systemd: 'systemctl start anacron.service' from emergency mode kills emergency shell

2021-07-20 Thread Zack Weinberg
On Tue, Jul 20, 2021 at 8:00 AM Michael Biebl  wrote:
> Am 16.07.21 um 21:09 schrieb Zack Weinberg:
> > Package: systemd
> > Version: 247.3-5
> > Severity: important
> > X-Debbugs-Cc: za...@panix.com
> >
> > Running ‘systemctl start anacron.service’ from the emergency shell
> > causes the emergency shell and all processes running inside it to be
> > killed; you get the “You are in emergency mode” banner again and are
> > re-prompted for the root password.
> >
> > I don’t know if this is a general problem with starting services from
> > emergency mode, or if it’s somehow specific to anacron.
>
> Can you provide a full journal -alb log after this has happened?

I don't use persistent journals so I will need to reproduce the
problem again, please stay tuned.

> Would be good to know, why you ended up in emergency mode.

I booted directly into emergency mode for low-level maintenance.

zw



Bug#991309: suggested fix

2021-07-20 Thread Christian Ehrhardt
Since there is no branch from debian/0.9.8-3 yet to propose against
here a suggested fix as a debdiff.

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd


fix-nftables-991309.debdiff
Description: Binary data


Bug#991308: openvswitch: CVE-2021-36980

2021-07-20 Thread Moritz Mühlenhoff
Source: openvswitch
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for openvswitch.

CVE-2021-36980[0]:
| Open vSwitch (aka openvswitch) 2.11.0 through 2.15.0 has a use-after-
| free in decode_NXAST_RAW_ENCAP (called from ofpact_decode and
| ofpacts_decode) during the decoding of a RAW_ENCAP action.

https://github.com/google/oss-fuzz-vulns/blob/main/vulns/openvswitch/OSV-2020-2197.yaml
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27851

Patches:
https://github.com/openvswitch/ovs/commit/38744b1bcb022c611712527f039722115300f58f
https://github.com/openvswitch/ovs/commit/65c61b0c23a0d474696d7b1cea522a5016a8aeb3
https://github.com/openvswitch/ovs/commit/6d67310f4d2524b466b98f05ebccc1add1e8cf35
https://github.com/openvswitch/ovs/commit/7774deede443e8b9102299efc869a52b65b2
https://github.com/openvswitch/ovs/commit/8ce8dc34b5f73b30ce0c1869af9947013c3c6575

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-36980
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36980

Please adjust the affected versions in the BTS as needed.



Bug#991309: nftables 0.9.8 regresses icmp rule deletion

2021-07-20 Thread Christian Ehrhardt
Package: nftables
Version: 0.9.8-3
Tags: fixed-in-experimental

Hi,
I wanted to raise awareness for an issue [1] that was originally filed
by Michael Biebl but not further pursued in the nftables package AFAICS.

In Debian CI that isn't obvious as the tests are all skipped
  
https://ci.debian.net/data/autopkgtest/testing/amd64/f/firewalld/13738304/log.gz
But the Ubuntu CI flags the issue
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/f/firewalld/20210510_135128_36f9c@/log.gz

I was looking into the case in [2] and found that in the meantime
there is a fix for that [3] available upstream.

I see that there is nftables 0.9.9-1~exp1 in experimental and I have
tagged this bug as fixed there.
Surely we would not want to move to 0.9.9 in the current release while
in the final freeze.
But given that it would be a regression for upgraders buster->bullseye
I wonder if the isolated patch [3] should maybe be applied.

I have done so in an Ubuntu PPA [4] and re-run the firewalld tests against it.
Those tests - and in general the issue of deleting too many icmp rules
- is fixed by that.

[1]: https://github.com/firewalld/firewalld/issues/752
[2]: https://bugs.launchpad.net/ubuntu/+source/nftables/+bug/1936902
[3]: 
https://git.netfilter.org/nftables/commit/?id=533565244d88a818d8828ebabd7625e5a8a4c374
[4]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4626/+packages

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd



Bug#991300: 1:0.4.30-1 is FTFBS on s390x (bytes per pixel in header is 4096 instead of 16)

2021-07-20 Thread Simon McVittie
Control: forwarded -1 https://gitlab.gnome.org/GNOME/gegl/-/issues/289
Control: severity -1 serious
Control: tags -1 + ftbfs sid bookworm

On Tue, 20 Jul 2021 at 11:14:32 +0200, Christian Ehrhardt wrote:
> I have reported the issue upstream at:
>   https://gitlab.gnome.org/GNOME/gegl/-/issues/289

When opening new bugs, you can record this in a machine-readable way by
mentioning it in the pseudo-header:

Package: gegl
Version: 1:0.4.30-1
Forwarded: https://gitlab.gnome.org/GNOME/gegl/-/issues/289
(etc.)

I'm marking this as release-critical for Debian 12, but not for Debian
11, since testing has an older version which is unaffected.

This seems very likely to be endianness-related: s390x is the only
big-endian release architecture remaining in Debian, but the powerpc and
ppc64 ports (which are also BE) also failed to build this version.

smcv



Bug#991307: aspell: CVE-2019-25051

2021-07-20 Thread Moritz Mühlenhoff
Source: aspell
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for aspell.

CVE-2019-25051[0]:
| objstack in GNU Aspell 0.60.8 has a heap-based buffer overflow in
| acommon::ObjStack::dup_top (called from acommon::StringMap::add and
| acommon::Config::lookup_list).

https://github.com/google/oss-fuzz-vulns/blob/main/vulns/aspell/OSV-2020-521.yaml
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18462

Patch:
https://github.com/gnuaspell/aspell/commit/0718b375425aad8e54e1150313b862e4c6fd324a

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-2019-25051
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25051

Please adjust the affected versions in the BTS as needed.



Bug#991185: systemd: 'systemctl start anacron.service' from emergency mode kills emergency shell

2021-07-20 Thread Michael Biebl

Am 16.07.21 um 21:09 schrieb Zack Weinberg:

Package: systemd
Version: 247.3-5
Severity: important
X-Debbugs-Cc: za...@panix.com

Running ‘systemctl start anacron.service’ from the emergency shell
causes the emergency shell and all processes running inside it to be
killed; you get the “You are in emergency mode” banner again and are
re-prompted for the root password.

I don’t know if this is a general problem with starting services from
emergency mode, or if it’s somehow specific to anacron.



Can you provide a full journal -alb log after this has happened?

Would be good to know, why you ended up in emergency mode.

Michael



Bug#991306: dirmngr(8) man page documents obsolete keys.gnupg.net

2021-07-20 Thread Vincent Lefevre
Package: dirmngr
Version: 2.2.27-2
Severity: minor
Tags: upstream
Forwarded: https://dev.gnupg.org/T5527

The dirmngr(8) man page says:

  The keyserver hkp://keys.gnupg.net uses round robin DNS to give
  a different keyserver each time you use it.

However, this is obsolete and no longer works: "gpg --recv-keys ..."
yields an error "gpg: keyserver receive failed: No name".

This is confirmed here:

  
https://stackoverflow.com/questions/66217436/gpg-keyserver-receive-failed-no-name

I've reported a bit more general bug at https://dev.gnupg.org/T5527
about keys.gnupg.net.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 dirmngr depends on:
ii  adduser  3.118
ii  gpgconf  2.2.27-2
ii  init-system-helpers  1.60
ii  libassuan0   2.5.4-1
ii  libc62.31-13
ii  libgcrypt20  1.8.7-6
ii  libgnutls30  3.7.1-5
ii  libgpg-error01.38-2
ii  libksba8 1.5.0-3
ii  libldap-2.4-22.4.57+dfsg-3
ii  libnpth0 1.6-3
ii  lsb-base 11.1.0

Versions of packages dirmngr recommends:
ii  gnupg  2.2.27-2

Versions of packages dirmngr suggests:
ii  dbus-user-session  1.12.20-2
ii  libpam-systemd 247.3-5
pn  pinentry-gnome3
pn  tor

-- no debconf information

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



Bug#991295: profanity: Update upstream repo link

2021-07-20 Thread bert
Package: profanity
Severity: minor
X-Debbugs-Cc: b...@dismail.de

Dear Maintainer,
uscan still uses the old repo URL.
Here is the new one: https://github.com/profanity-im/profanity/releases

Thanks!



-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (90, 'unstable'), 
(10, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, 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 profanity depends on:
ii  libc6  2.31-12
ii  libcurl3-gnutls7.74.0-1.3+b1
ii  libgcrypt201.8.7-6
ii  libglib2.0-0   2.66.8-1
ii  libgpgme11 1.14.0-1+b2
ii  libgtk-3-0 3.24.24-4
ii  libncursesw6   6.2+20201114-2
ii  libnotify4 0.7.9-3
pn  libotr5
ii  libpython3.9   3.9.2-1
ii  libreadline8   8.1-1
ii  libsignal-protocol-c2.3.2  2.3.3-1
ii  libsqlite3-0   3.34.1-3
pn  libstrophe0
ii  libtinfo6  6.2+20201114-2
ii  libx11-6   2:1.7.1-1
ii  libxss11:1.2.3-1

profanity recommends no packages.

profanity suggests no packages.



Bug#991305: unblock: lshw/02.18.85-0.7

2021-07-20 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lshw

  * Backport upstream fix for floating point exception on invalid FAT,
thanks to Dave Gomboc and Bernhard Übelacker. (Closes: #946940)
diff -Nru lshw-02.18.85/debian/changelog lshw-02.18.85/debian/changelog
--- lshw-02.18.85/debian/changelog  2021-01-04 00:41:23.0 +0200
+++ lshw-02.18.85/debian/changelog  2021-07-17 20:19:28.0 +0300
@@ -1,3 +1,11 @@
+lshw (02.18.85-0.7) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for floating point exception on invalid FAT,
+thanks to Dave Gomboc and Bernhard Übelacker. (Closes: #946940)
+
+ -- Adrian Bunk   Sat, 17 Jul 2021 20:19:28 +0300
+
 lshw (02.18.85-0.6) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lshw-02.18.85/debian/patches/0001-fix-755-handle-invalid-FAT.patch 
lshw-02.18.85/debian/patches/0001-fix-755-handle-invalid-FAT.patch
--- lshw-02.18.85/debian/patches/0001-fix-755-handle-invalid-FAT.patch  
1970-01-01 02:00:00.0 +0200
+++ lshw-02.18.85/debian/patches/0001-fix-755-handle-invalid-FAT.patch  
2021-07-17 20:19:05.0 +0300
@@ -0,0 +1,41 @@
+From 89b3b6b9ed03f22ca98954712db5a90acf2c6755 Mon Sep 17 00:00:00 2001
+From: Lyonel Vincent 
+Date: Sat, 28 Dec 2019 00:02:44 +0100
+Subject: fix #755: handle invalid FAT
+
+check that sectors_per_cluster!=0
+---
+ src/core/fat.cc | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/src/core/fat.cc b/src/core/fat.cc
+index e68aea6..41b0001 100644
+--- a/src/core/fat.cc
 b/src/core/fat.cc
+@@ -186,11 +186,6 @@ bool scan_fat(hwNode & n, source & id)
+   if (vs.heads == 0)
+   return false;
+ 
+-  /* cluster size check */
+-  if (vs.sectors_per_cluster == 0 ||
+-  (vs.sectors_per_cluster & (vs.sectors_per_cluster-1)))
+-  return false;
+-
+   /* media check */
+   if (vs.media < 0xf8 && vs.media != 0xf0)
+   return false;
+@@ -200,6 +195,11 @@ bool scan_fat(hwNode & n, source & id)
+   return false;
+ 
+ valid:
++  /* cluster size check */
++  if (vs.sectors_per_cluster == 0 ||
++  (vs.sectors_per_cluster & (vs.sectors_per_cluster-1)))
++  return false;
++
+   /* sector size check */
+   sector_size_bytes = le_short(_size_bytes);
+   if (sector_size_bytes != 0x200 && sector_size_bytes != 0x400 &&
+-- 
+2.20.1
+
diff -Nru lshw-02.18.85/debian/patches/series 
lshw-02.18.85/debian/patches/series
--- lshw-02.18.85/debian/patches/series 2020-04-26 14:43:52.0 +0300
+++ lshw-02.18.85/debian/patches/series 2021-07-17 20:19:28.0 +0300
@@ -10,3 +10,4 @@
 add-missing-ethlink-standards.patch
 cross.patch
 #revert-Fix_JSON_output_format.patch
+0001-fix-755-handle-invalid-FAT.patch


Bug#991304: unblock: eboard/1.1.3-0.4

2021-07-20 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package eboard

  * Add upstream fix for segfault on engine selection,
thanks to Eric Cooper and Bernhard Übelacker. (Closes: #962627)
diff -Nru eboard-1.1.3/debian/changelog eboard-1.1.3/debian/changelog
--- eboard-1.1.3/debian/changelog   2019-05-17 16:17:10.0 +0300
+++ eboard-1.1.3/debian/changelog   2021-07-17 21:48:28.0 +0300
@@ -1,3 +1,11 @@
+eboard (1.1.3-0.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for segfault on engine selection,
+thanks to Eric Cooper and Bernhard Übelacker. (Closes: #962627)
+
+ -- Adrian Bunk   Sat, 17 Jul 2021 21:48:28 +0300
+
 eboard (1.1.3-0.3) unstable; urgency=medium
 
   [ Gianfranco Costamagna ]
diff -Nru 
eboard-1.1.3/debian/patches/0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch
 
eboard-1.1.3/debian/patches/0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch
--- 
eboard-1.1.3/debian/patches/0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch
 1970-01-01 02:00:00.0 +0200
+++ 
eboard-1.1.3/debian/patches/0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch
 2021-07-17 21:48:09.0 +0300
@@ -0,0 +1,21 @@
+From ed33049aff2cefd7508bcda8ab738b8ec871c948 Mon Sep 17 00:00:00 2001
+From: Christian Palazzo 
+Date: Thu, 30 Apr 2020 00:43:21 +0200
+Subject: https://bugs.launchpad.net/ubuntu/+source/eboard/+bug/1306419
+
+diff --git a/proto_xboard.cc b/proto_xboard.cc
+index ba48aa1..edabe1b 100644
+--- a/proto_xboard.cc
 b/proto_xboard.cc
+@@ -1083,7 +1083,7 @@ void CraftyProtocol::readDialog() {
+   snprintf(EngineCommandLine,512,"crafty bookpath=%s logpath=%s tbpath=%s",
+  BookPath,LogPath,LogPath);
+   if (!global.env.Home.empty())
+-snprintf(EngineRunDir,512,"%s/.eboard/craftylog",global.env.Home.c_str());
++snprintf(EngineRunDir,256,"%s/.eboard/craftylog",global.env.Home.c_str());
+   else
+ strcpy(EngineRunDir,"/tmp");
+ 
+-- 
+2.20.1
+
diff -Nru eboard-1.1.3/debian/patches/series eboard-1.1.3/debian/patches/series
--- eboard-1.1.3/debian/patches/series  2019-05-17 16:16:10.0 +0300
+++ eboard-1.1.3/debian/patches/series  2021-07-17 21:48:28.0 +0300
@@ -2,3 +2,4 @@
 hungarian-translation.patch
 90_respect_deb_build_options.patch
 ld-as-needed.patch
+0001-https-bugs.launchpad.net-ubuntu-source-eboard-bug-13.patch


Bug#991303: unblock: scottfree/1.14-10.1

2021-07-20 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package scottfree

  * Add patch from Bernhard Übelacker to fix crash when restoring
from save-file. (Closes: #968375)
diff -Nru scottfree-1.14/debian/changelog scottfree-1.14/debian/changelog
--- scottfree-1.14/debian/changelog 2017-01-20 13:52:21.0 +0200
+++ scottfree-1.14/debian/changelog 2021-07-17 22:54:45.0 +0300
@@ -1,3 +1,11 @@
+scottfree (1.14-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Bernhard Übelacker to fix crash when restoring
+from save-file. (Closes: #968375)
+
+ -- Adrian Bunk   Sat, 17 Jul 2021 22:54:45 +0300
+
 scottfree (1.14-10) unstable; urgency=low
 
   * Team upload.
diff -Nru scottfree-1.14/debian/patches/04_968375.patch 
scottfree-1.14/debian/patches/04_968375.patch
--- scottfree-1.14/debian/patches/04_968375.patch   1970-01-01 
02:00:00.0 +0200
+++ scottfree-1.14/debian/patches/04_968375.patch   2021-07-17 
22:53:59.0 +0300
@@ -0,0 +1,37 @@
+Description: Include time.h, fix two warnings in fscanf calls.
+
+Author: Bernhard Übelacker 
+Bug-Debian: https://bugs.debian.org/968375
+Forwarded: no
+Last-Update: 2020-08-14
+
+Index: scottfree-1.14/ScottCurses.c
+===
+--- scottfree-1.14.orig/ScottCurses.c
 scottfree-1.14/ScottCurses.c
+@@ -22,6 +22,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "Scott.h"
+ 
+@@ -239,7 +240,7 @@ void LoadDatabase(FILE *f, int loud)
+ /* Load the header */
+   
+   if(fscanf(f,"%*d %d %d %d %d %d %d %d %d %d %d %d",
+-  ,,,)<10)
++  ,,)<10)
+   Fatal("Invalid database(bad header)");
+   GameHeader.NumItems=ni;
+   Items=(Item *)MemAlloc(sizeof(Item)*(ni+1));
+@@ -693,7 +694,7 @@ void LoadGame(char *name)
+   {
+   fscanf(f,"%d %d\n",[ct],[ct]);
+   }
+-  fscanf(f,"%ld %d %hd %d %d %hd\n",
++  fscanf(f,"%ld %hd %hd %d %d %hd\n",
+   ,
+   );
+   /* Backward compatibility */
diff -Nru scottfree-1.14/debian/patches/series 
scottfree-1.14/debian/patches/series
--- scottfree-1.14/debian/patches/series2017-01-20 13:48:06.0 
+0200
+++ scottfree-1.14/debian/patches/series2021-07-17 22:54:42.0 
+0300
@@ -1,3 +1,4 @@
 01_makefile.diff
 02_scottcurses_includes.diff
 03_clang.diff
+04_968375.patch


Bug#991302: unblock: smem/1.5-1.1

2021-07-20 Thread Adrian Bunk
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package smem

  * Add patch from Marco Paganini for Python 3 incompatibility
in "smem --bar". (Closes: #958129)

Regression from buster caused by the switch to Python 3.
diff -Nru smem-1.5/debian/changelog smem-1.5/debian/changelog
--- smem-1.5/debian/changelog   2020-01-05 05:57:10.0 +0200
+++ smem-1.5/debian/changelog   2021-07-17 22:47:50.0 +0300
@@ -1,3 +1,11 @@
+smem (1.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Marco Paganini for Python 3 incompatibility
+in "smem --bar". (Closes: #958129)
+
+ -- Adrian Bunk   Sat, 17 Jul 2021 22:47:50 +0300
+
 smem (1.5-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru smem-1.5/debian/patches/series smem-1.5/debian/patches/series
--- smem-1.5/debian/patches/series  2020-01-05 05:57:10.0 +0200
+++ smem-1.5/debian/patches/series  2021-07-17 22:47:40.0 +0300
@@ -1,3 +1,4 @@
 manpage.patch
 buildsystem.patch
 smem-py3k.patch
+smem-xrange-fix.patch
diff -Nru smem-1.5/debian/patches/smem-xrange-fix.patch 
smem-1.5/debian/patches/smem-xrange-fix.patch
--- smem-1.5/debian/patches/smem-xrange-fix.patch   1970-01-01 
02:00:00.0 +0200
+++ smem-1.5/debian/patches/smem-xrange-fix.patch   2021-07-17 
22:47:10.0 +0300
@@ -0,0 +1,11 @@
+--- original/smem  2020-04-18 12:20:22.524849106 -0700
 fixed/smem 2020-04-18 12:19:24.912251338 -0700
+@@ -646,7 +646,7 @@
+ 
+ pl = []
+ ind = numpy.arange(len(l))
+-for n in xrange(len(rc)):
++for n in range(len(rc)):
+ pl.append(pylab.bar(ind + offset + width * n,
+  [x[1][rc[n]] for x in l], width, color=gc(n)))
+ 


Bug#991299: Acknowledgement (clamav-freshclam: Default download timeout short, retrying download endlessly)

2021-07-20 Thread Mara Sophie Grosch

Hi again and sorry for the noise,

I checked the other open bug reports before, but somehow missed this to
be partly-duplicate of #690788

The problem is the same, the proposed "solutions" are different.
Resuming the partial download is probably a real solution, while my
proposals are easy, but more "workaroundy"

Anyway, just wanted to add the link to the existing bug



Bug#991301: syncthing-relaysrv: Security issue due to CVE-2021-21404 for all versions <1.15.0

2021-07-20 Thread Pierre Bernhardt
Package: syncthing-relaysrv
Version: <1.15.0
Severity: normal
Tags: newcomer

Dear Maintainer,

This is a copy of the text from CVE-2021-21404 because I cannot see that the
problem is allready fixed in downstream versions:
Syncthing is a continuous file synchronization program. In Syncthing before
version 1.15.0, the relay server `strelaysrv` can be caused to crash and exit
by sending a relay message with a negative length field. Similarly, Syncthing
itself can crash for the same reason if given a malformed message from a
malicious relay server when attempting to join the relay. Relay joins are
essentially random (from a subset of low latency relays) and Syncthing will by
default restart when crashing, at which point it's likely to pick another non-
malicious relay. This flaw is fixed in version 1.15.0.

It is not installed on my system but of relevant security issue it should be
fixed on all versions.



Bug#928925: [lilypond] Text much too big, rendering unusable output

2021-07-20 Thread lestert



This seems to have been fixed in lilypond 2.22.1.



Bug#991270: unblock: suricata/6.0.1-3

2021-07-20 Thread Graham Inggs
Control: tags -1 + moreinfo confirmed

Hi Sascha

On Mon, 19 Jul 2021 at 13:57, Sascha Steinbiss  wrote:
> I have added a debdiff to this bugreport that illustrates the
> situation. I could upload to unstable anytime. Please let me know if the
> fix is appropriate and I will initiate an upload if confirmed.

Please go ahead and upload to unstable, then remove the moreinfo tag
once it has built.

Regards
Graham



Bug#991300: 1:0.4.30-1 is FTFBS on s390x (bytes per pixel in header is 4096 instead of 16)

2021-07-20 Thread Christian Ehrhardt
Package: gegl
Version: 1:0.4.30-1

Hi,
I saw this build fail in Debian and Ubuntu today:
https://buildd.debian.org/status/fetch.php?pkg=gegl=s390x=1%3A0.4.30-1=1626634928=0
https://launchpadlibrarian.net/549105404/buildlog_ubuntu-impish-s390x.gegl_1%3A0.4.30-1_BUILDING.txt.gz

It comes down to two breaking testcases

118/249 gegl:composition / hdr_color FAIL 0.67s (exit status 250 or
signal 122 SIGinvalid)
150/249 gegl:composition / rgb_params FAIL 0.67s (exit status 250 or
signal 122 SIGinvalid)

I have found that on s390x the data gets corrupted and the header
eventually reports 4096 bytes per pixel (instead of the 16 it should
be).
That then breaks the imgcmp program used in the tests.

I have reported the issue upstream at:
  https://gitlab.gnome.org/GNOME/gegl/-/issues/289

The same issue is tracked in Ubuntu as:
  https://bugs.launchpad.net/gegl/+bug/1936901

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd



Bug#991299: clamav-freshclam: Default download timeout short, retrying download endlessly

2021-07-20 Thread Mara Sophie Grosch
Package: clamav-freshclam
Version: 0.103.2+dfsg-2
Severity: normal

Dear Maintainer,

yesterday I noticed my laptop having a lot of internet traffic from
cloudflare, but could not find what was the reason for it. Today I
enabled IP accounting and while looking at the journal (to check if a
`daemon-reload` is enough), I saw `freshclam` warning about missed
timeouts and retried downloads.

After stopping the `clamav-freshclam.service` and doing a manual
`sudo freshclam`, I saw the problem: it's configured by default to
timeout the download after 30s and then retries to download.

I'm currently at a location with a not-very-fast internet connection, so
the 30s just are not enough time to download the ~160MB it wanted to
retrieve.

I changed the ReceiveTimeout from 30 to 120, this allowed me to download
the updated database with my current connection.

I'd suggest any or both of these changes:

   * increase default timeout, best by not setting one at all
   * do not retry immediately after a missed timeout

Some days ago I used a metered connection. This only slows down after
the allowed data volume is used up, but maybe it was faster used up
because of this - so can be quite frustrating to users, especially since
it happens in the background.

Having a reverse DNS for the IP would have helped a bit, but since it's
cloudflare, it probably isn't used for clamav database only, so the info
it can give is limited..

Thank you for putting your time into this and best regards
Mara Sophie Grosch


-- Package-specific info:
--- configuration ---
# Automatically created by the clamav-freshclam postinst
# Comments will get lost when you reconfigure the clamav-freshclam package

DatabaseOwner clamav
UpdateLogFile /var/log/clamav/freshclam.log
LogVerbose false
LogSyslog false
LogFacility LOG_LOCAL6
LogFileMaxSize 0
LogRotate true
LogTime true
Foreground false
Debug false
MaxAttempts 5
DatabaseDirectory /var/lib/clamav
DNSDatabaseInfo current.cvd.clamav.net
ConnectTimeout 30
ReceiveTimeout 120
TestDatabases yes
ScriptedUpdates yes
CompressLocalDatabase no
Bytecode true
NotifyClamd /etc/clamav/clamd.conf
# Check for new database 24 times a day
Checks 24
DatabaseMirror db.local.clamav.net
DatabaseMirror database.clamav.net

--- data dir ---
total 342204
-rw-r--r-- 1 clamav clamav   1438720 May 31 17:48 bytecode.cld
-rw-r--r-- 1 clamav clamav 180754944 Jul 19 11:01 daily.cld
-rw-r--r-- 1 clamav clamav 168205379 Jul 20 10:57 main.cvd
-rw--- 1 clamav clamav69 Jul 17 16:03 mirrors.dat

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 clamav-freshclam depends on:
ii  clamav-base0.103.2+dfsg-2
ii  debconf [debconf-2.0]  1.5.75
ii  dpkg   1.20.9
ii  libc6  2.31-12
ii  libclamav9 0.103.2+dfsg-2
ii  logrotate  3.18.0-2
ii  lsb-base   11.1.0
ii  procps 2:3.3.17-5
ii  ucf3.0043

Versions of packages clamav-freshclam recommends:
ii  ca-certificates  20210119

Versions of packages clamav-freshclam suggests:
ii  apparmor 2.13.6-10
pn  clamav-docs  

-- debconf information excluded



Bug#991298: unblock: pillow/8.1.2+dfsg-0.3

2021-07-20 Thread Neil Williams
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pillow

8.1.2+dfsg-0.3 includes fix for CVE-2021-34552

unblock pillow/8.1.2+dfsg-0.3
diffstat for pillow-8.1.2+dfsg pillow-8.1.2+dfsg

 changelog|8 
 patches/CVE-2021-34552.patch |   40 
 patches/series   |1 +
 3 files changed, 49 insertions(+)

diff -Nru pillow-8.1.2+dfsg/debian/changelog pillow-8.1.2+dfsg/debian/changelog
--- pillow-8.1.2+dfsg/debian/changelog  2021-06-13 17:11:04.0 +0100
+++ pillow-8.1.2+dfsg/debian/changelog  2021-07-19 09:52:20.0 +0100
@@ -1,3 +1,11 @@
+pillow (8.1.2+dfsg-0.3) unstable; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * CVE-2021-34552 - Replace sprintf with snprintf. Backport upstream change
+from 8.3 to 8.1. 
+
+ -- Neil Williams   Mon, 19 Jul 2021 09:52:20 +0100
+
 pillow (8.1.2+dfsg-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch 
pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch
--- pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch   1970-01-01 
01:00:00.0 +0100
+++ pillow-8.1.2+dfsg/debian/patches/CVE-2021-34552.patch   2021-07-19 
09:51:59.0 +0100
@@ -0,0 +1,40 @@
+From 5f4504bb03f4edeeef8c2633dc5ba03a4c2a8a97 Mon Sep 17 00:00:00 2001
+From: Andrew Murray 
+Date: Tue, 15 Jun 2021 15:14:26 +1000
+Subject: [PATCH 1/2] Limit sprintf modes to 10 characters
+
+From 518ee3722a99d7f7d890db82a20bd81c1c0327fb Mon Sep 17 00:00:00 2001
+From: Andrew Murray 
+Date: Wed, 30 Jun 2021 23:47:10 +1000
+Subject: [PATCH 2/2] Use snprintf instead of sprintf
+
+* https://github.com/python-pillow/Pillow/pull/5567/files
+* Replace sprintf with snprintf in src/libImaging/Convert.c
+
+---
+--- a/src/libImaging/Convert.c
 b/src/libImaging/Convert.c
+@@ -1664,9 +1664,8 @@
+ #ifdef notdef
+ return (Imaging) ImagingError_ValueError("conversion not supported");
+ #else
+-static char buf[256];
+-/* FIXME: may overflow if mode is too large */
+-sprintf(buf, "conversion from %s to %s not supported", imIn->mode, 
mode);
++static char buf[100];
++snprintf(buf, 100, "conversion from %.10s to %.10s not supported", 
imIn->mode, mode);
+ return (Imaging) ImagingError_ValueError(buf);
+ #endif
+ }
+@@ -1724,9 +1723,8 @@
+ }
+ #else
+ {
+-  static char buf[256];
+-  /* FIXME: may overflow if mode is too large */
+-  sprintf(buf, "conversion from %s to %s not supported in 
convert_transparent", imIn->mode, mode);
++  static char buf[100];
++  snprintf(buf, 100, "conversion from %.10s to %.10s not supported in 
convert_transparent", imIn->mode, mode);
+   return (Imaging) ImagingError_ValueError(buf);
+ }
+ #endif
diff -Nru pillow-8.1.2+dfsg/debian/patches/series 
pillow-8.1.2+dfsg/debian/patches/series
--- pillow-8.1.2+dfsg/debian/patches/series 2021-06-13 17:10:51.0 
+0100
+++ pillow-8.1.2+dfsg/debian/patches/series 2021-07-19 09:45:27.0 
+0100
@@ -7,3 +7,4 @@
 CVE-2021-28676.patch
 CVE-2021-28677.patch
 CVE-2021-28678.patch
+CVE-2021-34552.patch


Bug#991285: unblock: strip-nondeterminism/1.12-0.1

2021-07-20 Thread Chris Lamb
Holger Levsen wrote:

> strip-nondeterminism (1.12.0-1) unstable; urgency=medium
>
>   [ Chris Lamb ]
>   * Support normalising Python "pyzip" files -- ie. zip-compressed .py files
> with a regular Python shebang. (Closes:  
> reproducible-builds/strip-nondeterminism#18)
>   * Drop single-debian-patch, etc.
>
>   [ Bernhard M. Wiedemann ]
>   * Move exception handling closer to call using perl's "//" operator.

As the author/merger of these changes, I would support an unblock and
have no reason to suspect that this might cause a regression,
especially given the codepaths that were modified.

However, the problems that this version fixes are relatively minor and
were actually to address issues that were initially discovered in
openSUSE, not Debian. They do affect Debian, but this remark provides
some insight on the impact of the issue in Debian itself.

However, as Holger mentions, the strongest argument for an unblock is
the following:

> Rather obviously this more or less against the freeze guidelines but given the
> fact that it's been used in many bullseye builds during the freeze  [...]

Either way though, it's always nice to minimise the diff, but I would
perfectly understand if this is rather too late.


Regards,

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



Bug#991297: rtw_8821ce does not work in debian 11

2021-07-20 Thread Michele Bucca
Package: firmware-realtek
Version 20210315-2

I'm testing debian bullseye and I've noticed that despite the firmware
of the wireless card Realtek RTL8821ce being added to the package, it
is still not working.

I downloaded the ISO debian-live-blsy-DI-rc2-amd64-xfce+nonfree.iso from

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2-live+nonfree/amd64/iso-hybrid/debian-live-blsy-DI-rc2-amd64-xfce+nonfree.iso

and when I boot the system the Wireless card is not detected by Network Manager.

if I type dmesg -l err in the terminal I get the following error message:

[8.123230] rtw_8821ce :03:00.0: rfe 2 isn't supported
[8.123394] rtw_8821ce :03:00.0: failed to setup chip efuse info
[8.123396] rtw_8821ce :03:00.0: failed to setup chip information

this problem does not exist in Ubuntu 21.04, when my wireless card is
detected out of the box and works fine.



Bug#991296: Should deltachat-core be shipped in bullseye?

2021-07-20 Thread Adrian Bunk
Source: deltachat-core
Version: 0.45.0+ds-1
Severity: serious

deltachat-core was never part of a stable release before,
and looking at #991284 it doesn't sound as if shipping
it in bullseye would be beneficial.



Bug#991274: Package libldap-2.4-2 was built without LDAP_CONNECTIONLESS

2021-07-20 Thread Gerald Vincent
Hi Quanah, 

Yes, I looked for possible setting to keep old behaviour, but i found nothing 
for now. 

I agree sssd team should provide this if connectionless is still not supported 
by openldap. 

Thanks, 
Gérald 



Bug#991292: dist-upgrade interruption leaves hold on freedombox package

2021-07-20 Thread James Valleroy
Package: freedombox
Version: 21.4.3
Severity: important
X-Debbugs-Cc: jvalle...@mailbox.org

Using freedombox from buster-backports (21.4.2~bpo10+1) on Lime2
hardware, I started a test of the dist-upgrade feature, using the
"--test" flag to perform dist-upgrade to bullseye:

# /usr/share/plinth/actions/upgrades start-dist-upgrade --test

After several hours, I found the process had been interrupted. By
running the same command again, it was able to complete the upgrades.

The freedombox dist-upgrade feature normally sets an apt-mark hold on
the freedombox package, to prevent the system from becoming
unreachable. The hold is set and removed within a try/finally
block.

However, at the end of my test, the hold was left on the freedombox
package.  Most like this is because the upgrade process was killed, so
the finally block will not be run, leaving the hold in place.

The impact is that if FreedomBox users rely on the automatic
dist-upgrade feature, there is a chance that after it completes, they
will need to manually remove the hold on the freedombox package.



Bug#991294: libgc FTCBFS for nios2: symbol differences

2021-07-20 Thread Helmut Grohne
Source: libgc
Version: 1:8.0.4-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libgc fails to cross build from source for nios2 due to symbol
differences. A closer look reveals that nios2 is one of the few
architectures where the cross build does not enable the use of atomic
builtins, but a native build does. Once enabled, we get a very different
and larger pile of symbol differences that look much more reasonable.
Looks like the previous symbol update wasn't correct. Please consider
applying the attached patch to fix that.

Helmut
diff --minimal -Nru libgc-8.0.4/debian/changelog libgc-8.0.4/debian/changelog
--- libgc-8.0.4/debian/changelog2020-12-06 12:44:00.0 +0100
+++ libgc-8.0.4/debian/changelog2021-07-20 06:30:56.0 +0200
@@ -1,3 +1,10 @@
+libgc (1:8.0.4-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Also use atomic builtins on nios2 and adapt symbol file. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 20 Jul 2021 06:30:56 +0200
+
 libgc (1:8.0.4-3) unstable; urgency=medium
 
   * Fix cross/native difference: explicitly disable usage of
diff --minimal -Nru libgc-8.0.4/debian/libgc1.symbols 
libgc-8.0.4/debian/libgc1.symbols
--- libgc-8.0.4/debian/libgc1.symbols   2020-10-27 14:07:51.0 +0100
+++ libgc-8.0.4/debian/libgc1.symbols   2021-07-20 06:30:54.0 +0200
@@ -4,8 +4,8 @@
  (arch=kfreebsd-amd64 kfreebsd-i386)GC_FreeBSDGetDataStart@Base 1:7.2d
  (arch=sparc sparc64)GC_SysVGetDataStart@Base 1:7.2d
  GC_abort_on_oom@Base 1:8.0
- (arch=!nios2 !sh4)GC_acquire_mark_lock@Base 1:8.0
- (arch=!nios2 !sh4)GC_active_count@Base 1:8.0
+ (arch=!sh4)GC_acquire_mark_lock@Base 1:8.0
+ (arch=!sh4)GC_active_count@Base 1:8.0
  GC_add_ext_descriptor@Base 1:7.2d
  GC_add_map_entry@Base 1:7.2d
  GC_add_roots@Base 1:7.2d
@@ -53,7 +53,7 @@
  GC_build_fl@Base 1:7.2d
  GC_build_fl_clear2@Base 1:7.2d
  GC_build_fl_clear4@Base 1:7.2d
- (arch=!nios2 !sh4)GC_bytes_allocd_tmp@Base 1:8.0
+ (arch=!sh4)GC_bytes_allocd_tmp@Base 1:8.0
  GC_bytes_found@Base 1:7.2d
  GC_call_with_alloc_lock@Base 1:7.2d
  GC_call_with_gc_active@Base 1:7.2d
@@ -146,8 +146,8 @@
  GC_do_blocking@Base 1:7.2d
  GC_do_blocking_inner@Base 1:7.2d
  GC_do_enumerate_reachable_objects@Base 1:7.6.4
- (arch=!nios2 !sh4)GC_do_local_mark@Base 1:8.0
- (arch=!nios2 !sh4)GC_do_parallel_mark@Base 1:8.0
+ (arch=!sh4)GC_do_local_mark@Base 1:8.0
+ (arch=!sh4)GC_do_parallel_mark@Base 1:8.0
  GC_dont_expand@Base 1:7.2d
  GC_dont_gc@Base 1:7.2d
  GC_dont_precollect@Base 1:7.2d
@@ -194,8 +194,8 @@
  (arch=!arm64 !nios2 !mips !mips64el !mipsel !riscv64 !s390 
!s390x)GC_find_limit_with_bound@Base 1:7.2d
  GC_findleak_delay_free@Base 1:7.2d
  GC_finish_collection@Base 1:7.2d
- (arch=!nios2 !sh4)GC_first_nonempty@Base 1:8.0
- (arch=!nios2 !sh4)GC_fl_builder_count@Base 1:8.0
+ (arch=!sh4)GC_first_nonempty@Base 1:8.0
+ (arch=!sh4)GC_fl_builder_count@Base 1:8.0
  GC_fnlz_roots@Base 1:7.6.4
  GC_fo_entries@Base 1:7.2d
  GC_force_unmap_on_gcollect@Base 1:7.2d
@@ -295,9 +295,9 @@
  GC_hblkfreelist@Base 1:7.2d
  GC_header_cache_miss@Base 1:7.2d
  GC_heapsize_at_forced_unmap@Base 1:7.6.4
- (arch=!nios2 !sh4)GC_help_marker@Base 1:8.0
- (arch=!nios2 !sh4)GC_help_wanted@Base 1:8.0
- (arch=!nios2 !sh4)GC_helper_count@Base 1:8.0
+ (arch=!sh4)GC_help_marker@Base 1:8.0
+ (arch=!sh4)GC_help_wanted@Base 1:8.0
+ (arch=!sh4)GC_helper_count@Base 1:8.0
  GC_ignore_self_finalize_mark_proc@Base 1:7.2d
  GC_ignore_warn_proc@Base 1:7.2d
  GC_in_thread_creation@Base 1:7.2d
@@ -372,16 +372,16 @@
  GC_mark_and_push_stack@Base 1:7.2d
  GC_mark_from@Base 1:7.2d
  GC_mark_init@Base 1:7.2d
- (arch=!nios2 !sh4)GC_mark_local@Base 1:8.0
- (arch=!nios2 !sh4)GC_mark_no@Base 1:8.0
+ (arch=!sh4)GC_mark_local@Base 1:8.0
+ (arch=!sh4)GC_mark_no@Base 1:8.0
  GC_mark_some@Base 1:7.2d
  GC_mark_stack_size@Base 1:7.2d
  GC_mark_stack_too_small@Base 1:7.2d
  GC_mark_state@Base 1:7.2d
- (arch=!nios2 !sh4)GC_mark_thread@Base 1:8.0
+ (arch=!sh4)GC_mark_thread@Base 1:8.0
  GC_mark_thread_local_fls_for@Base 1:8.0
  GC_mark_thread_local_free_lists@Base 1:8.0
- (arch=!nios2 !sh4)GC_mark_threads@Base 1:8.0
+ (arch=!sh4)GC_mark_threads@Base 1:8.0
  GC_mark_togglerefs@Base 1:7.6.4
  GC_max_heapsize@Base 1:7.4.2
  GC_max_retries@Base 1:7.2d
@@ -420,8 +420,8 @@
  GC_noop6@Base 1:7.4.2
  GC_noop_sink@Base 1:7.2d
  GC_normal_finalize_mark_proc@Base 1:7.2d
- (arch=!nios2 !sh4)GC_notify_all_builder@Base 1:8.0
- (arch=!nios2 !sh4)GC_notify_all_marker@Base 1:8.0
+ (arch=!sh4)GC_notify_all_builder@Base 1:8.0
+ (arch=!sh4)GC_notify_all_marker@Base 1:8.0
  GC_notify_or_invoke_finalizers@Base 1:7.2d
  GC_nprocs@Base 1:7.2d
  GC_null_finalize_mark_proc@Base 1:7.2d
@@ -493,9 +493,9 @@
  GC_push_current_stack@Base 1:7.2d
  GC_push_finalizer_structures@Base 1:7.2d
  GC_push_gc_structures@Base 1:7.2d
- (arch=nios2 sh4)GC_push_marked1@Base 1:7.4.2
- (arch=!alpha !amd64 !arm64 !armel !armhf !hppa !hurd-i386 !i386 !ia64