Bug#1040201: closed by Debian FTP Masters (reply to Patrick Matthäi ) (Bug#1040201: fixed in xine-lib-1.2 1.2.13+hg20230704-1)

2023-07-07 Thread Janek Stolarek
Thanks. Would it be possible to make another pull from libxine2 upstream? One 
more fix was added 
and we need that to fix volume in TDE.

Also, what needs to happen for this upstream version of libxine2 to be migrated 
to testing?

Janek



Bug#1040201: libxine2: Volume scaling changed to logaritmic, results in too low volume

2023-07-03 Thread Janek Stolarek
Package: libxine2
Version: 1.2.13-1
Severity: normal

Dear Maintainer,

version 1.2.11 of xine changed how volume scaling is done: it switched from
linear to logaritmic volume scaling. See this commit:

https://sourceforge.net/p/xine/xine-lib-1.2/ci/59544d4f4a763bd47a5e8b629e1afc74e0c9a719/

With the release of Bookworm this change made it into stable Debian (Bullseye 
used version 
1.2.10). This change seriously breaks volume control in applications that 
depend on libxine2. In
particular Amarok and Kaffeine shipped by Trinity Desktop Environment 
(currently not part of 
official Debian repositories).  More specifically it makes lower part of the 
volume scale to 
quiet to be usable, while the upper part of volume scale lacks necessary 
granularity.  There is a 
fix for this in upstream libxine2:

https://sourceforge.net/p/xine/xine-lib-1.2/ci/0a32d4509b39181da6553b85e4d35829716d23c7/

Would it be possible to pull latest upstream version of libxine2 into sid so 
that the TDE team can 
work on fixing applications that depend on xine?

P.S. Library versions listed below point to version of xine released with 
Bullseye. This is due to 
downgrade I had to make to work around the bug.

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libxine2 depends on:
ii  libxine2-bin   1.2.10-4+b1
ii  libxine2-misc-plugins  1.2.10-4+b1
ii  libxine2-plugins   1.2.10-4

Versions of packages libxine2 recommends:
ii  libxine2-ffmpeg  1.2.10-4+b1

Versions of packages libxine2 suggests:
pn  libxine2-doc  
pn  xine-ui   

-- no debconf information



Bug#1039718: pulseaudio: TDE Amarok too quiet after upgrading to Bookworm

2023-06-28 Thread Janek Stolarek
Package: pulseaudio
Version: 16.1+dfsg1-2+b1
Severity: normal

Dear Maintainer,

I recently upgraded from Debian 11 (Bullseye) to Debian 12 (Bookworm) and
experienced a regression with PulseAudio. After the upgrade Amarok (as
distributed with TDE, not KDE) plays at a significantly lower volume level than
before the update, to a point where it is barely usable. I experimented with
several other applications - VLC, Firefox, mplayer, xine - and for all of them
volume levels behave as expected and are sufficiently loud. With Amarok it seems
that the volume is no longer linear. In the lower range of the scale differences
between volume levels are negligible. For example, percieved difference between
changing Amarok volume from 28% to 48% is smaller than when changing if from 64%
to 68%.  (Note that changing Amarok's internal volume does not change its
corresponding PA volume slider in pavucontrol.) This problem is present both
when using Amarok's xine backend and its alsa backend, which might suggest that
this is a problem in Amarok. However, since the problem did not occur under
Debian 11 and Amarok and all of TDE is built from the same sources under Debian
11 and Debian 12, I believe this bug was introduced by a change outside of
Amarok.  I also tested this under a new user account with fresh configuration to
ensure this is not caused by a stale user configuration from before the upgrade.


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


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8
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.134
ii  init-system-helpers 1.65.2
ii  libasound2  1.2.8-1+b1
ii  libasound2-plugins  1.2.7.1-1
ii  libc6   2.36-9
ii  libcap2 1:2.66-4
ii  libdbus-1-3 1.14.6-1
ii  libfftw3-single33.3.10-1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3
ii  libgstreamer1.0-0   1.22.0-2
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-5
ii  liborc-0.4-01:0.4.33-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.2.0-1
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.1-1
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.6-1
ii  libtdb1 1.4.8-2
ii  libudev1252.6-1
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libwrap07.6.q-32
ii  libx11-62:1.8.4-2+deb12u1
ii  libx11-xcb1 2:1.8.4-2+deb12u1
ii  libxcb1 1.15-1
ii  libxtst62:1.2.3-1.1
ii  lsb-base11.6
ii  pulseaudio-utils16.1+dfsg1-2+b1
ii  sysvinit-utils [lsb-base]   3.06-4

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.6-1
ii  libpam-systemd [logind]  252.6-1
ii  rtkit0.13-5

Versions of packages pulseaudio suggests:
ii  paprefs  1.2-1
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 252.6-1

-- no debconf information

--===6402107246985721880==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="client.conf"

# 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
; daemon-b

Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

2020-08-14 Thread Janek Stolarek
Please disregard my last email completely - fault on my side. Secure Boot works 
as expected.

Janek



Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

2020-08-14 Thread Janek Stolarek
Hi guys,

I believe the fix for this bug introduced a security regression that I only 
noticed just now. 
Recall how I was able to test whether Secure Boot is enabled:

[root@skynet : ~] dmesg | grep secu
[0.00] secureboot: Secure boot enabled

Here's what I get now:

[root@skynet : ~]  dmesg | grep secu
[0.00] secureboot: Secure boot could not be determined (mode 0)

This happens both on kernel 5.6 (used when I reported the bug originally) and 
5.7. I wanted to 
double-check that this is due to the fix in grub but the old packages are no 
longer in the repo 
so I can't downgrade to test. Googling points me to similar past bug in GRUB:

https://bugzilla.redhat.com/show_bug.cgi?id=1418360

and the suggestion there is that "failure detect secure boot status causes the 
kernel to disable a 
number of security checks" which makes this a security issue. There'a also a 
lot of technical 
discussion that I don't follow but it probably will make more sense to you.

Should I file a separate bug report for this?

Janek



Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

2020-07-30 Thread Janek Stolarek
Thanks for fixing this so quickly!

Janek



Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

2020-07-30 Thread Janek Stolarek
> That's part of the Debian process for generating
> grub-efi-amd64-signed, it's no use to you. For now, uninstall the
> grub-efi-amd64-signed package that you have please?
Ok, I can confirm that the works. I installed the packages from the repo, 
disabled Secure Boot, 
and I can now boot into Windows without problems.

Janek



Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

2020-07-30 Thread Janek Stolarek
> (Just install the ones that are upgrades to packages you already have
> installed, of course, not absolutely everything there.)
One quick question: I have grub-efi-amd64-signed on my system but the 
repository contains 
grub-efi-amd64-signed-template. Is that intentional?

Janek



Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

2020-07-30 Thread Janek Stolarek
I'm fine with installing the debs - just send them over when they are ready.

Janek



Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

2020-07-30 Thread Janek Stolarek
Hi Steve,

> Are you using Secure Boot on this machine?
Yes:

[root@skynet : ~] dmesg | grep secu
[0.00] secureboot: Secure boot enabled

> Can you please confirm if going back to the previous
> versions of the Grub packages fixes the problem for you?
I can confirm that performing the following downgrade fixes the problem:

[DOWNGRADE] grub-common:amd64 2.02+dfsg1-20+deb10u1 -> 2.02+dfsg1-20
[DOWNGRADE] grub-efi-amd64:amd64 2.02+dfsg1-20+deb10u1 -> 2.02+dfsg1-20
[DOWNGRADE] grub-efi-amd64-bin:amd64 2.02+dfsg1-20+deb10u1 -> 2.02+dfsg1-20
[DOWNGRADE] grub-efi-amd64-signed:amd64 1+2.02+dfsg1+20+deb10u1 -> 
1+2.02+dfsg1+20
[DOWNGRADE] grub2-common:amd64 2.02+dfsg1-20+deb10u1 -> 2.02+dfsg1-20

Also, I have seen posts on reddit complaining about the same problem so it's 
not just me.

Janek