Bug#990939: unblock: newlisp/10.7.5-2

[Sergio Durigan Junior]

On Wednesday, July 14 2021, Paul Gevers wrote:

> On 11-07-2021 20:29, Sergio Durigan Junior wrote:
>>> Please unblock package newlisp
>
> unblocked.

Thanks, Paul.

>>> Depending on the -dev packages instead is not nice,
>>> but it is actually the fix with the smallest change.
>> 
>> I'm open to suggestions here.
>
> The original bug mentions:
> Use e.g. dpkg-shlibdeps/dh_shlibdeps for that. See option -d
> in dpkg-shlibdeps(1) for a hint on how to do that.

I don't know if the original bug was filed using a template or not, but
using dpkg-shlibdeps doesn't make sense in this case because the newlisp
binary doesn't link against the specified libraries.

Instead, the newlisp *scripts* (which are installed under
/usr/share/newlisp) contain explicit commands to make the newlisp
interpreter load the necessary libraries (via dlopen).

I can be really wrong here, but I don't see another way to tackle this
problem.  Either way, I don't want to hijack this thread either, but I
just thought I'd point this out.

Thanks,

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


signature.asc
Description: PGP signature

Bug#783990: efivarfs is a separate fs and needs moutning

[The Wanderer]

On 2021-07-16 at 13:02, The Wanderer wrote:

> On 2021-07-16 at 12:55, Ian Jackson wrote:
> 
>> I have now tested this.  I found that a safety catch in
>> mount-functions caused it to not work, and this additional patch is
>> needed.
>> 
>> mount-functions looks in /etc/filesystems and skips mounting things
>> which the kernel doesn't seem to supoort.  In general with so many
>> filesystems being kernel modules this seems to be of questionable use.
>> In this case it definitely broke things: I found that mounting the
>> filesystem with mount(8) auto-loads the module.

>> For your testing:
>> 
>> AFAICT it isn't a particularly good idea to just copy the new
>> mount-functions.sh into /lib but monkey-applying the patch with
>> 
>>   patch /lib/init/mount-functions.sh < 
>> 0001-initsripts-mount-functions-Do-not-check-efivarfs-in-.patch
>> 
>> worked for me.  With those patches (and the bodge in fstab commented
>> it) it all works.
> 
> I need to do some other things for a while, so I won't be rebooting
> again immediately, but I'll probably test this sometime this afternoon.

This has now been tested (twice, once from intentional shutdown and once
from unexpected power loss).

I did not make note of what boot-time message(s) there may or may not
have been, but the mount is still in place and functioning without
issues, and I don't see any new errors in e.g. dmesg.

Barring reason to do otherwise, I plan to leave the patch applied until
such time as something overwrites it (probably on a package upgrade). If
I notice any issues, I will try to report back.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#991219: ITP: ruby-kas-grpc -- Auto-generated gRPC client for KAS

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ruby-kas-grpc
  Version : 0.0.2
  Upstream Author : Gitlab.org
* URL :
https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent
* License : Expat
  Description : Auto-generated gRPC client for KAS
 The Kubernetes Agent Server (KAS) is a GitLab backend service dedicated
to managing Kubernetes Agents. This gem is the auto-generated gRPC
client for it.

Bug#991221: buster-pu: package mariadb-10.3 10.3.30-0+deb10u1

[Otto Kekäläinen]

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

I propose that the latest version of MariaDB 10.3.30 would be included
in the upcoming stable release update of Debian. Package is ready at
https://salsa.debian.org/mariadb-team/mariadb-10.3

Before I submit the final changelog etc I'd like to inquire what is
the schedule of the Debian 10.11 stable update?

There is currently no entry at https://release.debian.org/
If the date is far in the future (e.g. September) it might be that
there is a MariaDB 10.3.31 available already by then and putting
effort on 10.3.30 is moot.

Bug#991222: avahi: Please upload avahi to buster-backports

[Vasyl Gello]

Source: avahi
Version: 0.8-5
Severity: minor
X-Debbugs-Cc: mat...@debian.org

Dear colleagues,

I need to have python3-avahi backported because kodi-eventclients-zeroconf 
depends on it.

I asked about that on #debian-systemd but I dont have any logs of that room 
available,
so I don't know if that request was ever answered.

Vasyl

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#991223: modemmanager: missing policykit-1 in Depends or Recommends

[Cyril Brulebois]

Package: modemmanager
Version: 1.10.0-1
Severity: serious
Justification: missing dependency

Hi,

A basic modemmanager installation doesn't result in a functional mmcli
command. The following might work (e.g. after a reboot, to make sure the
modem detection is fine):

# mmcli -L
/org/freedesktop/ModemManager1/Modem/0 [QUALCOMM INCORPORATED] QUECTEL 
Mobile Broadband Module

But trying to force a scan (e.g. before or instead of rebooting)
doesn't:

# mmcli -S
error: couldn't request to scan devices: 
'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: PolicyKit 
authorization failed: 'GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: 
The name org.freedesktop.PolicyKit1 was not provided by any .service files''

Trying to establish a connection doesn't work either:

# mmcli -m 0 --simple-connect apn=orange
error: couldn't connect the modem: 
'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: PolicyKit 
authorization failed: 'GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: 
The name org.freedesktop.PolicyKit1 was not provided by any .service files''

Given the error message, it's pretty clear the problem is at the D-Bus
level, so isn't actually limited to mmcli: trying to toy with the modem
over D-Bus directly (e.g. using Python bindings) would result in the
same problems.


It looks to me policykit-1 should be at least in Recommends, possibly in
Depends. This might have been unreported until since end users are
likely using NetworkManager from a desktop environment, and
network-manager does list policykit-1 in Depends.


I've double checked those findings with buster myself, but I'm told the
same happens with bullseye as well, which would be consistent with the
facts Depends/Recommends didn't change between buster's version and
bullseye's.

This would seem worth fixing in both distributions.


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

Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Shengjing Zhu]

On Sun, Jul 18, 2021 at 3:00 AM Sebastian Ramacher  wrote:
[..]
> Ah, I missed the debdiff due to the other discussion. Please go ahead.
>

Uploaded, built and installed on all architecures.

-- 
Shengjing Zhu

Bug#991231: seahorse: Seahorse unable to import pkcs12 certificates

[Marcelo Luiz de Laia]

Package: seahorse
Version: 3.38.0.1-2
Severity: normal

Dear Maintainer,

When trying to import a certificate into seahorse/gnome-keyring, seahorse GUI
application shows the 'import' button grayed out, while mouse hovering the
"import" button shows the message "Cannot import because there are no
compatible importers".

At command line,

$ gnome-keyring import X-certificate.p12

Return:

gnome-keyring: couldn't parse: X-certificate.p12
gnome-keyring: couldn't find any place to import files

It's not possible to digitally sign documents with LibreOffice.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'stable'),
(500, 'oldstable'), (250, 'unstable'), (50, 'experimental')
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=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages seahorse depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gcr  3.38.1-2
ii  gnome-keyring3.36.0-1
ii  gnupg2.2.27-2
ii  libatk1.0-0  2.36.0-2
ii  libavahi-client3 0.8-5
ii  libavahi-common3 0.8-5
ii  libavahi-glib1   0.8-5
ii  libc62.31-12
ii  libgck-1-0   3.38.1-2
ii  libgcr-base-3-1  3.38.1-2
ii  libgcr-ui-3-13.38.1-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgpgme11   1.14.0-1+b2
ii  libgtk-3-0   3.24.24-4
ii  libhandy-1-0 1.0.3-2
ii  libldap-2.4-22.4.57+dfsg-3
ii  libpwquality11.4.4-1
ii  libsecret-1-00.20.4-2
ii  libsoup2.4-1 2.72.0-2

Versions of packages seahorse recommends:
ii  openssh-client  1:8.4p1-5

seahorse suggests no packages.

Bug#991225: Needs a versioned dependency on python3-translate

[Daniel Leidert]

Package: translate-toolkit
Version: 3.3.6-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The translate-toolkit has an unversioned dependency on python3-toolkit.
But so one can install the package from experimenal while still having
python3-toolkit installed. This leads to an error:

pkg_resources.VersionConflict: (translate-toolkit 3.3.2 
(/usr/lib/python3/dist-packages), Requirement.parse('translate-toolkit==3.3.6'))

and the scripts die. It clearly needs a versioned dependency on python3-toolkit.

Regards, Daniel



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

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

Versions of packages translate-toolkit depends on:
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-4
ii  python3-translate  3.3.2-1

Versions of packages translate-toolkit recommends:
ii  translate-toolkit-doc  3.3.2-1

translate-toolkit suggests no packages.

- -- no debconf information

- -- debsums errors found:
debsums: changed file /usr/bin/json2po (from translate-toolkit package)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmDzcDAACgkQS80FZ8KW
0F2drA//Vi8EUKDn1gdDfkSnLKvUwnpWcZp5c4oNZeD8uNpBqcEEm2YH5sroMyPk
kpELs76VBNqc+oJRwE7Q+5vMI3UNUriRL+kWJlqA5Ef6fOZjKDfF7oEFXsyFO2oq
gDdmaxs+qvAR0CrhmO7dKxDjT0XTn04xEsaNaKsjRhqi8QCNVS1lj7Ybguj5jquC
jag1NBffmEMjjNfcyw0zjNtGPBVNlFq5WAt4Hfy0MP6NXp5qYUZ2m2kQwn9qLCyz
EGq2UGRx+JdOQh4P/tAPg3Em4MoQXetgsQEt8tq2wmkguHfTWPQc5GmKGYTqbaiF
nZF2xpwNeA/bOB9W1eqjG3djIde88CGGe44X2ZID+ivQUr4M1DK8waBU0YSZR54w
AlPOAce+YDZ6qX3UGCUufRH4NbkuPFsHVwS1FqOdh6izvaYeX1VI+6HazsNIFwgD
S3hTjidDo7lG427/nNBLHA90u0Plumm3vTX/FfcN4KfLxYsbiddCnIxTN14cfKMd
5xsIx5i1KVD5aydnfUkQXgoxU74bxZ1TsZZF7sCR9CBGTyqcpzO+rZVS8xQCPI1a
9NFzK39dDWg0APybbdlAPvtOihBL9p36VK915kOToMHtyFotkLhhL38ITkniJ1qb
iADC6OkQNiJR5eutVj68xcHIPv0xTMMLrM1XVpsEtBlcXOgt4OY=
=XnyG
-END PGP SIGNATURE-

Bug#991226: json2po: The message-context for a string occurring multiple times is always the same

[Daniel Leidert]

Package: translate-toolkit
Version: 3.3.6-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have a JSON file, in which so,e strings occur several times in different
keys. But the message context only contains one key multiple times. I think,
this is an error. Here an example:

#: .app.Active
msgctxt ".app.Active"
".app.Active"
".app.Active"
".app.Active"
".app.Active"
".app.Active"
".app.Active"
".app.Active"
".app.Active"
".app.Active"
msgid "Active"
msgstr ""

Instead of listing .app.Active multiple times I expect the other contexts to be
listed here.

This issue is the same both in unstable and experimental.

Regards, Daniel

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

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

Versions of packages translate-toolkit depends on:
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-4
ii  python3-translate  3.3.2-1

Versions of packages translate-toolkit recommends:
ii  translate-toolkit-doc  3.3.2-1

translate-toolkit suggests no packages.

- -- no debconf information

- -- debsums errors found:
debsums: changed file /usr/bin/json2po (from translate-toolkit package)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmDzbt4ACgkQS80FZ8KW
0F22/g/+J8nZUOV8L/UAG+rhKlB7HqfYXDsjUAQhrUHcDe7tROKpcypKyayBQj4r
4QlY3Q8lOe6GSt18dQVOsl58QQ9m0RCxaF8n6c3WRZlAVgKmoTClzHB30rtU6+z/
AytuXEhIACe5RXTscQ9O18wyVvuAJTOzI9zsvaixXB250jSl1huNBEl58v9Vn0e2
6VlDxQ92MI/1ShCCKbh3dgRJeRw8JkMk8WIRuSXcRbXVfwmvERbi2+00chNLaNnN
C6oMbLisAtCVu0B6fot52U+d+VDRR/8gjgObTrAW/fqEM79GWwyU5r03hoTKX1Eb
VFD49LT0hFuAmGPfcoKwoIaS2dZDWzp4j5pv7cJc9OOQjjKe8UOVMxE3+v0uxQNW
aSLPoXuV8rPnnSNzDLrFUH28zAiuAk9uzUXQbCTJbu7FUGSCVYEE38Xjf0LV6bCj
W8oi9bPPUnn43r7X06GN+kkIFK5bmMDzsKPgVlXJfNXFW3QK+ZkC1FHq03yQryXs
f3c3I9139RKZZa3MKbiRTiOUzgSAg+1HvYka1/wkEC+Q2fA7PAuVNiMmxDZ3hnL+
wtYDdYcavHyVh814M/Dnlih6P7LXtKaO2r/TAnqeEbiA1VhKJix43wCdVcd59bzm
SVprl2WsQUdVIFMKRBbQgGY+Q4WwVC8j3GjHxbtfg4I5AGwsUMY=
=Oias
-END PGP SIGNATURE-

Bug#990774: runit-init: /lib/runit/shutdown does nothing when called with parameters

[Lorenzo]

Control: tags -1 confirmed
Control: tags -1 patch
Control: reassign -1 runit 2.1.2-27
Control: affects -1 runit-init



On Tue, 06 Jul 2021 23:58:19 +0200
Carsten Leonhardt  wrote:

> Package: runit-init
> Version: 2.1.2-40
> Severity: important
> 
> Hi Lorenzo,
> 

Hi Carsten,

Thanks for reporting this bug

> running runit as PID 1, my habitual "shutdown -r now" doesn't work, it
> does nothing at all.

This is actually worst than I initially thought, as making the -f flag
a noop is breaking the switch from sysvinit to runit (I will track the
switch issue, that is likely RC, in another bug).
Attached there is a minimalistic patch that should fix the problem: I
made some testing of the basic usage with runit-init and the init
switch.

> This also prevents acpi-support-base from handling the pressing of the
> power button to shutdown, the package calls
> 
> /sbin/shutdown -h -P now "Power button pressed"
> 
> (see /etc/acpi/powerbtn-acpi-support.sh)
> 
> In extension, that prevents libvirt to shutdown/reboot a VM running
> with runit-init ("virsh shutdown ").

I didn't have the time and the knowledge to test with libvirt. I know
that switching init can be time consuming and setup disruptive, but it
would be great if you can confirm that the attached patch fix the issue
for your usecase.

Regards,
Lorenzo

to build from git/salsa
https://salsa.debian.org/Lorenzo.ru.g-guest/runit/-/tree/2.1.2-41exp

only the patch for shutdown.c

--- ./shutdown.c2020-01-13 01:07:09.185373016 +0100
+++ ./shutdown-new.c2021-07-15 14:51:04.482088733 +0200
@@ -134,14 +134,16 @@
}
 
for (i = 1; i != argc; ++i) {
-   if (strcmp(argv[i], "-f"))
+   if (strcmp(argv[i], "-f") == 0)
cfg->force = true;
-   if (strcmp(argv[i], "--force"))
+   if (strcmp(argv[i], "--force") == 0)
cfg->force = true;
-   if (strcmp(argv[i], "-w"))
+   if (strcmp(argv[i], "-w") == 0)
cfg->wtmp_only = true;
-   if (strcmp(argv[i], "--wtmp-only"))
+   if (strcmp(argv[i], "--wtmp-only") == 0)
cfg->wtmp_only = true;
+   if (strcmp(argv[i], "-r") == 0)
+   cfg->action = ACTION_REBOOT;
}
 }
 

Bug#991224: json2po: Misses import pkg_resources

[Daniel Leidert]

Package: translate-toolkit
Version: 3.3.6-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

If I try to use the version in experimental, I get this error:

template None: name 'pkg_resources' is not defined

Adding an 'import pkg_resources' solves the issue.

Regards, Daniel


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

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

Versions of packages translate-toolkit depends on:
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-4
ii  python3-translate  3.3.2-1

Versions of packages translate-toolkit recommends:
ii  translate-toolkit-doc  3.3.2-1

translate-toolkit suggests no packages.

- -- no debconf information

- -- debsums errors found:
debsums: changed file /usr/bin/json2po (from translate-toolkit package)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmDzbdEACgkQS80FZ8KW
0F18vBAA2utezJegRI7YdhoRP7dztWz/y3t4WWypMoq/7+Z1p6PfugO4AqjIkJhu
qBML33l2Velw2LZukCoGsPasJzjrMMw4BW2eIa55v+ZWm3CMC4XrJspUas/fr8e8
qLgMwqutnGludsvxEShmJm6sPUvZDfnGXPkZNDaJZixuvf2Io2tu+VCVbearXtNv
cVDUdYk0CBlQc4vdArujusEQ0RaIiGYGbQo2YoZWYn9KAPdSzfrhLMRtwVrc52sG
27y+G6ibYqaMBfHXeRQGRkndaqSmYvCJGUcLCa2nNj9HST56FpKi0HJs3xs0pQPg
WeGaId3LZ1u7JSJ2T8/94UcU+eW9YpsxEWZHi+C/atv7SRLuG10soTTZt4pi4oAW
i3h1+wdVQWifEBekSHiWzrQjs+7KJLvdxamkKb5AfH6u++ByKBFPJ4o+JCTVrvIb
YHIvpqxROINEr3YhgqGCEisymUgaMnTTtcw+VSghNqq6tXNFmKSzjKbLCZctRlWn
U/4hEbsMjaXKvOtJigR5jSQX883j9d25QTpbvQ0Zg6IdGqdf624obm0g44aB3aZk
HZfrV+D0u2V8bXfVVGyDz81efwN6QdVQV5DyT+2xfakwUugyC6hnSojV7c9QgabF
9+uT4Olyt3G0BBEjXvivZNuLpHgBtpAQqxHCAitDATn7R/aPbIo=
=jsJ1
-END PGP SIGNATURE-

Bug#991225: Re #991225

[Daniel Leidert]

Please replace "python3-toolkit" with "python3-translate" in my previous mail.

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#991228: mozc-server: Japanese hiragana input fails after first keypress in anki

[Benjamin Carlyle]

Package: mozc-server
Version: 2.26.4220.100+dfsg-4ubuntu3
Severity: normal
Tags: l10n
X-Debbugs-Cc: benjamincarl...@soundadvice.id.au

Dear Maintainer,

Apologies for filing this from an Ubuntu system. The defect affects
debian as well. The issue is fixed in upstream under
https://github.com/google/mozc/issues/510 but fair warning it is
included in a much larger patch at does not apply cleanly at least to
the Ubuntu version of this package.

An uncaught C++ exception is raised when entering japanese text into the
"add card" window of the anki flashcard application. This crashes the
mozc input method and requires switching to english and then back to
japanese in order to restart it.

Steps to reproduce:
1. Open anki and start adding a card to a deck
2. Ensure you are using mozc in hiragana input mode
3. Type aimasu into a field on this dialogue
Expeted behaviour:
The characters あいます appear in the text field with alternate
suggestions available such as 会います and アイマス.
Actual behaviour:
あmasu is displayed ("i" is swallowed), and the suggestions dropdown is stopped.
Steps to resume normal operation:
Switch to english, then switch back to japanese, then reselect hiragana input

The related ubuntu bug is 
https://bugs.launchpad.net/ubuntu/+source/mozc/+bug/1931554
This ubuntu bug includes stack trace and some additional background and
links.

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

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

Versions of packages mozc-server depends on:
ii  libabsl20200923  0~20200923.3-3
ii  libc62.33-0ubuntu5
ii  libcairo21.16.0-5ubuntu1
ii  libgcc-s111.1.0-1ubuntu1~21.04
ii  libglib2.0-0 2.68.1-1~ubuntu21.04.1
ii  libgtk2.0-0  2.24.33-1ubuntu2
ii  libpango-1.0-0   1.48.2-1build2
ii  libprotobuf233.12.4-1ubuntu2
ii  libstdc++6   11.1.0-1ubuntu1~21.04

mozc-server recommends no packages.

mozc-server suggests no packages.

-- no debconf information

Bug#988707: closed by Debian FTP Masters (reply to bott...@debian.org (A. Maitland Bottoms)) (Bug#988707: fixed in qthid-fcd-controller 4.1-6)

[Adrian Bunk]

On Sat, Jun 19, 2021 at 02:21:16PM +, Debian Bug Tracking System wrote:
>...
>  qthid-fcd-controller (4.1-6) unstable; urgency=medium
>  .
>* Update package and move to Hamradio Maintainers group (Closes: #988707)
>...

This change needs an unblock request (reportbug release.debian.org)
to prevent removal from bullseye.

cu
Adrian

Bug#991223: modemmanager: missing policykit-1 in Depends or Recommends

[Cyril Brulebois]

Control: found -1 1.14.12-0.1

Cyril Brulebois  (2021-07-18):
> I've double checked those findings with buster myself, but I'm told
> the same happens with bullseye as well, which would be consistent with
> the facts Depends/Recommends didn't change between buster's version
> and bullseye's.

It's arguably worse in bullseye, during installation:

# apt install modemmanager
[…]
Created symlink 
/etc/systemd/system/dbus-org.freedesktop.ModemManager1.service → 
/lib/systemd/system/ModemManager.service.
Created symlink 
/etc/systemd/system/multi-user.target.wants/ModemManager.service → 
/lib/systemd/system/ModemManager.service.
Failed to start ModemManager.service: Unit polkit.service not found.
[…]

which means we don't even get the daemon up and running:

# systemctl status ModemManager.service
● ModemManager.service - Modem Manager
 Loaded: loaded (/lib/systemd/system/ModemManager.service; enabled; 
vendor preset: enabled)
 Active: inactive (dead)

and again, pulling the same package would help, given it ships:

policykit-1: /lib/systemd/system/polkit.service


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


signature.asc
Description: PGP signature

Bug#867548: HDMI on Haswell audio video sync and speed issues

[Bryan Cebuliak]

I  am   still   wondering  which  package   to   register  this   bug.  Is
it  some   kernel  config  issue  since   the   same   recent Buster
kernel   works  well  on Buster  but  not  on   Bullseye?  I   doubt  if
it  is  a  Pulseaudio  issue.
Another  possibly   relevant   link. Takashi Iwai is  the  man:
https://bugzilla.kernel.org/show_bug.cgi?id=74861

Bug#991227: runit: Broken switch from SysVinit - needs hardreset

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-40
Severity: important
Tags: patch
X-Debbugs-Cc: plore...@disroot.org

The fix for #919699 introduced a regression described in #990774: when shutdown,
halt or reboot is called with parameters it does nothing. This includes the -f 
flag.
A consequence is that the switch  Sysvinit --> runit-init can be broken.
When plain shutdown or reboot are called (for instance by a graphical desktop 
env),
SysVinit is told to enter runlevel 0 or 6, but then it expects halt -f or 
reboot -f
 to finish the job (but they are noop, so the system is left in a wierd state).

When reboot is called the system initate the shutdown process, then stops and
the user can login into emergency shell: from there, only if the user call 
again reboot,
the system will complete the shutdown process (after about 15 seconds of 
waiting).

If shutdown is called the system initate the shutdown process but then stops: 
all
tty's are down, no way to login, and init does not complete the shutdown. From 
there
one can only press the reset button.

Runit-init users are not affected only because, when stage3 returns (because 
halt -f is a noop)
runit uses it's own internal code to poweroff or reboot.
The switch from systemd is not affected because systemd uses it's own internal 
code
to perform the shutdown.

I've already tested that the patch for #990774, attached below,
fix this issue too

patch: (the last two lines with the -r flag are not strictly needed here )

--- ./shutdown.c2020-01-13 01:07:09.185373016 +0100
+++ ./shutdown-new.c2021-07-15 14:51:04.482088733 +0200
@@ -134,14 +134,16 @@
}
 
for (i = 1; i != argc; ++i) {
-   if (strcmp(argv[i], "-f"))
+   if (strcmp(argv[i], "-f") == 0)
cfg->force = true;
-   if (strcmp(argv[i], "--force"))
+   if (strcmp(argv[i], "--force") == 0)
cfg->force = true;
-   if (strcmp(argv[i], "-w"))
+   if (strcmp(argv[i], "-w") == 0)
cfg->wtmp_only = true;
-   if (strcmp(argv[i], "--wtmp-only"))
+   if (strcmp(argv[i], "--wtmp-only") == 0)
cfg->wtmp_only = true;
+   if (strcmp(argv[i], "-r") == 0)
+   cfg->action = ACTION_REBOOT;
}
 }
 

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 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 /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.31-12
ii  sysuser-helper  1.3.5.1

Versions of packages runit recommends:
ii  runit-init  2.1.2-41exp1

Versions of packages runit suggests:
ii  socklog  2.1.0+repack-4+b1

-- Configuration Files:
/etc/default/runit changed [not included]
/etc/runit/ctrlaltdel changed [not included]
/etc/runit/runsvdir/single/sulogin/run [Errno 2] No such file or directory: 
'/etc/runit/runsvdir/single/sulogin/run'

-- no debconf information

Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Adrian Bunk]

On Tue, Jul 13, 2021 at 02:08:22PM +0800, Shengjing Zhu wrote:
>...
> Sadly the std library are statically embedded in all packages built by Go 
> compiler.
> So if there's security issue in std library, bunch of packages need to be 
> rebuild.
>...

It might be an improvement to switch to gccgo as default Go compiler
in bookworm?

cu
Adrian

Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Shengjing Zhu]

(Replace pkg-go-maintain...@lists.alioth.debian.org with
debian-go@lists.d.o, the alioth list is deprecated)

On Sun, Jul 18, 2021 at 3:32 AM Adrian Bunk  wrote:
>
> On Tue, Jul 13, 2021 at 02:08:22PM +0800, Shengjing Zhu wrote:
> >...
> > Sadly the std library are statically embedded in all packages built by Go 
> > compiler.
> > So if there's security issue in std library, bunch of packages need to be 
> > rebuild.
> >...
>
> It might be an improvement to switch to gccgo as default Go compiler
> in bookworm?

Might be.
And it would be great if we can get some compiler experts or upstream
to have some inputs.
If anyone have experience on this area and want to drive this, I think
it's worth to try.

-- 
Shengjing Zhu

Bug#958129: smem: diff for NMU version 1.5-1.1

[Adrian Bunk]

Control: tags 958129 + pending

Dear maintainer,

I've prepared an NMU for smem (versioned as 1.5-1.1) and uploaded
it to DELAYED/1. Please feel free to tell me if I should cancel it.

cu
Adrian
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#991146: python3-libxml2: ambiguous package name 'python3-libxml2' with more than one installed instance

[Sebastian Ramacher]

Control: tags -1 bullseye-ignore

On 2021-07-17 17:59:43 +, stefa...@debian.org wrote:
> Hi Thorsten (2021.07.17_17:43:51_+)
> > I guess this is rare during normal operation, but we don’t prescribe
> > use of apt anywhere and dpkg can indeed trigger it, and this is the
> > actually normal case when crossgrading.
> 
> Yeah, it's worth fixing, and required for further multi-arch in the
> Python stack.
> 
> > The fix is really easy, dh_python3 must arch-qualify the py3compile
> > (and pypy3compile, I guess) line it inserts if the package is not
> > arch:any. For it to become effective, all packages with the code in
> > their maintainer scripts need to be rebuilt, which… is probably not
> > feasible right now.
> 
> Yeah, I think this is 3 steps:
> 1. Add support for arch-qualified dependencies in the py*compile
>scripts.
> 2. Generate arch-qualified dependencies (and appropriate versioned
>dependencies on python3.*, for the support in 1) in dh_python3.
> 3. Re-build arch-dependent packages with the new dh_python3.
> 
> That sounds way too big to chase before the freeze, so I think this is a
> bookworm problem.

I tend to agree. That's nothing we want to rush for bullseye.

Cheers

> 
> SR
> 
> -- 
> Stefano Rivera
>   http://tumbleweed.org.za/
>   +1 415 683 3272

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#983206: [libupnp13] Please update for CVE-2020-12695 & fixes

[Sebastian Ramacher]

Control: severity -1 grave
Control: tags -1 bullseye-ignore

On 2021-02-21 04:16:21 +, Lyndon Brown wrote:
> Package: libupnp13
> Version: 1:1.8.4-2
> Severity: critical
> 
> According to the changelog upstream version 1.14.0 includes a security
> fix for CVE-2020-12695 (currently not tracked for pupnp in the debian
> security tracker).
> 
> Please update to 1.14.x. Thanks.
> 
> I'm also having trouble getting DLNA working with minidlna on one
> system and vlc on another, with little idea so far why it's not
> working. Getting an updated libupnp13 with all the fixes they've made
> may help eliminate some possible causes.

https://github.com/pupnp/pupnp/commit/7b3f0f5f497f9f493c82307af495b87fa9ebdacb
is part of the fix for CVE-2020-12695 and thus libupnp requires a
transition. That will have to wait for bookworm.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#991220: Debian-installer - false automatic partitioning

[wagner]

Package: debian-installer
Version: 10.7-10.10

Hello,

from all the version the only one that does automatic partitioning 
correctly - configures the right size of swap partition, is version 
10.6.


I have tested every single newer release of debian on my hardware:
Dell Latitude E7470, 14' 2560x1440, i5-6300U, 7869MiB RAM

..every single time the partitioner ended up assigning 1 GB of swap 
space to my device. Both for LVM (encrypted and unencrypted) and the 
guided while installing the entire disk for the installation.


So after every single installation I ended up returning to 
10.6-live-nonfree and ten upgrading the system because that's the only 
way to configure my machine properly by assigning it 8.5 GB of space for 
the swap partition.


Please find out what's causing this issue. With new incoming versions 
there surely will be glitches in terms of graphical appearance as a 
result from upgrading nearly a year old buster 10.6 version to anything 
that will be released in the future days.


Sincerely Yours,

debian user701

Bug#991064: therion FTBFS with imagemagick with the #987504 change

[Olly Betts]

On Fri, Jul 16, 2021 at 06:44:49PM +0200, Dennis Filder wrote:
> The attached patch seems to allow the "Converting images" step to
> succeed.  I ran this only once though.

This looks reasonable to me (as an uploader of the package).

Wookey: Are you able to upload?  I'm seriously lacking in spare
time currently.

If not and someone wants to NMU, please go for it.

Cheers,
Olly

Bug#991190: dpkg-fsys-usrunmess: block service activation with policy-rc.d?

[Zack Weinberg]

On Sat, Jul 17, 2021 at 12:51 PM Guillem Jover  wrote:
> On Fri, 2021-07-16 at 15:23:01 -0400, Zack Weinberg wrote:
> > As a stopgap safety measure, I suggest that dpkg-fsys-usrunmess should
> > use policy-rc.d to block all service activation while it’s running.
>
> Hmm, right, that's not nice, sorry for the trouble. Hmm on one hand I
> guess installing a policy-rc.d would make this safer, on the other, it
> might end up not restarting services that will end up possibly using
> old inodes or pathname references, which might affect service monitoring
> for example, so I'm not sure what's worse.

You would know better than me -- I mostly use Debian as a workstation
environment, I have very little experience with weird server issues.

> But then I think the better option is to move the package
> configuration at the end once everything has been unmessed and the
> filesystem has been fully cleaned up.

That seems like a good change regardless.  If there are any packages
whose postinsts somehow depend on the presence or absence of files
that move between / and /usr in this process, they're more likely to
do the Right Thing after the moves are completely done.

Thanks for the quick reply.

zw

Bug#991198: libkscreenlocker5: Screen locker activates after resuming, briefly showing desktop contens

[Gregor Riepl]

Package: libkscreenlocker5
Version: 5.20.5-1
Severity: important
Forwarded: https://bugs.kde.org/show_bug.cgi?id=439814
X-Debbugs-Cc: onit...@gmail.com

Dear Maintainer,

This issue has started happening some time ago, but I don't know when exactly

kscreenlocker sometimes activates too slowly, and systemd seems to be very
eager to suspend.
This results in the previous screen contents briefly showing up before the lock
screen is displayed.

This looks like a broader issue, and apparently it's still unfixed:
https://bbs.archlinux.org/viewtopic.php?id=166221

As a workaround, one can always lock the screen manually before triggering
suspend (through lid close or similar), but this is tedious.


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

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

Versions of packages libkscreenlocker5 depends on:
ii  kpackagetool5  5.78.0-3
ii  libc6  2.31-12
ii  libkf5configcore5  5.78.0-4
ii  libkf5configgui5   5.78.0-4
ii  libkf5coreaddons5  5.78.0-4
ii  libkf5crash5   5.78.0-3
ii  libkf5declarative5 5.78.0-2
ii  libkf5globalaccel-bin  5.78.0-3
ii  libkf5globalaccel5 5.78.0-3
ii  libkf5i18n55.78.0-2
ii  libkf5idletime55.78.0-2
ii  libkf5notifications5   5.78.0-2
ii  libkf5package5 5.78.0-3
ii  libkf5quickaddons5 5.78.0-2
ii  libkf5waylandclient5   4:5.78.0-2
ii  libkf5waylandserver5   4:5.78.0-2
ii  libkf5windowsystem55.78.0-2
ii  libkf5xmlgui5  5.78.0-2
ii  libpam0g   1.4.0-7
ii  libqt5core5a   5.15.2+dfsg-5
ii  libqt5dbus55.15.2+dfsg-5
ii  libqt5gui5 5.15.2+dfsg-5
ii  libqt5network5 5.15.2+dfsg-5
ii  libqt5qml5 5.15.2+dfsg-5
ii  libqt5quick5   5.15.2+dfsg-5
ii  libqt5widgets5 5.15.2+dfsg-5
ii  libqt5x11extras5   5.15.2-2
ii  libstdc++6 10.2.1-6
ii  libwayland-client0 1.18.0-2~exp1.1
ii  libwayland-server0 1.18.0-2~exp1.1
ii  libx11-6   2:1.7.1-1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb11.14-3
ii  libxi6 2:1.7.10-1
ii  psmisc 23.4-2

Versions of packages libkscreenlocker5 recommends:
ii  kde-config-screenlocker  5.20.5-1

libkscreenlocker5 suggests no packages.

Bug#991188: jetty9: CVE-2021-34429

[Salvatore Bonaccorso]

Hi

On Fri, Jul 16, 2021 at 10:44:20PM +0200, Markus Koschany wrote:
> Control: owner -1 !
> 
> Hi,
> 
> Am Freitag, dem 16.07.2021 um 21:16 +0200 schrieb Salvatore Bonaccorso:
> > Source: jetty9
> > Version: 9.4.39-2
> > Severity: grave
> > Tags: security upstream
> > X-Debbugs-Cc: car...@debian.org, Debian Security Team
> > 
> > 
> > Hi,
> > 
> > The following vulnerability was published for jetty9.
> > 
> > CVE-2021-34429[0]:
> > 
> 
> just FYI. I am almost done preparing a buster-security update for Jetty 9 and 
> I
> get back to you this weekend. I will take care of this issue for Debian 11 
> too.

Thank you Markus.

Regards,
Salvatore

Bug#990977: unblock: python-aiosqlite/0.16.1-2

[Graham Inggs]

Control: tags -1 + moreinfo confirmed

Hi Benjamin

On Mon, 12 Jul 2021 at 08:57, Benjamin Hof  wrote:
> I'd be happy to provide a new upload with a more useful autopkgtest
> that executes the test suite, if that'd work for you.

That sounds good!  Please go ahead with a new upload and remove the
moreinfo tag once it has built.

Regards
Graham

Bug#436466: dash: Please optimise single command given to -c to exec it

[Vincent Bernat]

 ❦ 27 May 2020 08:42 -07, Jonathan Nieder:

 Because of bug #642922 (archived, but has some interesting discussion),
 this patch for this bug ended up being backed out.
> [...]
>> I gather that the ocamlbuild bug has been fixed so can this be
>> reinstated please?
>
> Curious: the ocamlbuild bug appears to still be open upstream
> , but
> https://github.com/ocaml/ocamlbuild/commit/00e05f686e15b07ac4268fcd10cf3738a5c28467
> was applied with the proposed fix in ocamlbuild 0.9.0.
>
> I suspect this means that the ocamlbuild bug was indeed fixed, and
> that we should be able to reinstate the patch.
>
> Except...  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642835;msg=55
> says the bug is present in ocamlbuild 0.10.1.  Ximin, do you remember
> where that version number came from?  Is it possible that the bug is
> *not* present in that version?

Once bullseye is released, would it be possible to reinstate the patch?
Or maybe in experimental. This way, it will be easier to check if the
problem is still present. Moreover, everyone should not carry the burden
of failures from ocamlbuild to correctly track processes. Another
workaround would be to use bash for ocamlbuild if the problem is still
here.

While the footprint of /bin/sh is small, it is not zero and since most
shells optimize this use case, many programs assume they can spawn
process through `/bin/sh -c` at no cost. In my case, I was curious why
processes spawned by i3 and its ecosystem were all leaving a /bin/sh
instance behind.
-- 
Many pages make a thick book, except for pocket Bibles which are on very
very thin paper.

Bug#991199: new upstream required (3.0.19)

[Daniel Baumann]

Package: prompt-toolkit

Hi,

please upgrade promptkit to 3.0.19, the current version of ptpython
requires it.

Regards,
Daniel

Bug#990631: thunderbird: Preferences tab is completely blank after the upgrade to 90b2

[jim_p]

Package: thunderbird
Version: 1:90.0~b2-1
Followup-For: Bug #990631
X-Debbugs-Cc: pitsior...@gmail.com

One minor update. My friend, the arch user, built thunderbird beta (91b1 as of
yesterday) from source and he reports that the blank preferences issue is now
gone there.
So, please package 91b1 for the repo and I will do the testing.

Bug#991200: unblock: python2.7/2.7.18-8

[Matthias Klose]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Andreas Beckmann 

Please unblock python2.7/2.7.18-8, just adding some breaks for smoother upgrades
as requested in #990520.  No code changes.  The debdiff is in the bug report.

Bug#991060: Processed: mlpost FTBFS with imagemagick with the #987504 change

[Stéphane Glondu]

tags 991060 - patch
thanks

Le 16/07/2021 à 21:33, Debian Bug Tracking System a écrit :
> Processing control commands:
> 
>> tag -1 patch
> Bug #991060 [src:mlpost] mlpost FTBFS with imagemagick with the #987504 
change
> Added tag(s) patch.
> [...]
> + test -d $(HOME)/.magick || mkdir -p $(HOME)/.magick
> + sed -e '/ .>/s@"none"@"read|write"@' $(POLFILE) > $(HOME)/.magick/policy.xml
>   $(OCAMLBUILD) doc/index.html
> + rm -Rf $(HOME)/.magick
>   ln -s _build/doc doc

Package builds are not allowed to fiddle with $HOME like that, by
policy: what if the builder already has its own imagemagick policy? But
I think your idea can be used: create a temporary home directory (e.g.
in debian or /tmp), and set $HOME to that.


Cheers,

-- 
Stéphane

Bug#991091: unblock: budgie-desktop/10.5.2-4

[Graham Inggs]

Control: tags -1 + moreinfo confirmed

Hi David

On Tue, 13 Jul 2021 at 22:33, David Mohammed  wrote:
> Please unblock package budgie-desktop

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

Regards
Graham

Bug#991073: Fwd: Bug#991073: unblock: ganglia-modules-linux/1.3.4-5

[Graham Inggs]

Control: tags -1 + moreinfo confirmed
Control: tags 990808 -1 -moreinfo confirmed

Sorry, I managed to reply to the wrong bug.


Hi Marcos

On Tue, 13 Jul 2021 at 17:33, Marcos Fouces   wrote:
> I still not uploaded the package to sid waiting for aproval.

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

Regards
Graham

Bug#991203: unblock: python-dbussy/1.3-1.1

[Adrian Bunk]

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

Please unblock package python-dbussy

  * Backport upstream fix to ensure that Type objects always have
a code field. (Closes: #978544)

Bug#991189: unblock: fail2ban/0.11.2-2

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo

Hi Graham,

On Sat, Jul 17, 2021 at 01:58:57PM +0200, Graham Inggs wrote:
> Control: tags -1 + moreinfo
> 
> Hi Salvatore
> 
> On Fri, 16 Jul 2021 at 21:24, Salvatore Bonaccorso  wrote:
> > fail2ban is affected by CVE-2021-32749, see detailed advisory in
> > https://github.com/fail2ban/fail2ban/security/advisories/GHSA-m985-3f3v-cwmm,
> > which is a possible remote code execution vulnerability in the mailing
> > action mail-whois.
> 
> fail2ban (0.11.2-2) unstable; urgency=high
> 
>   * Fix a problem with mail
> 
>  -- Sylvestre Ledru   Mon, 12 Jul 2021 06:52:40 +0200
> 
> Would it be better to have the CVE mentioned in the changelog?

Right, the description could have been more descriptive but is caused
by the following: The issue was not yet public at the time of the
upload, nor the CVE, but upstream was fine to Debian first issue an
update and then publish the GHSA. This was the reason that the
changelog entry gives not detail on what is wrong with mail.

We could re-trospectively ask for -3 with a more descriptive changelog
entry and include the CVE, but I would suggest to just unblock what we
have.

Regards,
Salvatore

Bug#991204: exim4-daemon-heavy: Please add SPF support

[Andreas Metzler]

Control: forcemerge 528344 991204

On 2021-07-17 Wouter Verhelst  wrote:
> Package: exim4-daemon-heavy
> Version: 4.94.2-6
> Followup-For: Bug #528344

> Perhaps important to note is that both DMARC and (currently still
> experimental, but...) ARC both depend on the builtin SPF support. While
> the SPF "support" by calling an external binary may work for SPF checks
> at a cost of a fork per ACL test (i.e., some performance penalty), this
> is not the case for the extra functionality that depends on the builtin
> SPF support, such as sending out DMARC validation reports, and adding
> ARC headers (to mitigate the issues with forwarding emails).

> Please seriously consider this wishlist item for bookworm already...


Hello Wouter,

... merging accidental duplicate report. Will be fixed in 4.95.

cu Andreas

Bug#991208: q2-demux: dist missing from q2_demux/_summarize/assets/ directory

[Beatrice Torracca]

Package: q2-demux
Version: 2020.11.1-1
Severity: normal

Hi,

I think there is something missing in Debian installation of the demux
plugin for qiime2. Please note that I am at my first steps with qiime
so I apologize if this is me doing something wrong.

When I try to use the qiime demux comand (following one of qiime tutorials) as:

qiime demux summarize --i-data demux.qza --o-visualization demux.qzv

I get this error:

Plugin error from demux:

  [Errno 2] No such file or directory: 
'/usr/lib/python3/dist-packages/q2_demux/_summarize/assets/dist'

and this is the content of the debug log file saved by qiime:

 BEGIN LOG FILE
/usr/lib/python3/dist-packages/seaborn/distributions.py:2557: FutureWarning: 
`distplot` is a deprecated function and will be removed in a future version. 
Please adapt your code to use either `displot` (a figure-level function with 
similar flexibility) or `histplot` (an axes-level function for histograms).
  warnings.warn(msg, FutureWarning)
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/q2cli/commands.py", line 329, in __call__
results = action(**arguments)
  File "", line 2, in summarize
  File "/usr/lib/python3/dist-packages/qiime2/sdk/action.py", line 244, in 
bound_callable
outputs = self._callable_executor_(scope, callable_args,
  File "/usr/lib/python3/dist-packages/qiime2/sdk/action.py", line 452, in 
_callable_executor_
ret_val = self._callable(output_dir=temp_dir, **view_args)
  File "/usr/lib/python3/dist-packages/q2_demux/_summarize/_visualizer.py", 
line 237, in summarize
shutil.copytree(os.path.join(TEMPLATES, 'assets', 'dist'),
  File "/usr/lib/python3.9/shutil.py", line 555, in copytree
with os.scandir(src) as itr:
FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/python3/dist-packages/q2_demux/_summarize/assets/dist'
 END LOG FILE

Thanks a lot for your work of packetization of qiime for Debian!

beatrice



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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 q2-demux depends on:
ii  python3 3.9.2-3
ii  python3-ipywidgets  6.0.0-8
ii  python3-numpy   1:1.19.5-1
ii  python3-pandas  1.1.5+dfsg-2
ii  python3-psutil  5.8.0-1
ii  python3-seaborn 0.11.1-1
ii  python3-setuptools  52.0.0-4
ii  python3-skbio   0.5.6-4
ii  python3-yaml5.3.1-4
ii  q2-types2020.11.1-1
ii  q2templates 2020.11.1+dfsg-1
ii  qiime   2020.11.1-1

q2-demux recommends no packages.

q2-demux suggests no packages.

-- no debconf information

Bug#991210: unblock: conmon/2.0.25+ds1-1.1

[Adrian Bunk]

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

Please unblock package conmon

  * Add upstream fix to not make container runtime processes
unkillable. (Closes: #990263)

I am not convinced that the lowering to non-RC of the bug
was appropriate, but this is moot if the fix goes into bullseye.
diff -Nru conmon-2.0.25+ds1/debian/changelog conmon-2.0.25+ds1/debian/changelog
--- conmon-2.0.25+ds1/debian/changelog  2021-01-31 05:56:56.0 +0200
+++ conmon-2.0.25+ds1/debian/changelog  2021-07-14 20:46:07.0 +0300
@@ -1,3 +1,11 @@
+conmon (2.0.25+ds1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix to not make container runtime processes
+unkillable. (Closes: #990263)
+
+ -- Adrian Bunk   Wed, 14 Jul 2021 20:46:07 +0300
+
 conmon (2.0.25+ds1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
conmon-2.0.25+ds1/debian/patches/0001-Reset-OOM-score-back-to-0-for-container-runtime.patch
 
conmon-2.0.25+ds1/debian/patches/0001-Reset-OOM-score-back-to-0-for-container-runtime.patch
--- 
conmon-2.0.25+ds1/debian/patches/0001-Reset-OOM-score-back-to-0-for-container-runtime.patch
 1970-01-01 02:00:00.0 +0200
+++ 
conmon-2.0.25+ds1/debian/patches/0001-Reset-OOM-score-back-to-0-for-container-runtime.patch
 2021-07-14 20:46:07.0 +0300
@@ -0,0 +1,76 @@
+From b033cb5dfde6de05e63408fc839f1bb641cddd85 Mon Sep 17 00:00:00 2001
+From: Mrunal Patel 
+Date: Thu, 27 May 2021 14:09:39 -0700
+Subject: Reset OOM score back to 0 for container runtime
+
+We don't want container runtime procesess to be unkillable
+so we reset oom_score_adj back to 0 before execv
+of the runtime process.
+
+Signed-off-by: Mrunal Patel 
+---
+ src/conmon.c | 4 +++-
+ src/oom.c| 6 ++
+ src/oom.h| 2 +-
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/src/conmon.c b/src/conmon.c
+index c349d6c..c6bd9f5 100644
+--- a/src/conmon.c
 b/src/conmon.c
+@@ -41,7 +41,7 @@ int main(int argc, char *argv[])
+ 
+   process_cli();
+ 
+-  attempt_oom_adjust();
++  attempt_oom_adjust("-1000");
+ 
+   /* ignoring SIGPIPE prevents conmon from being spuriously killed */
+   signal(SIGPIPE, SIG_IGN);
+@@ -275,6 +275,8 @@ int main(int argc, char *argv[])
+   }
+   }
+ 
++  // We don't want runc to be unkillable so we reset the 
oom_score_adj back to 0
++  attempt_oom_adjust("0");
+   execv(g_ptr_array_index(runtime_argv, 0), (char 
**)runtime_argv->pdata);
+   exit(127);
+   }
+diff --git a/src/oom.c b/src/oom.c
+index 5791777..0041a6b 100644
+--- a/src/oom.c
 b/src/oom.c
+@@ -5,16 +5,14 @@
+ #include 
+ #include 
+ 
+-#define OOM_SCORE "-1000"
+-
+-void attempt_oom_adjust()
++void attempt_oom_adjust(const char *const oom_score)
+ {
+   int oom_score_fd = open("/proc/self/oom_score_adj", O_WRONLY);
+   if (oom_score_fd < 0) {
+   ndebugf("failed to open /proc/self/oom_score_adj: %s\n", 
strerror(errno));
+   return;
+   }
+-  if (write(oom_score_fd, OOM_SCORE, strlen(OOM_SCORE)) < 0) {
++  if (write(oom_score_fd, oom_score, strlen(oom_score)) < 0) {
+   ndebugf("failed to write to /proc/self/oom_score_adj: %s\n", 
strerror(errno));
+   }
+   close(oom_score_fd);
+diff --git a/src/oom.h b/src/oom.h
+index 28e4178..9408c3b 100644
+--- a/src/oom.h
 b/src/oom.h
+@@ -1,6 +1,6 @@
+ #if !defined(OOM_H)
+ #define OOM_H
+ 
+-void attempt_oom_adjust();
++void attempt_oom_adjust(const char *const oom_score);
+ 
+ #endif // OOM_H
+-- 
+2.20.1
+
diff -Nru conmon-2.0.25+ds1/debian/patches/series 
conmon-2.0.25+ds1/debian/patches/series
--- conmon-2.0.25+ds1/debian/patches/series 1970-01-01 02:00:00.0 
+0200
+++ conmon-2.0.25+ds1/debian/patches/series 2021-07-14 20:46:07.0 
+0300
@@ -0,0 +1 @@
+0001-Reset-OOM-score-back-to-0-for-container-runtime.patch

Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

[Steve McIntyre]

Hi Ryan,

On Sat, Jul 17, 2021 at 09:19:22AM -0500, Ryan Thoryk wrote:
>On 7/17/21 8:18 AM, Steve McIntyre wrote:
>> On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote:
>> EFI/debian is *NOT* wrong, it's the correct location for a system that
>> has working firmware which supports setting UEFI boot variables. If
>> you *also* need to write a copy of grub (etc.) to the removable media
>> location (EFI/boot) then that's supported as well by the Debian
>> packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the
>> system asks about that.
>
>Thanks for that suggestion, that explains the correct procedure in resolving
>the issue.  What I'm trying to point out though (I tried this), is that if
>you spin up a new Debian ARM VM on AWS, and run "grub-install" *without*
>doing a dpkg-reconfigure, it results in an unbootable system.  To recover the
>system, you have to attach the disk on a different VM and replace the old
>boot loader image with the new one, then it boots again.  After running the
>dpkg-reconfigure command though like you suggested, it copied over the EFI
>boot image to the "BOOT" folder, and also set the nvram variables to
>apparently boot from the "debian" folder, so that solved the problem for me.
>After doing that, the system comes up after a reboot with the newer grub
>modules.
>
>With others on here, the issue might have to do with the system executing an
>older EFI boot image resulting in a module mismatch, like what happened to
>me.  Your dpkg-reconfigure suggestion might fix their issues too.

So when you say "spin up a new Debian ARM VM on AWS", what exact image
are you using here? It sounds like the build process for that image
needs to be fixed to DTRT for the platform. Then you and other users
won't be bitten by this problem...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll

Bug#990808: Bug#991073: unblock: ganglia-modules-linux/1.3.4-5

[Graham Inggs]

Control: tags -1 + moreinfo confirmed

Hi Marcos

On Tue, 13 Jul 2021 at 17:33, Marcos Fouces   wrote:
> I still not uploaded the package to sid waiting for aproval.

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

Regards
Graham

Bug#991015: Acknowledgement (cannot execute due to incorrect shebang line)

[Adrian Bunk]

On Fri, Jul 16, 2021 at 11:11:44AM -0300, Antonio Terceiro wrote:
> On Tue, Jul 13, 2021 at 12:48:49PM +0300, Adrian Bunk wrote:
> > On Mon, Jul 12, 2021 at 09:10:15PM -0400, Ryan Kavanagh wrote:
> > > This bug seems to be, in part, due to a potentially (?) broken ruby
> > > upgrade behaviour. I've been running unstable on this laptop for ~6
> > > years, but still had
> > > 
> > > ii  ruby2.1 [ruby-interpreter]  2.1.5-4
> > > ii  ruby2.2 [ruby-interpreter]  2.2.4-1
> > > 
> > > installed as my only ruby interpreters. These are no longer available in
> > > unstable, and ruby2.1 was last available in:
> > > 
> > > ruby2.1| 2.1.5-2+deb8u3 | oldoldstable | source, amd64, armel, armhf, 
> > > i386
> > > 
> > > Will users upgrading from buster to bullseye will encounter a similar
> > > issue if they've dist-upgraded from jessie to stretch to buster?
> >
> > The problem is the following in the dependencies:
> >   Depends: ruby | ruby-interpreter, ...
> > 
> > The /usr/bin/ruby symlink is in the ruby package,
> > the alternative dependency ruby-interpreter is
> > therefore wrong.
> 
> We noticed that a while ago, and ruby2.2 was the last of the rubyX.Y
> packages to actually provide `ruby-interpreter`.

Thanks for this information.

> At this point, there are 900+ packages that still depend on `ruby |
> ruby-interpreter`, so this isn't something we can easily fix. I will
> submit a lintian check for this to get eventually fixed, but it will
> take a while.
>...

~ 90% of these seem to be Ruby modules, it is not obvious to me that
"ruby | ruby-interpreter" is even a bug for these.

A bookworm MBF for the small part that are non-interpreter packages 
might be an option?

cu
Adrian

Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

[Steve McIntyre]

On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote:
>On Sat, 10 Jul 2021 23:15:15 +0100 Colin Watson  wrote:
>> In general, this means that grub-install is not installing to the place
>> that your firmware is actually booting from, which causes the core image
>> (installed to a file under /boot/efi/ on UEFI systems) to be out of sync
>> with the modules (installed to a subdirectory of /boot/grub/).  This is
>> much rarer on UEFI systems than on BIOS systems, but it's still possible
>> in some misconfigured cases.
>> 
>> Could you please attach the output of "sudo grub-install --debug", "sudo
>> efibootmgr -v", and "sudo find /boot/efi -ls"?
>
>Thanks for looking into this issue.
>
>I did some investigating this morning for my situation, and found the
>problem.  Your suggestion is what helped me.
>
>The test case I had was that if you start a new Debian ARM VM on AWS, and run
>grub-install on it, future boots fail, where they stop at the rescue prompt
>and an "insmod normal" shows the error message.  In other words,
>"grub-install" was breaking grub, which is pretty bad.
>
>After some investigating I found that grub-install was writing the EFI boot
>loader image (grubaa64.efi) to the wrong location on the system. It should be
>installing into /boot/efi/EFI/BOOT but is putting it into
>/boot/efi/EFI/debian.  Future boots fail because the loader image that
>executes (the one in BOOT) is the older version and is out of sync with the
>modules.
>
>I tried deleting the /boot/efi/EFI/BOOT folder to see what would happen,
>wondering if it would try to use the "EFI/debian" one, and after rebooting
>the system was stuck in an EFI shell (couldn't find a boot loader), so the
>"EFI/debian" folder is clearly wrong.  This could be similar to what's
>happening with others on here.

EFI/debian is *NOT* wrong, it's the correct location for a system that
has working firmware which supports setting UEFI boot variables. If
you *also* need to write a copy of grub (etc.) to the removable media
location (EFI/boot) then that's supported as well by the Debian
packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the
system asks about that.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Bug#990901: putty: CVE-2021-36367

[Jacob Nevins]

For the record,

contains upstream's response to the wording of CVE-2021-36367.

Bug#991201: unblock: refpolicy/2:2.20210203-7

[Russell Coker]

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

Please unblock package refpolicy

[ Reason ]
Improvement to policy for certbot, dhcp, mon, fsadm, and java.

[ Impact ]
This allows certbot to work out of the box on the first run.
It correctly labels dhclient hooks scripts and wide-dhcpv6-client hooks.
Changes to mon and fsadm policy support megaraid (AKA PERC) RAID controllers.
Made the Java policy work for JRE 17.

[ Tests ]
Tested all of this manually.

[ Risks ]
No real risk, just added new allow rules.

[ 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 refpolicy/2:2.20210203-7

diff -Nru refpolicy-2.20210203/debian/changelog 
refpolicy-2.20210203/debian/changelog
--- refpolicy-2.20210203/debian/changelog   2021-05-08 17:55:06.0 
+1000
+++ refpolicy-2.20210203/debian/changelog   2021-06-14 09:47:05.0 
+1000
@@ -1,3 +1,19 @@
+refpolicy (2:2.20210203-7) unstable; urgency=medium
+
+  * Allow certbot to create /var/log/letsencrypt and /var/lib/letsencrypt
+  * Label /etc/wide-dhcpv6/dhcp6c-ifupdown /etc/wide-dhcpv6/dhcp6c-script
+/etc/dhcp/dhclient-enter-hooks.d/* and /etc/dhcp/dhclient-exit-hooks.d/*
+as bin_t.
+  * Allow mon_local_test_t to run smartctl in fsadm_t for megaraid and other
+corner cases and allowed fsadm_t to read fsdaemon_var_lib_t.  Dontaudit
+fsadm_t inheriting file handles from mon_t.
+  * Allow fsadm_t to do a file type trans for creating
+/dev/megaraid_sas_ioctl_node
+  * Allow java_t to exec bin_t and lib_t files for jspawnhelper, and to read
+cgroup files.  Needed for JRE 17
+
+ -- Russell Coker   Mon, 14 Jun 2021 09:47:05 +1000
+
 refpolicy (2:2.20210203-6) unstable; urgency=medium
 
   * Add policy for cockpit web admin tool
diff -Nru refpolicy-2.20210203/debian/patches/0027-services 
refpolicy-2.20210203/debian/patches/0027-services
--- refpolicy-2.20210203/debian/patches/0027-services   2021-05-06 
04:09:33.0 +1000
+++ refpolicy-2.20210203/debian/patches/0027-services   2021-06-14 
09:47:05.0 +1000
@@ -217,26 +217,6 @@
  dev_rw_xserver_misc(boinc_t)
  
  domain_read_all_domains_state(boinc_t)
-Index: refpolicy-2.20210203/policy/modules/services/certbot.te
-===
 refpolicy-2.20210203.orig/policy/modules/services/certbot.te
-+++ refpolicy-2.20210203/policy/modules/services/certbot.te
-@@ -80,11 +80,15 @@ corenet_tcp_connect_dns_port(certbot_t)
- # bind to http port for standalone mode
- corenet_tcp_bind_http_port(certbot_t)
- 
-+dev_read_urand(certbot_t)
-+
- domain_use_interactive_fds(certbot_t)
- 
- files_read_etc_files(certbot_t)
- files_read_usr_files(certbot_t)
- 
-+# dontaudit for attempts to write python cache files
-+libs_dontaudit_write_lib_dirs(certbot_t)
- libs_exec_ldconfig(certbot_t)
- # for /usr/lib/gcc/x86_64-linux-gnu/8/collect2
- libs_exec_lib_files(certbot_t)
 Index: refpolicy-2.20210203/policy/modules/services/clamav.te
 ===
 --- refpolicy-2.20210203.orig/policy/modules/services/clamav.te
@@ -561,7 +541,7 @@
  files_read_usr_files(mon_local_test_t)
  files_search_mnt(mon_local_test_t)
  files_search_spool(mon_local_test_t)
-@@ -197,8 +203,11 @@ files_list_boot(mon_local_test_t)
+@@ -197,9 +203,13 @@ files_list_boot(mon_local_test_t)
  fs_search_auto_mountpoints(mon_local_test_t)
  fs_getattr_nfs(mon_local_test_t)
  fs_getattr_xattr_fs(mon_local_test_t)
@@ -571,9 +551,11 @@
 +fs_read_cgroup_files(mon_local_test_t)
 +fs_search_cgroup_dirs(mon_local_test_t)
  fs_search_nfs(mon_local_test_t)
++fstools_domtrans(mon_local_test_t)
  
  storage_getattr_fixed_disk_dev(mon_local_test_t)
-@@ -211,12 +220,14 @@ application_exec_all(mon_local_test_t)
+ storage_getattr_removable_dev(mon_local_test_t)
+@@ -211,12 +221,14 @@ application_exec_all(mon_local_test_t)
  
  auth_use_nsswitch(mon_local_test_t)
  
@@ -1765,3 +1747,130 @@
  dontaudit inetd_t self:capability sys_tty_config;
  allow inetd_t self:process { setsched setexec setrlimit };
  allow inetd_t self:fifo_file rw_fifo_file_perms;
+Index: refpolicy-2.20210203/policy/modules/kernel/corecommands.fc
+===
+--- refpolicy-2.20210203.orig/policy/modules/kernel/corecommands.fc
 refpolicy-2.20210203/policy/modules/kernel/corecommands.fc
+@@ -43,6 +43,8 @@ ifdef(`distro_redhat',`
+ /etc/cron\.monthly(/.*)?  
gen_context(system_u:object_r:bin_t,s0)
+ 
+ /etc/dhcp/dhclient\.d(/.*)?   gen_context(system_u:object_r:bin_t,s0)
++/etc/dhcp/dhclient-enter-hooks.d(/.*)? -- 
gen_context(system_u:object_r:bin_t,s0)
++/etc/dhcp/dhclient-exit-hooks.d(/.*)? --  
gen_context(system_u:object_r:bin_t,s0)
+ 
+ /etc/hotplug/.*agent  --  

Bug#991207: unblock: dlib/19.10-3.1

[Adrian Bunk]

On Sat, Jul 17, 2021 at 04:23:45PM +0300, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package dlib
> 
>   * Backport upstream fix for using cv_image.h with OpenCV 4,
> thanks to Alexandr Podgorniy. (Closes: #990676)
> 
> This fixes compiling code using cv_image.h with the bullseye OpenCV.

And with debdiff attached.

cu
Adrian
diff -Nru dlib-19.10/debian/changelog dlib-19.10/debian/changelog
--- dlib-19.10/debian/changelog 2019-01-17 09:17:25.0 +0200
+++ dlib-19.10/debian/changelog 2021-07-15 17:19:19.0 +0300
@@ -1,3 +1,11 @@
+dlib (19.10-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for using cv_image.h with OpenCV 4,
+thanks to Alexandr Podgorniy. (Closes: #990676)
+
+ -- Adrian Bunk   Thu, 15 Jul 2021 17:19:19 +0300
+
 dlib (19.10-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
dlib-19.10/debian/patches/0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch
 
dlib-19.10/debian/patches/0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch
--- 
dlib-19.10/debian/patches/0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch
   1970-01-01 02:00:00.0 +0200
+++ 
dlib-19.10/debian/patches/0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch
   2021-07-15 17:02:19.0 +0300
@@ -0,0 +1,33 @@
+From eea91537ac73498153266984da28c202965b75de Mon Sep 17 00:00:00 2001
+From: Davis King 
+Date: Sun, 22 Dec 2019 07:52:08 -0500
+Subject: Fix opencv version check to work on all opencv versions
+
+---
+ dlib/opencv/cv_image.h | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/dlib/opencv/cv_image.h b/dlib/opencv/cv_image.h
+index 5f224d00..05af0551 100644
+--- a/dlib/opencv/cv_image.h
 b/dlib/opencv/cv_image.h
+@@ -34,7 +34,16 @@ namespace dlib
+  << "\n\t img.channels(): " << img.channels() 
+  << "\n\t img.pixel_traits::num: " << 
pixel_traits::num 
+  );
++// Note, do NOT use CV_VERSION_MAJOR because in OpenCV 2 CV_VERSION_MAJOR 
actually held
++// CV_VERSION_MINOR and instead they used CV_VERSION_EPOCH.  So for example, 
in OpenCV
++// 2.4.9.1 CV_VERSION_MAJOR==4 and CV_VERSION_EPOCH==2.  However, 
CV_MAJOR_VERSION has always
++// (seemingly) held the actual major version number, so we use that to test 
for the OpenCV major
++// version.
++#if CV_MAJOR_VERSION > 3
++IplImage temp = cvIplImage(img);
++#else
+ IplImage temp = img;
++#endif
+ init();
+ }
+ 
+-- 
+2.20.1
+
diff -Nru dlib-19.10/debian/patches/series dlib-19.10/debian/patches/series
--- dlib-19.10/debian/patches/series2019-01-17 08:43:25.0 +0200
+++ dlib-19.10/debian/patches/series2021-07-15 17:19:17.0 +0300
@@ -1 +1,2 @@
 fix-soname.patch
+0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch

Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

[Ryan Thoryk]

On 7/17/21 8:18 AM, Steve McIntyre wrote:

On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote:
EFI/debian is *NOT* wrong, it's the correct location for a system that
has working firmware which supports setting UEFI boot variables. If
you *also* need to write a copy of grub (etc.) to the removable media
location (EFI/boot) then that's supported as well by the Debian
packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the
system asks about that.



Thanks for that suggestion, that explains the correct procedure in 
resolving the issue.  What I'm trying to point out though (I tried 
this), is that if you spin up a new Debian ARM VM on AWS, and run 
"grub-install" *without* doing a dpkg-reconfigure, it results in an 
unbootable system.  To recover the system, you have to attach the disk 
on a different VM and replace the old boot loader image with the new 
one, then it boots again.  After running the dpkg-reconfigure command 
though like you suggested, it copied over the EFI boot image to the 
"BOOT" folder, and also set the nvram variables to apparently boot from 
the "debian" folder, so that solved the problem for me.  After doing 
that, the system comes up after a reboot with the newer grub modules.


With others on here, the issue might have to do with the system 
executing an older EFI boot image resulting in a module mismatch, like 
what happened to me.  Your dpkg-reconfigure suggestion might fix their 
issues too.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#991211: unblock: debian-crossgrader/0.0.3+nmu3

[Adrian Bunk]

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

Please unblock package debian-crossgrader

  * Purge with --force-remove-protected in the third stage to
avoid failures due to packages that recently became protected.
(Closes: #990669)

This regression caused by changes in bullseye was hidden
when #968458 in python-apt made crossgrader fail even earlier.
diff -Nru debian-crossgrader-0.0.3+nmu2/debian/changelog 
debian-crossgrader-0.0.3+nmu3/debian/changelog
--- debian-crossgrader-0.0.3+nmu2/debian/changelog  2020-12-12 
23:22:05.0 +0200
+++ debian-crossgrader-0.0.3+nmu3/debian/changelog  2021-07-14 
20:23:38.0 +0300
@@ -1,3 +1,12 @@
+debian-crossgrader (0.0.3+nmu3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Purge with --force-remove-protected in the third stage to
+avoid failures due to packages that recently became protected.
+(Closes: #990669)
+
+ -- Adrian Bunk   Wed, 14 Jul 2021 20:23:38 +0300
+
 debian-crossgrader (0.0.3+nmu2) unstable; urgency=medium
 
   * NMU
diff -Nru debian-crossgrader-0.0.3+nmu2/debian_crossgrader/__main__.py 
debian-crossgrader-0.0.3+nmu3/debian_crossgrader/__main__.py
--- debian-crossgrader-0.0.3+nmu2/debian_crossgrader/__main__.py
2020-09-06 19:13:29.0 +0300
+++ debian-crossgrader-0.0.3+nmu3/debian_crossgrader/__main__.py
2021-07-11 19:22:28.0 +0300
@@ -138,7 +138,7 @@
 return
 
 if cont == 'y':
-subprocess.check_call(['dpkg', '--purge'] + targets)
+subprocess.check_call(['dpkg', '--purge', 
'--force-remove-protected'] + targets)
 remaining = apt_utils.get_arch_packages(foreign_arch)
 if args.packages:
 remaining = [pkg_name for pkg_name in remaining if pkg_name 
not in args.packages]

Bug#991202: unblock: dask.distributed/2021.01.0+ds.1-2.1

[Adrian Bunk]

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

Please unblock package dask.distributed

  * Backport upstream fix removing tests that fail under some
circumstances. (Closes: #987816)
  * python-distributed-doc: Fix broken symlink to html5shiv.min.js,
dh_link needs absolute paths. (Closes: #988675)
diff -Nru dask.distributed-2021.01.0+ds.1/debian/changelog 
dask.distributed-2021.01.0+ds.1/debian/changelog
--- dask.distributed-2021.01.0+ds.1/debian/changelog2021-02-01 
22:08:19.0 +0200
+++ dask.distributed-2021.01.0+ds.1/debian/changelog2021-07-13 
19:19:56.0 +0300
@@ -1,3 +1,13 @@
+dask.distributed (2021.01.0+ds.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix removing tests that fail under some
+circumstances. (Closes: #987816)
+  * python-distributed-doc: Fix broken symlink to html5shiv.min.js,
+dh_link needs absolute paths. (Closes: #988675)
+
+ -- Adrian Bunk   Tue, 13 Jul 2021 19:19:56 +0300
+
 dask.distributed (2021.01.0+ds.1-2) unstable; urgency=medium
 
   * Add fall-back-to-ipv6-localhost.patch to work around ipv6 networking
diff -Nru 
dask.distributed-2021.01.0+ds.1/debian/patches/0001-Remove-tests-for-process_time-and-thread_time-4895.patch
 
dask.distributed-2021.01.0+ds.1/debian/patches/0001-Remove-tests-for-process_time-and-thread_time-4895.patch
--- 
dask.distributed-2021.01.0+ds.1/debian/patches/0001-Remove-tests-for-process_time-and-thread_time-4895.patch
1970-01-01 02:00:00.0 +0200
+++ 
dask.distributed-2021.01.0+ds.1/debian/patches/0001-Remove-tests-for-process_time-and-thread_time-4895.patch
2021-07-13 19:19:56.0 +0300
@@ -0,0 +1,73 @@
+From 668f3f1d38c27277448af6f5aa88741cd1d33f3b Mon Sep 17 00:00:00 2001
+From: James Bourbeau 
+Date: Wed, 9 Jun 2021 08:57:53 -0500
+Subject: Remove tests for `process_time` and `thread_time` (#4895)
+
+---
+ distributed/tests/test_metrics.py | 46 ---
+ 1 file changed, 46 deletions(-)
+
+diff --git a/distributed/tests/test_metrics.py 
b/distributed/tests/test_metrics.py
+index 3a27e638..58c33266 100644
+--- a/distributed/tests/test_metrics.py
 b/distributed/tests/test_metrics.py
+@@ -1,9 +1,6 @@
+-import sys
+-import threading
+ import time
+ 
+ from distributed import metrics
+-from distributed.utils_test import run_for
+ 
+ 
+ def test_wall_clock():
+@@ -18,46 +15,3 @@ def test_wall_clock():
+ assert any(lambda d: 0.0 < d < 0.0001 for d in deltas), deltas
+ # Close to time.time()
+ assert t - 0.5 < samples[0] < t + 0.5
+-
+-
+-def test_process_time():
+-start = metrics.process_time()
+-run_for(0.05)
+-dt = metrics.process_time() - start
+-assert 0.03 <= dt <= 0.2
+-
+-# All threads counted
+-t = threading.Thread(target=run_for, args=(0.1,))
+-start = metrics.process_time()
+-t.start()
+-t.join()
+-dt = metrics.process_time() - start
+-assert dt >= 0.05
+-
+-# Sleep time not counted
+-start = metrics.process_time()
+-time.sleep(0.1)
+-dt = metrics.process_time() - start
+-assert dt <= 0.05
+-
+-
+-def test_thread_time():
+-start = metrics.thread_time()
+-run_for(0.05)
+-dt = metrics.thread_time() - start
+-assert 0.03 <= dt <= 0.2
+-
+-# Sleep time not counted
+-start = metrics.thread_time()
+-time.sleep(0.1)
+-dt = metrics.thread_time() - start
+-assert dt <= 0.05
+-
+-if sys.platform == "linux":
+-# Always per-thread on Linux
+-t = threading.Thread(target=run_for, args=(0.1,))
+-start = metrics.thread_time()
+-t.start()
+-t.join()
+-dt = metrics.thread_time() - start
+-assert dt <= 0.05
+-- 
+2.20.1
+
diff -Nru dask.distributed-2021.01.0+ds.1/debian/patches/series 
dask.distributed-2021.01.0+ds.1/debian/patches/series
--- dask.distributed-2021.01.0+ds.1/debian/patches/series   2021-02-01 
21:51:15.0 +0200
+++ dask.distributed-2021.01.0+ds.1/debian/patches/series   2021-07-13 
19:19:56.0 +0300
@@ -7,3 +7,4 @@
 use-local-favicon.patch
 mark-tests-require-installation.patch
 fall-back-to-ipv6-localhost.patch
+0001-Remove-tests-for-process_time-and-thread_time-4895.patch
diff -Nru dask.distributed-2021.01.0+ds.1/debian/python-distributed-doc.links 
dask.distributed-2021.01.0+ds.1/debian/python-distributed-doc.links
--- dask.distributed-2021.01.0+ds.1/debian/python-distributed-doc.links 
2021-01-17 05:54:55.0 +0200
+++ dask.distributed-2021.01.0+ds.1/debian/python-distributed-doc.links 
2021-07-13 19:19:56.0 +0300
@@ -1 +1 @@
-../../../../sphinx_rtd_theme/static/js/html5shiv.min.js 
usr/share/doc/python-distributed-doc/html/_static/js/html5shiv.min.js
+/usr/share/sphinx_rtd_theme/static/js/html5shiv.min.js 
usr/share/doc/python-distributed-doc/html/_static/js/html5shiv.min.js

Bug#991189: unblock: fail2ban/0.11.2-2

[Graham Inggs]

Control: tags -1 + moreinfo

Hi Salvatore

On Fri, 16 Jul 2021 at 21:24, Salvatore Bonaccorso  wrote:
> fail2ban is affected by CVE-2021-32749, see detailed advisory in
> https://github.com/fail2ban/fail2ban/security/advisories/GHSA-m985-3f3v-cwmm,
> which is a possible remote code execution vulnerability in the mailing
> action mail-whois.

fail2ban (0.11.2-2) unstable; urgency=high

  * Fix a problem with mail

 -- Sylvestre Ledru   Mon, 12 Jul 2021 06:52:40 +0200

Would it be better to have the CVE mentioned in the changelog?

Regards
Graham

Bug#991204: exim4-daemon-heavy: Please add SPF support

[Wouter Verhelst]

Package: exim4-daemon-heavy
Version: 4.94.2-6
Followup-For: Bug #528344

Perhaps important to note is that both DMARC and (currently still
experimental, but...) ARC both depend on the builtin SPF support. While
the SPF "support" by calling an external binary may work for SPF checks
at a cost of a fork per ACL test (i.e., some performance penalty), this
is not the case for the extra functionality that depends on the builtin
SPF support, such as sending out DMARC validation reports, and adding
ARC headers (to mitigate the issues with forwarding emails).

Please seriously consider this wishlist item for bookworm already...

Bug#991206: unblock: x264/2:0.160.3011+gitcde9a93-2.1

[Adrian Bunk]

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

Please unblock package x264

  * Backport upstream fix to support GPAC >= 0.8.0. (Closes: #975441)

This fixes a regression from buster by restoring MP4 output in the x264
binary, the library is unchanged.
diff -Nru x264-0.160.3011+gitcde9a93/debian/changelog 
x264-0.160.3011+gitcde9a93/debian/changelog
--- x264-0.160.3011+gitcde9a93/debian/changelog 2020-07-26 17:52:56.0 
+0300
+++ x264-0.160.3011+gitcde9a93/debian/changelog 2021-07-15 15:06:22.0 
+0300
@@ -1,3 +1,10 @@
+x264 (2:0.160.3011+gitcde9a93-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix to support GPAC >= 0.8.0. (Closes: #975441)
+
+ -- Adrian Bunk   Thu, 15 Jul 2021 15:06:22 +0300
+
 x264 (2:0.160.3011+gitcde9a93-2) unstable; urgency=medium
 
   * Team upload
diff -Nru 
x264-0.160.3011+gitcde9a93/debian/patches/0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch
 
x264-0.160.3011+gitcde9a93/debian/patches/0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch
--- 
x264-0.160.3011+gitcde9a93/debian/patches/0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch
 1970-01-01 02:00:00.0 +0200
+++ 
x264-0.160.3011+gitcde9a93/debian/patches/0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch
 2021-07-15 15:06:22.0 +0300
@@ -0,0 +1,58 @@
+From 7c2004b58c26da661618262c9c06b73ad3a9ff6c Mon Sep 17 00:00:00 2001
+From: "A. David" 
+Date: Thu, 2 Jul 2020 19:45:50 +0200
+Subject: mp4: Update GPAC support to v0.8.0 or later
+
+---
+ configure| 5 +++--
+ output/mp4.c | 6 +-
+ 2 files changed, 8 insertions(+), 3 deletions(-)
+
+Index: x264-0.160.3011+gitcde9a93/configure
+===
+--- x264-0.160.3011+gitcde9a93.orig/configure
 x264-0.160.3011+gitcde9a93/configure
+@@ -1240,15 +1240,16 @@ if [ "$gpac" = "auto" -a "$lsmash" != "y
+ gpac="no"
+ GPAC_LIBS="-lgpac"
+ cc_check "" -lz && GPAC_LIBS="$GPAC_LIBS -lz"
++cc_check "" -ldl && GPAC_LIBS="$GPAC_LIBS -ldl"
+ if [ "$SYS" = "WINDOWS" ] ; then
+ cc_check "" -lws2_32 && GPAC_LIBS="$GPAC_LIBS -lws2_32"
+ cc_check "" -lwinmm && GPAC_LIBS="$GPAC_LIBS -lwinmm"
+ fi
+ if cc_check gpac/isomedia.h "$GPAC_LIBS" "gf_isom_close(0);" ; then
+-if cc_check gpac/isomedia.h "$GPAC_LIBS" 
"gf_isom_set_pixel_aspect_ratio(0,0,0,0,0);" ; then
++if cc_check gpac/isomedia.h "$GPAC_LIBS" 
"gf_isom_set_pixel_aspect_ratio(0,0,0,0,0,0);" ; then
+ gpac="yes"
+ else
+-echo "Warning: gpac is too old, update to 2007-06-21 UTC or later"
++echo "Warning: gpac is too old, update to v0.8.0 or later"
+ fi
+ fi
+ fi
+Index: x264-0.160.3011+gitcde9a93/output/mp4.c
+===
+--- x264-0.160.3011+gitcde9a93.orig/output/mp4.c
 x264-0.160.3011+gitcde9a93/output/mp4.c
+@@ -147,7 +147,11 @@ static int close_file( hnd_t handle, int
+ {
+ uint32_t mvhd_timescale = gf_isom_get_timescale( 
p_mp4->p_file );
+ uint64_t tkhd_duration = (uint64_t)( mdhd_duration * ( 
(double)mvhd_timescale / p_mp4->i_time_res ) );
++#if GPAC_VERSION_MAJOR > 8
++gf_isom_append_edit( p_mp4->p_file, p_mp4->i_track, 
tkhd_duration, sample->CTS_Offset, GF_ISOM_EDIT_NORMAL );
++#else
+ gf_isom_append_edit_segment( p_mp4->p_file, p_mp4->i_track, 
tkhd_duration, sample->CTS_Offset, GF_ISOM_EDIT_NORMAL );
++#endif
+ }
+ gf_isom_sample_del(  );
+ 
+@@ -233,7 +237,7 @@ static int set_param( hnd_t handle, x264
+ dw *= sar;
+ else
+ dh /= sar;
+-gf_isom_set_pixel_aspect_ratio( p_mp4->p_file, p_mp4->i_track, 
p_mp4->i_descidx, p_param->vui.i_sar_width, p_param->vui.i_sar_height );
++gf_isom_set_pixel_aspect_ratio( p_mp4->p_file, p_mp4->i_track, 
p_mp4->i_descidx, p_param->vui.i_sar_width, p_param->vui.i_sar_height, 0 );
+ gf_isom_set_track_layout_info( p_mp4->p_file, p_mp4->i_track, dw, dh, 
0, 0, 0 );
+ }
+ 
diff -Nru x264-0.160.3011+gitcde9a93/debian/patches/series 
x264-0.160.3011+gitcde9a93/debian/patches/series
--- x264-0.160.3011+gitcde9a93/debian/patches/series2020-06-21 
12:40:55.0 +0300
+++ x264-0.160.3011+gitcde9a93/debian/patches/series2021-07-15 
15:06:22.0 +0300
@@ -1,2 +1,3 @@
 link_gpac_dynamically.patch
 properly_detect_x32.patch
+0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch

Bug#481081: Maildir appendfile names longer than they need to be

[Andreas Metzler]

On 2008-05-13 Andrew Buckeridge  wrote:
> Package: exim4
> Version: 4.69-2
> Severity: wishlist

> In ~/Maildir/cur/ I have: -
> 1210666181.H610983P31901.203.161.103.17.static.amnet.net.au
>^^^   ^^

> The Microseconds should start with M.
[...]

This part is fixed in 4.95 (rc0):

JH/01 Bug 1329: Fix format of Maildir-format filenames to match other mail-
  related applications.  Previously an "H" was used where available info
  says that "M" should be, so change to match.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#856480: O: mp3blaster -- Full-screen console mp3 and Ogg Vorbis player

[Frederico Muñoz]

Hello,


On Wed, 01 Mar 2017 18:20:51 +0500 Andrey Rahmatullin 
wrote:
> Package: wnpp
> Severity: normal
> 
> Per a private request of the maintainer, Jochen Friedrich, I'm
orphaning this
> package.

I'm a previous Debian Developer (removed since 2005 though) and I've
been wanting to get back in contributing; I use mp3blaster since ever
so this would for me be a great way to get back in the game. If it's
still up for grabs I am interested.

Best regards,

-- 
Frederico Muñoz
fsmu...@gmail.com

Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

[Ryan Thoryk]

On Sat, 10 Jul 2021 23:15:15 +0100 Colin Watson  wrote:

In general, this means that grub-install is not installing to the place
that your firmware is actually booting from, which causes the core image
(installed to a file under /boot/efi/ on UEFI systems) to be out of sync
with the modules (installed to a subdirectory of /boot/grub/).  This is
much rarer on UEFI systems than on BIOS systems, but it's still possible
in some misconfigured cases.

Could you please attach the output of "sudo grub-install --debug", "sudo
efibootmgr -v", and "sudo find /boot/efi -ls"?



Thanks for looking into this issue.

I did some investigating this morning for my situation, and found the 
problem.  Your suggestion is what helped me.


The test case I had was that if you start a new Debian ARM VM on AWS, 
and run grub-install on it, future boots fail, where they stop at the 
rescue prompt and an "insmod normal" shows the error message.  In other 
words, "grub-install" was breaking grub, which is pretty bad.


After some investigating I found that grub-install was writing the EFI 
boot loader image (grubaa64.efi) to the wrong location on the system. 
It should be installing into /boot/efi/EFI/BOOT but is putting it into 
/boot/efi/EFI/debian.  Future boots fail because the loader image that 
executes (the one in BOOT) is the older version and is out of sync with 
the modules.


I tried deleting the /boot/efi/EFI/BOOT folder to see what would happen, 
wondering if it would try to use the "EFI/debian" one, and after 
rebooting the system was stuck in an EFI shell (couldn't find a boot 
loader), so the "EFI/debian" folder is clearly wrong.  This could be 
similar to what's happening with others on here.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#991207: unblock: dlib/19.10-3.1

[Adrian Bunk]

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

Please unblock package dlib

  * Backport upstream fix for using cv_image.h with OpenCV 4,
thanks to Alexandr Podgorniy. (Closes: #990676)

This fixes compiling code using cv_image.h with the bullseye OpenCV.

Bug#991060: Processed: mlpost FTBFS with imagemagick with the #987504 change

[Dennis Filder]

On Sat, Jul 17, 2021 at 10:42:03AM +0200, Stéphane Glondu wrote:

> Package builds are not allowed to fiddle with $HOME like that, by
> policy: what if the builder already has its own imagemagick policy? But
> I think your idea can be used: create a temporary home directory (e.g.
> in debian or /tmp), and set $HOME to that.

mlpost expresses "debhelper-compat (= 13)" in d/control.  From the manpage:

   HOME, XDG_*
   In compat 13 and later, these environment variables are reset
   before invoking the upstream build system via the dh_auto_*
   helpers.  The variables HOME (all dh_auto_* helpers) and
   XDG_RUNTIME_DIR (dh_auto_test only) will be set to a writable
   directory. All remaining variables and XDG_RUNTIME_DIR (except for
   during dh_auto_test) will be cleared.

   The HOME directory will be created as an empty directory but it
   will be reused between calls to dh_auto_*.  Any content will
   persist until explicitly deleted or dh_clean.

So there should be no problems.  In my patches for other packages
affected by this and not yet on 13 I used XDG_CONFIG_HOME and
created/removed a tempdir under debian/tmp by hand.  But relying on
dh_clean is more consistent.

Regards,
Dennis.

Bug#991195: appdirs: Friendly Fork: platformdirs

[stefanor]

Hi Debian (2021.07.17_01:00:13_+)
> Upstream there has been a friendly fork of appdirs to "platformdirs".
> Assuming this is the future of the library, we should migrate debian
> packages from appdirs to platformdirs, once it's in the archive.

Uploaded to NEW, under the python-team:
https://salsa.debian.org/python-team/packages/platformdirs

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#991209: unblock: minetest/5.3.0+repack-2.1

[Adrian Bunk]

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

Please unblock package minetest

  * Add upstream fix for errors caused by missing param2
in falling.lua, thanks to Craig Small. (Closes: #990923)
diff -Nru minetest-5.3.0+repack/debian/changelog 
minetest-5.3.0+repack/debian/changelog
--- minetest-5.3.0+repack/debian/changelog  2021-01-31 15:41:26.0 
+0200
+++ minetest-5.3.0+repack/debian/changelog  2021-07-15 18:55:57.0 
+0300
@@ -1,3 +1,11 @@
+minetest (5.3.0+repack-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for errors caused by missing param2
+in falling.lua, thanks to Craig Small. (Closes: #990923)
+
+ -- Adrian Bunk   Thu, 15 Jul 2021 18:55:57 +0300
+
 minetest (5.3.0+repack-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru 
minetest-5.3.0+repack/debian/patches/0001-Falling-Fix-error-caused-by-missing-param2.patch
 
minetest-5.3.0+repack/debian/patches/0001-Falling-Fix-error-caused-by-missing-param2.patch
--- 
minetest-5.3.0+repack/debian/patches/0001-Falling-Fix-error-caused-by-missing-param2.patch
  1970-01-01 02:00:00.0 +0200
+++ 
minetest-5.3.0+repack/debian/patches/0001-Falling-Fix-error-caused-by-missing-param2.patch
  2021-07-15 18:55:34.0 +0300
@@ -0,0 +1,26 @@
+From aba8c3753162320c7cc8a66913ad82f4f1fd0d8b Mon Sep 17 00:00:00 2001
+From: SmallJoker 
+Date: Thu, 30 Jul 2020 19:03:48 +0200
+Subject: Falling: Fix error caused by missing param2
+
+Falling nodes that were spawned prior the recent falling node changes did not 
require param2.
+Default to param2 = 0 when none is found in the node data.
+---
+ builtin/game/falling.lua | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/builtin/game/falling.lua b/builtin/game/falling.lua
+index 714506a5f..4bfcca9e7 100644
+--- a/builtin/game/falling.lua
 b/builtin/game/falling.lua
+@@ -52,6 +52,7 @@ core.register_entity(":__builtin:falling_node", {
+   floats = false,
+ 
+   set_node = function(self, node, meta)
++  node.param2 = node.param2 or 0
+   self.node = node
+   meta = meta or {}
+   if type(meta.to_table) == "function" then
+-- 
+2.20.1
+
diff -Nru minetest-5.3.0+repack/debian/patches/series 
minetest-5.3.0+repack/debian/patches/series
--- minetest-5.3.0+repack/debian/patches/series 2021-01-31 11:43:36.0 
+0200
+++ minetest-5.3.0+repack/debian/patches/series 2021-07-15 18:55:53.0 
+0300
@@ -2,3 +2,4 @@
 shared_mods.patch
 rawlua.patch
 postgresql.patch
+0001-Falling-Fix-error-caused-by-missing-param2.patch

Bug#991212: python3-myhdl: myhdl always crashes in python3.9/ast.py

[Michael Büsch]

Package: python3-myhdl
Version: 0.11-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: m...@bues.ch

Result of running a very simple MyHDL file with Python 3.9 (Debian Sid):

$ python3 ./myhdltest.py
Traceback (most recent call last):
  File "..././myhdltest.py", line 14, in 
instance.convert(hdl='Verilog')
  File "/usr/lib/python3/dist-packages/myhdl/_block.py", line 342, in convert
return converter(self)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_toVerilog.py", line
177, in __call__
genlist = _analyzeGens(arglist, h.absnames)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 170,
in _analyzeGens
v.visit(tree)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line
1119, in visit_Module
_AnalyzeBlockVisitor.visit_Module(self, node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line
1070, in visit_Module
self.generic_visit(node)
  File "/usr/lib/python3.9/ast.py", line 415, in generic_visit
self.visit(item)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line
1099, in visit_FunctionDef
self.visit(n)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 521,
in visit_Assign
self.visit(target)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 466,
in visit_Attribute
self.setAttr(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 482,
in setAttr
self.visit(node.value)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 962,
in visit_Subscript
self.accessIndex(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 986,
in accessIndex
self.visit(node.slice.value)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3.9/ast.py", line 411, in generic_visit
for field, value in iter_fields(node):
  File "/usr/lib/python3.9/ast.py", line 249, in iter_fields
for field in node._fields:
AttributeError: 'int' object has no attribute '_fields'


The myhdltest.py example does work fine with the current upstream git master of
MyHDL:

commit 7b17942abbb2d9374df13f4f1f8c9d4589e1c88c

$ PYTHONPATH=/.../git/myhdl/ python3 ./myhdltest.py
$


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

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

Versions of packages python3-myhdl depends on:
ii  python3  3.9.2-3

Versions of packages python3-myhdl recommends:
ii  myhdl-cosimulation  0.11-1

Versions of packages python3-myhdl suggests:
ii  myhdl-doc  0.11-1
from myhdl import *

@block
def myhdltest(x, y):
@always_comb
def logic():
x[0].next = y[0]
return logic

instance = myhdltest(
x=Signal(intbv(0)[1:]),
y=Signal(intbv(0)[1:])
)
instance.convert(hdl='Verilog')

Bug#991182: unblock: jailkit/2.21-4

[Eriberto]

Hi Graham,

Thank you.

Regards,

Eriberto

Bug#991213: syncmaildir FTCBFS -- uses pkg-config of build architecture

[Nilesh Patra]

Package: syncmaildir
Version: 1.3.0-1.1
Severity: normal
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Tags: patch

Dear Maintainer,

1. syncmaildir hardcodes pkg-config in Makefile, due to which the
pkg-config prefixed with the triplet of the host architecture (which
debhelper passes by default) does not propagate.

2. Other than that, the d/rules file uses $(MAKE) which can simply be
replaced by dh_auto_build to directly propagate needed flags

3. Also, since the buildsystem in Makefile based, it makes sense to add in
--buildsystem=makefile to dh $@

4. Finally, the application of patches in d/patches seems a bit weird,
since it seems that they are _applied and committed_ to the project's source 
directory and then
uploaded. While that is fine in practice, but adding new patches with
quilt 
IMO, there should be some

$ git apply -R debian/patches/replace-use-of-grep--wc-with-grep--c-for.patch
$ echo $?
0
$ git commit -am 'Remove applied patch from root'

done before uploading.

Anyways, I've implemented changes in points 1,2,3 and made a patch,
please consider to apply this.

Nilesh

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages syncmaildir depends on:
ii  libc6   2.31-3
ii  libglib2.0-02.66.0-2
pn  lua5.1  
ii  openssh-client  1:8.4p1-5
ii  xdelta  1.1.3-9.3

syncmaildir recommends no packages.

syncmaildir suggests no packages.
diff -Nru syncmaildir-1.3.0/debian/patches/cross_build.patch 
syncmaildir-1.3.0/debian/patches/cross_build.patch
--- syncmaildir-1.3.0/debian/patches/cross_build.patch  1970-01-01 
00:00:00.0 +
+++ syncmaildir-1.3.0/debian/patches/cross_build.patch  2021-04-21 
14:05:47.0 +
@@ -0,0 +1,39 @@
+diff --git a/Makefile b/Makefile
+index ee2704e..e536007 100644
+--- a/Makefile
 b/Makefile
+@@ -42,6 +42,7 @@ LUAV=5.1
+ LUA=lua$(LUAV)
+ CFLAGS=-O2 -Wall -Wextra -Wcast-align -g
+ PKG_FLAGS=
++PKG_CONFIG?=pkg-config
+ 
+ # 
+ # Rules follow...
+@@ -81,12 +82,12 @@ smd-applet.c: smd-applet.vala smd-config.vapi
+ mddiff: mddiff.c smd-config.h
+   @echo CC $<
+   $H $(CC) $(CFLAGS) $< -o $@ \
+-  `pkg-config $(PKG_FLAGS) --cflags --libs glib-2.0` $(LDFLAGS)
++  `$(PKG_CONFIG) $(PKG_FLAGS) --cflags --libs glib-2.0` $(LDFLAGS)
+ 
+ smd-applet: $(SMD_APPLET_C) smd-config.h
+   @echo CC $<
+   $H $(CC) $(CFLAGS) -w $< -o $@ \
+-  `pkg-config $(PKG_FLAGS) --cflags --libs $(PKGS_VALA)` \
++  `$(PKG_CONFIG) $(PKG_FLAGS) --cflags --libs $(PKGS_VALA)` \
+   $(LDFLAGS)
+ 
+ $(GSCHEMAS_COMPILED): $(GSCHEMAS)
+@@ -98,9 +99,9 @@ $(GSCHEMAS_COMPILED): $(GSCHEMAS)
+   echo WARN: export XDG_DATA_DIRS=\$$XDG_DATA_DIRS:xdg/
+ 
+ check-build: check-w-gcc check-w-$(VALAC) check-w-glib-compile-schemas
+-  $H pkg-config $(PKGCONFIG_CHECK_GLIB_VERSION) || \
++  $H $(PKG_CONFIG) $(PKGCONFIG_CHECK_GLIB_VERSION) || \
+   (echo glib version too old: \
+-  `pkg-config $(PKGCONFIG_GLIB_VERSION)`; \
++  `$(PKG_CONFIG) $(PKGCONFIG_GLIB_VERSION)`; \
+echo required version: $(TARGET_GLIB); \
+false)
+ 
diff -Nru syncmaildir-1.3.0/debian/patches/series 
syncmaildir-1.3.0/debian/patches/series
--- syncmaildir-1.3.0/debian/patches/series 2021-04-21 14:05:47.0 
+
+++ syncmaildir-1.3.0/debian/patches/series 2021-04-21 14:05:47.0 
+
@@ -1,2 +1,3 @@
 #link-against-gthread2
 replace-use-of-grep--wc-with-grep--c-for.patch
+cross_build.patch
diff -Nru syncmaildir-1.3.0/debian/rules syncmaildir-1.3.0/debian/rules
--- syncmaildir-1.3.0/debian/rules  2021-04-21 14:05:47.0 +
+++ syncmaildir-1.3.0/debian/rules  2021-04-21 14:05:47.0 +
@@ -1,7 +1,7 @@
 #! /usr/bin/make -f
 
 %:
-   dh $@
+   dh $@ --buildsystem=makefile
 
 # I think this makes the application more robust in face of badly set
 # PATH, since external programs are looked up with absolute paths. 
@@ -9,7 +9,7 @@
 FLAVOUR=abspath/
 
 override_dh_auto_build:
-   $(MAKE) $(FLAVOUR)all PREFIX=usr H= \
+   dh_auto_build -- $(FLAVOUR)all PREFIX=usr H= \
CFLAGS="$(shell dpkg-buildflags --get CFLAGS)" \
LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS)"
 
@@ -20,7 +20,9 @@
$(MAKE) $(FLAVOUR)install DESTDIR=debian/tmp PREFIX=usr H=
 
 override_dh_auto_test:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))

Bug#991217: reportbug: please deprioritize *-security in "apt policy"

[Adam Borowski]

Package: reportbug
Version: 7.10.3
Severity: wishlist

Hi!
If there are multiple releases with the same priority available, reportbug
chooses one based on some arbitrary order.  This results in output like on
this very bug report:
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'), 
(1, 'experimental')

By default, all present sources have priority 500 unless explicitly
configured differently, be it by the user (/etc/apt/preferences) or by the
Release file (like for experimental).  This makes sense for apt itself --
with repositories at equal priority, the package to install is determined
by version number.

But, for a human, "-security" is merely a few updated packages.

Thus, what about this hack: subtract 0.1 from each release's priority if it
matches "*-security", sort and choose, then round back to full integers
when displaying.


Meow!
-- Package-specific info:
** Environment settings:
EDITOR="jstar"
EMAIL="kilob...@angband.pl"
INTERFACE="text"

** /home/kilobyte/.reportbugrc:
reportbug_version "7.10.3"
mode advanced
ui text

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

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

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

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs-bin-common   
ii  exim4  4.94.2-7
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  file   1:5.39-3
ii  gnupg  2.2.27-2
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4.1

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

python3-reportbug suggests no packages.

-- no debconf information

Bug#991190: dpkg-fsys-usrunmess: block service activation with policy-rc.d?

[Guillem Jover]

Hi!

On Fri, 2021-07-16 at 15:23:01 -0400, Zack Weinberg wrote:
> Package: dpkg
> Version: 1.20.9
> Severity: normal
> File: /usr/sbin/dpkg-fsys-usrunmess
> X-Debbugs-Cc: za...@panix.com

> I tried to run dpkg-fsys-usrunmess from systemd’s emergency mode,
> thinking that this would be safer, since nothing else would be
> running.  This tickled a bug in systemd (see #991185) and got
> dpkg-fsys-usrunmess killed in the middle of its run—specifically,
> during the ‘dpkg --pending --configure’ operation.  As you can
> probably imagine, this is a really bad time for the process to be
> interrupted.
> 
> As a stopgap safety measure, I suggest that dpkg-fsys-usrunmess should
> use policy-rc.d to block all service activation while it’s running.

Hmm, right, that's not nice, sorry for the trouble. Hmm on one hand I
guess installing a policy-rc.d would make this safer, on the other, it
might end up not restarting services that will end up possibly using
old inodes or pathname references, which might affect service monitoring
for example, so I'm not sure what's worse.

But then I think the better option is to move the package
configuration at the end once everything has been unmessed and the
filesystem has been fully cleaned up. As «dpkg --pending --configure»
can always be issued at any later point, and should in theory be
easier to recover from. So I'm for now going to queue this one.

I'm also pondering whether any potential benefit from that step
(forcing reconfiguration of packages), to generate any potentially
missing files (which I'm not even sure it's an actual problem, but did
it out of defensive programming) is worth any potential problem this
might cause, like the one you just found. :/

Thanks,
Guillem

Bug#990345: zookeeper: various security issues

[tony mancill]

On Fri, Jul 16, 2021 at 06:43:53AM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2021-07-15 at 21:18 -0700, tony mancill wrote:
> > This is certainly a valid point.  There is not time to change the
> > situation for bullseye aside from filing an RM bug to prevent the
> > package from shipping with the release.  That would impact transitive
> > dependencies of which I believe activemq is the most significant.
> 
> Would it be possible to provide a more current version via backports...
> I mean if it's not possible to get it in via some stable-update or so?

Yes, this should be possible.  I believe we would need to call the
package zookeeper35 or zookeeper36.

> > As an aside, I took a quick look at the latest upstream activemq
> > source
> > release (https://activemq.apache.org/activemq-5016002-release) and it
> > specifies zookeeper 3.4.14 in its pom.xml (which makes me feel a
> > little
> > better).
> 
> Isn’t that just telling the minimum version that works with it - not
> what they'd consider a safe use from a security PoV?

I don't recall there being API issues (although I need to check), but we
encountered problems at my $dayjob trying to use ZK 3.5 libraries in
applications interacting with ZK 3.4 servers.  IIRC, the issue has to do
with TTL nodes and was problematic enough that we ended up forking the
application to have ZK 3.4 and ZK 3.5 variants.

> > We can work on addressing the situation in bookworm.  (One idea I
> > would
> > propose is paring down the package to build just libzookeeper-java,
> > because I imagine that many people use the Debian package to run
> > their
> > ZooKeeper ensembles, although maybe that's not true.) 
> 
> Well I for example use the daemon, too, but the software from which I
> use it would anyway already require some newer version and doesn't work
> with 3.4 anymore.
> So for me that wouldn't matter much.

It's good to know that there are users of the package.  (For my $dayjob
use case, ZK deployments are now container-based using the upstream
binary distribution.)

I will set aside some time to look at what it would take to build a
ZK 3.6 package against Debian and we can continue the discussion.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#991146: python3-libxml2: ambiguous package name 'python3-libxml2' with more than one installed instance

[Stefano Rivera]

Hi Thorsten (2021.07.15_12:27:59_-0400)
> During crossgrading or when installing multiple versions of python3-libxml2
> they fail to configure because of a bug in the postinst script:

I can't reproduce this, apt won't let me install multiple architectures
of python3-libxml2 concurrently, due to dependencies.

Can you provide a minimal recipe for reproducing?

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#990368: Official patch

[tux supertuxkart]

Hello
I think the quickest way to solve this issue is to remove beastie and
hexley in debian:

So please apply those 2 patches:

https://github.com/supertuxkart/stk-code/commit/851290d4c866130abb22ee61114016378af4cb45
https://github.com/supertuxkart/stk-code/commit/cae38e862a1dbc1486283f551ee023e6c2255085

As seen in https://github.com/supertuxkart/stk-code/commits/1.2

Those patches have been fully tested and should be ok for production usage,
then you can remove those karts in supertuxkart-data (assets)

STK team

Bug#991146: python3-libxml2: ambiguous package name 'python3-libxml2' with more than one installed instance

[stefanor]

Hi Thorsten (2021.07.17_17:43:51_+)
> I guess this is rare during normal operation, but we don’t prescribe
> use of apt anywhere and dpkg can indeed trigger it, and this is the
> actually normal case when crossgrading.

Yeah, it's worth fixing, and required for further multi-arch in the
Python stack.

> The fix is really easy, dh_python3 must arch-qualify the py3compile
> (and pypy3compile, I guess) line it inserts if the package is not
> arch:any. For it to become effective, all packages with the code in
> their maintainer scripts need to be rebuilt, which… is probably not
> feasible right now.

Yeah, I think this is 3 steps:
1. Add support for arch-qualified dependencies in the py*compile
   scripts.
2. Generate arch-qualified dependencies (and appropriate versioned
   dependencies on python3.*, for the support in 1) in dh_python3.
3. Re-build arch-dependent packages with the new dh_python3.

That sounds way too big to chase before the freeze, so I think this is a
bookworm problem.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#962003: *ERROR* Failed to wait for idle; VT'd may hang

[Simon Josefsson]

Hi. I just installed Debian bullseye daily today (linux-image-amd64
version 5.10.40-1), and ran into this problem on a Lenovo X201. The
message repeats every other second or so. I don't notice any other
problem except for the repeated messages, fortunately.

I have tried installing the non-free intel iucode and 915 firmware
packages (intel-microcode and firmware-misc-nonfree), but they don't
appear to make a difference.

/Simon

Jul 17 15:59:44 latte kernel: [ 2612.027659] i915 :00:02.0: [drm]
*ERROR* Failed to wait for idle; VT'd may hang.
Jul 17 15:59:45 latte kernel: [ 2612.596917] i915 :00:02.0: [drm]
*ERROR* Failed to wait for idle; VT'd may hang.
Jul 17 15:59:45 latte kernel: [ 2612.656537] i915 :00:02.0: [drm]
*ERROR* Failed to wait for idle; VT'd may hang.
Jul 17 15:59:45 latte kernel: [ 2612.656538] i915 :00:02.0: [drm]
*ERROR* Failed to wait for idle; VT'd may hang.
Jul 17 15:59:45 latte kernel: [ 2612.997551] i915 :00:02.0: [drm]
*ERROR* Failed to wait for idle; VT'd may hang.

Bug#990642: linux-image-4.19.0-17-amd64: kernel panic on xen dom0 with Broadcom Limited NetXtreme II BCM5709

[spi]

So, did some more testing.

1) Tried two different ports for binding interface on the 4-port-NIC:
again kernel panic

2) Compiled mainline 5.14-rc1 (2021-07-11) kernel from kernel.org: again
kernel panic with either two ports on the 4-port-NIC


3) Added another 2-port-NIC into server:
06:01.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet
Controller (Copper) (rev 03)

06:01.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet
Controller (Copper) (rev 03)

driver: e1000
version: 7.3.21-k8-NAPI


When configuring a two port bonding interface on this Intel NIC there is
no kernel panic neither with 5.14-rc1 nor 4.19.0-17-amd64.


For me it seems there is an issue with the bnx2 driver used for the
Broadcom Limited NetXtreme II BCM5709 Gigabit Ethernet (rev 20).

Cheers,
spi

Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Shengjing Zhu]

On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher  wrote:
>
> On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote:
> > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu  wrote:
> > >
> > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise  wrote:
> > > >
> > > > On Wed, 2021-07-14 at 20:16 +0800, Shengjing Zhu wrote:
> > > >
> > > > > That feels over-engineering/energy-wasting.
> > > >
> > > > Another option would be to search the source code, and these findings
> > > > would need to be confirmed using grep, but looking at codesearch:
> > > >
> > > >
> > > > https://codesearch.debian.net/search?q=%5C.generateClientKeyExchange=0
> > > >
> > >
> > > generateClientKeyExchange is not an exported function, which is
> > > expected to be called by other library/softwares.
> >
> > oops, it should be "which is not expected..."
>
> What's the status? If we cannot reduce the number of packages to binNMU,
> then this needs to happen soon. Otherwise there won't be enough time to
> chase all the rebuilds.
>

>From my perspertive, for std library security fix in Go compiler, it's
better to rebuild all Go packages.

It's not possible to figure out the affected packages at sub-lib(eg
the crypto/tls package in std lib) level by source package.
Only possible with binary packages, either by
+ disassemble
+ or rebuild at local first to see if the result binary changes.

PS, the embedded version of Go std libary is tracked at all Go
packages' Built-Using field. And it's only tracked at source package
level, not every sub-lib level.
So for other Go lib packages security updates, we don't need to
rebuild the world.

-- 
Shengjing Zhu

Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Sebastian Ramacher]

On 2021-07-18 02:49:26 +0800, Shengjing Zhu wrote:
> On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher  
> wrote:
> >
> > On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote:
> > > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu  wrote:
> > > >
> > > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise  wrote:
> > > > >
> > > > > On Wed, 2021-07-14 at 20:16 +0800, Shengjing Zhu wrote:
> > > > >
> > > > > > That feels over-engineering/energy-wasting.
> > > > >
> > > > > Another option would be to search the source code, and these findings
> > > > > would need to be confirmed using grep, but looking at codesearch:
> > > > >
> > > > >
> > > > > https://codesearch.debian.net/search?q=%5C.generateClientKeyExchange=0
> > > > >
> > > >
> > > > generateClientKeyExchange is not an exported function, which is
> > > > expected to be called by other library/softwares.
> > >
> > > oops, it should be "which is not expected..."
> >
> > What's the status? If we cannot reduce the number of packages to binNMU,
> > then this needs to happen soon. Otherwise there won't be enough time to
> > chase all the rebuilds.
> >
> 
> From my perspertive, for std library security fix in Go compiler, it's
> better to rebuild all Go packages.
> 
> It's not possible to figure out the affected packages at sub-lib(eg
> the crypto/tls package in std lib) level by source package.
> Only possible with binary packages, either by
> + disassemble
> + or rebuild at local first to see if the result binary changes.
> 
> PS, the embedded version of Go std libary is tracked at all Go
> packages' Built-Using field. And it's only tracked at source package
> level, not every sub-lib level.
> So for other Go lib packages security updates, we don't need to
> rebuild the world.

Sorry, I meant: what's the status of the golang-1.15 upload?

Cheers

> 
> -- 
> Shengjing Zhu

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Shengjing Zhu]

On Sun, Jul 18, 2021 at 2:52 AM Sebastian Ramacher  wrote:
>
> On 2021-07-18 02:49:26 +0800, Shengjing Zhu wrote:
> > On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher  
> > wrote:
> > >
> > > On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote:
> > > > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu  wrote:
> > > > >
> > > > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise  wrote:
> > > > > >
> > > > > > On Wed, 2021-07-14 at 20:16 +0800, Shengjing Zhu wrote:
> > > > > >
> > > > > > > That feels over-engineering/energy-wasting.
> > > > > >
> > > > > > Another option would be to search the source code, and these 
> > > > > > findings
> > > > > > would need to be confirmed using grep, but looking at codesearch:
> > > > > >
> > > > > >
> > > > > > https://codesearch.debian.net/search?q=%5C.generateClientKeyExchange=0
> > > > > >
> > > > >
> > > > > generateClientKeyExchange is not an exported function, which is
> > > > > expected to be called by other library/softwares.
> > > >
> > > > oops, it should be "which is not expected..."
> > >
> > > What's the status? If we cannot reduce the number of packages to binNMU,
> > > then this needs to happen soon. Otherwise there won't be enough time to
> > > chase all the rebuilds.
> > >
> >
> > From my perspertive, for std library security fix in Go compiler, it's
> > better to rebuild all Go packages.
> >
> > It's not possible to figure out the affected packages at sub-lib(eg
> > the crypto/tls package in std lib) level by source package.
> > Only possible with binary packages, either by
> > + disassemble
> > + or rebuild at local first to see if the result binary changes.
> >
> > PS, the embedded version of Go std libary is tracked at all Go
> > packages' Built-Using field. And it's only tracked at source package
> > level, not every sub-lib level.
> > So for other Go lib packages security updates, we don't need to
> > rebuild the world.
>
> Sorry, I meant: what's the status of the golang-1.15 upload?
>

Not uploaded yet. But I have sent the debdiff, and wait for the ACK.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990825#17

-- 
Shengjing Zhu

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

[Salvatore Bonaccorso]

Hi Noah,

On Fri, Jul 02, 2021 at 10:41:12AM +0200, Moritz Mühlenhoff wrote:
> Source: dovecot
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
> 
> Hi,
> 
> The following vulnerabilities were published for dovecot.
> 
> 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
> 
> 
> 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
> 
>   
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2021-33515
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33515
> [1] https://security-tracker.debian.org/tracker/CVE-2021-29157
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29157
> [2] https://security-tracker.debian.org/tracker/CVE-2020-28200
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28200
> 
> Please adjust the affected versions in the BTS as needed.

Do you have a chance to try to get this yet in time for bullseye? Do
you have time for it (I do agree the time is now very tight).

Regards,
Salvatore

Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

[Ryan Thoryk]

On 7/17/21 9:44 AM, Steve McIntyre wrote:

Hi Ryan,

So when you say "spin up a new Debian ARM VM on AWS", what exact image
are you using here? It sounds like the build process for that image
needs to be fixed to DTRT for the platform. Then you and other users
won't be bitten by this problem...



I found that I was using an older ARM image from last year, but that 
doesn't mean the issue was fixed later.  In AWS's community AMI section, 
the main one I tried is listed as "debian-10-arm64-20200511-260".  When 
you launch it, if you do a package upgrade it installs a newer version 
of grub.  Then running a grub-install makes it unbootable.  If you do 
the dpkg-reconfigure method, you have to choose "yes" to the "force 
extra installation" question, if you choose "no", it won't boot anymore.


I tried launching a newer AMI, titled "debian-10-arm64-20210621-680", 
and that one reboots fine if you do a "grub-install", but that's because 
it didn't install a newer version of grub, since the packages are 
recent.  I don't know what would happen if it installed a newer grub, 
you might have to look into that.  In the boot folder the EFI boot 
loader is listed as "/boot/efi/EFI/BOOT/BOOTAA64.EFI", there's no 
"EFI/debian" folder.  I'm not sure what they did to generate the AMI image.


The AMI IDs I used are:
ami-00249fe66e0872181
and
ami-025a7500c83d92798

I didn't try the Marketplace one.

--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

[Ryan Thoryk]

On 7/17/21 10:09 AM, Ryan Thoryk wrote:

On 7/17/21 9:44 AM, Steve McIntyre wrote:

I found that I was using an older ARM image from last year, but that 
doesn't mean the issue was fixed later.  In AWS's community AMI section, 
the main one I tried is listed as "debian-10-arm64-20200511-260".  When 
you launch it, if you do a package upgrade it installs a newer version 
of grub.  Then running a grub-install makes it unbootable.  If you do 
the dpkg-reconfigure method, you have to choose "yes" to the "force 
extra installation" question, if you choose "no", it won't boot anymore.


I tried launching a newer AMI, titled "debian-10-arm64-20210621-680", 
and that one reboots fine if you do a "grub-install", but that's because 
it didn't install a newer version of grub, since the packages are 
recent.  I don't know what would happen if it installed a newer grub, 
you might have to look into that.  In the boot folder the EFI boot 
loader is listed as "/boot/efi/EFI/BOOT/BOOTAA64.EFI", there's no 
"EFI/debian" folder.  I'm not sure what they did to generate the AMI image.


The AMI IDs I used are:
ami-00249fe66e0872181
and
ami-025a7500c83d92798

I didn't try the Marketplace one.



One thing to add to that - when I did a "grub-install" on the newer AMI, 
it didn't write a "EFI/debian" folder, just an "EFI/BOOT" folder, which 
means that it might be working properly.  If that's the case, then the 
older instances are broken, which would affect existing systems.  I'm 
not sure if a grub upgrade would change that or not.


--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#991215: local copy of rust book does not allow to hide the navigation bar as the online version does

[Stefano Zacchiroli]

Package: rust-doc
Version: 1.52.1+dfsg1-1~exp3
Severity: minor
File: /usr/share/doc/rust-doc/html/book

Heya, it looks like the HTML version of the Rust book shipped with rust-doc
lacks some of the (CSS/JS) elements of the version of the book online at
https://doc.rust-lang.org/book/ . Most notably, the top-left button that allow
to toggle the left navigation bar is missing when browsing the local HTML
version.

That is annoying as, on small screens the left navigation bar can take a lot of
space and it would be nice to be able to hide it.

I've noticed the following error in the javascript console when browsing the
local version:

  book.js:572 Uncaught ReferenceError: ClipboardJS is not defined
at clipboard (book.js:572)
at book.js:594

which I do not get when browsing the live version on rust-lang.org.  (Even if
the book.js is installed and properly resolvable from the HTML page.)

Thanks for maintaining rust(-doc) in Debian!

Cheers

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
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 rust-doc depends on:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  fonts-open-sans 1.11-1.1
ii  libjs-highlight.js  9.18.5+dfsg1-1
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-mathjax   2.7.9+dfsg-1

Versions of packages rust-doc recommends:
ii  cargo-doc  0.47.0-3

rust-doc suggests no packages.

-- no debconf information

Bug#991216: flameshot: wrong tray icon

[Adam Borowski]

Package: flameshot
Version: 0.9.0+ds1-1
Severity: normal

Hi!
Flameshot fails to display its icon in the system tray; what I get is a
fallback that depends on configured icon set: an "i" bubble (Faenza-*), a
light bulb (Adwaita), etc.

The icon in the menu appears correctly.

Environment: XFCE.

Screenshot of the tray attached.


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

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

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 11-20210319-1
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++611-20210319-1

flameshot recommends no packages.

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

-- no debconf information

Bug#923090: or, query if the package has any mangled files

[Adam Borowski]

> i dont believe this is something *every* bug report should have, as it
> looks like it's a very small percentage of hosts could be in this
> configuration, and let's be honest, the impact is only limited to a
> handful of packages (i understand you're coming from the dpkg POV)
[...]
> this indeed looks like a more sensible approach: every package that
> actually cares about the merged-/usr status, should add its own bug
> script to inspect the system status

A third approach:
We can `dpkg -L` the package in question, and report the taint only if
any of the installed files has a symlink as a non-final component.

You might do that either for usrmerge symlinks only, or, as I suggest, for
any symlinked path -- as it's the latter that causes most of problems
related to usrmerge.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#990782: inkscape: /usr/share/inkscape/fonts does not exist

[Hendrik Tews]

Mattia Rizzolo  writes:

> That said, I'll ask upstream what they think about toning down
> the lines at DEBUG level, so they don't show up by default.

Thanks,

Hendrik

Bug#991218: dpkg-fsys-usrunmess: too verbose, slowing stuff on slow terminals

[Adam Borowski]

Package: dpkg
Version: 1.20.9
Severity: minor

Hi!
It's far better to run usrunmess from a system started "single" rather than
when running X-and-forty-daemons.  However, this usually means fbcon
terminal, which even on this year's hardware is so much slower than hardware
text mode on a CGA was.

Also, Debian's default kernels have eleventy million files installed under
/lib -- linux-image-5.10.0-8-amd64 for example ships 4752 modules.  Woe if
you have multiple kernel packages!

Put together, you spend a long long time watching files listed by usrunmess
slowly scroll by.

Thus: could you please decrease default verbosity somehow?


Meow!
-- Package-specific info:

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  liblzma5 5.2.5-2
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
pn  debsig-verify  

-- no debconf information

Bug#986527: sagemath: FTBFS: how to address for Bullseye

[Adrian Bunk]

On Wed, Jun 09, 2021 at 12:32:02AM +, John Scott wrote:
>...
> With respect to this particular issue, I'd like to share my perspective
> wrangling with a package that poses a similar dilemma: GCC (I'm working
> on packaging gcc-sh-elf). Like the status quo with SageMath in Debian,
> GCC has a test suite where failures are normal, and in general it takes
> an individual to watch out for what number of failures counts as "too
> many." Rather than hardcode an arbitrary threshold for what number of
> failing tests is acceptable, it seems that it's much better, and in the
> interest of Debian ports and alternative build environments, to just
> let the tests run for informative purposes.

Note that sagemath already seems to have 2 different classes of failures:
https://buildd.debian.org/status/package.php?p=sagemath

On armhf, mips64el and ppc64el the build fails reliably with
  Error: critical test failures (e.g. timeout, segfault, etc.)
This seems to be a reasonable build-time smoke test.

The only special case is s390x:
  Checking number of failed tests to determine whether to rerun tests in 
series...
  No: 504 tests failed, up to 400 failures are tolerated for rerun
It is not a surprise that more tests a failing on big endian,
but there are actually no "critical test failures".

>...
> I believe it's in the best interest of Debian users that this bug be
> downgraded for Bullseye so Sage can be used in the mostly-wholesome
> shape it's in, but since I lack expertise in maintaining it I too will
> leave this to someone else.

Flaky builds are a pain, also for bullseye.

IMHO the best action would be an upload with the following changes:
- your superficial autopkgtest
- raising the limit from 200 to something that makes builds non-flaky
- optionally force build failure on s390x

I could sponsor or NMU such an upload.

cu
Adrian

Bug#991119: unblock: postsrsd/1.10-2

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-07-14 21:48:50, Oxan van Leeuwen wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package postsrsd
> 
> [ Reason ]
> Security fix for CVE-2021-35525.
> 
> [ Impact ]
> Package is vulnerable to a potential DoS attack.
> 
> [ Tests ]
> Tests from upstream backported, testsuite from upstream passes, manually 
> tested 
> functionality.
> 
> [ Risks ]
> Fix is a one-to-one backport from upstream, modulus formatting changes.
> 
> [ 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 postsrsd/1.10-2

If this is a pre-approval request, please go ahead and remove the
moreinfo tag once the new version is available in unstable.

Cheers


> diff -Nru postsrsd-1.10/debian/changelog postsrsd-1.10/debian/changelog
> --- postsrsd-1.10/debian/changelog2020-12-02 22:36:36.0 +0100
> +++ postsrsd-1.10/debian/changelog2021-07-14 21:21:11.0 +0200
> @@ -1,4 +1,12 @@
> -postsrsd (1.10-1) UNRELEASED; urgency=medium
> +postsrsd (1.10-2) UNRELEASED; urgency=medium
> +
> +  * Fix CVE-2021-35525: potential DoS when Postfix sends certain long data
> +fields such as multiple concatenated email addresses. Fix backported from
> +upstream commit 077be98d8c8. (Closes: #990439)
> +
> + -- Oxan van Leeuwen   Wed, 14 Jul 2021 21:21:11 
> +0200
> +
> +postsrsd (1.10-1) unstable; urgency=medium
>  
>* New upstream release (Closes: #975633)
>* Drop patches integrated upstream
> diff -Nru 
> postsrsd-1.10/debian/patches/0002-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
>  
> postsrsd-1.10/debian/patches/0002-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
> --- 
> postsrsd-1.10/debian/patches/0002-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
> 1970-01-01 01:00:00.0 +0100
> +++ 
> postsrsd-1.10/debian/patches/0002-SECURITY-Fix-DoS-on-overly-long-input-from-Postfix.patch
> 2021-07-14 21:21:11.0 +0200
> @@ -0,0 +1,211 @@
> +From: =?utf-8?q?Timo_R=C3=B6hling?= 
> +Date: Sun, 21 Mar 2021 15:27:55 +0100
> +Subject: SECURITY: Fix DoS on overly long input from Postfix
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset="utf-8"
> +Content-Transfer-Encoding: 8bit
> +
> +Thanks to Mateusz Jończyk who reported this issue and gave valuable
> +feedback for its resolution.
> +
> +PostSRSd would hang on an overly long GET request, because the
> +fread()/fwrite() logic in the subprocess would get confused by the
> +remaining input line in its buffer.
> +
> +Theoretically, this error should never occur, as Postfix is supposed to
> +send valid email addresses only, which are shorter than the buffer, even
> +assuming every single character is percent-encoded. However, Postfix
> +sometimes does seem to send malformed request with multiple concatenated
> +email addresses. I'm not sure if there's a reliable way to trigger this
> +condition by an external attacker, but it is a security bug in PostSRSd
> +nevertheless.
> +
> +Fixes CVE-2021-35525.
> +
> +Origin: 
> https://github.com/roehling/postsrsd/commit/077be98d8c8a9847e4ae0c7dc09e7474cbe27db2
> +Forwarded: not-needed
> +Last-Update: 2021-07-14
> +---
> + postsrsd.c  | 52 
> ++---
> + run_postsrsd_tests.bats | 40 +
> + 2 files changed, 68 insertions(+), 24 deletions(-)
> +
> +diff --git a/postsrsd.c b/postsrsd.c
> +index c009d8f..5ebf7f6 100644
> +--- a/postsrsd.c
>  b/postsrsd.c
> +@@ -518,9 +518,9 @@ int main (int argc, char **argv)
> + fds[sc].events = POLLIN;
> +   }
> +   while(TRUE) {
> + int conn;
> +-FILE *fp;
> ++FILE *fp_read, *fp_write;
> + char linebuf[1024], *line;
> + char keybuf[1024], *key;
> + 
> + if (poll(fds, socket_count, 1000) < 0) {
> +@@ -540,41 +540,53 @@ int main (int argc, char **argv)
> +   int i;
> +   // close listen sockets so that we don't stop the main daemon 
> process from restarting
> +   for (i = 0; i < socket_count; ++i) close (sockets[i]);
> + 
> +-  fp = fdopen(conn, "r+");
> +-  if (fp == NULL) exit(EXIT_FAILURE);
> +-  fds[0].fd = conn;
> +-  fds[0].events = POLLIN;
> +-  if (poll(fds, 1, timeout * 1000) <= 0) return EXIT_FAILURE;
> +-  line = fgets(linebuf, sizeof(linebuf), fp);
> +-  while (line) {
> +-fseek (fp, 0, SEEK_CUR); /* Workaround for Solaris */
> ++  /* create separate input/output streams */
> ++  fp_read = fdopen(conn, "r");
> ++  if (fp_read == NULL)
> ++return EXIT_FAILURE;
> ++  fp_write = fdopen(dup(conn), "w");
> ++  if (fp_write == NULL) return EXIT_FAILURE;
> ++  errno = 0;
> ++ 

Bug#991146: python3-libxml2: ambiguous package name 'python3-libxml2' with more than one installed instance

[Thorsten Glaser]

Stefano Rivera dixit:

>Hi Thorsten (2021.07.15_12:27:59_-0400)
>> During crossgrading or when installing multiple versions of python3-libxml2
>> they fail to configure because of a bug in the postinst script:
>
>I can't reproduce this, apt won't let me install multiple architectures
>of python3-libxml2 concurrently, due to dependencies.

Hmm, indeed, Multi-Arch: allowed is not coïnstallable according to
https://wiki.ubuntu.com/MultiarchSpec but dpkg does allow me to
install (though not configure) them during crossgrading.

So perhaps this is a crossgrading-only issue, as apt orders the
installations and removals to not trigger this. (Unsure if it can
be triggered by installing with dpkg, without apt.)

Here’s a recipe: first prepare…

$ sudo cowbuilder --login
# dpkg --add-architecture i386
# apt-get update
# apt-get install python3-libxml2:i386   # so the .deb files exist
# apt-get install python3-libxml2:amd64  # will remove the i386 ones
# cd /var/cache/apt/archives

The “apt-get install python3-libxml2:i386” is not strictly needed here,
but it installs all the :i386 dependencies we need and downloads the
.deb files in one go.

(pbuild24310-sid/amd64)root@tglase:/var/cache/apt/archives# dpkg -i 
python3.9-minimal_3.9.2-1_i386.deb python3.9_3.9.2-1_i386.deb 
python3-minimal_3.9.2-3_i386.deb python3_3.9.2-3_i386.deb 
python3-libxml2_2.9.10+dfsg-6.7_i386.deb
(Reading database ... 14666 files and directories currently installed.)
Preparing to unpack python3.9-minimal_3.9.2-1_i386.deb ...
Unpacking python3.9-minimal:i386 (3.9.2-1) over (3.9.2-1) ...
Preparing to unpack python3.9_3.9.2-1_i386.deb ...
Unpacking python3.9:i386 (3.9.2-1) over (3.9.2-1) ...
Preparing to unpack python3-minimal_3.9.2-3_i386.deb ...
Unpacking python3-minimal:i386 (3.9.2-3) over (3.9.2-3) ...
Preparing to unpack python3_3.9.2-3_i386.deb ...
ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD 
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
Unpacking python3:i386 (3.9.2-3) over (3.9.2-3) ...
Selecting previously unselected package python3-libxml2:i386.
Preparing to unpack python3-libxml2_2.9.10+dfsg-6.7_i386.deb ...
Unpacking python3-libxml2:i386 (2.9.10+dfsg-6.7) ...
Setting up python3.9-minimal:i386 (3.9.2-1) ...
ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD 
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
Setting up python3.9:i386 (3.9.2-1) ...
ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD 
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
Setting up python3-minimal:i386 (3.9.2-3) ...
ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD 
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD 
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
Setting up python3:i386 (3.9.2-3) ...
ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD 
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD 
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
Setting up python3-libxml2:i386 (2.9.10+dfsg-6.7) ...
ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD 
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/usr/lib/cowdancer/libcowdancer.so' from LD_PRELOAD 
cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
dpkg-query: error: --listfiles needs a valid package name but 'python3-libxml2' 
is not: ambiguous package name 'python3-libxml2' with more than one installed 
instance

Use --help for help about querying packages.
Traceback (most recent call last):
  File "/usr/bin/py3compile", line 319, in 
main()
  File "/usr/bin/py3compile", line 298, in main
compile(files, versions,
  File "/usr/bin/py3compile", line 183, in compile
for fn, versions_to_compile in filter_files(files, e_patterns, versions):
  File "/usr/bin/py3compile", line 128, in filter_files
for fpath in files:
  File "/usr/share/python3/debpython/files.py", line 71, in filter_public
for fn in files:
  File "/usr/share/python3/debpython/files.py", line 53, in from_package
raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of python3-libxml2
dpkg: error processing package python3-libxml2:i386 (--install):
 installed python3-libxml2:i386 package post-installation script subprocess 
returned error exit status 1
Errors were encountered while processing:
 python3-libxml2:i386

I guess this is rare during normal operation, but we don’t prescribe
use of apt anywhere and dpkg can indeed trigger it, and this is the
actually normal case when crossgrading.

The fix is really easy, dh_python3 must arch-qualify the py3compile
(and pypy3compile, I guess) line it inserts if the package is not
arch:any. For it to become effective, all packages with the 

Bug#989563: Add support for new Unicode 8.0 skin tone emojis

[Jeremy Bicha]

There isn't nearly enough information here for anyone to help you.

The GNOME release of Debian 11 "Bullseye" supports Unicode 13.1
including all the skin-tone modifiers.

Thanks,
Jeremy Bicha

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

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-07-14 22:48:15 +0900, Kentaro Hayashi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: ken...@xdump.org
> 
> Please unblock package collectd
> 
> [ Reason ]
> 
> Fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982294
> 
> If collection3 is set up(not enabled by default), the following error is sent
> to logs repeatedly.
> 
>   FastCGI sent in stderr: "CGI::param called in list context from
> /usr/share/doc/collectd-core/examples/collection3/lib/
> Collectd/Graph/Common.pm line 529, this can lead to vulnerabilities. See the
> warning in "Fetching the value or values of a  single named parameter" at
> /usr/share/perl5/CGI.pm line 412"
> 
> This is not actually assigned as CVE-, but it is unexpected situation.
> 
> [ Impact ]
> 
> It doesn't break collectd behavior at all.
> 
> It only fixes the issue about generation of tons of warning messages
> about inappropriate usage of param() via bundled web interface utility
> (collection3).
> 
> [ Tests ]
> 
> Not ready for automated test because it need to run collection3 as a CGI.
> So, I manually tested attached patch.
> 
> [ Risks ]
> 
> Low, because very limited reverse dependency and it is only affected when web
> interface is enabled.
> 
> % LANG=C apt rdepends collectd
> collectd
> Reverse Depends:
>   Replaces: collectd-utils (<< 4.6.1-1~)
>   Recommends: kcollectd
>   Suggests: drraw
>   Suggests: libcollectdclient1
>   Replaces: collectd-core (<< 4.8.2-1~)
>   Recommends: collectd-utils
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> [ Other info ]
> 
> I've prepared debdiff patch.
> 
> unblock collectd/5.12.0-7

ACK, please go ahead and remove the moreinfo tag once the new version is
available in unstable.

Cheers

> diff -Nru collectd-5.12.0/debian/changelog collectd-5.12.0/debian/changelog
> --- collectd-5.12.0/debian/changelog  2021-06-02 00:56:33.0 +0900
> +++ collectd-5.12.0/debian/changelog  2021-07-14 21:46:02.0 +0900
> @@ -1,3 +1,10 @@
> +collectd (5.12.0-7) unstable; urgency=medium
> +
> +  * Team upload.
> +  * Fix CGI::param error in collection3 (Closes: 982294)
> +
> + -- Kentaro Hayashi   Wed, 14 Jul 2021 21:46:02 +0900
> +
>  collectd (5.12.0-6) unstable; urgency=medium
>  
>* [b4e7861] collectd-dev: Add missing header files again.
> diff -Nru collectd-5.12.0/debian/patches/cgi-param-in-list-context.patch 
> collectd-5.12.0/debian/patches/cgi-param-in-list-context.patch
> --- collectd-5.12.0/debian/patches/cgi-param-in-list-context.patch
> 1970-01-01 09:00:00.0 +0900
> +++ collectd-5.12.0/debian/patches/cgi-param-in-list-context.patch
> 2021-07-14 21:46:02.0 +0900
> @@ -0,0 +1,58 @@
> +From: Kentaro Hayashi 
> +Subject: Fix CGI::param error in collection3
> +Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982294
> +Forwarded: https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/6
> +
> +When using collection3 as a CGI, the following error is sent to logs 
> repeatedly.
> +This MR fixes it:
> +
> +  FastCGI sent in stderr: "CGI::param called in list context from 
> /usr/share/doc/collectd-core/examples/collection3/lib/Collectd/Graph/Common.pm
>  line 529, this can lead to vulnerabilities. See the warning in "Fetching the 
> value or values of a single named parameter" at /usr/share/perl5/CGI.pm line 
> 412"
> +
> +This is caused by inappropriate usage of param(),
> +it should be handled as a scalar or should be treated by multi_param() 
> explicitly.
> +
> +Closes: #982294
> +
> +ref. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982294
> +
> +--- a/contrib/collection3/lib/Collectd/Graph/Common.pm
>  b/contrib/collection3/lib/Collectd/Graph/Common.pm
> +@@ -526,7 +526,7 @@
> +   for (qw(hostname plugin plugin_instance type type_instance))
> +   {
> + my $part = $_;
> +-my @temp = param ($part);
> ++my @temp = multi_param ($part);
> + if (!@temp)
> + {
> +   next;
> +@@ -547,9 +547,9 @@
> + sub get_timespan_selection
> + {
> +   my $ret = 86400;
> +-  if (param ('timespan'))
> ++  if (scalar param ('timespan'))
> +   {
> +-my $temp = int (param ('timespan'));
> ++my $temp = int (scalar param ('timespan'));
> + if ($temp && ($temp > 0))
> + {
> +   $ret = $temp;
> +@@ -568,7 +568,7 @@
> + $ret{$_} = 0;
> +   }
> + 
> +-  for (param ('hostname'))
> ++  for (multi_param ('hostname'))
> +   {
> + my $host = _sanitize_generic_allow_minus ($_);
> + if (defined ($ret{$host}))
> +@@ -597,7 +597,7 @@
> + $ret{$_} = 0;
> +   }
> + 
> +-  for (param ('plugin'))
> ++  for (multi_param ('plugin'))
> +   {
> + if (defined ($ret{$_}))
> + {
> diff -Nru collectd-5.12.0/debian/patches/series 
> collectd-5.12.0/debian/patches/series
> --- 

Bug#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Sebastian Ramacher]

On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote:
> On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu  wrote:
> >
> > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise  wrote:
> > >
> > > On Wed, 2021-07-14 at 20:16 +0800, Shengjing Zhu wrote:
> > >
> > > > That feels over-engineering/energy-wasting.
> > >
> > > Another option would be to search the source code, and these findings
> > > would need to be confirmed using grep, but looking at codesearch:
> > >
> > >
> > > https://codesearch.debian.net/search?q=%5C.generateClientKeyExchange=0
> > >
> >
> > generateClientKeyExchange is not an exported function, which is
> > expected to be called by other library/softwares.
> 
> oops, it should be "which is not expected..."

What's the status? If we cannot reduce the number of packages to binNMU,
then this needs to happen soon. Otherwise there won't be enough time to
chase all the rebuilds.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#946940: lshw: diff for NMU version 02.18.85-0.7

[Adrian Bunk]

Control: tags 946940 + pending

Dear maintainer,

I've prepared an NMU for lshw (versioned as 02.18.85-0.7) and uploaded 
it to DELAYED/1. Please feel free to tell me if I should cancel it.

cu
Adrian
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#988530: Again...

[Charles Curley]

Just had the same thing happen with version 3.5.51 on Bullseye.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#962627: eboard: diff for NMU version 1.1.3-0.4

[Adrian Bunk]

Control: tags 962627 + pending

Dear maintainer,

I've prepared an NMU for eboard (versioned as 1.1.3-0.4) and uploaded
it to DELAYED/1. Please feel free to tell me if I should cancel it.

cu
Adrian
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#990825: [pre-approval] unblock: golang-1.15/1.15.9-6

[Sebastian Ramacher]

On 2021-07-18 02:54:31 +0800, Shengjing Zhu wrote:
> On Sun, Jul 18, 2021 at 2:52 AM Sebastian Ramacher  
> wrote:
> >
> > On 2021-07-18 02:49:26 +0800, Shengjing Zhu wrote:
> > > On Sun, Jul 18, 2021 at 2:29 AM Sebastian Ramacher  
> > > wrote:
> > > >
> > > > On 2021-07-15 02:03:19 +0800, Shengjing Zhu wrote:
> > > > > On Thu, Jul 15, 2021 at 2:02 AM Shengjing Zhu  wrote:
> > > > > >
> > > > > > On Thu, Jul 15, 2021 at 1:54 AM Paul Wise  wrote:
> > > > > > >
> > > > > > > On Wed, 2021-07-14 at 20:16 +0800, Shengjing Zhu wrote:
> > > > > > >
> > > > > > > > That feels over-engineering/energy-wasting.
> > > > > > >
> > > > > > > Another option would be to search the source code, and these 
> > > > > > > findings
> > > > > > > would need to be confirmed using grep, but looking at codesearch:
> > > > > > >
> > > > > > >
> > > > > > > https://codesearch.debian.net/search?q=%5C.generateClientKeyExchange=0
> > > > > > >
> > > > > >
> > > > > > generateClientKeyExchange is not an exported function, which is
> > > > > > expected to be called by other library/softwares.
> > > > >
> > > > > oops, it should be "which is not expected..."
> > > >
> > > > What's the status? If we cannot reduce the number of packages to binNMU,
> > > > then this needs to happen soon. Otherwise there won't be enough time to
> > > > chase all the rebuilds.
> > > >
> > >
> > > From my perspertive, for std library security fix in Go compiler, it's
> > > better to rebuild all Go packages.
> > >
> > > It's not possible to figure out the affected packages at sub-lib(eg
> > > the crypto/tls package in std lib) level by source package.
> > > Only possible with binary packages, either by
> > > + disassemble
> > > + or rebuild at local first to see if the result binary changes.
> > >
> > > PS, the embedded version of Go std libary is tracked at all Go
> > > packages' Built-Using field. And it's only tracked at source package
> > > level, not every sub-lib level.
> > > So for other Go lib packages security updates, we don't need to
> > > rebuild the world.
> >
> > Sorry, I meant: what's the status of the golang-1.15 upload?
> >
> 
> Not uploaded yet. But I have sent the debdiff, and wait for the ACK.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990825#17

Ah, I missed the debdiff due to the other discussion. Please go ahead.

Cheers

> 
> -- 
> Shengjing Zhu

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature