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

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

[Debian Bug Tracking System]

Processing control commands:

> found -1 1.14.12-0.1
Bug #991223 [modemmanager] modemmanager: missing policykit-1 in Depends or 
Recommends
Marked as found in versions modemmanager/1.14.12-0.1.

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

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#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#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#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

Processed: severity of 990128 is important

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 990128 important
Bug #990128 [libcurl4-gnutls-dev] libcurl4-gnutls-dev: Un-installable in 
multiarch environment: /usr/bin/curl-config differs
Severity set to 'important' from 'serious'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
990128: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990128
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 989792

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 989792 + upstream
Bug #989792 [src:dqlite] dqlite assumes a kernel configured with 4kB page size
Added tag(s) upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
989792: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989792
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#990808: marked as done (ganglia-modules-linux: library paths in configs are wrong)

[Debian Bug Tracking System]

Your message dated Sat, 17 Jul 2021 21:33:28 +
with message-id 
and subject line Bug#990808: fixed in ganglia-modules-linux 1.3.6-5
has caused the Debian Bug report #990808,
regarding ganglia-modules-linux: library paths in configs are wrong
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
990808: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990808
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: ganglia-modules-linux
Version: 1.3.6-4
Severity: important


Hi.

The library paths in the configs (and sample configs):
/etc/ganglia/conf.d/mod_fs.conf-sample
/etc/ganglia/conf.d/mod_io.conf
/etc/ganglia/conf.d/mod_multicpu.conf-sample


use still the old locations like:
/usr/lib/ganglia/modio.so

whereas these files are now in:
/usr/lib/x86_64-linux-gnu/ganglia


Cheers,
Chris.
--- End Message ---
--- Begin Message ---
Source: ganglia-modules-linux
Source-Version: 1.3.6-5
Done: Marcos Fouces 

We believe that the bug you reported is fixed in the latest version of
ganglia-modules-linux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 990...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marcos Fouces  (supplier of updated ganglia-modules-linux 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 12 Jul 2021 00:22:06 +0200
Source: ganglia-modules-linux
Architecture: source
Version: 1.3.6-5
Distribution: unstable
Urgency: medium
Maintainer: Marcos Fouces 
Changed-By: Marcos Fouces 
Closes: 990808
Changes:
 ganglia-modules-linux (1.3.6-5) unstable; urgency=medium
 .
   * Fix multiarch support in *.conf files (Closes: #990808).
Checksums-Sha1:
 cabc51304d6026bb46c186a1b130e3432ca85235 2051 ganglia-modules-linux_1.3.6-5.dsc
 a1c0cca59802701c641cba2e4d20443c845959ad 4852 
ganglia-modules-linux_1.3.6-5.debian.tar.xz
 38e667686e346b9d582324676b7e1ff5bd3e7863 6451 
ganglia-modules-linux_1.3.6-5_source.buildinfo
Checksums-Sha256:
 8053cdbff1ed90e3d45f5e95c951c3be2788ff6513d2ff9875e5d19bfaeb55d0 2051 
ganglia-modules-linux_1.3.6-5.dsc
 a0552eb7f66f41d1e5dfdb5cdb648311285342ba67454c3a421769ea3a838959 4852 
ganglia-modules-linux_1.3.6-5.debian.tar.xz
 34c0a801bf52ea6861c319ea269bb7b0bad43fa033f6b52fda96e3aa3a06c9c7 6451 
ganglia-modules-linux_1.3.6-5_source.buildinfo
Files:
 71115b75d8ab3a7eb1890cd39d9c9875 2051 admin optional 
ganglia-modules-linux_1.3.6-5.dsc
 6269b275adf4cc79063dfa1e5c3311db 4852 admin optional 
ganglia-modules-linux_1.3.6-5.debian.tar.xz
 8e9b683c4973508be813251bc1f3e095 6451 admin optional 
ganglia-modules-linux_1.3.6-5_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEfLiv/VYDL+NaNH0uasy9D6O3RHwFAmDzSO8ACgkQasy9D6O3
RHwMIw//UK1yGCYgBX+XaKFwS/0HPMFOttst0+HNKxQq3bH4oIGCoDC+H1xTaA8k
WdMW1vQtH4zEqbOI0cdZQlZnu43uN1jV8GeR5jbo3MV9neJwpLH41C5vsBCL8RvV
cImzXwyq2UhaoA4NrzbJwjtPmK2LKtg7SssFx0EvDYw99hebF1g6VyAmnhhquqjD
yvJybtZP97AhwTssYzxVpTcMJWKb9j7zbpAdWH8e8yQC+z76SwQED7BYCjUZS+8h
T8HEtHUV2kMdah3fla/6x33USVdyEgbjySEwFSC+lwu0bpdEtwctJqqP9Xsgi4NP
eMe04AKz80HKR7m1Q0MeliCG34obnq8xv1gLp9hwAdfMw28Ss6iue5hOI1Sq3RtZ
Qjw7zY8CVZKvuxdBsykrpwUTHVNF1KLW4mu4rxbJc4W97SkA7agOlT23p3SyhjDQ
LyLl/TUCmcraR2FLOAywDqgmcN8V46M8K8i47RhLb8bMNBNHLqkV9QRAqol3+0TG
Fv3RbhlQ+DxLte9g9een/mvop+HZVopKFLgidWi7EcCxFh/mmMe1cpx7N6+4DLOo
3xnDPck5YRkLUBLL+ou+2n4O/dZLbVTocl6MlrNneZdYAoHtPskUZ9TQ4bky7eUh
4jH3SHuj+KFhZyvkAgav1gzRiqzxXDKkYlQ+OvodsIxsBCfbLXU=
=rcJT
-END PGP SIGNATURE End Message ---

Processed: tagging 935548, tagging 986803, tagging 989479, tagging 990079, tagging 990528, tagging 990525 ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # can be fixed via DSAs
> tags 935548 + bullseye-ignore
Bug #935548 [src:libxml-security-java] libxml-security-java: CVE-2019-12400
Added tag(s) bullseye-ignore.
> tags 986803 + bullseye-ignore
Bug #986803 [rustc] CVE-2021-28875 CVE-2021-28876 CVE-2021-28877 CVE-2021-28878 
CVE-2021-28879 CVE-2020-36317 CVE-2020-36318
Added tag(s) bullseye-ignore.
> tags 989479 + bullseye-ignore
Bug #989479 [src:sogo] sogo: CVE-2021-33054
Added tag(s) bullseye-ignore.
> tags 990079 + bullseye-ignore
Bug #990079 [chromium] chromium: Update Chromium to 91.0.4472.114
Added tag(s) bullseye-ignore.
> tags 990528 + bullseye-ignore
Bug #990528 [src:ndpi] ndpi: CVE-2021-36082
Added tag(s) bullseye-ignore.
> tags 990525 + bullseye-ignore
Bug #990525 [src:libgrokj2k] libgrokj2k: CVE-2021-36089
Added tag(s) bullseye-ignore.
> tags 990691 + bullseye-ignore
Bug #990691 [src:gpac] gpac: CVE-2020-35980
Added tag(s) bullseye-ignore.
> tags 990835 + bullseye-ignore
Bug #990835 [src:suricata] suricata: CVE-2021-35063
Added tag(s) bullseye-ignore.
> tags 991046 + bullseye-ignore
Bug #991046 [src:tomcat9] tomcat9: CVE-2021-33037 CVE-2021-30640 CVE-2021-30639
Added tag(s) bullseye-ignore.
> tags 991040 + bullseye-ignore
Bug #991040 [varnish] varnish: CVE-2021-36740: VSV7
Added tag(s) bullseye-ignore.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
935548: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935548
986803: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986803
989479: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989479
990079: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990079
990525: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990525
990528: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990528
990691: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990691
990835: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990835
991040: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991040
991046: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991046
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: BTS housekeeping and severity adjustments

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 989296 serious
Bug #989296 [libvtkgdcm-dev] missing dependencies and wrong path in the .cmake 
file
Severity set to 'serious' from 'important'
> severity 989289 serious
Bug #989289 [libpmix-dev] libpmix-dev: Should depend on libevent-dev
Severity set to 'serious' from 'important'
> severity 989175 serious
Bug #989175 [ruby-maven-libs] Version patch doesn't work with coloured Maven 
output
Severity set to 'serious' from 'important'
> found 989175 3.3.9+ds-1
Bug #989175 [ruby-maven-libs] Version patch doesn't work with coloured Maven 
output
Marked as found in versions ruby-maven-libs/3.3.9+ds-1.
> severity 968498 serious
Bug #968498 [fbless] fbless cant open files
Severity set to 'serious' from 'important'
> forwarded 991212 https://github.com/myhdl/myhdl/issues/350
Bug #991212 [python3-myhdl] python3-myhdl: myhdl always crashes in 
python3.9/ast.py
Set Bug forwarded-to-address to 'https://github.com/myhdl/myhdl/issues/350'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
968498: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968498
989175: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989175
989289: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989289
989296: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989296
991212: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991212
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Processed: tagging 988294

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 988294 + bullseye-ignore
Bug #988294 [src:libunity] libunity: Maintainer email is not reachable
Added tag(s) bullseye-ignore.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
988294: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988294
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Debian Bug Tracking System]

Processing control commands:

> severity -1 grave
Bug #983206 [libupnp13] [libupnp13] Please update for CVE-2020-12695 & fixes
Severity set to 'grave' from 'critical'
> tags -1 bullseye-ignore
Bug #983206 [libupnp13] [libupnp13] Please update for CVE-2020-12695 & fixes
Added tag(s) bullseye-ignore.

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

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

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

[Debian Bug Tracking System]

Processing control commands:

> tags -1 bullseye-ignore
Bug #991146 [dh-python] python3-libxml2: ambiguous package name 
'python3-libxml2' with more than one installed instance
Added tag(s) bullseye-ignore.

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

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#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#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#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#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#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#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#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#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#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)

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

Processed: found 991151 in 2:3.3.15-2

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 991151 2:3.3.15-2
Bug #991151 [procps] procps: dropped the reload option from the init script, 
breaking corekeeper
Marked as found in versions procps/2:3.3.15-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
991151: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991151
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed (with 1 error): Fwd: Bug#991073: unblock: ganglia-modules-linux/1.3.4-5

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + moreinfo confirmed
Bug #991073 [release.debian.org] unblock: ganglia-modules-linux/1.3.4-5
Added tag(s) moreinfo and confirmed.
> tags 990808 -1 -moreinfo confirmed
Unknown tag/s: 1.
Recognized are: patch wontfix moreinfo unreproducible help security upstream 
pending confirmed ipv6 lfs d-i l10n newcomer a11y ftbfs fixed-upstream fixed 
fixed-in-experimental sid experimental potato woody sarge sarge-ignore etch 
etch-ignore lenny lenny-ignore squeeze squeeze-ignore wheezy wheezy-ignore 
jessie jessie-ignore stretch stretch-ignore buster buster-ignore bullseye 
bullseye-ignore bookworm bookworm-ignore trixie trixie-ignore.

Bug #990808 [ganglia-modules-linux] ganglia-modules-linux: library paths in 
configs are wrong
Requested to remove no tags; doing nothing.
Bug #990808 [ganglia-modules-linux] ganglia-modules-linux: library paths in 
configs are wrong
Removed tag(s) moreinfo and confirmed.

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

Bug#991079: marked as done (gir1.2-budgie-1.0 has empty Depends)

[Debian Bug Tracking System]

Your message dated Sat, 17 Jul 2021 10:48:36 +
with message-id 
and subject line Bug#991079: fixed in budgie-desktop 10.5.2-4
has caused the Debian Bug report #991079,
regarding gir1.2-budgie-1.0 has empty Depends
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
991079: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991079
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: gir1.2-budgie-1.0
Version: 10.5-1
Severity: serious

${gir:Depends} needs "dh --with gir" in debian/rules.
--- End Message ---
--- Begin Message ---
Source: budgie-desktop
Source-Version: 10.5.2-4
Done: David Mohammed 

We believe that the bug you reported is fixed in the latest version of
budgie-desktop, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 991...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
David Mohammed  (supplier of updated budgie-desktop 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 13 Jul 2021 19:24:58 +0100
Source: budgie-desktop
Built-For-Profiles: noudeb
Architecture: source
Version: 10.5.2-4
Distribution: unstable
Urgency: medium
Maintainer: David Mohammed 
Changed-By: David Mohammed 
Closes: 991079
Changes:
 budgie-desktop (10.5.2-4) unstable; urgency=medium
 .
   * Bug-fixes
 - Ensure gir package does not have an empty Depends (Closes: #991079)
Checksums-Sha1:
 981c85b16406facfcedae004ed8133cea35c8aaa 3360 budgie-desktop_10.5.2-4.dsc
 6f66b3da6e32a1e7ded651f952d6ce9a507a99af 35736 
budgie-desktop_10.5.2-4.debian.tar.xz
 4d194b990a534531d06e8d8746c99176b16e33aa 21724 
budgie-desktop_10.5.2-4_source.buildinfo
Checksums-Sha256:
 43dd09beb6608391770f0a4db431227118faa6f19847e321a31355a8db7de1cc 3360 
budgie-desktop_10.5.2-4.dsc
 97a87877e7de50b866c46e44a4f05901251b04fc4bbded3c62a438561cd9a069 35736 
budgie-desktop_10.5.2-4.debian.tar.xz
 abe0bcdc5acbe056c31eaad24127b261a0140a92e1671e1cfe22298f3b61a2be 21724 
budgie-desktop_10.5.2-4_source.buildinfo
Files:
 3d57c05a34817fbdd87bfa1622f9bfd6 3360 x11 optional budgie-desktop_10.5.2-4.dsc
 d9d41209dce36673f9ef8042059751d5 35736 x11 optional 
budgie-desktop_10.5.2-4.debian.tar.xz
 f8950f79623b734c187b895b530620c1 21724 x11 optional 
budgie-desktop_10.5.2-4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEHh+wAXyZiorixJimwuqoomrcWe4FAmDysJYACgkQwuqoomrc
We7ibhAAkwPZxGbcnJP3yRfp24SB6wbonn5dgk4LMSoH1vqpGwHhgtlQmEc1niVl
5AyV2keyE7fBmH8EXzeKMy/YeeURyU1hxyGAALwSARwjITRQBtCOgtIRlk4COZGF
CQFF8UFg3nCszqPG2KRb1yL8qnJCAZK2fU+zvURY5w1lQBznBh3IpJQU1v/KhAYk
cqcVSZGv9iphTON0a39kR29ejdZ+oE9l//K2MQzxNZjzhtKwGuj2f9hPnY7NCwqQ
KMNfQ5ywr/9VGgrrOiwh8gk0nRFihfhCxP0T9nESq+wSwcF8XzyazsnwH5MhQSVZ
9hdoR/vIvzWswMOHHvURNNIKR9y/TnAkC51IZhAXlsz8CN/CROIuIWIjq6CWtXKJ
eBxffqEaWadS7UmoWmopWX2AxHuVQKaMTBNgCGb/hkvurR8jaAIbvT4wNkE+Axn9
trtIFmRVXRS7RJCCBROuxn7GxUWYnJprZzYWgzj5LRyEcDy6j4HWAR/0VzDdDPWI
x17y81SVan0nHonr2/VozikY+iSx5q0iNz9vCnQBdekPgJ92Ls6KoGx0RxD+g5Em
2LjUvZKGkiee5OACxKHBJdTu7M/3WfQC8Uk6iGc7qKUTq4uphZd1wbORDrD6Rpsn
ahsMa2suc91nNmJ4sU1u408MPNaT21f1LtZBOoE+2Pi3FMUODZ4=
=uLEZ
-END PGP SIGNATURE End Message ---

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

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + moreinfo confirmed
Bug #990808 [ganglia-modules-linux] ganglia-modules-linux: library paths in 
configs are wrong
Added tag(s) moreinfo and confirmed.

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

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

Processed: Re: Processed: mlpost FTBFS with imagemagick with the #987504 change

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 991060 - patch
Bug #991060 [src:mlpost] mlpost FTBFS with imagemagick with the #987504 change
Removed tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
991060: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991060
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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#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

Processed: tagging 636459

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 636459 - patch
Bug #636459 [tmpreaper] tmpreaper: protect on directory fails. Invalid process 
order.
Removed tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
636459: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636459
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems