date:20211103

Bug#998419: kodi: CVE-2021-42917

2021-11-03 Thread Salvatore Bonaccorso

Hi Vasyl,

On Wed, Nov 03, 2021 at 10:05:01PM +, Vasyl Gello wrote:
> Control: fixed -1 2:19.3+dfsg1-1
> Control: found -1 2:19.1+dfsg2-2~bpo10+1-1
> 
> Hi Salvatore!
> 
> This bug was fixed in 19.3 upstream, and the sid/bookworm version is not 
> vulnerable.

Yes you are right, that was an error on my side, checking the source,
upstream commit and where the fix was included, thanks for correcting,
and apologies for the bad tracking at first. I double checked what
happened, and it was defintively that I got confused about the
inclusion from the upstream commit and not realizing it is in 19.3
already.

> I would like to upload 19.3 to stable-pu or stable-sec but the
> approval from SRM is pending for 19.2.
> 
> Is it possible to upload 2:19.3+dfsg1-1 to stable-sec as a whole package?
> Or I have to apply the patch for 2:19.1+dfsg2-2 and upload -3?

I'm not yet sure the issue would warrant a security update per se, but
the question can be answered for both DSA and update via a point
release: 2:19.3+dfsg1-1 could not enter directly bullseye. If you do a
rebase to the 19.3 upstream then this would be either a "rebuild"
approach 2:19.3+dfsg1-1~deb11u1 (if no other changes to packaging to
be done) or if you import 19.3 on top of the current bullseye
packaging because there were other changes not suitable in meanwhile,
then 2:19.3+dfsg1-0+deb11u1 to have it sorting before 2:19.3+dfsg1-1.

The general strategy is to cherry-pick commits, but as you know there
are some sources with exceptions to that rule for stable updates,
firefox, linux, mariadb, php, ffmpeg are such cases, and they have
some guarantee from CI and testsuies, promises about stabilities
(e.g. no new features, bugfix only branches, etc ...).

If you are discussing this already with SRM then this is indeed the
way to go to see if they agree on your proposal to follow the 19.x
series for kodi for bullseye.

Samewise for buster, by cherry-picking the fix, be it for an upcoming
point release or a DSA.

I cannot answer the question for stretch directly, but I see that LTS
will would like to issue a DLA for it.

Regards,
Salvatore

Bug#998431: patchage: Segmentation Fault

2021-11-03 Thread Alexandre Lymberopoulos

Package: patchage
Version: 1.0.0~dfsg0-0.2
Severity: important

Hi,

I'm moving to pipewire and, in order to keep things clean, intend to
remove pulseaudio and jack (please tell me if I
shouldn't). Connections between inputs and outputs are managed with
qjackctl by now and I heard of patchage, but it segfaults everytime I
try to run it here. Below is the output on the terminal:

Loading UI file /usr/share/patchage/patchage.ui

(patchage:24834): Gdk-WARNING **: 00:52:39.493: gdk_window_set_icon_list: icons 
too large
No configuration file present
Segmentation fault

Installing ladish doen't help. If any extra information is needed
please let me know.

Best, Alexandre

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-2-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=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages patchage depends on:
ii  libasound21.2.5.1-1
ii  libatk1.0-0   2.36.0-2
ii  libatkmm-1.6-1v5  2.28.2-1
ii  libc6 2.32-4
ii  libcairo2 1.16.0-5
ii  libcairomm-1.0-1v51.12.2-4
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.11.0+dfsg-1
ii  libganv-1-1v5 1.8.0-1
ii  libgcc-s1 [libgcc1]   11.2.0-10
ii  libgdk-pixbuf2.0-02.40.2-2
ii  libglib2.0-0  2.70.0-3
ii  libglibmm-2.4-1v5 2.66.2-1
ii  libgtk2.0-0   2.24.33-2
ii  libgtkmm-2.4-1v5  1:2.24.5-4+b1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.19~dfsg-2
ii  libpango-1.0-01.48.10+ds1-1
ii  libpangocairo-1.0-0   1.48.10+ds1-1
ii  libpangoft2-1.0-0 1.48.10+ds1-1
ii  libpangomm-1.4-1v52.46.1-1
ii  libsigc++-2.0-0v5 2.10.4-2
ii  libstdc++611.2.0-10

Versions of packages patchage recommends:
ii  jackd  5+nmu1

Versions of packages patchage suggests:
pn  ladish  

-- no debconf information

Bug#992495: segfault in av1_cyclic_refresh_free()

2021-11-03 Thread Boyuan Yang

Control: tags -1 +moreinfo +unreproducible

Hi,

I could not reproduce this issue on current Debian 11 Stable, Debian Testing
and Debian Unstable. Could you verify that this is still crashing on your
devices? If yes, please also consider providing the exact .jpg file that would
trigger the crashing.

Thanks,
Boyuan Yang

On Thu, 19 Aug 2021 13:04:23 +0200 Philipp Marek 
wrote:
> Package: libaom0
> Version: 1.0.0.errata1-3
> Severity: normal
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> When using libaom0 (via ImageMagick's "convert" or gimp), it crashes 
> when writing a avif:
> 
> 
> $ gdb ... --args convert 20210812_215114.jpg 20210812_215114.avif
> 
> Thread 1 "convert" received signal SIGSEGV, Segmentation fault.
> 0x74451b64 in av1_cyclic_refresh_free (cr=0x0) at
./av1/encoder/aq_cyclicrefresh.c:83
> 83  ./av1/encoder/aq_cyclicrefresh.c: Datei oder Verzeichnis nicht
gefunden.
> #0  0x74451b64 in av1_cyclic_refresh_free (cr=0x0) at
./av1/encoder/aq_cyclicrefresh.c:83




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

Bug#998428: dbus-session-bus-common: Deprecated option in /usr/share/dbus-1/session.conf

2021-11-03 Thread Nelson A. de Oliveira

Package: dbus-session-bus-common
Version: 1.13.18-2
Severity: normal

Hi!

While starting the D-Bus User Message Bus it's possible to see:

=
dbus-broker-launch[5405]: Policy to allow eavesdropping in 
/usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored
dbus-broker-launch[5405]: Policy to allow eavesdropping in 
/usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored
=

Probably it should be updated.

Thank you!

Best regards,
Nelson

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#998429: at-spi2-core: Deprecated option in /usr/share/defaults/at-spi2/accessibility.conf

2021-11-03 Thread Nelson A. de Oliveira

Package: at-spi2-core
Version: 2.42.0-2
Severity: normal

Hi!

While starting the Accessibility services bus it's possible to see:

=
at-spi-bus-launcher[5820]: Policy to allow eavesdropping in 
/usr/share/defaults/at-spi2/accessibility.conf +15: Eavesdropping is deprecated 
and ignored
at-spi-bus-launcher[5820]: Policy to allow eavesdropping in 
/usr/share/defaults/at-spi2/accessibility.conf +17: Eavesdropping is deprecated 
and ignored
=

Probably it should be updated.

Thank you!

Best regards,
Nelson


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages at-spi2-core depends on:
ii  libatspi2.0-0  2.42.0-2
ii  libc6  2.32-4
ii  libdbus-1-31.13.18-2
ii  libglib2.0-0   2.70.0-3
ii  libsystemd0249.5-2
ii  libx11-6   2:1.7.2-2+b1
ii  libxtst6   2:1.2.3-1

at-spi2-core recommends no packages.

at-spi2-core suggests no packages.

-- no debconf information

Bug#998427: iwd: Deprecated option in /usr/share/dbus-1/system.d/iwd-dbus.conf

2021-11-03 Thread Nelson A. de Oliveira

Package: iwd
Version: 1.19-1
Severity: minor

Hi!

While booting the system it's possible to see this:

=
dbus-broker-launch[2169]: Deprecated policy context in 
/usr/share/dbus-1/system.d/iwd-dbus.conf +21. The 'at_console' context is 
deprecated and will be ignored in the future.
=

Probably this should be updated?

Thank you!

Best regards,
Nelson

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iwd depends on:
ii  libc6 2.32-4
ii  libreadline8  8.1-2

Versions of packages iwd recommends:
ii  dbus [dbus-system-bus] 1.13.18-2
ii  dbus-broker [dbus-system-bus]  29-3
pn  wireless-regdb 

iwd suggests no packages.

-- no debconf information

Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator

2021-11-03 Thread Seunghun Han

Hi Bastian,

On Thu, Nov 4, 2021 at 6:43 AM Bastian Germann  wrote:
> Can you explain why it builds on amd64 when it is docker related?
I'm sorry that I didn't explain it in detail. The previous build error
occurred at GitLab runner, and I found it was a docker environment. To
have the identical environment, I pulled the docker image of GitLab
runner, built the package, and ran tests of it. Then some of the tests
failed, and I thought some test cases didn't work in a container
environment like docker. But, they work well in native, and I thought
it could be a trivial issue.

> The failing build is on i386 and also fails natively on my i386 machine.
> It looks a bit like Y2K38 triggering...
I'm sorry. I missed the point that i386 means 32bit system. I agree
with your opinion about Y2K and should find the reason and the
solution.

> I am also not sure if you are allowed to write in /tmp on package building. I 
> will check that.
Everyone has write access right to /tmp directory, so I guess the
package also has it.


Best regards,

Seunghun

Bug#998240: Bug#954916: another breakage due to LaTeX changes?

2021-11-03 Thread Norbert Preining

Hi Joseph,

last year you helped fixing a strange lgrind.dtx file:

On Wed, 25 Mar 2020, Joseph Wright wrote:
> On 25/03/2020 11:03, Enrico Gregorio wrote:
> > > Where can we find lgrind.dtx?
> > http://mirrors.ctan.org/support/lgrind/lgrind.dtx

> The structure of the .dtx is ... unusual. It's got the \begin{document} in
> the 'input' stage and the \end{document} 'as normal'. The result is "%" ends
> up with the 'wrong' catcode, which is where the issue arises: what should be
> a comment in the .def is not any longer. It can be fixed by making the .dtx
> 'normal', i.e. moving the \begin{document} line, but I'm not sure if that is
> an acceptable fix.

You send a simple patch, and that worked all nicely till TeX Live 2021,
and now the same lgrind.dtx (patched version is attached) fails again.

The error message is comes from this part of the code:

% The meta-symbols and their meanings are:
% \begin{description}
% \item[\$] The end of a line
% \item[\^] The beginning of a line
% \item[$\backslash$d] A delimiter (space, tab, newline, start of line)
% \item[$\backslash$a] Matches any string of symbols (like `.*' in lex)
***

And the error is:
[8]
! Missing } inserted.

}
l.540 % \item[\^]
  The beginning of a line
? X


Any suggestion again? As said, it was working till Dezember 2020 ;-)

All the best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
% \iffalse
%
% This is LGrind.DTX. This was written by:
%
% -  Van Jacobson, Lawrence Berkeley Laboratory (based on
%vgrind by Dave Presotto & William Joy of UC Berkeley),
%the original written for \TeX.
% -  Jerry Leichter of Yale University, modifications for \LaTeX.
% -  George V. Reilly of Brown University, renamed to lgrind
% -  Michael Piefel, Humboldt-University Berlin, for \LaTeXe
%and a thousand little changes
%
% \fi
% \iffalse
%% Based on Van Jacobson's ``tgrindmac'', a macro package for TeX.
%% Modified, 1987 by Jerry Leichter. Put '@' in all internal names.
%% Modified, 1991 by George Reilly. Changed name from tgrind to lgrind.
%% Modified, 1995 by Michael Piefel. Made it work with \LaTeXe.
%%  -1999Hundreds of bells and whistles. No changelog here.
%
%<*dtx>
\ProvidesFile{lgrind.dtx}
  [2002/01/28 v3.67 LGrind environment and supporting stuff]
%
%\NeedsTeXFormat{LaTeX2e}[1996/06/01]
%\ProvidesPackage{lgrind}
%  [2002/01/28 v3.67 LGrind environment and supporting stuff]
%<*driver>
\NeedsTeXFormat{LaTeX2e}[1996/06/01]
\documentclass{ltxdoc}
\CodelineIndex
\RecordChanges
\begin{document}
\DocInput{lgrind.dtx}
\end{document}
%
% \fi
%
% \newcommand{\LG}{\textsf{LGrind}}
% \newcommand{\NFSS}{\textsf{NFSS}}
% \frenchspacing
% 
% \GetFileInfo{lgrind.dtx}
% \title{The \LG{} package\thanks{This file
% has version number \fileversion, last
% revised \filedate.}}
% \author{Various Artists}
% \date{\filedate}
% \maketitle
% 
% \CheckSum{679}
% 
% \begin{abstract}
% The \LG{} package is a pretty printer for source
% code. It evolved from vgrind, supported \TeX{} (tgrind) and
% \LaTeX{} and now finally \LaTeXe, in particular \NFSS.
% \end{abstract}
% 
% \changes{v1.0}{1985/02/10}{Written}
% \changes{v2.0}{1991/09/06}{Upgrade to \LaTeX2.09}
% \changes{v3.0}{1995/09/24}{Upgrade to \LaTeXe}
% 
% \section{Introduction}
% \subsection{What is it?}
% The \LG{} package consists of three files:
% \begin{itemize}
% \item \texttt{lgrind} or \texttt{lgrind.exe} is the executable. It will
% convert an \LaTeX-File with embedded listings or a source code file
% into a lot of macro-calls.
% \item \texttt{lgrind.sty} provides the environments and macros to make
% the produced mess readable.
% \item \texttt{lgrindef} contains the information
% needed to tell keywords from comments, comments from strings \dots
% \end{itemize}
% 
% \subsection{Who is to blame?}
% \LG{} is not the work of a single one. The program is based on
% \textsf{vgrind} by Dave Presotto \& William Joy of UC Berkeley.
% 
% Van Jacobson wrote \textsf{tgrind} for \TeX. Jerry Leichter
% of Yale University modified it for \LaTeX. George V. Reilly of 
% Brown University changed the name to lgrind and added the
% program-text-within-comments and @-within-\LaTeX{} features,
% and finally
% Michael Piefel of the Humboldt-University Berlin converted it to
% work under \LaTeXe, i.\,e. with \NFSS, and improved the documentation.
%
% However, there have been many contributors who supported the development; in
% particular the range of supported languages is mainly due to them.
% Unfortunately I do not know all of them, but my thanks go to everybody.
% A special Thank You to
% Torsten Sch\"utze for his OS/2 support and many and various hints.
% 
% \section{\LG{} -- grind nice program listings}
% 
% \begin{tabbing}
% \texttt{lgrind} \= \texttt{[-s] [-e]

Bug#998220: pipewire: libspa-0.2-bluetooth not installed

2021-11-03 Thread Ralf Jung


This however did not solve my problem, I will file another bug report for the
remaining part


I am also still struggling with getting BT working again; do you have a link to 
the other bug report?


Addendum: the missing bit in my case (besides installing libspa-0.2-bluetooth 
package and removing pulseaudio-module-bluetooth) was that I had to re-pair the 
device. Now it seems things are working again as before.


Kind regards,
Ralf

Bug#998220: pipewire: libspa-0.2-bluetooth not installed

2021-11-03 Thread Ralf Jung

Hi all,

The first problem was that the headset disconnected immediately after
connecting. There was an associated error in journalctl :

src/service.c:btd_service_connect() a2dp-sink profile connect failed for Protocol not available

Some search engine pointed to me that this may be associated with missing
libspa-0.2-bluetooth, so I installed it and this first error disappeared. So a
first suggestion would be to make sure that libspa-0.2-bluetooth is added as a
dependency to some of the pipewire set.

I am having the same problem. According to
https://wiki.debian.org/BluetoothUser/a2dp, one also has to uninstall
pulseaudio-module-bluetooth.

This is one of the rare cases where upgrading Debian just silently broke the
system -- all bluetooth audio functionality just stopped working without
warning. I hope something can be done to avoid this.

Amusingly, the description of the libspa package says " It is considered to be
experimental, and is disabled by default (even if installed) to avoid conflicts
with equivalent functionality in PulseAudio. " -- however, since upgrades now
seem to automatically switch people over from PA to pipewire, does this still
make sense? So far certainly one cannot speak of "equivalent functionality",
since the bluetooth support in PA actually worked out of the box without any
fiddling...

This however did not solve my problem, I will file another bug report for the
remaining part

I am also still struggling with getting BT working again; do you have a link to
the other bug report?

Kind regards,
Ralf

Bug#994617: h5py: please be more forgiving about mismatching HDF5 versions

2021-11-03 Thread Drew Parsons

Source: h5py
Followup-For: Bug #994617

Hi Mattia, historically hdf5 has not been entirely ABI-stable, see
https://forum.hdfgroup.org/t/c-c-abi-stability-and-binary-compatibility-between-patch-versions/5312
https://forum.hdfgroup.org/t/another-abi-breakage/5503

The test was added in https://github.com/h5py/h5py/pull/867
Not entirely clear what the context of the test is (the upstream
issues references in the PR seem to discuss being unable to read the
libhdf5 version on Windows).

But the h5py test was added in 2017, while HDF5 was still discussion
ABI [in]stability in 2019. But 1.10.2 and 1.10.3 were released in
2018, after which HDF5 seems to be identifying ABI correctly.

They include binary compatibility reports in their Release Notes
e.g.
https://portal.hdfgroup.org/display/support/HDF5%201.10.8#compatibility1108

https://portal.hdfgroup.org/display/support/HDF5%201.10.3#compatibility
identifies an incompatibility between 1.10.2 and 1.10.3
HDF5 1.10.3 introduced ABI 103

But their binary incompatibilities seem to be correctly reflected in
ABI sonames. The discussion in 2019 addressed 1.10.1 and 1.10.2. They
considered 1.10.2 the proper stable release (in 2018), and updated the ABI for
1.10.3 as needed (also in 2018).

python3-h5py-serial and python3-h5py-mpi declare their dependency on
the appropriate ABI-versioned libhdf5 so you're right, that should
capture compatibility satisfactorily.

1 2 >

1 - 100 of 176 matches

Mail list logo