Bug#991360: FYI build and manual test ok

[Christian Ehrhardt]

Hi,
Build in unstable [1] and manual testing of the formerly failing
firewalld testcase (as it does skip in debci) worked. So to me it
looks good to go other than the aging period.

That is the state we wanted it to be as Arturo and myself will then be
unavailable for a while.
But due to that, if anything comes up and only a minor/trivial bump of
any kind is needed I'd ask to do so instead of waiting for us.

[1]: https://buildd.debian.org/status/package.php?p=nftables

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#991417: simple-cdd generated iso: No kernel modules were found

[Cyril Brulebois]

Hi Mike,

Mike Depot  (2021-07-22):
> Package: installation-reports
> 
> Boot method: "simple-cdd --qemu-only"
> Image version: 5.10.0-7-amd64
> Date: 2021-07-22

This might be best filed against simple-cdd but anyway…

> I've been using simple-cdd running on my bullseye host to generate a
> custom iso (also bullseye).  My simple-cdd config had been working
> fine until a couple days ago.  Now I am getting an error early in
> debian-installer when I boot from the generated ISO:
> 
> "No kernel modules were found. This probably is due to a mismatch between the 
> kernel used by this version of the installer and the kernel version available 
> in the archive."

Yes, the ABI of the linux kernel was bumped.

I would hope it should be possible to point simple-cdd (and debian-cd)
at the daily builds (which have the required change), but a quick grep
around in the simple-cdd code source and Git repository didn't help me
get the “how” part.

Alternatively, wait for the RC3, which should happen in the next few
days (maybe one week or two, depending on what happens within Debian).


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


signature.asc
Description: PGP signature

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

[Cyril Brulebois]

Control: tag -1 pending

Cyril Brulebois  (2021-07-18):
> 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

I'm attaching the source debdiff I'm getting ready to upload to
unstable; maybe it'll be unblocked in time for 11.0 (it's been such a
long-standing issue that it could wait until 11.1 but hopefully there's
still some time for 11.0).

I'd be pushing this to a new sid branch, since master is used for
experimental at the moment.

Happy to get an ACK, but I won't wait too long. :)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru modemmanager-1.14.12/debian/changelog modemmanager-1.14.12/debian/changelog
--- modemmanager-1.14.12/debian/changelog	2021-03-12 19:09:44.0 +0100
+++ modemmanager-1.14.12/debian/changelog	2021-07-23 06:31:17.0 +0200
@@ -1,3 +1,15 @@
+modemmanager (1.14.12-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix missing dependency on policykit-1 (Closes: #991223): without
+it, a lot of operations would result in a D-Bus level “The name
+org.freedesktop.PolicyKit1 was not provided by any .service files”
+error. In bullseye, ModemManager.service wouldn't even start due to
+the missing polkit.service dependency at the systemd level.
+  * Adjust gbp configuration for sid uploads.
+
+ -- Cyril Brulebois   Fri, 23 Jul 2021 06:31:17 +0200
+
 modemmanager (1.14.12-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru modemmanager-1.14.12/debian/control modemmanager-1.14.12/debian/control
--- modemmanager-1.14.12/debian/control	2021-03-12 19:09:31.0 +0100
+++ modemmanager-1.14.12/debian/control	2021-07-23 06:27:27.0 +0200
@@ -29,6 +29,7 @@
 Architecture: linux-any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
+ policykit-1,
 Recommends: usb-modeswitch
 Description: D-Bus service for managing modems
  ModemManager is a DBus-activated daemon which controls mobile broadband
diff -Nru modemmanager-1.14.12/debian/gbp.conf modemmanager-1.14.12/debian/gbp.conf
--- modemmanager-1.14.12/debian/gbp.conf	2021-03-12 19:09:31.0 +0100
+++ modemmanager-1.14.12/debian/gbp.conf	2021-07-23 06:30:51.0 +0200
@@ -1,3 +1,3 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = master
+debian-branch = sid


signature.asc
Description: PGP signature

Bug#991395: r-cran-knitr: New upstream version needed by other R packages

[Andreas Tille]

Hi,

I checked this but it also

   Depends: r-cran-xfun (>= 0.21) but 0.20-1 is to be installed

and may be others.  I have a busy day today an I'm AFK over the weekend.

Given that the current release date is less than 10 days away I'm not
really motivated to upload a chain of dependencies to experimental
right now.  But all packages are team maintained so you are kindly
invited to do

dch --team

and upload on behalf of the team (just in case it is not communicated
properly:  Team uploads are always welcome in general).  Please make
sure to push your changes to Git in case you will do so.  (I've just
pushed my changes for 1.33.)

Kind regards

 Andreas.

On Thu, Jul 22, 2021 at 10:50:43AM -0500, Dirk Eddelbuettel wrote:
> 
> Package: r-cran-knitr
> Severity: normal
> 
> We have knitr 1.31 per
>   https://packages.debian.org/search?keywords=r-cran-knitr
> but upstream is (since April) at 1.33 per
>   https://cran.r-project.org/package=knitr
> which is now needed by e.g. rgl aka r-cran-rgl.
> 
> We are in a freeze, so I too have been uploading to experimental but it would
> be nice if you could drop it into experimental now so I can put r-cran-rgl 
> there.
> 
> Dirk
> 
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team
> 

-- 
http://fam-tille.de

Bug#991418: /etc/mime.types will replace application/x-xcf with image/x-xcf

[Andreas Tille]

Hi Joost,

I've just fixed both in Git yesterday (unfortunately silently).

We can upload after the freeze.

Kind regards

 Andreas.

On Fri, Jul 23, 2021 at 05:29:32AM +0200, Joost van Baal-Ilić wrote:
> Package: r-cran-httpuv
> Package: r-cran-mime
> Severity: normal
> 
> Hi Charles,
> 
> Thanks a lot for this heads up, much appreciated!  Turning your message into
> a (maybe superfluous) bug, so it won't get lost.
> 
> Bye,
> 
> Joost
> 
> On Thu, Jul 22, 2021 at 05:12:04PM +0900, Charles Plessy wrote:
> > Dear maintainers,
> > 
> > I am contacting you because a code search shows that your source package
> > contains the string 'application/x-xcf'.  (Please refer to the attached
> > maintainer list).
> > 
> > After the release I will change /etc/mime.types to use 'image/x-xcf'
> > instead as the GIMP maintainers (and fact checking with search engines)
> > confirmed that this is the intended media type for XCF files
> > (https://bugs.debian.org/991158).  
> > 
> > Just in case I prefer to inform you ahead of the change.  If you think
> > there is no action to take on your side, it is fine and sorry for the
> > noise !
> > 
> > Have a nice day,
> > 
> > Charles
> > 
> > -- 
> > Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> > Tooting from work,   https://mastodon.technology/@charles_plessy
> > Tooting from home, https://framapiaf.org/@charles_plessy
> 
> [...]
> > Debian R Packages Maintainers 
> >r-cran-httpuv
> >r-cran-mime
> > 
> [...]
> > 
> > Joost van Baal-Ilić 
> >r-cran-httpuv (U)
> >r-cran-mime (U)
> > 
> [...]
> 
> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team

-- 
http://fam-tille.de

Bug#990083: Further testing

[Fabrice Quenneville]

Hello,

I have done extensive testing and stress tested my setup and was not able
to reproduce the bug again.

I suggest you close this bug, sorry to have wasted your time.

I suspect something wrong happened on my NAS and the client NFS didn't like
it and crashed on transitions. And in the steps i took one must have
corrected the issue as I can no longer reproduce the problem.

I do get crashes sometimes opening menus but that is a whole different
issue that I believe is already tracked from looking at the project on
GitHub.

Thanks


On Tue, Jun 29, 2021, 12:13 PM Fabrice Quenneville 
wrote:

> Hi,
>
> I have shut down my NAS as something strange is happening on it. But since
> my NAS is off I have been watching YouTube through the KODI add-on and I
> also get some similar crashes.
>
> I will try to generate meaningful logs in the next few days when I get
> some time.
>
> Thank you
>
> On Tue, Jun 29, 2021, 12:09 PM Vasyl Gello  wrote:
>
>> Hi Fabrice!
>>
>> Just curious: can you please use Kodi's built-in functionality to access
>> NFS agare, not system mount and see if it helps?
>> Maybe create a backup of Kodi profile & try mounting in userspace.
>> --
>> Vasyl Gello
>> --
>> Certified SolidWorks Expert
>>
>> Mob.:+380 (98) 465 66 77
>>
>> E-Mail: vasek.ge...@gmail.com
>>
>> Skype: vasek.gello
>> --
>> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
>>
>

Bug#991420: /etc/mime.types will replace application/x-xcf with image/x-xcf

[Joost van Baal-Ilić]

Package: r-cran-httpuv
Severity: normal


On Fri, Jul 23, 2021 at 05:29:32AM +0200, Joost van Baal-Ilić wrote:
> Package: r-cran-httpuv
> Package: r-cran-mime
> Severity: normal
> 
> Hi Charles,
> 
> Thanks a lot for this heads up, much appreciated!  Turning your message into
> a (maybe superfluous) bug, so it won't get lost.
> 
> Bye,
> 
> Joost
> 
> On Thu, Jul 22, 2021 at 05:12:04PM +0900, Charles Plessy wrote:
> > Dear maintainers,
> > 
> > I am contacting you because a code search shows that your source package
> > contains the string 'application/x-xcf'.  (Please refer to the attached
> > maintainer list).
> > 
> > After the release I will change /etc/mime.types to use 'image/x-xcf'
> > instead as the GIMP maintainers (and fact checking with search engines)
> > confirmed that this is the intended media type for XCF files
> > (https://bugs.debian.org/991158).  
> > 
> > Just in case I prefer to inform you ahead of the change.  If you think
> > there is no action to take on your side, it is fine and sorry for the
> > noise !
> > 
> > Have a nice day,
> > 
> > Charles
> > 
> > -- 
> > Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> > Tooting from work,   https://mastodon.technology/@charles_plessy
> > Tooting from home, https://framapiaf.org/@charles_plessy
> 
> [...]
> > Debian R Packages Maintainers 
> >r-cran-httpuv
> >r-cran-mime
> > 
> [...]
> > 
> > Joost van Baal-Ilić 
> >r-cran-httpuv (U)
> >r-cran-mime (U)
> > 
> [...]
> 
> 

Bug#991419: new upstream (0.7.1)

[Daniel Baumann]

Package: ck

Hi Robert

Thank you for maintaining "ck" in Debian.

One of my packages (dnsperf) requires ck which unfortunately is
currently not build on armel. I've locally built and verified the
current "ck" upstream version (0.7.1) on amd64/i386 and all arm*
architectures.

I saw that your last upload of it was in 2017 and collected some dust
since. Are you still interested in maintaining "ck"? Do you like some help?

Given it's a build-dependency of dnsperf (and a few other packages of
mine), I'd be happy to take the package over in case you're not
interested anymore.

Regards,
Daniel

Bug#991418: /etc/mime.types will replace application/x-xcf with image/x-xcf

[Joost van Baal-Ilić]

Package: r-cran-httpuv
Package: r-cran-mime
Severity: normal

Hi Charles,

Thanks a lot for this heads up, much appreciated!  Turning your message into
a (maybe superfluous) bug, so it won't get lost.

Bye,

Joost

On Thu, Jul 22, 2021 at 05:12:04PM +0900, Charles Plessy wrote:
> Dear maintainers,
> 
> I am contacting you because a code search shows that your source package
> contains the string 'application/x-xcf'.  (Please refer to the attached
> maintainer list).
> 
> After the release I will change /etc/mime.types to use 'image/x-xcf'
> instead as the GIMP maintainers (and fact checking with search engines)
> confirmed that this is the intended media type for XCF files
> (https://bugs.debian.org/991158).  
> 
> Just in case I prefer to inform you ahead of the change.  If you think
> there is no action to take on your side, it is fine and sorry for the
> noise !
> 
> Have a nice day,
> 
> Charles
> 
> -- 
> Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> Tooting from work,   https://mastodon.technology/@charles_plessy
> Tooting from home, https://framapiaf.org/@charles_plessy

[...]
> Debian R Packages Maintainers 
>r-cran-httpuv
>r-cran-mime
> 
[...]
> 
> Joost van Baal-Ilić 
>r-cran-httpuv (U)
>r-cran-mime (U)
> 
[...]

Bug#991416: bridge-utils: broken IPv4 connection after upgrading to Debian Bullseye, setting old MAC with bridge_hw fixes the issue

[Matthias Bosc]

Package: bridge-utils
Version: 1.7-1
Severity: serious


Dear Maintainer,

I’ve upgraded yesterday my server running Debian 10 (Buster) to Debian 11 
(Bullseye). The server is hosted by OVH and has both IPv4 and IPv6 connection.
Everything ran seamlessly excepted until I rebooted the server: I lost the IPv4 
connection on my bridge interface (IPv6 was still OK).

To clarify my network set-up in /etc/network/interfaces (I don’t have anything 
else configured):
auto eno3
iface eno3 inet manual

auto br0
iface br0 inet static
bridge_ports eno3
address XX.XX.XX.XXX0/24
gateway XX.XX.XX.XXX

iface br0 inet6 static
address IPV6_ADDRESS/64
[…] (route related)

After a long time trying to figure out why the server wasn’t answering ping 
from outside and couldn’t reach internet through IPv4 while the interface was 
up and well configured, it *seems* that some behaviour has changed.
I suspected that the network was blocked because of the different MAC address 
between eno3 and br0 (I was able to ping my gateway).
Setting the eno3 MAC address on the br0 interface (with bridge_hw) fixed the 
issue.

I haven’t the hardware to reproduce the previous behaviour (how the MAC address 
was previously assigned to the bridged interface), and to migrate again from 10 
to 11,
but in case this new behaviour effectively come from a change in the Bullseye 
package, it could lead to some problems while upgrading.

Hope this helps,
Matthias

---

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

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

Versions of packages bridge-utils depends on:
ii  libc6  2.31-12

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.36

-- no debconf information
Thank you for using reportbug

Bug#991417: simple-cdd generated iso: No kernel modules were found

[Mike Depot]

Package: installation-reports

Boot method: "simple-cdd --qemu-only"
Image version: 5.10.0-7-amd64
Date: 2021-07-22

Machine: qemu kvm, on top of bullseye amd64
Processor: QEMU Virtual CPU version 2.5+ (over i7-6920HQ physical)
Memory: 4G in QEMU (64G physical)

I've been using simple-cdd running on my bullseye host to generate a custom iso 
(also bullseye).  My simple-cdd config had been working fine until a couple 
days ago.  Now I am getting an error early in debian-installer when I boot from 
the generated ISO:

"No kernel modules were found. This probably is due to a mismatch between the 
kernel used by this version of the installer and the kernel version available 
in the archive."

I find that simple-cdd is generating the iso with the following kernel:
Linux ... 5.10.0-7-amd64 #1 SMP Debian 5.10.40.1 (2021-05-28) x86_64 GNU Linux

However the host system (recently apt upgraded) has the following kernel:
Linux ... 5.10.0-8-amd64 #1 SMP Debian 5.10.46.2 (2021-07-20) x86_64 GNU Linux
(note the date on the kernel is only 2 days prior from when I ran into this 
issue)

I am not specifying mirror/codename nor mirror/suite in the preseed that 
simple-cdd is using.  My understanding is this allows debian-installer to 
install whatever version ends up in the generated iso's initrd.  I also tried 
again with these values enabled and set to "bullseye" however the problem 
remained.

Searching for this error I find that other people that have had the same issue 
in the past.  In past bug reports this seems to have been fixed somewhere in 
the distro, so I'm reporting it here.

Since this problem seems to come back every now and again, I'd also like to 
know if there is a workaround that people can put into their simple-cdd config 
to allow things to keep working when the kernels occasionally get out of sync 
like this.  If that's possible, it might be good to mention that workaround 
here, for future searchers.

Thanks!

Bug#991415: unblock: kdump-tools/1:1.6.8.4

[dann frazier]

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

Please unblock package kdump-tools

[ Reason ]
Addresses two bugs:

  [ Benjamin Drung ]
  * Fix broken status log messages when dumping w/ FTP (Closes: #991412).

  [ dann frazier ]
  * Add /var/lib/kdump to debian/kdump-tools.dirs to avoid errors
creating the initial set of boot file symlinks (Closes: #991175).

[ Impact ]
The first can have a significant impact to users who are trying to setup
FTP dumps because the output suggests the package is misconfigured even
when it isn't.

The second can cause a first boot service startup failure because the boot
file symlinking process assumes /var/lib/kdump already exists.

[ Tests ]
I did a manual FTP dump test to verify the correct messages, as well as
upgrade/remove/purge tests.

[ Risks ]
I consider both bug fixes to be trivial.

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

unblock kdump-tools/1:1.6.8.4

Bug#991414: volk no longer supports neon on armhf

[Marcus Müller]

Hi Peter,

thanks for digging in so deeply!

First thing I'm going to do: Loop Johannes Demel in here, he's the most 
knowledgeable
person on the CPU detection and build issues.

Johannes, see below. There's two things to unpack here:

1. It looks like debian disables NEON. Do we need to check with Mait on that? 
Or is this
somehow "right"?
2. see the build problem; that looks like an archi/µarch mismatch, but I don't 
know how to
interpret it.

Maybe you can shine some light on this?

Best regards,
Marcus


On 23.07.21 00:07, peter green wrote:
> Package: volk
> Version: 2.0.0-1
> Severity: important
> X-debbugs-cc: mmuel...@gnuradio.org
> 
> Hi,
> 
> While raspbian and Debian armhf have different baselines what they share in
> common is that neon is not part of the baseline configuration but is present 
> on
> a large proportion of the systems people use in practice (for Debian armhf I
> suspect nearly all users have neon, for raspbian it's less because we still
> have pi1/pi0 users around) . So where upstream supports runtime detection
> of neon said runtime detection should be enabled and used.
> 
> Back in 2015 I disabled neon in raspbian's volk package, I can't remember why
> but I suspect it was because at the time I had no means of determining whether
> the package had runtime CPU   detection.
> 
> alle_die_mit_der from gnuradio upstream came into #raspbian on irc (to ask 
> about
> options for building stuff) and I took the opportunity to talk about the issue
> of runtime CPU detection. He guided me on how to test volk (quotes below) and
> I thus decided to revert our raspbian neon-disabling changes and build a 
> package
> for testing on raspbian bullseye.
> 
>>  The volk package in raspbian currently has neon disabled. from 
>> what you have
>> said I strongly suspect it could be re-enabled but before I actually 
>> re-enable it I need
>> a test plan that I can use to make sure i'm not breaking anything.
>>  VOLK has a unit test for every single "kernel"
>>  `make test` is your friend :)
>>  is there a way to run the tests against an installed version of 
>> volk?
>>  yeah
>>  `volk_profile` essentially does the same, while 
>> benchmarking them
>> <--snip-->
>>  does volk_profile use the same runtime cpu detection as normal 
>> use of volk?
>>  yes
>>  it should
>> <--snip-->
>>  you can query the runtime-available platforms with 
>> `volk-config-info
>> --avail-machines`
> 
> However to my surprise I discovered that the package built on raspbian from
> unmodified Debian sources didn't have any neon support either. I discovered 
> that
> the CMake scripts were failing to detect Neon because they were not using
> -mfpu=neon when building test programs.
> 
> I have confirmed this is not a raspbian specific issue and it seems to have
> been this way since version 2.0.0, this makes it a regression between buster
> and bullseye.
> 
> I modified the cmake scripts to use -mfpu=neon when detecting neon support
> but then the build itself failed with.
> 
>> cd /volk-2.4.1.new/obj-arm-linux-gnueabihf/lib && /usr/bin/cc -DHAVE_DLFCN_H
>> -DHAVE_FENV_H -D_GLIBCXX_USE_CXX11_ABI=1 
>> -I/volk-2.4.1.new/kernels/volk/asm/neon
>> -I/usr/include/orc-0.4 -I/volk-2.4.1.new/obj-arm-linux-gnueabihf/include
>> -I/volk-2.4.1.new/include -I/volk-2.4.1.new/kernels
>> -I/volk-2.4.1.new/obj-arm-linux-gnueabihf/lib -I/volk-2.4.1.new/lib
>> -I/usr/include/cpu_features -O2 -g -DNDEBUG -fPIC -o
>> CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o
>>  -c
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s: 
>> Assembler
>> messages:
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:11: 
>> Error:
>> selected FPU does not support instruction -- `vmov.i32 q12,#0'
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:18: 
>> Error:
>> selected processor does not support `vld2.16 {d16-d19},[r4]!' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:22: 
>> Error:
>> selected FPU does not support instruction -- `vsub.i16 q10,q8,q9'
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:23: 
>> Error:
>> selected processor does not support `vcge.s16 q11,q10,#0' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:24: 
>> Error:
>> selected processor does not support `vcgt.s16 q10,q12,q10' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:25: 
>> Error:
>> selected processor does not support `vand.i16 q11,q8,q11' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:26: 
>> Error:
>> selected processor does not support `vand.i16 q10,q9,q10' in ARM mode
>> /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:27: 
>> Error:
>> selected FPU does not support instruction -- 

Bug#991414: volk no longer supports neon on armhf

[peter green]

Package: volk
Version: 2.0.0-1
Severity: important
X-debbugs-cc: mmuel...@gnuradio.org

Hi,

While raspbian and Debian armhf have different baselines what they share in
common is that neon is not part of the baseline configuration but is present on
a large proportion of the systems people use in practice (for Debian armhf I
suspect nearly all users have neon, for raspbian it's less because we still
have pi1/pi0 users around) . So where upstream supports runtime detection
of neon said runtime detection should be enabled and used.

Back in 2015 I disabled neon in raspbian's volk package, I can't remember why
but I suspect it was because at the time I had no means of determining whether
the package had runtime CPU   detection.

alle_die_mit_der from gnuradio upstream came into #raspbian on irc (to ask about
options for building stuff) and I took the opportunity to talk about the issue
of runtime CPU detection. He guided me on how to test volk (quotes below) and
I thus decided to revert our raspbian neon-disabling changes and build a package
for testing on raspbian bullseye.


 The volk package in raspbian currently has neon disabled. from what 
you have said I strongly suspect it could be re-enabled but before I actually 
re-enable it I need a test plan that I can use to make sure i'm not breaking anything.
 VOLK has a unit test for every single "kernel"
 `make test` is your friend :)
 is there a way to run the tests against an installed version of volk?
 yeah
 `volk_profile` essentially does the same, while benchmarking 
them
<--snip-->
 does volk_profile use the same runtime cpu detection as normal use 
of volk?
 yes
 it should
<--snip-->
 you can query the runtime-available platforms with 
`volk-config-info --avail-machines`


However to my surprise I discovered that the package built on raspbian from
unmodified Debian sources didn't have any neon support either. I discovered that
the CMake scripts were failing to detect Neon because they were not using
-mfpu=neon when building test programs.

I have confirmed this is not a raspbian specific issue and it seems to have
been this way since version 2.0.0, this makes it a regression between buster
and bullseye.

I modified the cmake scripts to use -mfpu=neon when detecting neon support
but then the build itself failed with.


cd /volk-2.4.1.new/obj-arm-linux-gnueabihf/lib && /usr/bin/cc -DHAVE_DLFCN_H 
-DHAVE_FENV_H -D_GLIBCXX_USE_CXX11_ABI=1 -I/volk-2.4.1.new/kernels/volk/asm/neon 
-I/usr/include/orc-0.4 -I/volk-2.4.1.new/obj-arm-linux-gnueabihf/include 
-I/volk-2.4.1.new/include -I/volk-2.4.1.new/kernels 
-I/volk-2.4.1.new/obj-arm-linux-gnueabihf/lib -I/volk-2.4.1.new/lib 
-I/usr/include/cpu_features -O2 -g -DNDEBUG -fPIC -o 
CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o 
-c /volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s: 
Assembler messages:
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:11: 
Error: selected FPU does not support instruction -- `vmov.i32 q12,#0'
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:18: 
Error: selected processor does not support `vld2.16 {d16-d19},[r4]!' in ARM mode
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:22: 
Error: selected FPU does not support instruction -- `vsub.i16 q10,q8,q9'
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:23: 
Error: selected processor does not support `vcge.s16 q11,q10,#0' in ARM mode
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:24: 
Error: selected processor does not support `vcgt.s16 q10,q12,q10' in ARM mode
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:25: 
Error: selected processor does not support `vand.i16 q11,q8,q11' in ARM mode
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:26: 
Error: selected processor does not support `vand.i16 q10,q9,q10' in ARM mode
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:27: 
Error: selected FPU does not support instruction -- `vadd.i16 q10,q11,q10'
/volk-2.4.1.new/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s:28: 
Error: selected processor does not support `vst1.16 {d20-d21},[r12]!' in ARM 
mode
gmake[4]: *** [lib/CMakeFiles/volk_obj.dir/build.make:1780: 
lib/CMakeFiles/volk_obj.dir/__/kernels/volk/asm/neon/volk_16i_max_star_horizontal_16i.s.o]
 Error 1


I could go digging deeper into the build scripts to see if I can figure out how
to make the buildsystem build the neon kernels (but not the generic kernels)
with -mfpu=neon, but I felt it was time to seek advice from those more familiar
with the codebase than me.

Bug#991413: dump_dmesg: Can't find some symbols for log_buf

[dann frazier]

Package: makedumpfile
Version: 1:1.6.8-4
Severity: important

makedumpfile in buster does not support extraction of dmesg from buster's
kernel:

[7.032459] kdump-tools[517]: The dumpfile is saved to STDOUT.
[7.034898] kdump-tools[517]: makedumpfile Completed.
[7.054470] kdump-tools[498]: kdump-tools: saved vmcore via FTP in 192.168.12
2.57:/files/192.168.122.80-dump.202107221551.
[7.065609] kdump-tools[498]: running makedumpfile --dump-dmesg /proc/vmcore 
/tmp/dmesg.ftp.202107221551.
[7.072299] kdump-tools[522]: dump_dmesg: Can't find some symbols for log_buf
.
[7.075787] kdump-tools[522]: The kernel version is not supported.
[7.079931] kdump-tools[522]: The makedumpfile operation may be incomplete.
[7.084831] kdump-tools[522]: makedumpfile Failed.
[7.089567] kdump-tools[498]: kdump-tools: makedumpfile --dump-dmesg failed. 
dmesg content will be unavailable ...
[7.096158] kdump-tools[523]:  failed!
[7.099504] kdump-tools[498]: kdump-tools: failed to save dmesg content via F
TP in 192.168.122.57:/files/192.168.122.80-dmesg.202107221551 ...
[7.108765] kdump-tools[525]:  failed!
[7.112192] kdump-tools[527]: Thu, 22 Jul 2021 15:51:17 -0600



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

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

Versions of packages makedumpfile depends on:
ii  libc6  2.31-13
ii  libdw1 0.183-3
ii  libelf10.183-3
ii  liblzo2-2  2.10-2
ii  perl   5.32.1-4
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages makedumpfile recommends:
ii  crash7.2.9-2
ii  kexec-tools  1:2.0.22-2

makedumpfile suggests no packages.

-- no debconf information

Bug#990805: lios: Unable open preferences settings menu

[Samuel Thibault]

Control: forwarded -1 https://gitlab.com/Nalin-x-Linux/lios-3/-/issues/23

Hello,

Gniurk, le mer. 07 juil. 2021 22:10:52 +0200, a ecrit:
> On the Lios application, it is not possible to open the preferences settings 
> menu, the orca screen reader wait a very long time before we can browse 
> options on the dialog box.
> my locales settings are fr-FR.UTF-8
> 
> Steps to reproduce the problem:
> Open lios,
> On the menu bar, select preferences then Preferences-General submenu, the 
> screen reader read nothing before one minute.

It seems it is an upstream issue due to the *very* long list of
espeak-ng voices. I have forwarded it to upstream

https://gitlab.com/Nalin-x-Linux/lios-3/-/issues/23

Samuel

Bug#990836: Patch v2

[Mauricio Faria de Oliveira]

Sending a debdiff v2, which uses a separate patch file for the (same) change.

This should be simpler to isolate/revert if/once hwmatch is available
on non-pc/i386 platforms, and also is better on documentation too,
including DEP3 Bug- headers.

cheers,
-- 
Mauricio Faria de Oliveira


grub2_hwmatch_v2.debdiff
Description: Binary data

Bug#991320: flameshot crashing on startup

[allan]

many thanks, dennis - if you need anything else feel free to reach out.

On Thu, Jul 22, 2021 at 3:33 PM Dennis Filder  wrote:
>
> Okay, I can reproduce the crash now with that setting.

Bug#991400: systemd: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service

[Thomas Uhle]

On Thu, 22 Jul 2021, Michael Biebl wrote:


Kernel: Linux 3.16.85-odroidc2 (SMP w/4 CPU threads; PREEMPT)

Oh, right.

This is not a Debian supported kernel. Please ask your vendor to update it to 
something more recent.




Unfortunately, Hardkernel won't put any more effort into upgrading the 
Linux kernel for Odroid-C2 at the moment (according to 
https://forum.odroid.com/viewtopic.php?t=39474#p298277). That is why I 
asked for cherrypicking the patch from Github for the systemd version in 
bullseye because I hoped that this would also be a suitable solution for 
this issue.


Best regards,

Thomas Uhle

Bug#991412: FTP status messages show wrong remote info

[dann frazier]

Package: kdump-tools
Version: 1:1.6.8.3
Severity: important
X-Debbugs-Cc: Benjamin Drung 

Due to use of the wrong variable names, dumps to an FTP server log incorrect
messages. For example:

[7.598933] kdump-tools[498]: kdump-tools: saved vmcore via FTP in :.

when it should be:

[7.196923] kdump-tools[498]: kdump-tools: saved vmcore via FTP in 192.168.12
2.57:/files/192.168.122.80-dump.202107221510.

This could lead users to believe their system is misconfigured, leading
them down the wrong debug path when trying to enable kdump via FTP.

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

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

Versions of packages kdump-tools depends on:
ii  bsdextrautils 2.36.1-7
ii  bsdmainutils  12.1.7+nmu3
ii  busybox-static [busybox]  1:1.30.1-6+b2
ii  debconf [debconf-2.0] 1.5.77
ii  file  1:5.39-3
ii  init-system-helpers   1.60
ii  kexec-tools   1:2.0.22-2
ii  linux-base4.6
ii  lsb-base  11.1.0
ii  makedumpfile  1:1.6.8-4
ii  ucf   3.0043

Versions of packages kdump-tools recommends:
ii  initramfs-tools-core  0.140

kdump-tools suggests no packages.

Bug#991364: [Python-modules-team] Bug#991364: python3-ua-parser: Missing dependency on python3-yaml

[Emmanuel Arias]

Hello!

Thanks for the report.

I've just push to salsa the fix [0]. I will need sponsorship for upload
(I guess after freezing)

I cc to Edward that he's marked as Uploaders.

[0] https://salsa.debian.org/python-team/packages/python-ua-parser

Cheers,
Emmanuel

On Wed, Jul 21, 2021 at 12:21 PM Arnaud Rebillout  wrote:

> Package: python3-ua-parser
> Version: 0.10.0-1
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
>
> Dear Maintainer,
>
> the package python3-yaml must be a dependency of python3-ua-parser.
> Here's the trace (was on buster but it still applies to sid):
>
> Traceback (most recent call last):
>   [...]
> from ua_parser import user_agent_parser
>   File
> "/usr/lib/python3/dist-packages/ua_parser/user_agent_parser.py", line 457,
> in 
> import yaml
> ModuleNotFoundError: No module named 'yaml'
>
> Cheers,
>
>   Arnaud
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
>

Bug#991222: [Pkg-utopia-maintainers] Bug#991222: avahi: Please upload avahi to buster-backports

[Michael Biebl]

Control: tags -1 + wontfix

Am 18.07.21 um 00:43 schrieb 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.


Debian 11 is soon to be released, so I don't plan to make any 
buster-backports uploads for avahi (anymore).





OpenPGP_signature
Description: OpenPGP digital signature

Bug#991400: systemd: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service

[Michael Biebl]

Am 22.07.21 um 21:17 schrieb Thomas Uhle:

On Thu, 22 Jul 2021, Michael Biebl wrote:


Are you booting with systemd.unified_cgroup_hierarchy=false
under bullseye.

If so, why?



No, I'm not. I guess it's because of the legacy kernel which still has 
cgroups v1. But I really don't understand so much about this.




Kernel: Linux 3.16.85-odroidc2 (SMP w/4 CPU threads; PREEMPT)

Oh, right.

This is not a Debian supported kernel. Please ask your vendor to update 
it to something more recent.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#991320: flameshot crashing on startup

[Dennis Filder]

Control: tag -1 patch upstream
X-Debbugs-CC: allan grossman 

On Wed, Jul 21, 2021 at 04:47:17PM -0500, allan wrote:

> [General]
> disabledTrayIcon=true

Okay, I can reproduce the crash now with that setting.  The update
check silently assumes that tray and its associated member variables
have been initialized.

The attached patch at least prevents flameshot from crashing.  A
proper fix would ensure that any enabled feature that depends on
disabled features automatically gets disabled, too.

Regards.
Description: Fix nullptr dereference
 It occurs when the user has disabledTrayIcon=true, but also
 checkForUpdates=true (explicitly or the default).
Last-Update: 2021-07-22
Author: Dennis Filder 
--- a/src/core/controller.cpp
+++ b/src/core/controller.cpp
@@ -192,7 +192,8 @@
 m_appLatestUrl = json["html_url"].toString();
 QString newVersion =
   tr("New version %1 is available").arg(m_appLatestVersion);
-m_appUpdates->setText(newVersion);
+if (m_appUpdates != nullptr)
+m_appUpdates->setText(newVersion);
 if (m_showCheckAppUpdateStatus) {
 sendTrayNotification(newVersion, "Flameshot");
 QDesktopServices::openUrl(QUrl(m_appLatestUrl));

Bug#991411: munin: "Permission denied" when trying to create /var/run/munin/munin-update.lock

[Celejar]

Package: munin
Version: 2.0.67-2
Severity: important
X-Debbugs-Cc: cele...@gmail.com

My munin installation, which had been working for several years, broke
after an upgrade this morning from 2.0.67-1 ->  2.0.67-2. Now,
munin-cron fails with:

Creating lock /var/run/munin/munin-update.lock failed: Permission denied
 at /usr/share/perl5/Munin/Master/Update.pm line 127

[At least, that's the contents of an email to root every five
minutes.]

-- 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_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages munin depends on:
ii  cron [cron-daemon]   3.0pl1-137
ii  debconf [debconf-2.0]1.5.77
ii  fonts-dejavu-core2.37-2
ii  init-system-helpers  1.60
ii  libdate-manip-perl   6.85-1
pn  libdigest-md5-perl   
ii  libfile-copy-recursive-perl  0.45-1
ii  libhtml-template-perl2.97-1.1
ii  libio-socket-inet6-perl  2.72-2.1
ii  liblog-log4perl-perl 1.54-1
ii  librrds-perl 1.7.2-3+b7
pn  libstorable-perl 
ii  liburi-perl  5.08-1
ii  lsb-base 11.1.0
ii  munin-common 2.0.67-2
ii  netbase  6.3
ii  perl [libtime-hires-perl]5.32.1-4
ii  rrdtool  1.7.2-3+b7
ii  systemd-sysv 247.3-6

Versions of packages munin recommends:
pn  libcgi-fast-perl  
ii  munin-doc 2.0.67-2
ii  munin-node2.0.67-2

Versions of packages munin suggests:
ii  chromium [www-browser]  90.0.4430.212-1
ii  firefox [www-browser]   88.0.1-1
pn  httpd   
pn  libapache2-mod-fcgid
ii  libnet-ssleay-perl  1.88-3+b1
ii  links2 [www-browser]2.21-1+b1
ii  lynx [www-browser]  2.9.0dev.6-2

-- debconf information:
  munin/postrm_remove_rrd_files: false

Bug#976530: dolphin-emu: FTBFS: tests failed

[Jos]

Hi,

The reason why one of the unit tests failed is because this unit test was
triggering undefined behavior when generating its test values. In other
words, there was no bug in the actual program, just in the unit test. This
bug was fixed upstream in
https://github.com/dolphin-emu/dolphin/commit/8d21fa56a1133529273d57df06888e42bb63fde7
(though do note that this commit depends on an earlier commit from the same
pull request).

For what it's worth, in upstream we've only encountered this issue on
arm64, not amd64. But since it is undefined behavior, I'm not too surprised
that this issue doesn't act the same way in your build environment as in
ours.

I'm not sure how you want to proceed, but I hope this information was
useful.

JosJuice,
dolphin-emu upstream maintainer

Bug#991410: blueman: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed

[Thomas Uhle]

Package: blueman
Version: 2.1.4-1+b1
Severity: normal

Dear maintainers,

after upgrading from buster to bullseye, I see the following error message 
in syslog every time when blueman-mechanism.service is started (timestamp 
and host name stripped):


blueman-mechani[812]: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN 
(screen)' failed

From what I understand, blueman-mechanism.service is started as a system 
unit before user login, i.e. also before the X11 server has started. So 
this error message seems to be comprehensible. I guess it comes from 
calling Gtk.IconTheme.get_default() which can be found several times in 
the blueman code. But as I am not familiar with the blueman code, I 
cannot tell why, where and what for blueman-mechanism is calling it.
I assume that this error message is nothing to worry about, but it is 
annoying to have it in syslog. Do you know whether this is something that 
should be addressed upstream?


Best regards,

Thomas Uhle


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-7-arm64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages blueman depends on:
ii  adwaita-icon-theme   3.38.0-1
ii  bluez5.55-3.1
ii  bluez-obexd  5.55-3.1
ii  dbus 1.12.20-2
ii  dbus-x11 [dbus-session-bus]  1.12.20-2
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-ayatanaappindicator3-0.1  0.5.5-2
ii  gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gtk-3.0   3.24.24-4
ii  gir1.2-nm-1.01.30.0-2
ii  gir1.2-pango-1.0 1.46.2-3
ii  gnome-icon-theme 3.12.0-3
ii  libbluetooth35.55-3.1
ii  libc62.31-12
ii  libglib2.0-0 2.66.8-1
ii  libpulse-mainloop-glib0  14.2-2
ii  librsvg2-common  2.50.3+dfsg-1
ii  notify-osd [notification-daemon] 0.9.35+15.04.20150126-1+b1
ii  policykit-1  0.105-31
ii  python3  3.9.2-3
ii  python3-cairo1.16.2-4+b2
ii  python3-gi   3.38.0-2
ii  python3-gi-cairo 3.38.0-2

Versions of packages blueman recommends:
ii  pulseaudio-module-bluetooth  14.2-2

blueman suggests no packages.

Bug#991409: unblock request: msmtp/1.8.11-2.1

[Felix Lechner]

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

Hi,

Please unblock the package msmtp.

[ Reason ]
The version presently in bullseye does not understand lowercase SMTP
commands. It violates RFC821 [1] from 1982 and later applicable specs
such as RFC5321. [2]

[ Impact ]
Users of the version in bullseye cannot send emails via SMTP port 25
locally when software sends mixed or lowercase commands. The issue was
discovered when sending key expiration reminders to Debian
contributors via Python's smtplib [3][4] but probably affects
additional programs, modules and libraries. The faulty behavior is
further detailed in Bug#985468 [5] and the links provided therein.
[6][7]

[ Tests ]
I personally used the patched version on half a dozen machines since
March, and have had no issues with it.

[ Risks ]
The commit cherry-picked here [8] was accepted by upstream over a year
ago. It replaces several instances of 'strcmp' with the case
insensitive equivalent 'strcasecmp'. The risk of breakage is probably
low.

[ 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 ]
The debdiff for the sources is shown at the bottom of this message.
For easier perusal I also attached the actual patch.

unblock thunderbird/1:78.12.0-1

[1] https://tools.ietf.org/html/rfc821
[2] https://tools.ietf.org/html/rfc5321
[3] https://bugs.debian.org/892058
[4] https://salsa.debian.org/lechner/key-expirations
[5] https://bugs.debian.org/985468
[6] https://bugs.python.org/issue29860
[7] https://github.com/marlam/msmtp-mirror/issues/45
[8] 
https://github.com/marlam/msmtp-mirror/commit/7dcfd522efc13fde4df448d834bc6ba2b205

* * *

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

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

Bug#988963: libgc1c2: please drop obsolete Conflicts/Replaces on libgc1 in buster, it interferes with upgrades to bullseye

[Paul Gevers]

Hi,

On 19-07-2021 15:12, Andreas Beckmann wrote:
> On Wed, 30 Jun 2021 21:36:54 +0200 Paul Gevers  wrote:
>> Hi libgc maintainers,
> 
>> Can you please comment? We missed the 10.10 point release already and
>> 10.11 may happen after we release bullseye, but at least we could
>> improve the upgrade for people upgrading after 10.11. Do you agree with
>> me doing an NMU to fix this issue?
> 
> I've been running my local piuparts buster->bullseye upgrade tests with
> the attached patch applied to src:libgc in buster. Except for some
> corner cases this has resolved the majority of the upgrade paths where
> the circular Conflicts previously prevented libgc1 and guile-X.Y-libs
> to be upgraded.

For information for all those following this bug, one of the stable
release managers mentioned on IRC that they weren't convinced this bug
is worth fixing for bullseye considering the timing this late in the
freeze and the severity of the issue.

Which means we probably should assign this bug to release-notes...

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991408: Netbeans: source code problem

[Leandro Cunha]

Package: netbeans
Version: 12.1-3
Severity: critical

A while ago, I was analyzing this package and found that it has nothing to
do with the IDE for Java whose name is Netbeans, I suggest updating this
and make this package relevant for those who need this IDE for their
development environment. Or even removing this package, since the
maintainer's suggestion is to install via flatpak and since Netbeans is no
longer available by installing this package [2].
Thanks.

[1] https://salsa.debian.org/java-team/netbeans
[2]
https://salsa.debian.org/java-team/netbeans/-/blob/master/debian/README.source

-- 
Cheers,
Leandro Cunha

Bug#991407: unblock: pppoeconf/1.21+nmu2

[Jochen Sprickerhof]

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

Please unblock package pppoeconf

[ Reason ]
pppoe-discovery from the ppp package dropped the -A option in a recent
version. As the option had no function in old version, I dropped it from
the pppoeconf call to pppoe-discovery (#990978).

[ Impact ]
Without this change pppoeconf in bullseye is broken as it will not find
any modem.

[ Tests ]
I was able to reproduce the bug and also that it does not happen anymore
with the new version.

[ Risks ]
The patch only removes an old noop option in a shell script. I don't see
a risk.

[ 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 added a patch with two typo fixes for the man page which I found in
the BTS.

unblock pppoeconf/1.21+nmu2
diff -Nru pppoeconf-1.21+nmu1/debian/changelog 
pppoeconf-1.21+nmu2/debian/changelog
--- pppoeconf-1.21+nmu1/debian/changelog2021-01-01 16:42:10.0 
+0100
+++ pppoeconf-1.21+nmu2/debian/changelog2021-07-22 20:51:01.0 
+0200
@@ -1,3 +1,14 @@
+pppoeconf (1.21+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove -A option from pppoe-discovery (Closes: #990978).
+It had no function anymore and was removed in new versions.
+Thanks: Michael Prokop
+  * Apply two manpage corrections (Closes: #814354).
+Thanks: Christoph Biedl
+
+ -- Jochen Sprickerhof   Thu, 22 Jul 2021 20:51:01 +0200
+
 pppoeconf (1.21+nmu1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru pppoeconf-1.21+nmu1/pppoeconf pppoeconf-1.21+nmu2/pppoeconf
--- pppoeconf-1.21+nmu1/pppoeconf   2013-12-27 03:07:24.0 +0100
+++ pppoeconf-1.21+nmu2/pppoeconf   2021-07-22 20:49:37.0 +0200
@@ -190,7 +190,7 @@
 
 touch $TMP/pppoe.scan
 ip link set $iface up
-($DISCOVERY_PROGRAM $mmm -A -I $iface > $TMP/$iface.pppoe ; rm 
$TMP/pppoe.scan) &
+($DISCOVERY_PROGRAM $mmm -I $iface > $TMP/$iface.pppoe ; rm 
$TMP/pppoe.scan) &
 
 ( time=0 ; while test -f $TMP/pppoe.scan ; do time=`expr $time + 
6`; echo $time; sleep 1; done ) | $DIALOG --title "$title" --gauge "$text 
$mmode" 10 60 0
 
diff -Nru pppoeconf-1.21+nmu1/pppoeconf.8.sgml 
pppoeconf-1.21+nmu2/pppoeconf.8.sgml
--- pppoeconf-1.21+nmu1/pppoeconf.8.sgml2013-12-27 03:07:24.0 
+0100
+++ pppoeconf-1.21+nmu2/pppoeconf.8.sgml2021-07-22 20:50:22.0 
+0200
@@ -70,12 +70,12 @@
 DESCRIPTION
 
 The  program is user-friendly dialog
- based setup tool for pppd (and pppoe
- if needed). It will look for existing ethernet cards and look for ADSL
+ based setup tool for pppd (and 
pppoe if
+ needed). It will look for existing ethernet cards and look for ADSL
  hardware connected to one of them. You can add an interface name
  iface to force  to use it. Then it will get
  some login info and do some minor modifications to make working
- settings. Note that you can use ESC key to exit program when you 
wan.
+ settings. Note that you can use ESC key to exit program when you 
want.
 
   
   

Bug#991394: proftpd-basic: mod_sftp is missing an upstream fix: #866 "mod_sftp crashes when using pubkey-auth with DSA keys"

[Anishchuk, Igor]

Package: proftpd-basic
Version: 1.3.6-4+deb10u5
Severity: normal

Dear Maintainer,

When connecting to proftpd daemon using SFTP protocol and authenticating
using a DSS key, the server process crashes with segmentation fault.
This is caused by an upstream issue #866
(https://github.com/proftpd/proftpd/issues/866) that is fixed in PR #867
(https://github.com/proftpd/proftpd/pull/867).

The issue happens in module mod_sftp that has an obvious copy-paste
error in the code. The upstream fix #867 reliably solves the issue.

With Best Regards,
Igor

Bug#991400: systemd: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service

[Thomas Uhle]

On Thu, 22 Jul 2021, Michael Biebl wrote:


Are you booting with systemd.unified_cgroup_hierarchy=false
under bullseye.

If so, why?



No, I'm not. I guess it's because of the legacy kernel which still has 
cgroups v1. But I really don't understand so much about this.


Best regards,

Thomas Uhle

Bug#991403: mtools: mcopy fails on arm*, breaks d-i builds

[Chris Lamb]

Paul Gevers wrote:

> Can you please revert at least the latest upload? We're extremely close
> to the release of bullseye, I don't want to see more trouble in d-i
> land, we had enough of that this freeze.

Sure, will do this tomorrow morning (BST).

ACK the comment about new upstreams versions. Alas, this upload was an
attempt to address a different regression (which shouldn't have been
introduced/uploaded to begin with...  ultimately, just underscoring
the entire purpose of freezes.) Lesson learned.


Regards,

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

Bug#991403: mtools: mcopy fails on arm*, breaks d-i builds

[Paul Gevers]

Hi Chris,

On Thu, 22 Jul 2021 21:00:57 +0200 Cyril Brulebois  wrote:
> On a side note, I must say I'm quite confused seeing all those new
> upstream releases going to unstable instead of experimental during a
> freeze:

Can you please revert at least the latest upload? We're extremely close
to the release of bullseye, I don't want to see more trouble in d-i
land, we had enough of that this freeze.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991372: unblock: glibc/2.31-13

[Cyril Brulebois]

Hi,

Aurelien Jarno  (2021-07-21):
> d-i team is Cc:ed.
> 
> unblock glibc/2.31-13

Looks good to me, thanks.


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


signature.asc
Description: PGP signature

Bug#991406: systemd: proc: unrecognized mount option "hidepid=invisible" or missing value

[Thomas Uhle]

Package: systemd
Version: 247.3-6
Severity: important

Dear maintainers,

after upgrading from buster to bullseye, I see the following error message 
in syslog multiple times (timestamp and host name stripped):


kernel: proc: unrecognized mount option "hidepid=invisible" or missing value

In some forum posts, it has been stated that it is due to 
/lib/systemd/systemd-remount-fs which seems to require a pretty recent 
Linux kernel like version 5.10 in bullseye. So everyone with a legacy 
kernel will get this error message in syslog several times because older 
kernels require a numerical value such as "hidepid=1" or "hidepid=2" 
instead of "hidepid=invisible".
Do you know whether this has already been fixed in a newer systemd version 
or whether this has already been dealt with upstream? I could not find 
anything with respect to this issue but I guess it should not be hard for 
a systemd developer to change systemd-remount-fs' behaviour depending on 
the running kernel version.

It really would be great if this could be fixed.

Thank you in advance!

Thomas Uhle


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 3.16.85-odroidc2 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-10
ii  libapparmor1 2.13.6-10
ii  libaudit11:3.0-2
ii  libblkid12.36.1-7
ii  libc62.31-12
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.18-4
ii  libcryptsetup12  2:2.3.5-1
ii  libgcrypt20  1.8.7-6
ii  libgnutls30  3.7.1-5
ii  libgpg-error01.38-2
ii  libip4tc21.8.7-1
ii  libkmod2 28-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.36.1-7
ii  libpam0g 1.4.0-9
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.3-6
ii  libzstd1 1.4.8+dfsg-2.1
ii  mount2.36.1-7
ii  systemd-timesyncd [time-daemon]  247.3-6
ii  util-linux   2.36.1-7

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.3-6
ii  libpam-systemd   247.3-6
ii  udev 247.3-6

Bug#991405: 389-ds-base: CVE-2021-3652

[Salvatore Bonaccorso]

Source: 389-ds-base
Version: 1.4.4.11-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/389ds/389-ds-base/issues/4817
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for 389-ds-base.

CVE-2021-3652[0]:
| CRYPT password hash with asterisk allows any bind attempt to succeed

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3652
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3652
[1] https://github.com/389ds/389-ds-base/issues/4817

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#991404: pppoeconf: diff for NMU version 1.21+nmu2

[Jochen Sprickerhof]

Package: pppoeconf
Version: 1.21+nmu1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for pppoeconf (versioned as 1.21+nmu2) and
uploaded it. I will also ask the release team to accept this into 
bullseye.


Regards

Jochen
diff -Nru pppoeconf-1.21+nmu1/debian/changelog pppoeconf-1.21+nmu2/debian/changelog
--- pppoeconf-1.21+nmu1/debian/changelog	2021-01-01 16:42:10.0 +0100
+++ pppoeconf-1.21+nmu2/debian/changelog	2021-07-22 20:51:01.0 +0200
@@ -1,3 +1,14 @@
+pppoeconf (1.21+nmu2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove -A option from pppoe-discovery (Closes: #990978).
+It had no function anymore and was removed in new versions.
+Thanks: Michael Prokop
+  * Apply two manpage corrections (Closes: #814354).
+Thanks: Christoph Biedl
+
+ -- Jochen Sprickerhof   Thu, 22 Jul 2021 20:51:01 +0200
+
 pppoeconf (1.21+nmu1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru pppoeconf-1.21+nmu1/pppoeconf pppoeconf-1.21+nmu2/pppoeconf
--- pppoeconf-1.21+nmu1/pppoeconf	2013-12-27 03:07:24.0 +0100
+++ pppoeconf-1.21+nmu2/pppoeconf	2021-07-22 20:49:37.0 +0200
@@ -190,7 +190,7 @@
 
 touch $TMP/pppoe.scan
 ip link set $iface up
-($DISCOVERY_PROGRAM $mmm -A -I $iface > $TMP/$iface.pppoe ; rm $TMP/pppoe.scan) &
+($DISCOVERY_PROGRAM $mmm -I $iface > $TMP/$iface.pppoe ; rm $TMP/pppoe.scan) &
 
 ( time=0 ; while test -f $TMP/pppoe.scan ; do time=`expr $time + 6`; echo $time; sleep 1; done ) | $DIALOG --title "$title" --gauge "$text $mmode" 10 60 0
 
diff -Nru pppoeconf-1.21+nmu1/pppoeconf.8.sgml pppoeconf-1.21+nmu2/pppoeconf.8.sgml
--- pppoeconf-1.21+nmu1/pppoeconf.8.sgml	2013-12-27 03:07:24.0 +0100
+++ pppoeconf-1.21+nmu2/pppoeconf.8.sgml	2021-07-22 20:50:22.0 +0200
@@ -70,12 +70,12 @@
 DESCRIPTION
 
 The  program is user-friendly dialog
- based setup tool for pppd (and pppoe
- if needed). It will look for existing ethernet cards and look for ADSL
+ based setup tool for pppd (and pppoe if
+ needed). It will look for existing ethernet cards and look for ADSL
  hardware connected to one of them. You can add an interface name
  iface to force  to use it. Then it will get
  some login info and do some minor modifications to make working
- settings. Note that you can use ESC key to exit program when you wan.
+ settings. Note that you can use ESC key to exit program when you want.
 
   
   


signature.asc
Description: PGP signature

Bug#991403: mtools: mcopy fails on arm*, breaks d-i builds

[Cyril Brulebois]

Package: mtools
Version: 4.0.33-1
Severity: serious
Tags: d-i
Justification: breaks d-i
X-Debbugs-Cc: debian-b...@lists.debian.org

Hi,

The latest upload of mtools to unstable breaks d-i builds on arm* (at
least arm64 and armhf), hindering our ability to publish newer releases
of the installer for bullseye:

Example on arm64:

efi-image -o ./tmp/cdrom_grub/grub_efi -g arm64-efi \
-e aa64 -n debian-installer/arm64 \
-s y -d ./tmp/cdrom_grub/lib
util/efi-image: Using pre-signed grub-efi and shim binaries for aa64
util/efi-image: Running first pass of mkfs.msdos with size 25426 blocks
mkfs.fat 4.2 (2021-01-31)
./tmp/cdrom_grub/grub_efi/efi.img has 4 heads and 32 sectors per track,
hidden sectors 0x;
logical sector size is 512,
using 0xf8 media descriptor, with 50848 sectors;
drive number 0x80;
filesystem has 2 16-bit FATs and 4 sectors per cluster.
FAT size is 52 sectors, and provides 12677 clusters.
There are 4 reserved sectors.
Root directory contains 512 slots and uses 32 sectors.
Volume ID is deb1, no volume label.
mcopy: No directory slots
mcopy: No directory slots
mcopy: No directory slots
mcopy: No directory slots
mcopy: No directory slots
[ repeats a lot ]

Build failures with daily builds:
  https://d-i.debian.org/daily-images/arm64/20210722-02:15/build_cdrom_grub.log
  https://d-i.debian.org/daily-images/armhf/20210722-00:14/build_cdrom_grub.log

This can be reproduced with the debian-installer source package in
unstable, after a single change in build/config/common to catch up
with recent ABI change:

-LINUX_KERNEL_ABI ?= 5.10.0-7
+LINUX_KERNEL_ABI ?= 5.10.0-8

This is clearly a regression from the previous version (4.0.32-1),
which seemed plausible given the timing of daily build failure
regression (between Jul 21 and Jul 22); but that's also been confirmed
by reproducing the issue in an arm64 sid schroot on amdahl, then by
reverting to the previous version, unpacked in ~/mtools, and PATH
overridden with ~/mtools:$PATH → the issue goes away.


On a side note, I must say I'm quite confused seeing all those new
upstream releases going to unstable instead of experimental during a
freeze:
  https://tracker.debian.org/pkg/mtools


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Bug#991400: systemd: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service

[Michael Biebl]

Control: tags -1 + moreinfo
Control: severity -1 normal

Am 22.07.21 um 20:45 schrieb Thomas Uhle:

Package: systemd
Version: 247.3-6
Severity: important

Dear maintainers,

after upgrading from buster to bullseye, I have the following new error 
message in syslog every time after login:


systemd[1375]: -.slice: Failed to migrate controller cgroups from 
/user.slice/user-1000.slice/user@1000.service, ignoring: Permission denied





Are you booting with systemd.unified_cgroup_hierarchy=false
under bullseye.

If so, why?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#991402: mupdf: CVE-2021-37220

[Salvatore Bonaccorso]

Source: mupdf
Version: 1.17.0+ds1-1.3
Severity: important
Tags: security upstream
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=703791
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.17.0+ds1-1.3~deb11u1

Hi,

The following vulnerability was published for mupdf.

CVE-2021-37220[0]:
| MuPDF through 1.18.1 has an out-of-bounds write because the cached
| color converter does not properly consider the maximum key size of a
| hash table. This can, for example, be seen with crafted "mutool draw"
| input.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-37220
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-37220
[1] 
http://git.ghostscript.com/?p=mupdf.git;h=f5712c9949d026e4b891b25837edd2edc166151f
[2] https://bugs.ghostscript.com/show_bug.cgi?id=703791

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#983390: mesa-vulkan-drivers: bad interactions between VkLayer_MESA_device_select and other layers

[googlemail]

Recently, Mesa 20.3.5-1 was unblocked for Bullseye, and has resolved 
most issues I had encountered since upgrading from Buster on a test setup.


The notable exception is MangoHud on 32 bit Windows applications in 
Wine, which still dies rather silently on launch. Although not in all 
cases, since for example very old games that won't touch Vulkan at all 
and run completely through OpenGL work fine.


This still needs the workaround of either setting VK_ICD_FILENAMES 
appropriately, or making /usr/share/vulkan/icd.d/lvp_icd.i686.json 
unavailable.


I tested this with both MangoHud 0.6.1 (i386) from current Bullseye, and 
the upstream binary 0.6.5 release, same behaviour respectively.


But I'm unqualified to tell if this is still a Mesa issue, or needs to 
be resolved in MangoHud.


Still a massive improvement from 20.3.4-1, so big thanks anyway :-)

Bug#991400: systemd: Failed to migrate controller cgroups from /user.slice/user-1000.slice/user@1000.service

[Thomas Uhle]

Package: systemd
Version: 247.3-6
Severity: important

Dear maintainers,

after upgrading from buster to bullseye, I have the following new error 
message in syslog every time after login:


systemd[1375]: -.slice: Failed to migrate controller cgroups from 
/user.slice/user-1000.slice/user@1000.service, ignoring: Permission denied

Down below I have added a more comprehensive excerpt from syslog for you 
to see when this error message occurs (timestamps and host name stripped). 
From what I understand, this issue has already been brought up upstream by 
Michael Biebl (see https://github.com/systemd/systemd/issues/18047), but 
the patch at https://github.com/systemd/systemd/pull/18553 went into 
systemd version 248 which was obviously too late for bullseye. Since I 
still get the same error message, I guess that this patch yet has not been 
cherrypicked for the current binary release 247.3-6 in Debian and I would 
like to ask you if you could do so because I would like to stay with a 
stable Debian release after the release of bullseye.


Thank you in advance!

Thomas Uhle


-- Package-specific info:
<#part type="text/plain" disposition=attachment description="Bug script output">
systemd[1]: Created slice User Slice of UID 1000.
systemd-logind[648]: New session c1 of user thomas.
systemd[1]: Starting User Runtime Directory /run/user/1000...
systemd[1]: Finished User Runtime Directory /run/user/1000.
systemd[1]: Starting User Manager for UID 1000...
systemd[1375]: pam_unix(systemd-user:session): session opened for user 
thomas(uid=1000) by (uid=0)
systemd[1375]: Queued start job for default target Main User Target.
systemd[1375]: -.slice: Failed to migrate controller cgroups from 
/user.slice/user-1000.slice/user@1000.service, ignoring: Permission denied
systemd[1375]: Created slice User Application Slice.
[...]
systemd[1]: Started User Manager for UID 1000.
systemd[1]: Started Session c1 of user thomas.
<#/part>

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 3.16.85-odroidc2 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-10
ii  libapparmor1 2.13.6-10
ii  libaudit11:3.0-2
ii  libblkid12.36.1-7
ii  libc62.31-12
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.18-4
ii  libcryptsetup12  2:2.3.5-1
ii  libgcrypt20  1.8.7-6
ii  libgnutls30  3.7.1-5
ii  libgpg-error01.38-2
ii  libip4tc21.8.7-1
ii  libkmod2 28-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.36.1-7
ii  libpam0g 1.4.0-9
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.3-6
ii  libzstd1 1.4.8+dfsg-2.1
ii  mount2.36.1-7
ii  systemd-timesyncd [time-daemon]  247.3-6
ii  util-linux   2.36.1-7

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.3-6
ii  libpam-systemd   247.3-6
ii  udev 247.3-6

Bug#991401: mupdf: CVE-2020-19609

[Salvatore Bonaccorso]

Source: mupdf
Version: 1.17.0+ds1-1.3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.17.0+ds1-1.3~deb11u1

Hi,

The following vulnerability was published for mupdf.

CVE-2020-19609[0]:
| Artifex MuPDF before 1.18.0 has a heap based buffer over-write in
| tiff_expand_colormap() function when parsing TIFF files allowing
| attackers to cause a denial of service.

Upstream issue [4] contains a reproducer.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-19609
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-19609
[1] 
http://git.ghostscript.com/?p=mupdf.git;h=b7892cdc7fae62aa57d63ae62144e1f11b5f9275
[2] 
http://git.ghostscript.com/?p=mupdf.git;h=2c4f11f8dcdbd18c35a65e58cc789be0e46012a8
[3] https://bugs.ghostscript.com/show_bug.cgi?id=701176
[4] https://bugs.ghostscript.com/show_bug.cgi?id=703076

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#991365: krb5: CVE-2021-36222

[Benjamin Kaduk]

Yes, I started working on an upload for buster, but got a bit sidetracked
since the 1.17-3+deb10u1 in the archive was not imported into the packaging
repo previously.

I expect to make progress today.

-Ben

Bug#989612: mke2fs -E offset=N still warns about existing partition table at the beginning

[Josh Triplett]

On Wed, Jul 21, 2021 at 10:24:32PM -0400, Theodore Ts'o wrote:
> Thanks for reporting this bug.  The following commit should fix the
> issue.
> 
>   - Ted
> 
> commit 942b00cb9d2f2b52f4c58877d523145ee59a89b0
> Author: Theodore Ts'o 
> Date:   Wed Jul 21 15:46:09 2021 -0400
> 
> mke2fs: do not warn about a pre-existing partition table when using a 
> non-zero offset
> 
> The existing code attempted to avoid warning about a pre-existing file
> system with a non-zero offset, but because the offset was not set at
> the time of the check, this intention was not actually working.  So
> this commit will suppress warnings about pre-existing a partition
> table as well as pre-existing file system when there is a non-zero
> offset.

Thank you!

Bug#991365: krb5: CVE-2021-36222

[Salvatore Bonaccorso]

Hi Benjamin,

On Wed, Jul 21, 2021 at 10:37:55AM -0700, Benjamin Kaduk wrote:
> On Wed, Jul 21, 2021 at 07:13:49PM +0200, Salvatore Bonaccorso wrote:
> > 
> > On Wed, Jul 21, 2021 at 10:01:23AM -0600, Sam Hartman wrote:
> > 
> > About buster: Given the above we can fix via the upcoming point
> > release for buster, I guess that can be enough in this case. What
> > would happen if the unauthenticated user "hammers" with it the KDC
> > which is then continously restarted, what would be the impact? Sorry
> > for my ignorance.
> 
> I believe that given the relative network traffic flows, KDC startup time,
> and systemd behavior, a dedicated attacker flooding the "bad" packets
> towards a KDC would be able to effectively DoS the legitimate clients with
> a relatively small outbound pipe.  It would not be a full DoS, since some
> legitimiate requests would be handled, but the legitimate clients have a
> well-behaved retry and backoff timer and it is easy for the attacker to win
> the race.  Sites typically have multiple KDCs for redundancy, but they are
> typically all discoverable by all clients, including the attacker.
> Furthermore, if the KDC is crashing repeatedly on startup, my recollection
> is that systemd will back off how quickly it is restarted and may
> eventually disable the unit entirely.
> 
> The mitigating factor here is that an administrator would in theory be able
> to detect the bad traffic and block it with a firewall, but that turns into
> a cat and mouse game that a dedicated attacker will probably win.
> 
> Which, all together, might actually support serious after all rather than
> important.

Okay in this case, I guess you convinced me that a DSA might be
appropriate. Would you be available to prepare an update for
buster-security accordingly as well?

I see you filled as well #991374 for an unblock into bullseye, thank
you. We should make sure this get accepted.

Regards,
Salvatore

Bug#991399: mariadb: Daemon hangs on stop with replication and parallel slaves

[Guillem Jover]

Source: mariadb-10.5
Source-Version: 1:10.5.10-2
Severity: serious
Forwarded: https://jira.mariadb.org/browse/MDEV-20821
Control: fixed -1 1:10.5.11-1~exp1

Hi!

When replication is enabled with the slave running in parallel mode,
the daemon completely hangs and will not terminate, which means daemon
shutdowns need to timeout and a SIGKILL sent to take effect, as such
daemon restarts will fail.

This is fixed in upstream 10.5.11, the relevant upstream bugs are:

  https://jira.mariadb.org/browse/MDEV-20821
  https://jira.mariadb.org/browse/MDEV-22370

I've set this as serious, as ending up with no mariadb running on a
system can be pretty fatal, and because upstream had it as "critical",
but feel free to lower if you think it would not deserve it. Given that
there appears to be a version that fixes this issue in experimental, it
seems this would not be too cumbersome, and it would be nice if that
could be targeted for bullseye.

Thanks,
Guillem

Bug#961401: Sequence of module loading is relevant

[Markus Hiereth]

Dear Maintainers,

recently I found out that scanner communication is dependent on the
sequence of loading of the two kernel modules ehci-hcd and uhci-hcd.

This sequence may, in normal day-by-day boot procedures, differ. Thus,
the scanner communication fails sometimes; Or, to tell the truth, it
fails more often than it works.

As I managed to make the scanner work by unloading all kernel modules
(rmmod) and afterward loading (modprobe) them manually, I made
variations of the loading sequence.

Meanwhile I found out, that the most simple way to establish
communication with the scanner on the USB bus is to unload only
ehce-hcd and uhci-hcd followed by loading first ehci-hcd and then
uhci-hcd.

Probably this helps you to analyse the problem and serves others who
have similar problems with USB devices as a workaround.

Best regards
Markus Hiereth

Bug#991398: Wrong file sizing

[Totorito Totorito]

Package: dphys-swapfile
Version: 20100506-5

Dear Maintainer,
When I use an external usb to create a swap file, with the actual configuration 
I cannot go over 50% of the whole size of the drive.

Please correct the code at this part
"
HALF_AVAIL_MB=$(echo "${AVAIL_KB} 2048 / p" | dc)
 if [ "${CONF_SWAPSIZE}" -gt "${HALF_AVAIL_MB}" ] ; then
 echo -n ", restricting to ${CONF_MAXDISK_PCT}% of remaining disk size: 
${HALF_AVA$
 CONF_SWAPSIZE="${HALF_AVAIL_MB}"
 fi
"

So I can use the variable CONF_MAXDISK_PCT correctly and go over 50% of the 
whole space.
I’m using "Linux Raspbian 5.10.17-v7+ #1421 SMP Thu May 27 13:59:01 BST 2021 
armv7l GNU/Linux"

—
Tommaso Carraro

Bug#991320: flameshot crashing on startup

[allan]

this link and the link above only address the tray icon - nothing on
the network thing on github bugtracker.  both of these bugs are
closed.

https://github.com/flameshot-org/flameshot/issues/1721

amusingly, if i rename flameshot.ini and start the flameshot daemon in
the background (which is how i had it set up in openbox autostart)
flameshot works as expected.  diff between default config and mine -

wizard@wizard-fujitsu:~/.config/flameshot$ diff flameshot.ini
flameshot.ini.broken
2,5c2,7
< disabledTrayIcon=false
< drawColor=#ff
< drawThickness=0
< showStartupLaunchMessage=true
---
> # disabledTrayIcon=true
> drawColor=#00ff00
> drawThickness=9
> savePath=/media/internal/temp
> startupLaunch=false
> # checkForUpdates=false

using the config i had that's been working for over a year flameshot
daemon (flameshot &) crashes if checkForUpdates=false.

starting 'flameshot gui' without the daemon running in the background
crashes with either config.





On Thu, Jul 22, 2021 at 8:43 AM allan  wrote:
>
> i think i figured it out.  looks like it's upstream and wontfix.
>
> https://github.com/flameshot-org/flameshot/issues/1730



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

Bug#991397: unblock: exim4/4.94.2-7

[Andreas Metzler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ex...@packages.debian.org, Adrian Bunk 

Please unblock package exim4

This is release fixes a single bug by pulling the respective fix from
upstream's +fixes branch.

When control=fakereject is used with a custom error message the
respective non-safe data was expanded. With allow_insecure_tainted_data
not set this only causes a entry in paniclog, otherwise the actual
expansion might happen.

Debian's default exim configuration does not use control=fakereject but
still I would consider this an important bug that I would like to see
fixed.

unblock exim4/4.94.2-7

Thanks, 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'
diff -Nru exim4-4.94.2/debian/changelog exim4-4.94.2/debian/changelog
--- exim4-4.94.2/debian/changelog	2021-05-26 18:49:44.0 +0200
+++ exim4-4.94.2/debian/changelog	2021-07-13 18:04:57.0 +0200
@@ -1,3 +1,10 @@
+exim4 (4.94.2-7) unstable; urgency=medium
+
+  * 73_05-Fix-tainted-message-for-fakereject.patch from upstream +fixes
+branch: Fix re-expansion of custom message with control=fakereject.
+
+ -- Andreas Metzler   Tue, 13 Jul 2021 18:04:57 +0200
+
 exim4 (4.94.2-6) unstable; urgency=medium
 
   * Cherrypick
diff -Nru exim4-4.94.2/debian/patches/73_05-Fix-tainted-message-for-fakereject.patch exim4-4.94.2/debian/patches/73_05-Fix-tainted-message-for-fakereject.patch
--- exim4-4.94.2/debian/patches/73_05-Fix-tainted-message-for-fakereject.patch	1970-01-01 01:00:00.0 +0100
+++ exim4-4.94.2/debian/patches/73_05-Fix-tainted-message-for-fakereject.patch	2021-07-13 18:03:04.0 +0200
@@ -0,0 +1,44 @@
+From c819f3bcad02bcb06004ae2ad135b68fab0ae888 Mon Sep 17 00:00:00 2001
+From: Jeremy Harris 
+Date: Wed, 7 Jul 2021 22:19:07 +0100
+Subject: [PATCH 5/5] Fix tainted message for fakereject
+
+(cherry picked from commit a9ac2d7fc219e41a353abf1f599258b9b9d21b7e)
+---
+ doc/ChangeLog | 4 
+ src/acl.c | 4 +++-
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/doc/ChangeLog b/doc/ChangeLog
+index e60c1cad5..3e93f653f 100644
+--- a/doc/ChangeLog
 b/doc/ChangeLog
+@@ -227,6 +227,10 @@ JH/53 Bug 2743: fix immediate-delivery via named queue.  Previously this would
+   fail with a taint-check on the spoolfile name, and leave the message
+   queued.
+ 
++JH/57 Fix control=fakreject for a custom message containing tainted data.
++  Previously this resulted in a log complaint, due to a re-expansion present
++  since fakereject was originally introduced.
++
+ 
+ Exim version 4.94
+ -
+diff --git a/src/acl.c b/src/acl.c
+index 7061230b4..65324405c 100644
+--- a/src/acl.c
 b/src/acl.c
+@@ -3137,7 +3137,9 @@ for (; cb; cb = cb->next)
+ 	{
+ 	const uschar *pp = p + 1;
+ 	while (*pp) pp++;
+-	fake_response_text = expand_string(string_copyn(p+1, pp-p-1));
++	/* The entire control= line was expanded at top so no need to expand
++	the part after the / */
++	fake_response_text = string_copyn(p+1, pp-p-1);
+ 	p = pp;
+ 	}
+ 	   else /* Explicitly reset to default string */
+-- 
+2.30.2
+
diff -Nru exim4-4.94.2/debian/patches/series exim4-4.94.2/debian/patches/series
--- exim4-4.94.2/debian/patches/series	2021-05-22 13:27:33.0 +0200
+++ exim4-4.94.2/debian/patches/series	2021-07-13 18:03:23.0 +0200
@@ -10,6 +10,7 @@
 73_02-Fix-ipv6norm.patch
 73_03-Named-Queues-fix-immediate-delivery.-Bug-2743.patch
 73_04-Fix-host_name_lookup-Close-2747.patch
+73_05-Fix-tainted-message-for-fakereject.patch
 75_01-Introduce-main-config-option-allow_insecure_tainted_.patch
 75_02-search.patch
 75_03-dbstuff.patch


signature.asc
Description: PGP signature

Bug#991396: sdic-gene95: fails to install behind proxy

[Andreas Beckmann]

Package: sdic-gene95
Version: 2.1.3-22
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install if
the only internet connectivity available is a proxy set via environment
variables {http,https,ftp}_proxy.

The postinst checks
  nc -w 3 -z www.namazu.org 80
(ignoring any proxy settings) before downloading the file with wget
(which would honour the proxy settings).

This seems to be the only package doing it this way.

And while we are at it:

* there is no validation of the downloaded file (e.g. comparison with a
known sha512 sum)
* the default download location is /tmp which is writable by everyone,
so everyone can place files with names expected by the postinst script
there. It does not look like these will be used, but their presence
will at least break package installation. And there may be a possibility
for symlink attacks and race conditions.

cheers,

Andreas

Bug#991395: r-cran-knitr: New upstream version needed by other R packages

[Dirk Eddelbuettel]

Package: r-cran-knitr
Severity: normal

We have knitr 1.31 per
  https://packages.debian.org/search?keywords=r-cran-knitr
but upstream is (since April) at 1.33 per
  https://cran.r-project.org/package=knitr
which is now needed by e.g. rgl aka r-cran-rgl.

We are in a freeze, so I too have been uploading to experimental but it would
be nice if you could drop it into experimental now so I can put r-cran-rgl 
there.

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#991393: debhelper should probably prevent zero mtime in packages

[Andrej Shadura]

Source: debhelper
Severity: wishlist

Hi,

As a maintainer and the upstream of inputplug, I ran into this conflict
between what cargo produces and what the Debian archive expects: since
[1], cargo publish resets mtime of all files to 0. On the contrary, if
any of those files leak into .debs, they will be REJECTed by the
archive [2]. While arguably this is something cargo should not do or my
d/rules should have fixed, it would be great if debhelper could fix that
for me.

[1]: https://github.com/rust-lang/cargo/pull/8864
[2]: https://bugs.debian.org/991369


-- 
Cheers,
  Andrej

Bug#991141: possible fix

[Michael Walle]

It seems that debian-cd (re)builds its own efi.img and doesn't
add the dtbs but only the EFI/ subdirectory from the d-i
efi.img.

This might fix the problem, please take it with a grain of salt
because I was unable to actually test it. I've tried the
commands by hand though.

diff --git a/tools/boot/bullseye/boot-arm64 
b/tools/boot/bullseye/boot-arm64

index d954dff3..7c55d408 100755
--- a/tools/boot/bullseye/boot-arm64
+++ b/tools/boot/bullseye/boot-arm64
@@ -84,9 +84,11 @@ cat cdrom/debian-cd_info.tar.gz | (cd boot$N/; tar 
zx)

 if [ -d boot$N/grub ] ; then
 echo "  Adding EFI boot code for $ARCH on CD$N"

-# Move GRUB files to the right place.
+# Move GRUB and DTB files to the right place.
 mkdir -p $CDDIR/EFI/boot
 mcopy -n -s -i boot$N/grub/efi.img '::efi/*' $CDDIR/EFI
+mkdir -p $CDDIR/dtb
+mcopy -n -s -i boot$N/grub/efi.img '::dtb/*' $CDDIR/dtb
 mkdir -p $CDDIR/boot/grub
 mv boot$N/grub/* $CDDIR/boot/grub/
 rmdir boot$N/grub

--
-michael

Bug#991099: gem2deb should Provides: dh-sequence-ruby

[Antonio Terceiro]

Hi,

On Wed, Jul 14, 2021 at 07:46:09AM +0200, Helmut Grohne wrote:
> Package: gem2deb
> Version: 1.4
> Tags: patch
> 
> Traditionally, packages could enable debhelper addons using
> --with=ADDON. That's what works today and is most commonly used.
> Recently, debhelper added another way of doing so. If one declares a
> build dependency on dh-sequence-ADDON, the addon is automatically
> enabled. This is beneficial for two major reason:
>  * Don't repeat yourself. There no longer is a need to issue both
>"Build-Depends: gem2deb" and "dh --with=ruby". A single
>"Build-Depends: dh-sequence-ruby" takes care of both.
>  * We can declaratively conditionalize Build-Depends. The most obvious
>one is e.g. "Build-Depends-Indep: dh-sequence-ruby". Conditionally
>enabling an addon in debian/rules has been quite annoying thus far
>and the declarative method makes it simple. Build profiles are also
>supported, so "Build-Depends: dh-sequence-ruby " does the
>right thing.
> 
> As such, please consider applying the attached patch. I think that this
> is really harmless, so if there is any chance of getting this into
> bullseye, please do it. Otherwise, it'll have to be added to
> bullseye-backports in order to support packages in bookworm that start
> relying on it. I do see that this comes quiet late, so I don't expect
> miracles.

Thanks.

I applied your patch but I don't intend to upload any non-bugfix update
to gem2deb this late into the freeze.


signature.asc
Description: PGP signature

Bug#991320: flameshot crashing on startup

[allan]

i think i figured it out.  looks like it's upstream and wontfix.

https://github.com/flameshot-org/flameshot/issues/1730

Bug#991275: tar doesn't restore all directory timestamps from the extracted archive

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 
https://lists.gnu.org/archive/html/bug-tar/2021-07/msg00011.html

I've reported the bug upstream.

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

Bug#991320: flameshot crashing on startup

[allan]

not able to choke my network as option isn't available in kernel
module, connman or router.  using iw to throttle bitrate seems to be
unsupported by this intel chipset or at least it's not in the list of
supported commands if you do 'iw list'.

flameshot 0.9 appimage took some digging to find but also crashes -

wizard@wizard-fujitsu:~/temp$ ./Flameshot-0.9.0.x86_64.AppImage
Run experimental self-contained bundle
QSettings::value: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
Segmentation fault
wizard@wizard-fujitsu:~/temp$

purged 0.9 and installed current flameshot 0.10.0.rc1-1 deb from
github and it works as expected.

then i purged 0.10 and reinstalled 0.9 from sid repo in case we need
more testing.  if i really need to run flameshot i can just disable
checking for upgrades for the time being.

Bug#991392: flameshot: Don't "phone home" for updates by default

[Chris Lamb]

Source: flameshot
Version: 0.9.0+ds1-1
Severity: important
Tags: patch

Hi,

By default, flameshot "calls home" every 24 hours via the GitHub API
to check for new versions. This is not quite in the Debian tradition
and doesn't present the best UI/UX experience given the presence of
APT repos.

I have attached a patch to change the default setting for this
configuration option. Users who wish to enable the behaviour
post-installation may do so, but this patch renders this opt-in.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/src/utils/confighandler.cpp b/src/utils/confighandler.cpp
index 6786225..b63237f 100644
--- a/src/utils/confighandler.cpp
+++ b/src/utils/confighandler.cpp
@@ -298,7 +298,7 @@ void ConfigHandler::setKeepOpenAppLauncher(const bool 
keepOpen)
 
 bool ConfigHandler::checkForUpdates()
 {
-bool res = true;
+bool res = false;
 if (m_settings.contains(QStringLiteral("checkForUpdates"))) {
 res = m_settings.value(QStringLiteral("checkForUpdates")).toBool();
 }

Bug#991391: metrohash FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: metrohash
Version: 1.1.3-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

metrohash fails to cross build from source, because debian/rules uses
the build architecture compiler via a make default variable in
debian/rules. The easiest way of fixing that - using dpkg's
buildtools.mk - makes metrohash cross buildable. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru metrohash-1.1.3/debian/changelog 
metrohash-1.1.3/debian/changelog
--- metrohash-1.1.3/debian/changelog2019-01-28 20:34:42.0 +0100
+++ metrohash-1.1.3/debian/changelog2021-07-22 14:50:10.0 +0200
@@ -1,3 +1,10 @@
+metrohash (1.1.3-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply cross tools. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 22 Jul 2021 14:50:10 +0200
+
 metrohash (1.1.3-4) unstable; urgency=medium
 
   * d/control: Fix Homepage
diff --minimal -Nru metrohash-1.1.3/debian/rules metrohash-1.1.3/debian/rules
--- metrohash-1.1.3/debian/rules2019-01-28 20:33:47.0 +0100
+++ metrohash-1.1.3/debian/rules2021-07-22 14:50:09.0 +0200
@@ -1,7 +1,8 @@
 #!/usr/bin/make -f
 
 #export DH_VERBOSE=1
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
 
 CXXFLAGS+=-Wall -pedantic -fPIC
 LDFLAGS+=-shared -Wl,-as-needed -Wl,-soname,libmetrohash.so.1

Bug#991390: digitools FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: digitools
Version: 1.03-1.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

digitools fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes digitools cross buildable. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru digitools-1.03/debian/changelog 
digitools-1.03/debian/changelog
--- digitools-1.03/debian/changelog 2013-06-04 11:56:00.0 +0200
+++ digitools-1.03/debian/changelog 2021-07-22 14:44:33.0 +0200
@@ -1,3 +1,10 @@
+digitools (1.03-1.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 22 Jul 2021 14:44:33 +0200
+
 digitools (1.03-1.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru digitools-1.03/debian/rules digitools-1.03/debian/rules
--- digitools-1.03/debian/rules 2012-02-27 19:25:10.0 +0100
+++ digitools-1.03/debian/rules 2021-07-22 14:44:32.0 +0200
@@ -35,7 +35,7 @@
 build-stamp: configure-stamp 
 
# Add here commands to compile the arch part of the package.
-   $(MAKE) 
+   dh_auto_build
touch build-stamp
 
 clean:

Bug#991381: [Pkg-phototools-devel] Bug#991381: darktable: camera not showing in lens correction list and not recognised but is supported

[David Bremner]

Control: tag -1 moreinfo

Stas Zytkiewicz  writes:

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

Let me know if the problem can be replicated on Debian.

Bug#991389: Should keytouch-editor get removed from bullseye?

[Adrian Bunk]

Package: keytouch-editor
Severity: serious
Tags: bullseye sid

Quoting #988541:

keytouch-editor is an editor for creating files for keytouch.
keytouch was removed from Debian 10 years ago because it was broken

Bug#991388: Should prometheus-nginx-vts-exporter be removed from bullseye?

[Adrian Bunk]

Package: prometheus-nginx-vts-exporter
Severity: serious

See #988002 for background.

Bug#991379: ITP: gh -- the Github CLI

[Paride Legovini]

Note-to-self and possibly others:

The "full text" link of the "Marked Bug as done" entry has the full text 
of the email sent to control@ to close the bug, and it contains the 
explanation.


I normally use the `Control:` pseudo-headers and didn't think of looking 
there. Thanks Bart for the pointer.


Cheers,

Paride

Bug#991387: Should librpcsecgss be shipped in bullseye?

[Adrian Bunk]

Source: librpcsecgss
Version: 0.19-7
Severity: serious
Tags: bullseye sid

Quoting #986300:

librpcsecgss was a library written by the NFS4 on Linux project. It is
however, now unused in Debian, and the current upstream NFS4 (userland)
implementation also does not need/ship it anymore. Therefore it will
also not be reintroduced when updating Debians NFS code.

Bug#985072: RM: python-ceilometerclient -- ROM; Deprecated upstream

[Adrian Bunk]

Control: tags -1 moreinfo

On Fri, Mar 12, 2021 at 03:37:02PM +0100, Thomas Goirand wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> 
> Hi,
> 
> It's been a few OpenStack releases that there's no ceilometer-api service in
> OpenStack (only old-stable has it), and therefore, python-ceilometerclient
> is deprecated upstream. These days, Ceilometer directly pushes metrics to
> Gnocchi.
> 
> So, let's remove python-ceilometerclient from Sid and Bullseye before we
> release.

Some reverse (build) dependencies need fixing first:

# Broken Depends:
aodh: python3-aodh
ceilometer: python3-ceilometer
openstack-meta-packages: openstack-clients
rally-openstack: python3-rally-openstack
vitrage-tempest-plugin: vitrage-tempest-plugin
watcher: python3-watcher

# Broken Build-Depends:
aodh: python3-ceilometerclient
ceilometer: python3-ceilometerclient
rally-openstack: python3-ceilometerclient
watcher: python3-ceilometerclient


> Thanks,
> 
> Thomas Goirand (zigo)

cu
Adrian

Bug#991267: pg_config.h leaks internal macros

[Peter Eisentraut]

On 21.07.21 13:51, Max Kellermann wrote:

On 2021/07/21 13:42, Peter Eisentraut  wrote:

What specifically are you trying to check for in libpq?  Maybe there is a
better way, or we could add one.


It's about this compile-time check:

  https://github.com/CM4all/libcommon/blob/master/src/pg/Connection.hxx#L430

This is a C++ wrapper for libpq, and some users of this library run on
very old Debian versions with just libpq 8, and other users run on
Debian 11 with libpq wrapped in C++20 Coroutines, and for that they
need PQsetSingleRowMode() which is only available since version 9.


For more recently added features, libpq has feature macros such as

/* Indicates presence of PQenterPipelineMode and friends */
#define LIBPQ_HAS_PIPELINING 1
/* Indicates presence of PQsetTraceFlags; also new PQtrace output format */
#define LIBPQ_HAS_TRACE_FLAGS 1

The feature you are testing arrived in PostgreSQL 9.2, so it's too old 
to do anything about at this point.

Bug#991386: Security vulnerability: Denial of Service

[Marcus Frings]

Source: ublock-origin
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

Disclosure: 
https://github.com/vtriolet/writings/blob/main/posts/2021/ublock_origin_and_umatrix_denial_of_service.adoc

Fixed in 1.36.2: https://github.com/gorhill/uBlock/releases/tag/1.36.2

Bug#991385: pulseaudio: bluetooth auto-loopback for a2dp doesn't work since pulseaudio 14

[Sander van Grieken]

Package: pulseaudio
Version: 14.2-2
Severity: important
X-Debbugs-Cc: san...@outrightsolutions.nl

Dear Maintainer,

* What led up to the situation?

I had a working A2DP bluetooth sink working on a headless device, by utilizing
the auto-loopback feature :

load-module module-bluetooth-policy a2dp_source=1 hfgw=0

Somewhere between pulseaudio-13.0-5 and pulseaudio-14.2-2 the auto-loopback
functionality stopped working.
The audio is still arriving on the device (as seen by pavucontrol peak-meters),
just the loopback module isn't loaded anymore.

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

I downgraded pulseaudio to 13.0-5, which restored the auto-loopback feature




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


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1:1.2.2-dmo1
ii  libc62.31-12
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2
ii  libgcc-s110.2.1-6
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.2-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-1
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-6
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.3-6
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.2-2

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

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

-- Configuration Files:
/etc/pulse/default.pa changed [not included]

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
autospawn = no

; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; 

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

[Martin-Éric Racine]

Hey Sudip!

ti 20. heinäk. 2021 klo 22.49 Sudip Mukherjee
(sudipm.mukher...@gmail.com) kirjoitti:
> On Tue, Jul 20, 2021 at 6:51 PM Martin-Éric Racine
>  wrote:
> >
> > Package: micro-httpd
> > Version: 20051212-15.1
> > Severity: normal
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > The dependencies in the systemd files that currently ship with micro-httpd 
> > only work if micro-httpd is bound to 0.0.0.0 as shipped. If it's bound to 
> > another IP address, systemd will report a failure to launch micro-httpd, 
> > because all network interfaces are not up yet, so the IP we're trying to 
> > bind to hasn't been assigned to any interface yet.
>
> Thanks for using micro-httpd and testing. Will attend to this one and
> also the earlier one that you have raised after the freeze is over.

Thanks for the acknowledgement. Looking forward to this.

Martin-Éric

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

[Paul Gevers]

Control: tags -1 moreinfo

Hi Jelmer,

On 21-07-2021 00:24, Jelmer Vernooij wrote:
> Done, thanks. Hopefully this looks alright.

The diff of the package in tpu doesn't look like the one I ACKed.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982159: wine-development won't be in future stable releases

[Adrian Bunk]

Control: severity -1 serious

wine-development won't be in future stable releases, see #988246.

cu
Adrian

Bug#991384: libwine-development fails to install on arm*: head: cannot open '/usr/aarch64-w64-mingw32/lib/zlib*.dll' for reading: No such file or directory

[Adrian Bunk]

Package: libwine-development
Version: 6.0+repack-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:dxvk

https://buildd.debian.org/status/logs.php?pkg=dxvk=1.9+ds1-1

...
Setting up libwine-development:arm64 (6.0+repack-1) ...
head: cannot open '/usr/aarch64-w64-mingw32/lib/zlib*.dll' for reading: No such 
file or directory
dpkg: error processing package libwine-development:arm64 (--configure):
 installed libwine-development:arm64 package post-installation script 
subprocess returned error exit status 1
...

Bug#991383: glusterfs-server: Separate glusterfs-cli package

[Dominic Jäger]

Package: glusterfs-server
Version: 9.2-1
Severity: wishlist

Dear Maintainer,

the package glusterfs-server provides the whole gluster command line utility 
[0].
This includes the remote-host functions.

I think it would be useful to separate these command line functions out of
glusterfs-server into a separate package glusterfs-cli. One use case is
listing all available volumes on a remote Gluster cluster
> gluster --remote-host=192.168.0.150 volume list
so that one of them can be mounted without having the whole Gluster server
installed.

It is implemented this way in, for example, Fedora [1].
Kaleb S. KEITHLEY mentioned in Gluster Slack #development that the Gluster
Community packages would follow the lead of the Debian/Ubuntu packaging bits
in this case.

[0] https://manpages.debian.org/testing/glusterfs-server/gluster.8.en.html
[1] 
https://fedora.pkgs.org/34/fedora-x86_64/glusterfs-cli-9.1-1.fc34.x86_64.rpm.html


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

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

Versions of packages glusterfs-server depends on:
ii  glusterfs-client  9.2-1
ii  glusterfs-common  9.2-1
ii  libc6 2.31-12
ii  libgfrpc0 9.2-1
ii  libgfxdr0 9.2-1
ii  libglusterd0  9.2-1
ii  libglusterfs0 9.2-1
ii  libreadline8  8.1-1
ii  libxml2   2.9.10+dfsg-6.7
ii  lsb-base  11.1.0

Versions of packages glusterfs-server recommends:
ii  nfs-common  1:1.3.4-6

glusterfs-server suggests no packages.

-- no debconf information

Bug#991158: media-types: use image/x-xcf rather than application/x-xcf to match gimp.desktop

[Charles Plessy]

Control: tag -1 pending

Le Sat, Jul 17, 2021 at 07:29:22AM +1000, Joel Hockey a écrit :
> 
> The GIMP team have confirmed that image/x-xcf is the correct mime.
> 
> https://www.mail-archive.com/gimp-developer-list%40gnome.org/msg09755.html

Thanks Joel,

the change will be applied after the release.

It seems that a couple of other packages have borrowed mime-support's
media type.

http://codesearch.debian.net/search?q=application%2Fx-xcf=1

I will notify their maintainers.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#991379: ITP: gh -- the Github CLI

[Paride Legovini]

On Thu, 22 Jul 2021 01:31:02 +0100 Scupake  wrote:>

* Package name: gh
* URL : https://cli.github.com/
* License : MIT


Hi,

Was this bug closed after some out-of-band discussion? If this is the 
case I think it's worth leaving a note on the bug itself, as a head-up 
for people going down the same road in the future.


Thanks!

Paride

Bug#991382: udev: cdr-drive opens after suspend

[Michael Biebl]

Control: tags -1 + moreinfo

Am 22.07.21 um 08:53 schrieb M G Berberich:

Package: udev
Version: 247.3-6
Severity: normal

Dear Maintainer,

for some days the cdrom-drive opens after the system wakes up from
suspend.  This occured after installing kernel 5.13.X, but this might
be a coincidence.

The kernel is a stock kernel:
Linux 5.13.4 #3 SMP PREEMPT Tue Jul 20 21:09:45 CEST 2021 x86_64 GNU/Linux



What makes you conclude this is a udev bug?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983435: you all forgot to fix stable

[bugsgrid+deb]

Control: found -1 2.02+dfsg1-20+deb10u3
Control: found -1 2.04-10
Control: fixed -1 2.04-19
# adding back versions for reopen

Seriously, I reported that the issue exists in sid _too_,
just for your convenience,
and then you fixed only sid...  what is this?

If refreshing the patch is so hard to take a time,
why not just revert it already?

IMO the offending patch itself is not suitable for stable from the very first.
I believe "stable" should prefer stable in behavior,
not some random additon of seemingly good intention.
It is not solving any bug or whatsoever, and introduced an actual bug.

Now "stable" is just stale at broken state.

Bug#991381: darktable: camera not showing in lens correction list and not recognised but is supported

[Stas Zytkiewicz]

Package: darktable
Version: 3.6.0-1.1
Severity: normal

Dear Maintainer,


I have a Canon 800D.
When I open a RAW image in darkroom the lens correction always fails to detect 
the camera. It will recognize the lens but not the camera. It tells me to add 
it manually.
But the list with Canon cameras doesn't show a 800D/Rebel T7i.
Looking in /usr/share/darktable/rawspeed/cameras.xml I see that the 800D is 
supported (also the 80D is in the xml but not in the list)
I have double checked that the exif data displays the correct camera type and 
the firmware in the camera is up to date.
Not sure why multiple cameras that are inside the xml file don't show up in the 
"manual add" camera list?

This is the out put of the exiftool:
exiftool IMG_1638.CR2 | grep -i "camera.*name"
Camera Model Name : Canon EOS 800D

The fix is to add the dependency for liblensfun-bin which contains the 
lensfun-update-data tool.
Then run the lensfun-update-data to update the lensfun dbase with all the 
supported cameras.
See also my guthub issue in the darktable repo:
https://github.com/darktable-org/darktable/issues/9562


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

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

Versions of packages darktable depends on:
ii  fonts-roboto 2:0~20170802-3
ii  iso-codes4.4-1
ii  libc62.31-0ubuntu9.2
ii  libcairo21.16.0-4ubuntu1
ii  libcolord-gtk1   0.2.0-0ubuntu1
ii  libcolord2   1.4.4-2
ii  libcups2 2.3.1-9ubuntu1.1
ii  libcurl3-gnutls  7.68.0-1ubuntu2.5
ii  libexiv2-27  0.27.2-8ubuntu2.4
ii  libgcc-s110.3.0-1ubuntu1~20.04
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-3ubuntu0.2
ii  libglib2.0-0 2.64.6-1~ubuntu20.04.3
ii  libgomp1 10.3.0-1ubuntu1~20.04
ii  libgphoto2-6 2.5.25-0ubuntu0.1
ii  libgphoto2-port122.5.25-0ubuntu0.1
ii  libgraphicsmagick-q16-3  1.4+really1.3.35-1
ii  libgtk-3-0   3.24.20-0ubuntu1
ii  libicu66 66.1-2ubuntu2
ii  libilmbase24 2.3.0-6build1
ii  libjpeg8 8c-2ubuntu8
ii  libjs-prototype  1.7.1-3
ii  libjs-scriptaculous  1.9.0-2
ii  libjson-glib-1.0-0   1.4.4-2ubuntu2
ii  liblcms2-2   2.9-4
ii  liblensfun1  0.3.2-5build1
ii  liblua5.3-0  5.3.3-1.1ubuntu2
ii  libopenexr24 2.3.0-6ubuntu0.5
ii  libopenjp2-7 2.3.1-1ubuntu4.20.04.1
ii  libosmgpsmap-1.0-1   1.1.0-6
ii  libpango-1.0-0   1.44.7-2ubuntu4
ii  libpangocairo-1.0-0  1.44.7-2ubuntu4
ii  libpng16-16  1.6.37-2
ii  libpugixml1v51.10-1
ii  librsvg2-2   2.48.9-1ubuntu0.20.04.1
ii  libsecret-1-00.20.4-0ubuntu1
ii  libsoup2.4-1 2.70.0-1
ii  libsqlite3-0 3.31.1-4ubuntu0.2
ii  libstdc++6   10.3.0-1ubuntu1~20.04
ii  libtiff5 4.1.0+git191117-2ubuntu0.20.04.1
ii  libwebp6 0.6.1-2ubuntu0.20.04.1
ii  libx11-6 2:1.6.9-2ubuntu1.2
ii  libxml2  2.9.10+dfsg-5ubuntu0.20.04.1
ii  libxrandr2   2:1.5.2-0ubuntu1
ii  zlib1g   1:1.2.11.dfsg-2ubuntu1.2

darktable recommends no packages.

darktable suggests no packages.

-- no debconf information

Bug#991283: unblock: mesa/20.3.5-1

[Timo Aaltonen]

On 21.7.2021 11.12, Simon McVittie wrote:

On Wed, 21 Jul 2021 at 10:15:12 +0300, Timo Aaltonen wrote:

On 19.7.2021 19.44, Simon McVittie wrote:

Should the mesa source package be unblocked for bullseye?


ack


For clarity: does this mean "yes, I would like mesa_20.3.5-1 to reach
bullseye"?


Correct, sorry for not requesting it before, and thanks for your attempt :)


There don't seem to be any RC bugs open. The Mesa maintainers would know
better than I do whether there have been non-RC regression reports.


Does your ack mean no regressions have been reported?


Right, I went through the debian-x mailbox and couldn't find any.


[ ] I reviewed all changes and I approve them


After looking at the filtered debdiff, do the Mesa maintainers approve
this unblock request?


Yes, though it does have debian/patches/llvm-12-build-fix.diff patch 
cruft (sigh..), it's harmless since it's not used.




--
t

Bug#986488: Further test issues on s390x

[Christian Ehrhardt]

Hi - as an FYI on s390x tests
https://ci.debian.net/data/autopkgtest/unstable/s390x/p/pyspread/13200913/log.gz
there are further test issues of the new tests added in 1.99.6

I've reported them upstream at
https://gitlab.com/pyspread/pyspread/-/issues/93

To fix the test is easy (just drop the special case for not little
endian), but while I'm 95% sure that is fine I'm lacking the final 5%
and would want to have upstreams answers to it before suggesting to
change this in freeze time.

P.S. I'm unsure if a second forwarded tag might cause problems and
this issue is related but not necessarily considered the very same, so
I'm intentionally NOT adding a new forwarded tag.

Test fail log:

__ test_RGB32 __

def test_RGB32():
qimg = QtGui.QImage(320, 240, QtGui.QImage.Format_RGB32)
qimg.fill(0)
v = _qimageview(qimg)
qimg.fill(23)
qimg.setPixel(12, 10, QtGui.qRgb(0x12, 0x34, 0x56))
assert_equal(v.shape, (240, 320))
assert_equal(v[10, 10], 23 | 0xff00)
>   assert_equal(v[10, 12], 0xff123456
 if sys.byteorder == 'little' else 0x563412ff)

pyspread/lib/test/test_qimageview.py:145:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

a = 4279383126, b = 1446253311

def assert_equal(a, b):
>   assert a == b
E   assert 4279383126 == 1446253311

pyspread/lib/test/test_qimageview.py:72: AssertionError
_ test_ARGB32 __

def test_ARGB32():
qimg = QtGui.QImage(320, 240, QtGui.QImage.Format_ARGB32)
qimg.fill(0)
v = _qimageview(qimg)
qimg.setPixel(12, 10, QtGui.qRgb(0x12, 0x34, 0x56))
assert_equal(v.shape, (240, 320))
>   assert_equal(v[10, 12], 0xff123456
 if sys.byteorder == 'little' else 0x563412ff)

pyspread/lib/test/test_qimageview.py:156:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

a = 4279383126, b = 1446253311

def assert_equal(a, b):
>   assert a == b
E   assert 4279383126 == 1446253311



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd