Bug#991471: ITP: systemd-zram-generator -- Auto generator for zram devices to systemd service.

[heysion]

Package: wnpp
Severity: wishlist
Owner: heysion 

* Package name: systemd-zram-generator
  Version : 0.3.2
  Upstream Author : Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl, Igor Raits
i.gnatenko.br...@gmail.com, наб nabijaczlew...@gmail.com
* URL : https://github.com/systemd/zram-generator
* License : MIT
  Programming Lang: Rust
  Description : Auto generator for zram devices to systemd service.
systemd-zram-setup@.service generator for zram devices
This generator provides a simple and fast mechanism to configure swap on
/dev/zram* devices.
The main use case is create swap devices, but devices with a file system can be
created too, see below.

Bug#991470: unblock: q2-sample-classifier/2020.11.1-2

[Nilesh Patra]

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

Please unblock package q2-sample-classifier

[ Reason ]
This package misses a few needed dependencies, which renders it unusable

[ Impact ]
The package will be broken for the user, and they will have to fetch the
dependencies by themselves

[ Tests ]
Autopkgtests have been added in this release

[ Risks ]
No risks as such

[ 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 q2-sample-classifier/2020.11.1-2
diff -Nru q2-sample-classifier-2020.11.1/debian/changelog 
q2-sample-classifier-2020.11.1/debian/changelog
--- q2-sample-classifier-2020.11.1/debian/changelog 2020-12-06 
21:40:46.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/changelog 2021-07-25 
10:36:56.0 +0530
@@ -1,3 +1,15 @@
+q2-sample-classifier (2020.11.1-2) unstable; urgency=medium
+
+  * Team Upload.
+  * d/control: Add depends on python3-distutils,
+q2-types, q2-feature-table
+  * Add autopkgtests
+  * d/rules: Do not run build time tests with || true
+rather just print the message that this will be dealt
+with in autopkgtests
+
+ -- Nilesh Patra   Sun, 25 Jul 2021 10:36:56 +0530
+
 q2-sample-classifier (2020.11.1-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru q2-sample-classifier-2020.11.1/debian/control 
q2-sample-classifier-2020.11.1/debian/control
--- q2-sample-classifier-2020.11.1/debian/control   2020-12-06 
21:40:46.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/control   2021-07-25 
10:33:16.0 +0530
@@ -22,6 +22,9 @@
  ${misc:Depends},
  ${python3:Depends},
  qiime (>= 2020.11.0),
+ python3-distutils,
+ q2-types,
+ q2-feature-table
 Description: QIIME 2 plugin for machine learning prediction of sample data
  QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
  package with a focus on data and analysis transparency. QIIME 2 enables
diff -Nru q2-sample-classifier-2020.11.1/debian/rules 
q2-sample-classifier-2020.11.1/debian/rules
--- q2-sample-classifier-2020.11.1/debian/rules 2020-12-06 21:40:46.0 
+0530
+++ q2-sample-classifier-2020.11.1/debian/rules 2021-07-25 10:29:27.0 
+0530
@@ -13,11 +13,11 @@
rm -rf 
debian/q2-sample-classifier/usr/lib/python3.9/site-packages/q2_sample_classifier/__pycache__/
rm -rf 
debian/q2-sample-classifier/usr/lib/python3.9/site-packages/q2_sample_classifier/tests/__pycache__/
 
-# FIXME: modules cannot be registered at build time - ignoring build tests for 
now
+#FIXME:
 override_dh_auto_test:
-#ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-   dh_auto_test || true
-#endif
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+   echo "I: Delaying true testing to autopkgtests since QIIME2 module 
cannot be registered at build time"
+endif
 
 override_dh_auto_clean:
dh_auto_clean
diff -Nru q2-sample-classifier-2020.11.1/debian/tests/control 
q2-sample-classifier-2020.11.1/debian/tests/control
--- q2-sample-classifier-2020.11.1/debian/tests/control 1970-01-01 
05:30:00.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/tests/control 2021-07-18 
17:29:15.0 +0530
@@ -0,0 +1,3 @@
+Tests: run-unit-test
+Depends: @, python3-pytest-cov
+Restrictions: allow-stderr, skip-not-installable
diff -Nru q2-sample-classifier-2020.11.1/debian/tests/run-unit-test 
q2-sample-classifier-2020.11.1/debian/tests/run-unit-test
--- q2-sample-classifier-2020.11.1/debian/tests/run-unit-test   1970-01-01 
05:30:00.0 +0530
+++ q2-sample-classifier-2020.11.1/debian/tests/run-unit-test   2021-07-25 
10:31:17.0 +0530
@@ -0,0 +1,20 @@
+#!/bin/bash
+set -e
+
+pkg=q2_sample_classifier
+
+if [ "${AUTOPKGTEST_TMP}" = "" ] ; then
+  AUTOPKGTEST_TMP=$(mktemp -d /tmp/${pkg}-test.XX)
+  trap "rm -rf ${AUTOPKGTEST_TMP}" 0 INT QUIT ABRT PIPE TERM
+fi
+
+cp -a /usr/lib/python3/dist-packages/${pkg}* "${AUTOPKGTEST_TMP}"
+
+cd "${AUTOPKGTEST_TMP}"
+if [ ! -f /usr/lib/python3/dist-packages/pytest_cov/__init__.py ] ; then
+   echo "Please install package python3-pytest-cov to run this script"
+   exit 1
+fi
+
+# Run build-time tests
+py.test-3 --cov=${pkg}

Bug#991469: systemd-zram-generator: Auto generator for zram devices to systemd service.

[heysion]

Package: systemd-zram-generator
Version: 0.3.2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



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

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

Bug#990279: Also affects stable...

[Timothy Pearson]

Just hit this upgrading a stable box from 4.19.0-6-powerpc64le to 
4.19.0-17-powerpc64le.  AMD RX480, works perfectly again after downgrading to 
the older kernel.

Bug#991467:

[Davide Beatrici]

I confirm the attached patches fix the issue, thanks!

On an unrelated note: no bugs show up at 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=linux-image-5.10.0-8-amd64;dist=unstable
 aside from the one I opened, even when selecting "Archived and Unarchived".

How can I see the bugs that are closed?

Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

[Luke Kenneth Casson Leighton]

i've created a test account, stupidly upgraded first so i cannot check
the "broken" case.

i will therefore use the original account with the underscore, however
i need to ask a 3rd  party to run the ssh command.

the setup i have is quite comprehensive, 30 ssh keys 25 projects, it
may be an interaction between them.

l.

Bug#991468: Can't add GtkHeaderBar to "Client side window decoration" area

[Osamu Aoki]

Package: glade
Version: 3.38.2-2
Severity: normal

I know Debian can't do feature improvement.  So this is more-or-less a
public service memo for ``  to Glade users until future
Glade fix this sloppy and not so well documented Glade behavior.

When things are too complicated to handle for Glade (such as relatively
new feature supports), Glade sometimes give up creating the proper XML
content for us and we need to use text editor to fix the sloppy XML to
create the usable XML.

One noticeable case is "Client side window decoration" area and another
is the area created by "GtkPopoverMenu".  If you try to add some graphic
widget to the intended area using Glade GUI operation, Glade gives you
"... need placeholder to add children" as a part of error message and
refuse to do expected.  Yes, this is sad.

Please look at upstream issue page I updated with my workaround:
  https://gitlab.gnome.org/GNOME/glade/-/issues/499

I think the manual workaround I proposed there is non-trivial.

Once you see the inside of the XML file with the text editor and compare
this with recently published modern UI XML files out there, you
understand `` needs to be replaced with the manually
crafted proper XML content.

I hope this helps people to work around this sloppy Glade generated XML
file issue.  (At least, it took me a while to find my solution.)

HTH.

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

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

Versions of packages glade depends on:
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgladeui-2-13  3.38.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libpango-1.0-0   1.46.2-3
ii  libxml2  2.9.10+dfsg-6.7

Versions of packages glade recommends:
ii  devhelp   3.38.1-1
ii  libgtk-3-dev  3.24.24-4

glade suggests no packages.

-- no debconf information

Bug#991467: Vega 56's GPUTach stuck at 100% as soon as the driver is loaded

[Diederik de Haas]

On zondag 25 juli 2021 00:48:41 CEST Davide Beatrici wrote:
> Package: linux-image-5.10.0-8-amd64
> Version: 5.10.46-2
> 
> As soon as the screen resolution changes, all LEDs (GPUTach) on the side of
> my Vega 56 light up and never turn off again, indicating a constant 100%
> utilization.
> 
> The fan spins slightly faster compared to when the card is idle (i.e. only
> the first LED on).
> 
> No problems at all when booting with 5.10.0-7-amd64.

This sounds like the exact same issue as reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991453

Can you verify that?

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

Bug#991453: linux-image-5.10.0-8-amd64: Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle

[Diederik de Haas]

On zaterdag 24 juli 2021 22:03:23 CEST Diederik de Haas wrote:
> > It's already backported to 5.10, just after 5.10.46 was released:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h
> > =l inux-5.10.y=fea853aca3210c21dfcf07bb82d501b7fd1900a7
> 
> Just found out the reverted commit was introduced just before the 5.10.46
> tag was created, which should mean that any version before 5.10.46 should
> NOT have this problem. 

I just found out it's 2 commits that should be reverted
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=1bd81429d53ded4e111616c755a64fad80849354
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=fea853aca3210c21dfcf07bb82d501b7fd1900a7

The first one I saved (and attached) as 'fix-bug991453-part1.patch' and the 
second one as 'fix-bug991453-part1.patch'

Then I followed step 4.2.1 and 4.2.2 of the kernel handbook:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
That resulted in 'linux-image-5.10.0-8-amd64-unsigned_5.10.46-2a~test_amd64.deb'
which I then installed on my system and rebooted into that.

$ uname -a
Linux bagend 5.10.0-8-amd64 #1 SMP Debian 5.10.46-2a~test (2021-07-24) x86_64 
GNU/Linux
$ cat /sys/class/drm/card0/device/gpu_busy_percent
0
$ sensors
nvme-pci-0100
Adapter: PCI adapter
Composite:+40.9°C  (low  = -273.1°C, high = +72.8°C)
   (crit = +75.8°C)
Sensor 1: +40.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2: +51.9°C  (low  = -273.1°C, high = +65261.8°C)

amdgpu-pci-0c00
Adapter: PCI adapter
vddgfx:  750.00 mV 
fan1:1208 RPM  (min =0 RPM, max = 3500 RPM)
edge: +42.0°C  (crit = +85.0°C, hyst = -273.1°C)
   (emerg = +90.0°C)
junction: +42.0°C  (crit = +105.0°C, hyst = -273.1°C)
   (emerg = +110.0°C)
mem:  +43.0°C  (crit = +95.0°C, hyst = -273.1°C)
   (emerg = +100.0°C)
power1:7.00 W  (cap = 260.00 W)

k10temp-pci-00c3
Adapter: PCI adapter
Tctl: +76.5°C  
Tdie: +56.5°C

# radeontop
Graphics pipe 0.83%
0.17G / 0.94G Memory Clock 17.67%
0.03G / 1.63G Shader Clock  1.78%

These are the same 'scores' as I had with the 5.10.0-7-amd64 kernel.
So applying the mentioned/attached patches on top of the current kernel
as available in Debian Testing/Bullseye and Sid, fixes the problem.

In the last year I've spend considerable time to bring down my energy
usage/needs and I never expected that (reverting) 2 kernel commits
would save me 67W (continuously), so thank you very much piorunz for
bringing this to my attention.
I normally have a quiet system and noticed it often wasn't quiet lately; 
I blame(d) 'baloo' (file indexing) for that, but it turns out it was mostly
my GPU running at 100% all the time.

As it looks like a lot of users with AMD GPUs are affected and the 
considerable energy wasted because of it (Climate Change), 
I really hope/urge that these 2 patches/reverts are applied before Bullseye
gets released.

Cheers,
  Diederik
>From 1bd81429d53ded4e111616c755a64fad80849354 Mon Sep 17 00:00:00 2001
From: Yifan Zhang 
Date: Sat, 19 Jun 2021 11:40:54 +0800
Subject: Revert "drm/amdgpu/gfx9: fix the doorbell missing when in CGPG
 issue."

commit ee5468b9f1d3bf48082eed351dace14598e8ca39 upstream.

This reverts commit 4cbbe34807938e6e494e535a68d5ff64edac3f20.

Reason for revert: side effect of enlarging CP_MEC_DOORBELL_RANGE may
cause some APUs fail to enter gfxoff in certain user cases.

Signed-off-by: Yifan Zhang 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 1859d293ef712..fb15e8b5af32f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -3619,12 +3619,8 @@ static int gfx_v9_0_kiq_init_register(struct amdgpu_ring *ring)
 	if (ring->use_doorbell) {
 		WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_LOWER,
 	(adev->doorbell_index.kiq * 2) << 2);
-		/* If GC has entered CGPG, ringing doorbell > first page doesn't
-		 * wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround
-		 * this issue.
-		 */
 		WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
-	(adev->doorbell.size - 4));
+	(adev->doorbell_index.userqueue_end * 2) << 2);
 	}
 
 	WREG32_SOC15_RLC(GC, 0, mmCP_HQD_PQ_DOORBELL_CONTROL,
-- 
cgit 1.2.3-1.el7

>From fea853aca3210c21dfcf07bb82d501b7fd1900a7 Mon Sep 17 00:00:00 2001
From: Yifan Zhang 
Date: Sat, 19 Jun 2021 11:39:43 +0800
Subject: Revert "drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to
 cover full doorbell."

commit baacf52a473b24e10322b67757ddb92ab8d86717 upstream.

This reverts commit 1c0b0efd148d5b24c4932ddb3fa03c8edd6097b3.

Bug#991444: ganglia-monitor: gmond and gmetric look for /etc/gmond.conf instead of /etc/ganglia/gmond.conf

[Marcos Fouces]

Hi Jochen, 

many thanks for this bug report.

I uploaded a fixed release in the git repo [1]. Due to the deep freeze
policy, i cannot upload it to unstable until Bullseye comes to life.

Greetings, 
Marcos

[1] https://salsa.debian.org/debian/ganglia

Bug#965346: qbittorrent-nox: Web UI password is silently reset to the default during upgrade from buster to bullseye

[Mike Gerber]

I also experienced this issue.

Bug#989863: debian-installer: Firmware problems in bullseye

[Cyril Brulebois]

Hi Paul,

Paul Gevers  (2021-07-24):
> On 24-07-2021 09:05, Cyril Brulebois wrote:
> > @RT: I'd be happy to have some feedback from your regarding this
> >  approach; telling people to enable contrib/non-free so that
> >  they can install firmware packages is definitely *not*
> >  something I take lightly, but I'd be happy to have some kind of
> >  review there to see if that looks reasonable at all. I'm not
> >  sure there are many options these days anyway…
> 
> It's only my opinion, but as it's my understanding too that a lot of
> hardware just doesn't work great without the contrib/non-free drivers, I
> think it's sensible to help users with instructions on how to get those.
> You're not installing them and you're not enabling contrib/non-free, so
> decent warnings can be given (spirit of free software vs hardware that
> works well).

Great, thanks for the confirmation.

> I understand it's hard to get, but having the confirmation that
> `nomodeset` actually works for the (or most) black screen issues would
> obviously be great.

Yes, I think it should be feasible to organize some polling once RC 3 is
out. (That is, come up with a solution to achieve that, and point to it
in the release announcement, and get that relayed via bits.d.o and all
the press jazz if they're available.)

> Side note: apart from the installation guide, do we think that this
> warrants a note in the release notes too?

Yeah, having some stub telling users there's an increasing need for
firmware, and that they should check the installation guide for more
information… would be great!

> > @RT: This would be my preferred approach, and based on cdbuilder
> >  coming back up, plus my recent verifications in a d-i context,
> >  I think this should be manageable in time for the announced
> >  release date. Ideally we would be able to release an RC3 a
> >  week from now, letting us fix any boo-boo in time before
> >  mid-August.
> 
> I assume your ugly backup plan is (near) ready (or really trivial), so
> can be dropped in at the last moment in case there's set backs?

Given Simon's excellent suggestion regarding firmware-linux (which for
some reason I totally forgot about that), this should be really trivial
indeed! I have no doubt we can make that happen at the 11th hour in case
all the rest doesn't work (without spending time on testing this right
away to make sure the backup plan works).

Thanks, Simon!


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


signature.asc
Description: PGP signature

Bug#989863: debian-installer: Firmware problems in bullseye

[Paul Gevers]

Hi Cyril,

On 24-07-2021 09:05, Cyril Brulebois wrote:
> @RT: I'd be happy to have some feedback from your regarding this
>  approach; telling people to enable contrib/non-free so that they
>  can install firmware packages is definitely *not* something I take
>  lightly, but I'd be happy to have some kind of review there to see
>  if that looks reasonable at all. I'm not sure there are many
>  options these days anyway…

It's only my opinion, but as it's my understanding too that a lot of
hardware just doesn't work great without the contrib/non-free drivers, I
think it's sensible to help users with instructions on how to get those.
You're not installing them and you're not enabling contrib/non-free, so
decent warnings can be given (spirit of free software vs hardware that
works well). I understand it's hard to get, but having the confirmation
that `nomodeset` actually works for the (or most) black screen issues
would obviously be great.

Side note: apart from the installation guide, do we think that this
warrants a note in the release notes too?

> @RT: This would be my preferred approach, and based on cdbuilder coming
>  back up, plus my recent verifications in a d-i context, I think
>  this should be manageable in time for the announced release date.
>  Ideally we would be able to release an RC3 a week from now, letting
>  us fix any boo-boo in time before mid-August.

I assume your ugly backup plan is (near) ready (or really trivial), so
can be dropped in at the last moment in case there's set backs?

> Thanks for your attention! I've had plenty on my mind, and some
> braindump was in order. Sorry it's been *that* long a read.

I even read in more than once to get the details right.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991453: linux-image-5.10.0-8-amd64: Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle

[Diederik de Haas]

> It's already backported to 5.10, just after 5.10.46 was released:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=l
> inux-5.10.y=fea853aca3210c21dfcf07bb82d501b7fd1900a7

Just found out the reverted commit was introduced just before the 5.10.46 tag
was created, which should mean that any version before 5.10.46 should NOT
have this problem. The version uploaded to the Debian archive before that
was 5.10.40-1, which in my case was linux-image-5.10.0-7-amd64.
I no longer had that installed, so added the following line to 
/e/a/sources.list:
deb [check-valid-until=no] 
https://snapshot.debian.org/archive/debian/20210529T204006Z/ sid main

Installed linux-image-5.10.0-7-amd64 and rebooted into that ...

On zaterdag 24 juli 2021 14:22:38 CEST Diederik de Haas wrote:
> On zaterdag 24 juli 2021 01:29:55 CEST piorunz wrote:
> > GPU core works at 100% usage at all times, even at idle.
> > 
> > $ cat /sys/class/drm/card0/device/gpu_busy_percent
> > 99
> > 
> > $ sensors
> > (...)
> > amdgpu-pci-0900
> > Adapter: PCI adapter
> > vddgfx:1.14 V
> > fan1:1098 RPM  (min =0 RPM, max = 3000 RPM)
> > edge: +51.0°C  (crit = +100.0°C, hyst = -273.1°C)
> > 
> >(emerg = +105.0°C)
> > 
> > junction: +55.0°C  (crit = +110.0°C, hyst = -273.1°C)
> > 
> >(emerg = +115.0°C)
> > 
> > mem:  +56.0°C  (crit = +100.0°C, hyst = -273.1°C)
> > 
> >(emerg = +105.0°C)
> > 
> > power1:   74.00 W  (cap = 272.00 W)
> > 
> > radeontop - 100% GPU usage and full clocks:
> > Graphics pipe 100.00%
> > 1.00G / 1.00G Memory Clock 100.00%
> > 2.47G / 2.58G Shader Clock  95.92%
> 
> I'm getting the same results on my Radeon RX Vega 64.
> $ cat /sys/class/drm/card0/device/gpu_busy_percent
> 99
> $ sensors
> nvme-pci-0100
> Adapter: PCI adapter
> Composite:+43.9°C  (low  = -273.1°C, high = +72.8°C)
>(crit = +75.8°C)
> Sensor 1: +43.9°C  (low  = -273.1°C, high = +65261.8°C)
> Sensor 2: +49.9°C  (low  = -273.1°C, high = +65261.8°C)
> 
> amdgpu-pci-0c00
> Adapter: PCI adapter
> vddgfx:1.09 V
> fan1:1240 RPM  (min =0 RPM, max = 3500 RPM)
> edge: +50.0°C  (crit = +85.0°C, hyst = -273.1°C)
>(emerg = +90.0°C)
> junction: +63.0°C  (crit = +105.0°C, hyst = -273.1°C)
>(emerg = +110.0°C)
> mem:  +51.0°C  (crit = +95.0°C, hyst = -273.1°C)
>(emerg = +100.0°C)
> power1:   74.00 W  (cap = 260.00 W)
> 
> k10temp-pci-00c3
> Adapter: PCI adapter
> Tctl: +66.0°C
> Tdie: +46.0°C
> 
> And also for radeontop.

$ cat /sys/class/drm/card0/device/gpu_busy_percent
0
$ sensors
nvme-pci-0100
Adapter: PCI adapter
Composite:+32.9°C  (low  = -273.1°C, high = +72.8°C)
   (crit = +75.8°C)
Sensor 1: +32.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2: +41.9°C  (low  = -273.1°C, high = +65261.8°C)

amdgpu-pci-0c00
Adapter: PCI adapter
vddgfx:  750.00 mV 
fan1:1182 RPM  (min =0 RPM, max = 3500 RPM)
edge: +37.0°C  (crit = +85.0°C, hyst = -273.1°C)
   (emerg = +90.0°C)
junction: +38.0°C  (crit = +105.0°C, hyst = -273.1°C)
   (emerg = +110.0°C)
mem:  +39.0°C  (crit = +95.0°C, hyst = -273.1°C)
   (emerg = +100.0°C)
power1:7.00 W  (cap = 260.00 W)

k10temp-pci-00c3
Adapter: PCI adapter
Tctl: +65.6°C  
Tdie: +45.6°C

# radeontop
Graphics pipe 0.83%
0.17G / 0.94G Memory Clock 17.67%
0.03G / 1.63G Shader Clock  1.81%

So running a kernel != 5.10.46 does not have this problem :)

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

Bug#991466: thunar needs gvfs-backends to read phone memory

[Teo]

Package: thunar
Version: 4.16.8-1
Severity: important
Tags: patch
X-Debbugs-Cc: teodoro777.coluc...@live.com

Dear Maintainer,

About a year ago I reported this bug https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=962731, marked as fixed after an update of thunar to
version 4.15.3-1. The problem is that now I am trying debian bullsay RC2, which
has thunar version 4.16.8-1 available, but the problem persists. I hope
something changes, because it is not written in any manual that this package is
used to read the memory of an android smartphone, I had to find out by making
use of the support of other users.

I apologize for opening a new bug and not writing in the previous one, but I
couldn't reopen this last one.

Regard
Teo


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

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

Versions of packages thunar depends on:
ii  desktop-file-utils   0.26-1
ii  exo-utils4.16.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libexo-2-0   4.16.0-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libgudev-1.0-0   234-1
ii  libice6  2:1.0.10-1
ii  libnotify4   0.7.9-3
ii  libpango-1.0-0   1.46.2-3
ii  libsm6   2:1.2.3-1
ii  libthunarx-3-0   4.16.8-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2
ii  shared-mime-info 2.0-1
ii  thunar-data  4.16.8-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  gvfs  1.46.2-1
ii  libxfce4panel-2.0-4   4.16.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  thunar-volman 4.16.0-1
ii  tumbler   4.16.0-1
ii  udisks2   2.9.2-2
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
pn  gvfs-backends 
ii  thunar-archive-plugin 0.4.0-2
ii  thunar-media-tags-plugin  0.3.0-2

Bug#991465: new upstream (5.0.11)

[Daniel Baumann]

Package: iproute2

Hi,

it would be nice if you could upload the current upstream version
(5.0.11) to experimental, it has some fixes for bugs we're suffering
from at work (particular the netns one).

Regards,
Daniel

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

[Vasyl Gello]

Control: close -1

Hi Michael!

Thanks for your help! ;)
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError

[Paul Gevers]

Hi Chris,

On 24-07-2021 10:54, Chris Lamb wrote:
> However, why the slight change to security-related overflow handling
> in bitfield fields *on i386 systems* should result in this failure
> eludes me...  :/

The changelog mentions some other bug fixes, the first one looks
potentially related (new failure):
Fail EXEC command in case a watched key is expired (#9194)

and so does the third (WRONGTYPE error):
Fix SINTERSTORE not to delete dest key when getting a wrong type error
(#9032)


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988456: atftpd: Installation inconsistent and not functional

[Andreas B. Mundt]

Package: atftpd
Version: 0.7.git20120829-3.2
Followup-For: Bug #988456
X-Debbugs-Cc: a...@debian.org

Control: retitle -1 Installation inconsistent, missing dependency, not 
up-to-date
Control: severity -1 important
Control: tags -1 unreproducible


Dear all,

the last days I used atftpd in two different setups, and after
installing tcpd it works fine here. (The missing tcpd is obvious from
the log messages). 

I agree that the package needs some work, however, it is definitely not
'completely unusable to everyone'. 

Therefore, I lower the severity level to important.  It would be a pity
to not have it shipped in bullseye.

Best regards,

  Andi

Bug#991453: linux-image-5.10.0-8-amd64: Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle

[tv.deb...@googlemail.com]

I see this on Vega (RX 56) as well as Navi10 (5700XT) , and I think 
Polaris (RX 570) is affected too. So it's not only an issue with Navi 2X 
. Is it worth opening a separate bug report for each card?

Bug#991464: spdlog: FTBFS on non-linux platform

[Boyuan Yang]

Source: spdlog
Severity: normal
Version: 1:1.8.1+ds-2.1
X-Debbugs-CC: cru...@debian.org

Dear spdlog maintainers,

Currently package spdlog cannot be built on non-linux platform due to missing
of systemd-related headers:

https://buildd.debian.org/status/package.php?p=spdlog

/<>/include/spdlog/sinks/systemd_sink.h:14:10: fatal error:
systemd/sd-journal.h: No such file or directory
   14 | #include 
  |  ^~
compilation terminated.

Please check with upstream to see if the package can be built without systemd
support. If systemd is a hard requirement, please set package building
architecture to "linux-any" instead of "any".

Thanks,
Boyuan Yang


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

Bug#987321: openntpd: if-up.d script uses SysV command instead of systemd and blocks boot

[Baptiste Beauplat]

Control: severity -1 critical

On 2021/04/21 07:42 PM, François Cerbelle wrote:
> openntpd installs a smart if-up.d script to reload the configuration
> when an interface is started. It blocks the boot process until a timeout
> occurs at the "Raise network interfaces" step. 

This effectively prevent systems from configuring multiple interfaces
when using 'auto' in /etc/network/interfaces.

-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#991463: new upstream (5.3.2) with nsec3 (potential DoS) fixes

[Daniel Baumann]

Package: knot-resolver
Version: 5.3.1-1

Hi,

it would be nice if you could upload the current upstream release to
experimental and cherry-pick the necessary fixes for bullseye.

Regards,
Daniel

Bug#991462: new upstream (3.5.0)

[Daniel Baumann]

Package: etcd
Severity: wishlist

Hi,

it would be nice if you could upload the current upstream version (to
exerpiemental).

Regards,
Daniel

Bug#991447: unblock: flameshot/0.9.0+ds1-2 (pre-approval)

[Boyuan Yang]

Control: tags -1 -moreinfo

在 2021-07-24星期六的 00:02 +0200，Sebastian Ramacher写道：
> Control: tags -1 moreinfo confirmed
> 
> On 2021-07-23 16:02:46 -0400, Boyuan Yang wrote:
> > Package: release.debian.org
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: by...@debian.org
> > Severity: normal
> > 
> > Please unblock package flameshot
> > 
> > I am looking forward to fixing several bugs that affect current
> > flameshot/0.9.0+ds1-1 in Debian Testing. These bugs include privacy breach
> > (automatic software update checking), crashing under some circumstances
> > and
> > incorrect icon under Xfce environment. All patches are tested with
> > acknowledgement from upstream.
> > 
> > [ Reason ]
> > * https://bugs.debian.org/991392
> > Currently flameshot would check for update by querying github api every 24
> > hours. This functionality was previously enabled by default. A patch was
> > added
> > to disable new version checking by default.
> > 
> > * https://bugs.debian.org/991320
> > Currently flameshot would crash when tray icon is disabled and new version
> > checking is enabled.
> > 
> > * https://bugs.debian.org/991216
> > Currently flameshot will show an incorrect icon (bulb icon instead of
> > flameshot's own icon) under Xfce environment.
> > 
> > [ Impact ]
> > If the new version is not in Debian 11:
> > 
> > * The software would query new version using internet every 24 hours by
> > default, which is an unwanted behavior for some users.
> > 
> > * The software would crash under the configuration described above. The
> > crash
> > would persist unless the user manually edit configuration file to disable
> > such
> > setting.
> > 
> > * The software would show an incorrect icon for all Xfce users.
> > 
> > [ Tests ]
> > I manually tested all 3 patches using a clean Debian Testing chroot to
> > confirm
> > that the bugs are all fixed.
> > 
> > [ Risks ]
> > The risk should be minimal since patches for crash and xfce are merged in
> > upstream trunk. The patch for disabling automatic update check has been
> > verified by lamby and me (see https://bugs.debian.org/991392 ).
> > 
> > [ 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 new version flameshot/0.9.0+ds1-2 hasn't been uploaded onto Unstable
> > yet.
> > Please let me know if I may proceed.
> > 
> > Please find the full debdiff in the attachment.
> > 
> > 
> > 
> > unblock flameshot/0.9.0+ds1-2
> 
> Assuming that the upload happens soon, please go ahead. Once the version
> is available in unstable, please remove the moreinfo tag.
> 
> Cheers

The new version has been uploaded to unstable.


Thanks,
Boyuan




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

Bug#989103: Fix

[Keith Edmunds]

Downgrading the deb-multimedia package libasound2-plugins from 1.2.2-dmo2
to 1.2.2-2 fixed this for me.

See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991337#30

Bug#991461: linux-image-5.10.0-8-armmp: [armhf] PHC not available with driver fec on i.MX6 SoC

[Cédric Delmas]

Package: src:linux
Version: 5.10.46-2
Severity: normal
Tags: patch


Dear maintainer,


With the current Bullseye armhf Linux kernel, the PTP Hardware Clock is not 
available on the network interface of an i.MX6 SoC managed by the driver 'fec' 
(CONFIG_FEC).
This driver is currently built-in and the Ethernet interface works properly.

$ ethtool -i eth0
driver: fec
version: 5.10.0-8-armmp
firmware-version:
expansion-rom-version:
bus-info: eth0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

$ ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all

$ dmesg | fgrep eth0
[   23.580932] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow 
control rx/tx
[   23.581001] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready




The problem is that the driver 'ptp' (CONFIG_PTP_1588_CLOCK) is built as a 
module. As a result, the call to function ptp_clock_register() (in file 
drivers/net/ethernet/freescale/fec_ptp.c, line 631) effectively uses the stub 
version defined at include/linux/ptp_clock_kernel.h:277.


One way to solve this problem should be to also build the driver 'fec' as a 
module.

Expected result (obtained after applying the attached patch):
$ ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all

$ dmesg | fgrep eth0
[6.570275] fec 2188000.ethernet eth0: registered PHC device 0
[   24.988653] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow 
control rx/tx
[   24.988720] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready



If you do not see a possible regression, could it be possible to have this 
change integrated in the official package?


Thank you in advance.
Best regards.

Cédric Delmas



-- Package-specific info:
** Version:
Linux version 5.10.0-8-armmp (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-2 (2021-07-20)

** Command line:
  console=ttymxc0,115200 quiet

** Tainted: WCE (9728)
 * kernel issued warning
 * staging driver was loaded
 * unsigned module was loaded

** Kernel log:
[   12.684805] systemd[1]: Finished Load Kernel Module configfs.
[   12.687424] systemd[1]:modprobe@drm.service: Succeeded.
[   12.691377] systemd[1]: Finished Load Kernel Module drm.
[   12.703809] systemd[1]:modprobe@fuse.service: Succeeded.
[   12.706144] systemd[1]: Finished Load Kernel Module fuse.
[   12.709347] systemd[1]: Finished Load Kernel Modules.
[   12.716102] systemd[1]: Finished Remount Root and Kernel File Systems.
[   12.726265] systemd[1]: Mounting FUSE Control File System...
[   12.737173] systemd[1]: Mounting Kernel Configuration File System...
[   12.747882] systemd[1]: Condition check resulted in Rebuild Hardware 
Database being skipped.
[   12.748797] systemd[1]: Condition check resulted in Platform Persistent 
Storage Archival being skipped.
[   12.763249] systemd[1]: Starting Load/Save Random Seed...
[   12.781066] systemd[1]: Starting Apply Kernel Variables...
[   12.807354] systemd[1]: Starting Create System Users...
[   12.832250] systemd[1]: Mounted FUSE Control File System.
[   12.833534] systemd[1]: Mounted Kernel Configuration File System.
[   13.265966] systemd[1]: Started Journal Service.
[   13.435605] systemd-journald[195]: Received client request to flush runtime 
journal.
[   13.479320] random: crng init done
[   13.479337] random: 7 urandom warning(s) missed due to ratelimiting
[   15.386473] Registered IR keymap rc-empty
[   15.386638] rc rc0: gpio_ir_recv as /devices/platform/ir-receiver/rc/rc0
[   15.389515] rc rc0: lirc_dev: driver gpio_ir_recv registered at minor = 0, 
raw IR receiver, no transmitter
[   15.389783] input: gpio_ir_recv as 
/devices/platform/ir-receiver/rc/rc0/input0
[   15.442505] imx-ipuv3 240.ipu: IPUv3H probed
[   15.587588] imx_media_common: module is from the staging directory, the 
quality is unknown, you have been warned.
[   15.609741] imx6_media: module is from the staging directory, the quality is 
unknown, you have been warned.
[   15.748158] etnaviv etnaviv: bound 13.gpu (ops gpu_ops [etnaviv])
[   15.752573] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops [etnaviv])
[   15.752600] etnaviv-gpu 13.gpu: model: GC880, revision: 5106
[   15.760781] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[   15.764480] [drm] Initialized etnaviv 

Bug#991337: pulseaudio: Can confirm with another DAC/USB sound card

[Jean-Marie Favreau]

Dear maintainer, dear all,

It seems that the problem comes from the package libasound2-plugins from deb-
multimedia.
The following command to force the debian version of the package fixes the bug:

sudo apt install libasound2-plugins=1.2.2-2

Cheers

On Wed, 21 Jul 2021 21:56:27 +0200 Jakub Lucký  wrote:
> Package: pulseaudio
> Version: 14.99.2+dfsg1-1
> Followup-For: Bug #991337
> 
> Dear Maintainer,
> 
> I can confirm the same segfault behaviour when plugging in Digidesign MBox 2 
USB soundcard. Pulseaudio crashes immediately as the soundcard is initialized, 
as shown in the dmesg loglines:
> 
> [105992.407921] usb 2-2: New USB device found, idVendor=0dba, 
idProduct=3000, bcdDevice= 1.43
> [105992.407924] usb 2-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
> [105992.407926] usb 2-2: Product: Mbox 2 
> [105992.407927] usb 2-2: Manufacturer: Digidesign
> [105996.008564] usb 2-2: Digidesign Mbox 2: 24bit 48kHz
> [105996.846468] pulseaudio[29671]: segfault at fff8 ip 
> 7f95f844d0d7 
sp 7ffc82ff4370 error 5 in libasound.so.2.0.0[7f95f843f000+8d000]
> 
> When the USB soundcard is not plugged in, pulseaudio works as expected. This 
has also been the case before those errors started to occur (can't pinpoint 
exact date, haven't been using the sound card much recently)
> 
> Jakub Lucky
> 
> 
> -- Package-specific info:
> File '/etc/default/pulseaudio' does not exist
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages pulseaudio depends on:
> ii  adduser  3.118
> ii  init-system-helpers  1.60
> ii  libasound2   1.2.4-1.1
> ii  libasound2-plugins   1:1.2.2-dmo2
> ii  libc62.31-13
> ii  libcap2  1:2.44-1
> ii  libdbus-1-3  1.12.20-2
> ii  libfftw3-single3 3.3.8-2
> ii  libgcc-s110.2.1-6
> ii  libglib2.0-0 2.66.8-1
> 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.99.2+dfsg1-1
> 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

-- 
Jean-Marie Favreau - https://jmfavreau.info

Bug#991460: vcmi: aborts when hovering over campaign selection figures

[fulvio ciriaco]

Package: vcmi
Version: 0.99+dfsg+git20190113.f06c8a87-2+b1
Severity: important

steps to reproduce:
1. select new  -> campaign
2. move the mouse to select the campaign
vcmi aborts immediately with the following message:

Initializing VCMI_Lib: 313 ms
Screen handler: 8 ms
Main graphics: 103 ms
Message handler: 1 ms
Initialization of VCMI (together): 1126 ms
corrupted double-linked list

it happens on different computers, motherboards and graphic cards.
as a workaround, it is possible to select a campaign opening vcmi in valgrind 
(very
slow), saving the first day and reopening normally. 

thank you

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

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

Versions of packages vcmi depends on:
ii  libavcodec587:4.3.2-0+deb11u2
ii  libavformat58   7:4.3.2-0+deb11u2
ii  libavutil56 7:4.3.2-0+deb11u2
ii  libboost-filesystem1.74.0   1.74.0-9
ii  libboost-locale1.74.0   1.74.0-9
ii  libboost-program-options1.74.0  1.74.0-9
ii  libboost-thread1.74.0   1.74.0-9
ii  libc6   2.31-12
ii  libfuzzylite6.0 6.0+dfsg-3
ii  libgcc-s1   10.2.1-6
ii  libminizip1 1.1-8+b1
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5network5  5.15.2+dfsg-9
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libsdl2-2.0-0   2.0.14+dfsg2-3
ii  libsdl2-image-2.0-0 2.0.5+dfsg1-2
ii  libsdl2-mixer-2.0-0 2.0.4+dfsg1-3
ii  libsdl2-ttf-2.0-0   2.0.15+dfsg1-1
ii  libstdc++6  10.2.1-6
ii  libswscale5 7:4.3.2-0+deb11u2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages vcmi recommends:
ii  ffmpeg   7:4.3.2-0+deb11u2
ii  innoextract  1.8-1.2+b1
ii  unshield 1.4.2-1
ii  unzip6.0-26

Versions of packages vcmi suggests:
pn  homm3-demo-data | homm3-data  

-- no debconf information

Bug#991118: RFS: openarc/1.0.0~beta3+dfsg-1~exp1

[Daniel Baumann]

Hi David,

I had a look at your openarc package. All in all it looks mostly good,
there are a few minor things:

  * debian/copyright:
The upstream contact should not be a name only, but a means of
contact, such as an email address.

  * debian/copyright:
the formatting of the file is a bit off; the "m4/ac_pthread.m4"-
stanza and the GPL license block are "clumped together".

the "Files:" blocks and the "License:" blocks are separate things,
see e.g.
http://metadata.ftp-master.debian.org/changelogs/main/l/lzip/unstable_copyright
as an example where (hopefully) it's easy to
see what I mean.

  * debian/copyright:
the m4 macro doesn't need to be listed (see the exception), but it
also doesn't harm.

  * debian/copyright:
what about the license for the debian packaging?

  * debian/*.postrm:
why removing the systemd service file on purge? if it's included in
the package (rather than generated at install time, which would be
"unusual" anyway), then, it will automatically be purged by dpkg.

  * did you consider using 'wrap-and-sort -bast'?

Regards,
Daniel

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Christian Rauch]

Thanks for the tip. I already updated the package names and licence
information in the pull-request:

https://salsa.debian.org/sdl-team/libdecor-0/-/merge_requests/1

Best,
Christian


Am 24.07.21 um 15:17 schrieb Dominique Dumont:
> Hi
>
> I would suggest to use cme to generate debian/copyright file.
>
> See 
> https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme
>
> You can also try cme to fix small mistakes in debian package files.
>
> See 
> https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme
>
> HTH
>

Bug#961056: debian-installer: qemu-system-s390x installation fails due to incorrect serial device

[Salvatore Bonaccorso]

Hi,

On Tue, May 19, 2020 at 08:24:27PM +0200, Valentin Vidić wrote:
> On Tue, May 19, 2020 at 07:23:21PM +0200, John Paul Adrian Glaubitz wrote:
> > Please see #926539 [1].
> 
> Thanks, I have sent the patch for the driver instead:
> 
>   https://lkml.org/lkml/2020/5/19/854

This appears to be applied upstream in 5.14-rc1

https://git.kernel.org/linus/b7d91d230a119fdcc334d10c9889ce9c5e15118b

and got backported to 5.10.52, 4.19.198 and 4.9.276.

Regards,
Salvatore

Bug#279001:

[Chrystopher C. Dizon]

How do they define a bug?
Why am i being labeled one, if am contributing far more creative codes more
than destructive?
Have  i?

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Dominique Dumont]

Hi

I would suggest to use cme to generate debian/copyright file.

See 
https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme

You can also try cme to fix small mistakes in debian package files.

See 
https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme

HTH

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Mon, 18 Jan 2021 23:42:32 +0100 Francesco Poli wrote:

[...]
> Hello again and again and again...
> 
> Another test: firefox-esr/78.6.1esr-1
> No difference: after allowing the use of the mic, the mic signal does
> not seem to reach the browser (as if the mic were broken).
> 
> But the mic works perfectly with chromium and with
> firefox-esr/68.7.0esr-1 ...
> 
> Is there any news on this issue?
> Could you please reply?
> 
> Thanks for your time!

Hi.

I have performed more tests on :
no difference, after allowing the use of the mic, the mic signal does
not seem to reach the browser (as if the mic were broken).

packagemicrophone
=
firefox-esr/78.12.0esr-1   fails
firefox-esr/78.12.0esr-1~deb10u1   fails
firefox/88.0.1-1   fails


But the mic still works perfectly with chromium and with
firefox-esr/68.7.0esr-1 ...



This bug report has turned into a monologue.
Could anyone among the maintainers of Mozilla-related packages reply,
please?

Does anybody actually care about this issue?

This regression has been present in Debian testing since May 2020 and,
after some initial investigation (May and June 2020) there seems to
have been no further progress.

Can you reproduce the issue with a microphone?

It has been suggested in the past that the issue could be caused by one
of the Debian-specific patches, since upstream Firefox does not seem to
be affected.
Has anyone tried to pinpoint the patch causing the regression?

Or, in case the issue is reproducible with upstream Firefox as well,
has the bug report been forwarded upstream?


Thank you for your time and patience.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpom_9jpYUJD.pgp
Description: PGP signature

Bug#989103: pulseaudio crashes on startup

[Keith Edmunds]

Caution: naivety ahead.

I'm seeing similar behaviour, but I'm not sure it's identical. I don't
have "load-module module-alsa-sink" uncommented in /etc/pulse/default.pa.
I've also rebuild pulseaudio with the patches but my problem persists.

With no USB audio devices connected, pulseaudio works fine. Connecting
either my (USB) Yamaha AG06 mixer or my Behringer UMC204HD cause
pulseaudio to segfault.

I built a debug version of pulseaudio. Here's the backtrace when it
segfaults:

(gdb) bt
#0  0x729bd0d7 in snd_async_del_handler () at
/lib/x86_64-linux-gnu/libasound.so.2

#1  0x729d7549 in snd_pcm_close () at
/lib/x86_64-linux-gnu/libasound.so.2 

#2 0x729ea559 in  () at /lib/x86_64-linux-gnu/libasound.so.2

#3 0x729d756d in snd_pcm_close () at
/lib/x86_64-linux-gnu/libasound.so.2 

#4  0x72adeeae in _snd_pcm_a52_open () at
/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_a52.so

#5 0x729d3c45 in  () at /lib/x86_64-linux-gnu/libasound.so.2

#6 0x729d42a7 in  () at /lib/x86_64-linux-gnu/libasound.so.2 

#7 0x729d71e8 in snd_pcm_open () at
/lib/x86_64-linux-gnu/libasound.so.2

#8  0x7292f1b3 in pa_alsa_open_by_device_string
(device=0x55971270 "a52:3", dev=0x0, ss=0x7fffdb74,
map=0x7fffdb80, mode=0, period_size=0x7fffdb58,
buffer_size=0x7fffdb60, tsched_size=0, use_mmap=0x0, use_tsched=0x0,
require_exact_channel_number=true) at modules/alsa/alsa-util.c:702

The code at line 702:

if ((err = snd_pcm_open(_handle, d, mode,
SND_PCM_NONBLOCK|
SND_PCM_NO_AUTO_RESAMPLE|
SND_PCM_NO_AUTO_CHANNELS|
(reformat ? 0 : SND_PCM_NO_AUTO_FORMAT))) < 0) {

Is this likely to be the same bug?
If so, should the patch have fixed it?
What more information can I provide to help?

Bug#581039: tightvncserver: New upstream release 2.0.x

[Sven Geuer]

Control: tags -1 = wontfix

To all whom it may concern:

Upstream does not maintain Thightvnc on Linux any more. Tightvnc 1.3.10
is the latest available version.

I recommend to try tigervnc or gnome-remote-desktop.

Sven 

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

[David Bremner]

Control: tag -1 unreproducible

Luke Kenneth Casson Leighton  writes:
>
> i have used gitolite3 for many years, this is the first time i have ever
> had a major bug, and it involved a username with an underscore in it.
> ssh to the server reported "hello user" not "hello user_", and
> COMPLETELY the wrong repository was granted write access.
>
> this is an extremely serious security issue.

0) I could not duplicate the problem with the version in
   stable or testing/unstable. 

   I did notice that due to ssh-agent caching, it was
   easy to use more keys than I wanted, so make sure to verify which key
   you are using with ssh -v.

1) Security support for stretch (current oldstable) ended more than a
   year ago. That means that any further uploads of that version would
   be via the LTS team [1]. 

2) It would be useful to know if you can duplicate the problem in
   current stable. If you can, a bit more information about how to
   duplicate the problem would help (you can send it to me privately if
   you are worried about publicizing a vulnerability).

[1]: https://wiki.debian.org/LTS


signature.asc
Description: PGP signature

Bug#991459: ITP: uvw -- C++ wrapper for libuv

[Daniel Baumann]

Package: wnpp

  * Package name : uvw
  * Upstream Author : Michele Caini 
  * License : MIT
  * Homepage : https://github.com/skypjack/uvw

uvw is a header-only, event based, tiny and easy to use libuv wrapper in
modern C++.

Regards,
Daniel

Bug#780434: tightvncserver: no support for Composite extension as required by GNOME 3, Compiz, etc.

[Sven Geuer]

Control: tags -1 = wontfix

To all whom it may concern:

Nowadays Gnome on Debian uses Wayland instead of X. Even when ran/run
on X it required X11's Xcomposite extension for quite some time now.

On the other hand, Thightvnc is old software. It bases on Xfree86, an
outdated implementation of X. Thightvnc's X server doesn't comprise the
Xcomposite extension. Also, upstream does not maintain Thightvnc on
Linux any more.

Conclusion: Tightvncserver cannot serve a recent Gnome desktop.

Recommendation: Install the gnome-remote-desktop package and enable
screen sharing in your Gnome Settings.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#617724: xtightvncviewer: Cannot scroll up

[Sven Geuer]

Control: tags -1 = wontfix

Hi Dmitry,

On Sat, 12 Mar 2011 00:09:05 +0200 Dmitry Baryshev
 wrote:
> O, it works! :) I think it will be great to display a message box
> with help when vncviewer starts (only once). Smth like "To scroll
> down use left mouse button, and right to scroll up".
[...]

Thightvnc is old software. Upstream does not maintain Thightvnc on
Linux any more. Thus, scrolling will stay the way it is.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#726599: xtightvncviewer: can't scroll up, only down

[Sven Geuer]

Control: tags -1 = wontfix

Hi Gary,

On Thu, 17 Oct 2013 20:58:20 +0200 Ola Lundqvist 
wrote:
> Hi
> 
> The vertial scroller is of a very old type. I think you get down by
> clicking the left button and up by clicking the right. Please let me
> know if that did not help.
> 
> // Ola
[...]

Thightvnc is old software. Upstream does not maintain Thightvnc on
Linux any more. Thus, scrolling will stay the way it is.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#991458: ITP: unifrac -- high-performance phylogenetic diversity calculations

[Nilesh Patra]

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

Subject: ITP: unifrac -- high-performance phylogenetic diversity calculations
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: unifrac
  Version : 0.10.0
  Upstream Author : , UniFrac development team.
* URL : https://github.com/biocore/unifrac
* License : BSD-3-clause
  Programming Lang: C
  Description : high-performance phylogenetic diversity calculations
 The de facto repository for high-performance phylogenetic diversity
 calculations. The methods in this repository are based on an
 implementation of the Strided State UniFrac algorithm which is faster,
 and uses less memory than Fast UniFrac. Strided State UniFrac supports
 Unweighted UniFrac, Weighted UniFrac, Generalized UniFrac, Variance
 Adjusted UniFrac and meta UniFrac. This repository also includes Stacked
 Faith (manuscript in preparation), a method for calculating Faith's PD
 that is faster and uses less memory than the Fast UniFrac-based
 reference implementation.
 .
 This package contains the Python3 module.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/unifrac

Bug#954158: tightvncserver output a blank screen with gray color under gnome

[Sven Geuer]

Control: tags -1 = wontfix

Hello Gulfstream,

On Tue, 17 Mar 2020 at 16:33, gulfstream  wrote:

> Package: tightvncserver
> Version: 1:1.3.9-9.1
> Severity: grave
>
>
> Hello, I want to use tightvnc under the gnome desktop, but only a
> blank screen was got in the client. Nothing is on the screen except a
> cursor.
>
> What is the matter? Would you please resolve it?
>
> Thank you very much!
>
>
>
> Best regards,
> Gulfstream

Nowadays Gnome on Debian uses Wayland instead of X. Even when ran/run
on X it required X11's Xcomposite extension for quite some time now.

On the other hand, Thightvnc is old software. It bases on Xfree86, an
outdated implementation of X. Thightvnc's X server doesn't comprise the
Xcomposite extension. Also, upstream does not maintain Thightvnc on
Linux any more.

Conclusion: Tightvncserver cannot serve a recent Gnome desktop.

Recommendation: Install the gnome-remote-desktop package and enable
screen sharing in your Gnome Settings.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#991457: unblock: graphicsmagick/1.4+really1.3.36+hg16481-2

[GCS]

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

Hi RMs,

I would like to ask for unblocking GraphicsMagick, with a simple but
important fix of freeing used memory[1].

[ Reason ]
Fixes a simple regression - writing labelled PDF files.

[ Impact ]
No more assertion on normal and common usage.

[ Tests ]
Good upstream test suite.

[ Risks ]
None.

[ 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 graphicsmagick/1.4+really1.3.36+hg16481-2

Thanks for considering,
Laszlo/GCS
[1] http://hg.graphicsmagick.org/hg/GraphicsMagick/rev/22aaff86b4aa
diff -Nru graphicsmagick-1.4+really1.3.36+hg16481/debian/changelog graphicsmagick-1.4+really1.3.36+hg16481/debian/changelog
--- graphicsmagick-1.4+really1.3.36+hg16481/debian/changelog	2021-02-28 23:26:56.0 +0100
+++ graphicsmagick-1.4+really1.3.36+hg16481/debian/changelog	2021-07-24 11:42:42.0 +0200
@@ -1,3 +1,10 @@
+graphicsmagick (1.4+really1.3.36+hg16481-2) unstable; urgency=medium
+
+  * Backport fix for use appropriate memory deallocator for memory returned
+by StringToList() (closes: #991380).
+
+ -- Laszlo Boszormenyi (GCS)   Sat, 24 Jul 2021 11:42:42 +0200
+
 graphicsmagick (1.4+really1.3.36+hg16481-1) unstable; urgency=high
 
   * Mercurial snapshot, fixing the following security issues:
diff -Nru graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/series graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/series
--- graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/series	2020-06-03 17:49:58.0 +0200
+++ graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/series	2021-07-24 11:42:42.0 +0200
@@ -1,2 +1,3 @@
 link-demos.diff
 semaphore_O0_ppc64el.patch
+use_appropriate_memory_deallocator.patch
diff -Nru graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/use_appropriate_memory_deallocator.patch graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/use_appropriate_memory_deallocator.patch
--- graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/use_appropriate_memory_deallocator.patch	1970-01-01 01:00:00.0 +0100
+++ graphicsmagick-1.4+really1.3.36+hg16481/debian/patches/use_appropriate_memory_deallocator.patch	2021-07-24 11:42:42.0 +0200
@@ -0,0 +1,52 @@
+
+# HG changeset patch
+# User Bob Friesenhahn 
+# Date 1626915582 18000
+# Node ID 22aaff86b4aa34c10b3fbfb104adaaeef8653a36
+# Parent  acf305f9ef3e85e6273d62e72d81cce03440eb3d
+WritePDFImage(): Use appropriate memory deallocator for memory returned by StringToList().
+
+diff -r acf305f9ef3e -r 22aaff86b4aa ChangeLog
+--- a/ChangeLog	Wed Jul 21 19:47:33 2021 -0500
 b/ChangeLog	Wed Jul 21 19:59:42 2021 -0500
+@@ -1,3 +1,9 @@
++2021-07-21  Bob Friesenhahn  
++
++* coders/pdf.c (WritePDFImage): Use appropriate memory deallocator
++for memory returned by StringToList().  Fixes SourceForge issue
++646 "Assertion failed using -label with PDF".
++
+ 2021-02-28  Bob Friesenhahn  
+ 
+ * configure.ac: Add tests for Jasper jp2_decode(), jpc_decode(),
+diff -r acf305f9ef3e -r 22aaff86b4aa coders/pdf.c
+--- a/coders/pdf.c	Wed Jul 21 19:47:33 2021 -0500
 b/coders/pdf.c	Wed Jul 21 19:59:42 2021 -0500
+@@ -1046,9 +1046,9 @@
+   FormatString(buffer,"(%.1024s) Tj\n",labels[i]);
+   (void) WriteBlobString(image,buffer);
+   (void) WriteBlobString(image,"ET\n");
+-  MagickFreeResourceLimitedMemory(labels[i]);
++  MagickFreeMemory(labels[i]);
+ }
+-  MagickFreeResourceLimitedMemory(labels);
++  MagickFreeMemory(labels);
+ }
+   FormatString(buffer,"%g 0 0 %g %ld %ld cm\n",x_scale,y_scale,geometry.x,
+geometry.y);
+diff -r acf305f9ef3e -r 22aaff86b4aa www/Changelog.html
+--- a/www/Changelog.html	Wed Jul 21 19:47:33 2021 -0500
 b/www/Changelog.html	Wed Jul 21 19:59:42 2021 -0500
+@@ -35,6 +35,12 @@
+ 
+ 
+ 
++2021-07-21  Bob Friesenhahn  bfriesensimpledallastxus
++
++* coders/pdf.c (WritePDFImage): Use appropriate memory deallocator
++for memory returned by StringToList().  Fixes SourceForge issue
++646 Assertion failed using -label with PDF.
++
+ 2021-02-28  Bob Friesenhahn  bfriesensimpledallastxus
+ 
+ * configure.ac: Add tests for Jasper jp2_decode(), jpc_decode(),

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

[Thomas Uhle]

On Fri, 23 Jul 2021, Christopher Schramm wrote:


Hi Thomas,

I just created https://github.com/blueman-project/blueman/pull/1572 upstream.

Cheers



Thank you!

Thomas

Bug#991456: firefox: crashes when zooming in on chatguesser map

[Jiri Palecek]

Package: firefox
Version: 90.0-2
Severity: normal
X-Debbugs-Cc: Jiri Palecek 

Dear Maintainer,

there is a nasty crash in firefox from version 90, that makes it almost
unusable at least for me. It happens on more pages randomly, but I could
best reproduce it by going on a chatguesser map
(eg. http://chatguesser.com/map/nuujaka) and zooming in several times
with a wheel.

This crash is already noted upstream:

https://bugzilla.mozilla.org/show_bug.cgi?id=1719232

But when I tried to bisect it with the mozregression tool, I couldn't
reproduce the bug with mozilla's nightlies. So there must be something
in the Debian build process which at least facilitates the emergence of
the crashes.

The crash happens on i386, not on amd64. It also crashes on OS X.

Could you help with that, please?

Regards
Jiri Palecek

-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Light theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: NoScript
Location: /usr/share/webext/noscript
Package: webext-noscript
Status: enabled

Name: Picture-In-Picture
Location: /usr/lib/firefox/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Reset Search Defaults
Location: 
/home/jirka/.mozilla/firefox/jt9usqcb.default-release/features/{0069d56b-c86a-4697-8860-239b14c84951}/reset-search-defau...@mozilla.com.xpi
Status: enabled

Name: System theme theme
Location: /usr/lib/firefox/omni.ja
Package: firefox
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: WebCompat Reporter
Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled


-- Addons package information
ii  firefox 90.0-2   i386 Mozilla Firefox web browser
ii  webext-noscript 10.1.9.6-2   all  permissions manager for Firefox

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

Kernel: Linux 5.7.0-1-686-pae (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-11
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s111-20210424-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.67-2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   11-20210424-1
ii  libvpx6  1.10.0+really1.8.1-dmo1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-2
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec58  10:4.4-dmo4

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-5
ii  fonts-stix [otf-stix]  1.1.1-3
ii  

Bug#991453: linux-image-5.10.0-8-amd64: Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle

[Diederik de Haas]

Control: tags -1 confirmed

On zaterdag 24 juli 2021 01:29:55 CEST piorunz wrote:
> GPU core works at 100% usage at all times, even at idle.
> 
> $ cat /sys/class/drm/card0/device/gpu_busy_percent
> 99
> 
> $ sensors
> (...)
> amdgpu-pci-0900
> Adapter: PCI adapter
> vddgfx:1.14 V
> fan1:1098 RPM  (min =0 RPM, max = 3000 RPM)
> edge: +51.0°C  (crit = +100.0°C, hyst = -273.1°C)
>(emerg = +105.0°C)
> junction: +55.0°C  (crit = +110.0°C, hyst = -273.1°C)
>(emerg = +115.0°C)
> mem:  +56.0°C  (crit = +100.0°C, hyst = -273.1°C)
>(emerg = +105.0°C)
> power1:   74.00 W  (cap = 272.00 W)
> 
> radeontop - 100% GPU usage and full clocks:
> Graphics pipe 100.00%
> 1.00G / 1.00G Memory Clock 100.00%
> 2.47G / 2.58G Shader Clock  95.92%

I'm getting the same results on my Radeon RX Vega 64.
$ cat /sys/class/drm/card0/device/gpu_busy_percent
99
$ sensors
nvme-pci-0100
Adapter: PCI adapter
Composite:+43.9°C  (low  = -273.1°C, high = +72.8°C)
   (crit = +75.8°C)
Sensor 1: +43.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2: +49.9°C  (low  = -273.1°C, high = +65261.8°C)

amdgpu-pci-0c00
Adapter: PCI adapter
vddgfx:1.09 V  
fan1:1240 RPM  (min =0 RPM, max = 3500 RPM)
edge: +50.0°C  (crit = +85.0°C, hyst = -273.1°C)
   (emerg = +90.0°C)
junction: +63.0°C  (crit = +105.0°C, hyst = -273.1°C)
   (emerg = +110.0°C)
mem:  +51.0°C  (crit = +95.0°C, hyst = -273.1°C)
   (emerg = +100.0°C)
power1:   74.00 W  (cap = 260.00 W)

k10temp-pci-00c3
Adapter: PCI adapter
Tctl: +66.0°C  
Tdie: +46.0°C

And also for radeontop.

> This I believe has been fixed upstream:
> https://gitlab.freedesktop.org/drm/amd/-/issues/1632
> 
> Can you please make sure this will be backported to Debian 5.10 kernel?

It's already backported to 5.10, just after 5.10.46 was released:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y=fea853aca3210c21dfcf07bb82d501b7fd1900a7

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

Bug#991455: gitolite3: underscore in username causes corruption and incorrect behaviour

[Luke Kenneth Casson Leighton]

Package: gitolite3
Version: 3.6.6-1
Severity: important
Tags: upstream

Dear Maintainer,

i have used gitolite3 for many years, this is the first time i have ever
had a major bug, and it involved a username with an underscore in it.
ssh to the server reported "hello user" not "hello user_", and
COMPLETELY the wrong repository was granted write access.

this is an extremely serious security issue.


-- System Information:
Debian Release: 9.12
  APT prefers stable
  APT policy: (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages gitolite3 depends on:
ii  adduser  3.115
ii  debconf [debconf-2.0]1.5.61
ii  git [git-core]   1:2.29.2-1~bpo10+1
ii  libjson-perl 2.90-1
ii  openssh-client   1:7.4p1-11.0nosystemd1
ii  openssh-server [ssh-server]  1:7.4p1-11.0nosystemd1
ii  perl 5.28.1-6

gitolite3 recommends no packages.

Versions of packages gitolite3 suggests:
pn  git-daemon-sysvinit  
ii  gitweb   1:2.29.2-1~bpo10+1

-- debconf information excluded

Bug#961622: Confirmed segfault on watching any stream

[Rick Kropski]

I can confirm this happening.  This is absolutely absurd.  Debian is 
supposed to produce a _stable_ operating system, is it not?  To the best 
of my understanding, that is why the included packages are often of 
older versions of software: to maintain and ensure security and 
stability.  I find it absolutely incomprehensible as to why a package, 
'out of the box,' just completely fails and segfaults.  If the nature of 
the package is such that, it is bound to not work due to API changes in 
the service it interacts with, it should NOT be included.  The only 
possibly way to remedy this problem in a timely fashion, is for the 
package provider to fix the problem immediately, and at this point, for 
the user to be able to compile that new version from source; which 
completely negates any reason AT ALL for this to be a Debian package; as 
the user should not be required to do that, and the Operating System 
providing the package, can't reliably update the package appropriately, 
assuming that developer even fixes the problem at all.



[10:51:26] Warning - GNOME-Twitch : {GtApp:94} Invalid logging level
[10:51:26] Message - GNOME-Twitch : {GtApp:370} Startup, running version 
'0.4.1'
[10:51:26] Message - GNOME-Twitch : {GtFollowsManager:254} Follows file 
at '/home/neoscholaris/.local/share/gnome-twitch/followed-channels.json' 
doesn't exist

[10:51:26] Message - GNOME-Twitch : {GtApp:339} Activate
[10:51:26] Message - GNOME-Twitch : {GtPlayer:132} Loading chat settings
[10:51:26] Message - GNOME-Twitch : {GtPlayer:999} Loaded player backend 
'GStreamer Cairo player backend'

[10:51:26] Message - GNOME-Twitch : {GtPlayerBackendGstreamerCairo:246} Init
[10:51:26] Warning - GNOME-Twitch : cannot set NULL uri
[10:51:27] Message - GNOME-Twitch : {GtPlayer:1310} Opening stream 
'lck_korea' with quality 'source'
[10:51:27] Warning - GNOME-Twitch : {GtTwitch:336} Received unsuccessful 
response from url 
'https://api.twitch.tv/api/channels/lck_korea/access_token' with code 
'410' and body '{"error":"Gone","status":410,"message":"this API has 
been removed."}'
[10:51:27] Warning - GNOME-Twitch : {GtTwitch:594} Error getting stream 
access token for channel 'lck_korea' because: Received unsuccessful 
response from url 'https://api.twitch.tv/api/channels/(any 
channel)/access_token' with code '410' and body 
'{"error":"Gone","status":410,"message":"this API has been removed."}'

Segmentation fault

Bug#730258: Hello

[Kayla Manthey]

Greetings, My name is Kayla Manthey, please reply me back?

Bug#989863: debian-installer: Firmware problems in bullseye

[Simon McVittie]

On Sat, 24 Jul 2021 at 09:05:59 +0200, Cyril Brulebois wrote:
> If we were to go the “(almost) all in” route, it might make sense to
> either blacklist (some of) those, or to whitelist the known-ok ones,
> which would require some monitoring of new additions over time (which
> dillon, behind d-i.debian.org, could help us with).

As an 80% solution, would it be feasible to have the officially-unofficial
media with firmware install the firmware-linux metapackage by default,
or at least install it if a desktop task was chosen?

firmware-linux pulls in firmware-amd-graphics and firmware-misc-nonfree
(which has the Nvidia firmware), and I think its rules for inclusion
imply not needing an EULA or other special license-acceptance by the
user. If I understand correctly, the equivalent packages are installed
by default in many distros that are less purist about being 100% Free
Software than we are.

I think the hierarchy of importance for installing things *from d-i*
goes something like this:

- essential boot stuff like raspi-firmware, without which the installed
  system is completely unusable on that hardware
  (but I don't think it's possible to start d-i on Raspberry Pi without
  providing the equivalent of raspi-firmware out-of-band somehow anyway)

- graphics devices: nobody wants a blank screen, and new users will be
  much more able to install extra packages later if they can at least get
  into a working GUI

- network devices: networking makes it much easier to install more
  firmware, but if you have a working GUI and no networking, you can at
  least read documentation, install more firmware from non-netinst media,
  or get a list of packages to download onto a USB stick on another machine

- audio and accessibility devices: essential for users who need those
  particular accessibility measures (screen readers, in the case of audio),
  but can be set up later from the installed system for most users

- everything else (in particular firmware-ivtv and
  firmware-microbit-python are not essential to anyone's use of the
  system as a whole, only their use of specific devices)

smcv

Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError

[Chris Lamb]

Paul Gevers wrote:

> With a recent upload of redis the autopkgtest of python-fakeredis fails
> in testing when that autopkgtest is run with the binary packages of
> redis from unstable. It passes when run with only packages from testing.

Just to confirm that I can reliably and locally reproduce the failure
of the:

   test/test_hypothesis.py::TestJoint::test

... test in python-fakeredis when run against redis 5:6.0.15-1 on my
amd64 machine, and it reliably succeeds against redis 5:6.0.14-1. (I
wan't certain it was reliable as there are some known flaky tests in
python-fakeredis.)

However, why the slight change to security-related overflow handling
in bitfield fields *on i386 systems* should result in this failure
eludes me...  :/


Regards,

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

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

[Michael Biebl]

Am 23.07.21 um 13:44 schrieb M G Berberich:

Am Donnerstag, den 22. Juli schrieb 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?


This is an assumption, Udev is the subsystem that handles media eject
button events. The problem can be circumvented by commenting out the
“media eject button pressed” handling in
/lib/udev/rules.d/60-cdrom_id.rules.

   # ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", 
GOTO="cdrom_end"

(which does prove nothing). This might be a problem elsewhere,
p.e. the kernel issuing a spurious media eject button press event.
(https://bugzilla.kernel.org/show_bug.cgi?id=213795).


This udev rules *reacts* to such an event, it doesn't generate it. So 
the problem does indeed look like it is elsewhere.
If this started happening after a kernel update, this might indeed be a 
good candidate.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#989863: debian-installer: Firmware problems in bullseye

[Cyril Brulebois]

Hi,

I thought I'd file two separate bug reports with details of test
installations (with main-only images, and with firmware-enabled images),
on two test machines (one with Radeon, one with Nvidia), but after
having collected information from a single test installation, I fear
this is going to be a waste of time for no real added value. Therefore,
I'll just reply inline with my current gut feelings.

This is an overlong mail, apologies for that, but both topics are
somewhat connected, so…


Release team, you can search for @RT to jump at partial conclusions.


Cyril Brulebois  (2021-06-14):
> This is an umbrella bug report that I intend to use to track at least
> two separate issues (that are really the two sides of the same coin):

# main-only images

>  - Official installation images (main-only) might lead to a successful
>installation but result in a black screen upon rebooting the
>installed system. Some of these issues are due to free drivers
>wanting or even requiring some firmware to work properly, on a
>per-device basis.

## isenkram-based proof-of-concept

I've investigated isenkram as a possible thing to document for end-users
to try whenever they have firmware-related issues. Let me say upfront
that this requires being able to log into the installed system: it
relies on having the “missing firmware” messages in dmesg, and automates
looking up the relevant firmware packages, enabling contrib/non-free,
and installing the firmware packages that were detected as needed.

A couple of comments:
 - When I first looked into it, I must say I wasn't exactly impressed by
   the state of the isenkram-autoinstall-firmware script in the
   isenkram-cli package (#989884); it was easy enough to fix the
   multiple issues in there to make it functional again in bullseye
   though.
 - The initial reaction to #989884 made me doubt whether we should be
   relying on this component, at least for a moment: While I understand
   the maintainer's point of view regarding what the package's main
   goals are, it felt like our d-i needs were handwaved away somehow.
   Practically though, the patches were merged in a timely manner, and
   as long as we can rely on that for the duration of a stable release,
   we might have a sufficiently good answer for people looking to
   complete the Debian installation.
 - The issues I fixed in isenkram-cli were around some fallback code
   path, and the AppStream maintainer suggested there might have been
   some issues in AppStream causing the primary code path to fail:
 https://bugs.debian.org/989884#24
   The relevant update was accepted into testing since then, but I
   haven't had a chance to check that hypothesis. It would be great to
   know whether we actually have two working lookup implementation and
   not just the fallback one. (This could mean more reliability during
   a release cycle, in case one of them breaks — again.)


## unability to reproduce black screens with test hardware

While the two test laptops (that were sent to me for debugging purposes)
were picked to come with two possibly problematic video cards, I haven't
been able to produce the black screen I was trying to get: the Radeon
one manages to work with llvmpipe out of the box (switching to RENOIR
once firmware is installed + reboot has happened), the Nvidia one has an
Intel GPU anyway.

I've tested the nomodeset kernel command line option though, which gets
me a working graphical environment as well with different settings, and
I *think* the system was using fallback, generic drivers (think VESA,
FBDEV, and the like), but I couldn't 100% confirm this by checking X
logs (which is slightly ironic for a former X maintainer but oh well).

I also *think* using this option would help people dodge the black
screen they can get with some other hardware, so that they can follow
the isenkram-based procedure; I haven't been able to confirm that myself
yet. It might make sense to have a call for help/feedback here, along
those lines: “after installing Debian with a graphical environment, if
you get a black screen, does passing `nomodeset` on the kernel command
line help get the system boot to a graphical environment?  [y/n]”. We
might ask for more details like the actual hardware they're testing
with, to see where the workaround is effective (and where it's needed).
I don't view this call for help/feedback as a blocker for a d-i release,
or for 11.0; we can always refine documentation if that hint is not
sufficient. And hopefully, people assisting end users will suggest using
firmware-enabled images anyway (read more about that below).


## proposed solution

If others agree, I suggest we add the following somewhere in the
installation guide (I don't think we should have a specific warning in
the installer; or more specifically it would be way too late to have it
be shown localized at this stage; more on that in the second part of my
mail). Heavily summarized (to give readers of this bug report