Bug#1021646: blender: enable HIP in Cycles

[Cordell Bloor]

Package: blender
Version: 3.2.2+dfsg-3
Severity: wishlist

Dear Maintainer,

I've been working with Étienne Mollier and others on the Debian AI team
to enable ROCm in Debian. I believe it would now be possible to build
Blender with support for AMD GPUs by using the HIP package in Debian
Unstable. The Debian HIP package still has a few rough edges that need
cleaning up, but is fully functional. The rocrand package is an example
of a library that is built using HIP.

AMD HIP support for Navi 21 hardware can be enabled in Blender using
the CMake options:

-DWITH_CYCLES_HIP_BINARIES=ON
-DCYCLES_HIP_BINARIES_ARCH=gfx1030

There are also a few environment variables that are (temporarily)
required to compile HIP code when using the Debian package:

export HIP_CLANG_PATH=/usr/bin
export DEVICE_LIB_PATH=/usr/lib/${DEB_HOST_MULTIARCH}/amdgcn/bitcode
export ROCM_PATH=/usr

As well, there are a few packages needed in the Build-Depends:

hipcc
libamd-comgr-dev
libhsa-runtime-dev
rocminfo

I put a bit more background information in my posting on the mailing
list:
https://lists.debian.org/debian-multimedia/2022/09/msg00507.html

If you have any questions or run into any roadblocks, I'd be glad to
help! If you need hardware for testing, just let me know. There were
a few GPUs donated to the Debian project for supporting HIP and it's
likely that some are still be available.

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

Kernel: Linux 5.4.0-126-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages blender depends on:
ii  blender-data  3.2.2+dfsg-3
ii  fonts-dejavu  2.37-2
ii  libavcodec59  7:5.1.2-1
ii  libavdevice59 7:5.1.2-1
ii  libavformat59 7:5.1.2-1
ii  libavutil57   7:5.1.2-1
ii  libboost-locale1.74.0 1.74.0-17
ii  libc6 2.35-3
ii  libembree3-3  3.13.4+dfsg-1
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.12.1+dfsg-3
ii  libgcc-s1 12.2.0-5
ii  libgl11.5.0-1
ii  libglew2.22.2.0-4+b1
ii  libgomp1  12.2.0-5
ii  libimath-3-1-29   3.1.5-1+b1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-1
ii  libjemalloc2  5.2.1-5
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  libopenal11:1.19.1-2
ii  libopencolorio2.1 2.1.2+dfsg1-4
ii  libopenexr-3-1-30 3.1.5-4
ii  libopenimageio2.3 2.3.18.0+dfsg-5
ii  libopenjp2-7  2.5.0-1
ii  libopenvdb9.1 9.1.0-7+b1
ii  libosdcpu3.4.43.4.4-2
ii  libosdgpu3.4.43.4.4-2
ii  libpcre3  2:8.39-14
ii  libpng16-16   1.6.38-2
ii  libpugixml1v5 1.12.1-1
ii  libpulse0 16.1+dfsg1-2
ii  libpython3.10 3.10.7-2
ii  libsdl2-2.0-0 2.24.1+dfsg-1
ii  libsndfile1   1.1.0-3
ii  libspnav0 1.0-1
ii  libstdc++612.2.0-5
ii  libswscale6   7:5.1.2-1
ii  libtbb12  2021.5.0-15
ii  libtiff5  4.4.0-4
ii  libx11-6  2:1.8.1-2
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8-1+b1
ii  libxml2   2.9.14+dfsg-1+b1
ii  libxrender1   1:0.9.10-1.1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  libzstd1  1.5.2+dfsg-1
ii  zlib1g1:1.2.11.dfsg-4.1

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#1021645: bullseye-pu: package postfix/3.5.13-0+deb11u1

[Scott Kitterman]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

This is another in my occasional series of postfix updates to
keep up with upstream maintenance updates to the version in
stable (v3.5).  Upstream is still judicious and reasonable in
their approach to fixing things.  The maintenance updates are
generally suitable for Debian stable updates.

[ Reason ]
Fix bugs.  As far as I have determined, with one exception that
was a Debian patch in the last update earlier in the year and is
now in the upstream code, these issues to not correspond to
specific BTS bugs, but a number of these changes address issues
which Debian users might experience.

[ Impact ]
Users will continue to have the bugs.  Additionally, upstream
ocassionally checks if postfix is up to date in Debian and so
doing the stable updates helps upstream relations.

[ Tests ]
Postfix does have an autopkgtest.  I have built the proposed
package locally (on bullseye) and have it running in production
with no issues noted.

[ Risks ]
Risks should be minimal.  This upstream has a very good track
record for low risk updates (we have been doing these several
cycles and haven't experienced any significan issues.  None of
the fixes are particularly comples.

[ 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 (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Here is the proposed debian/changelog entry with the
explanation of the changes:

postfix (3.5.17-0+deb11u1) bullseye; urgency=medium

  [Scott Kitterman]

  * Delete debian/patches/postfix-dup-postconf.patch, earlier backport now
upstream (from 3.5.14)

  [Wietse Venema]

  * 3.5.14
- Bugfix (introduced: 20210708): duplicate bounce_notice_recipient
  entries in postconf output. The fix to send SMTP session
  transcripts to bounce_notice_recipient was incomplete.
  Reported by Vincent Lefevre. File: smtpd/smtpd.c.

- Bugfix (introduced: Postfix 3.0): the proxymap daemon did
  not automatically authorize proxied maps inside pipemap
  (example: pipemap:{proxy:maptype:mapname, ...}) or inside
  unionmap. Problem reported by Mirko Vogt. Files:
  proxymap/proxymap.c.

- Bugfix (introduced: Postfix 2.5): off-by-one error while
  writing a string terminator. This code had passed all memory
  corruption tests, presumably because it wrote over an
  alignment padding byte, or over an adjacent character byte
  that was never read. Reported by Robert Siemer. Files:
  *qmgr/qmgr_feedback.c.

- Cleanup: added missing _maps parameter names to the
  proxy_read_maps default value, based on output from the
  mantools/missing-proxy-read-maps script.  File:
  global/mail_params.h.

  * 3.5.15
- Bitrot: Glibc 2.34 implements closefrom(). File:
  util/sys_defs.h.

- Bitrot: Berkeley DB 18 is like Berkeley DB 6. Yasuhiro
  Kimura. File: util/dict_db.c.

  * 3.5.16
- Cleanup: added missing _checks, _reply_footer, _reply_filter,
  _command_filter, and _delivery_status_filter parameter names
  to the proxy_read_maps default value. Files: global/mail_params.h,
  mantools/missing-proxy-read-maps.

- Bugfix: in an internal client module, "host or service not
  found" was a fatal error, causing the milter_default_action
  setting to be ignored. It is now a non-fatal error. The
  same client is used by many Postfix clients (smtpd_proxy,
  dovecot auth, tcp_table, memcache, socketmap, and so on).
  Problem reported by Christian Degenkolb. File: util/inet_connect.c.

- Cleanup (problem introduced: Postfix 3.0): with dynamic map
  loading enabled, an attempt to create a map with "postmap
  regexp:path" would result in a bogus error message "Is the
  postfix-regexp package installed?" instead of "unsupported
  map type for this operation". This happened with all built-in
  map types (static, cidr, etc.) that have no 'bulk create'
  support. Problem reported by Greg Klanderman. File:
  global/dynamicmaps.c.

- Cleanup (problem introduced: Postfix 2.7): milter_header_checks
  maps are now opened before the cleanup server enters the
  chroot jail. Problem reported by Jesper Dybdal. Files:
  cleanup/cleanup.h, cleanup/cleanup_init.c,
  cleanup/cleanup_milter.c, cleanup/cleanup_state.c.

  * 3.5.17
- Cleanup: Postfix 3.5.0 introduced debug logging noise in
  map_search_create(). Files: global/map_search.c.

- Workaround: in a TLS server disable Postfix's 1-element
  internal session cache, to work around an OpenSSL 3.0
  regression that broke TLS handshakes. It is rarely useful.
  Report by Spil Oss, fix by Viktor Dukhovni. File:
  tls/tls_server.c.

- Cleanup: Postfix 3.3.0 introduced an uninitialized
  verify_append() request 

Bug#1021644: logind: OnExternalPower is confusedj

[Helmut Grohne]

Package: systemd
Version: 251.5-1

Hi,

logind seems confused

# busctl get-property org.freedesktop.login1 /org/freedesktop/login1 
org.freedesktop.login1.Manager OnExternalPower
b true
# /lib/systemd/systemd-ac-power  --verbose
no
#

The system in question actually is running on battery. Both appear to be
using the on_ac_power() C function. When running strace on the latter
one can vaguely guess that on_ac_power() is actually run. When running
strace on logind however, the sendmsg call happens immediately after the
recvmsg call, so it seems like on_ac_power() is not actually run, but
the value is cached or something. During boot, the system in question
was on ac power.

Looking closer, I now guess that the issue is here:
https://sources.debian.org/src/systemd/251.5-2/src/login/logind-dbus.c/?hl=380#L380

Could it be that the function pointer is converted to boolean rather
than being called? I.e. could it be that the function should actually be
called?

-static BUS_DEFINE_PROPERTY_GET_GLOBAL(property_get_on_external_power, "b", 
manager_is_on_external_power);
+static BUS_DEFINE_PROPERTY_GET_GLOBAL(property_get_on_external_power, "b", 
manager_is_on_external_power());

Admittedly, I've not tested this, because restarting logind is so
annoying as it kills all login sessions. So this could be a red herring.

Helmut

Bug#1021641: libamdhip64-5: libamdhip64.so.5.2.21153- missing githash

[Cordell Bloor]

Package: libamdhip64-5
Version: 5.2.3-1~0exp1
Severity: normal

Dear Maintainer,

These two libraries have file names that end in a dash. That naming confuse 
some linkers:

/usr/lib/x86_64-linux-gnu/libamdhip64.so.5.2.21153-
/usr/lib/x86_64-linux-gnu/libhiprtc-builtins.so.5.2.21153-

Upstream bug report:
https://github.com/ROCm-Developer-Tools/HIP/pull/2218

Upstream fix in ROCm 5.3.0:
https://github.com/ROCm-Developer-Tools/hipamd/commit/56b32604729cca08bdcf00c7a69da8a75cc95b8a

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

Kernel: Linux 5.4.0-126-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libamdhip64-5 depends on:
ii  libc6   2.35-3
ii  libgcc-s1   12.2.0-5
ii  libhsa-runtime64-1  5.2.3-1~0exp0
ii  libnuma12.0.15-1
ii  libstdc++6  12.2.0-5

libamdhip64-5 recommends no packages.

libamdhip64-5 suggests no packages.

-- no debconf information

Bug#1021640: hipcc passes runpath unconditionally

[Cordell Bloor]

Package: hipcc
Version: 5.2.3-1~0exp1
Severity: normal

Dear Maintainer,

hipcc.pl adds "--enable-new-dtags -Wl,-rpath=$HIP_LIB_PATH:$ROCM_PATH/lib" to
the link flags unconditionally. This seems like a problem, as it needs to be
stripped in every package built with hipcc. It should probably either be
controlled by an environment variable or removed from hipcc entirely.

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

Kernel: Linux 5.4.0-126-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages hipcc depends on:
ii  clang-151:15.0.2-2~exp1
ii  clang-tools-15  1:15.0.2-2~exp1
ii  libamdhip64-dev 5.2.3-1~0exp1
ii  libfile-which-perl  1.27-1
ii  liburi-encode-perl  1.1.1-2
ii  lld-15  1:15.0.2-2~exp1
ii  rocm-device-libs5.1.0-1

hipcc recommends no packages.

hipcc suggests no packages.

-- no debconf information

Bug#1021639: wayfire: symbol lookup error: wayfire: undefined symbol: wlr_backend_get_renderer

[Nick Black (Public gmail account)]

Version: 0.7.4-2
close 1021639


i'm stupid. /usr/local strikes again. sorry!


signature.asc
Description: PGP signature

Bug#1021639: wayfire: symbol lookup error: wayfire: undefined symbol: wlr_backend_get_renderer

[Nick Black (Public gmail account)]

Package: wayfire
Version: 0.7.4-2
Severity: important
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I installed wayfire 0.7.4-2, and attempted to run wayfire. It refused to start,
due to an undefined symbol. Prior to this, it printed several diagnostics, so
I'm guessing this symbol is used by some plugin or dynlib.

[schwarzgerat](0) $ wayfire
II 11-10-22 21:58:23.668 - [src/main.cpp:288] Starting wayfire version
0.8.0-bbe63a72 (Dec  1 2021, branch 'master')
II 11-10-22 21:58:23.669 - [backend/x11/backend.c:397] Creating X11 backend
II 11-10-22 21:58:23.669 - [backend/x11/backend.c:480] X11 does not support
shared pixmaps
EE 11-10-22 21:58:23.669 - [backend/x11/backend.c:609] Failed to query DRI3 DRM
FD
wayfire: symbol lookup error: wayfire: undefined symbol:
wlr_backend_get_renderer

Also, is the version number correct? The diagnostic indicates 0.8.0, but the
package is 0.7.4.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages wayfire depends on:
ii  libc62.35-3
ii  libcairo21.16.0-6
ii  libgcc-s112.2.0-5
ii  libgles2 1.5.0-1
ii  libglib2.0-0 2.74.0-2
ii  libinput10   1.21.0-1
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpixman-1-00.40.0-1
ii  libpng16-16  1.6.38-2
ii  libstdc++6   12.2.0-5
ii  libwayland-server0   1.21.0-1
ii  libwf-config10.7.1-2
ii  libwf-utils0 0.7.4-2
ii  libwlroots10 0.15.1-3
ii  libxcb1  1.15-1
ii  libxkbcommon01.4.1-1

wayfire recommends no packages.

wayfire suggests no packages.

-- no debconf information

Bug#1021638: RFS: gamehub/0.16.3-2-master+ds-1~bpo11+1 -- Unified library for games from multiple sources

[Phil Morrell]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gamehub". It is a trivial
backport (dch --bpo) but it does need to go through NEW:

 * Package name : gamehub
   Version  : 0.16.3-2-master+ds-1~bpo11+1
   Upstream contact : Anatoliy Kashkin 
 * URL  : https://tkashkin.github.io/projects/gamehub/
 * License  : CC0-1.0, GPL-3+
 * Vcs  : https://salsa.debian.org/yangfl-guest/gamehub
   Section  : games

The source builds the following binary packages:

  gamehub - Unified library for games from multiple sources

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/gamehub/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gamehub/gamehub_0.16.3-2-master+ds-1~bpo11+1.dsc

Changes since the last upload:

 gamehub (0.16.3-2-master+ds-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.
 .
 gamehub (0.16.3-2-master+ds-1) unstable; urgency=medium
 .
   * New upstream release
 * Fix FTBFS (Closes: #1011700)
   * Bump Standards-Version to 4.6.1
 .
 gamehub (0.16.1-2-master+ds-1) unstable; urgency=medium
 .
   * New upstream release
   * Bump Standards-Version to 4.6.0
 .
 gamehub (0.16.0-1-master+ds-1) unstable; urgency=medium
 .
   * Initial release (Closes: #982335)

Regards,
--
  Phil Morrell


signature.asc
Description: PGP signature

Bug#1021637: rust-pyo3: autopkgtest failure

[Adrian Bunk]

Source: rust-pyo3
Version: 0.16.5-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-pyo3/26874345/log.gz

...
rust-pyo3:@  FAIL non-zero exit status 101
librust-pyo3-dev:abi3 PASS
librust-pyo3-dev:abi3-py310 PASS
librust-pyo3-dev:abi3-py37 PASS
librust-pyo3-dev:abi3-py38 PASS
librust-pyo3-dev:abi3-py39 PASS
librust-pyo3-dev:anyhow FAIL non-zero exit status 101
librust-pyo3-dev:auto-initialize PASS
librust-pyo3-dev:default FAIL non-zero exit status 101
librust-pyo3-dev:extension-module FAIL non-zero exit status 101
librust-pyo3-dev:eyre PASS
librust-pyo3-dev:full FAIL non-zero exit status 101
librust-pyo3-dev:generate-abi3-import-lib PASS
librust-pyo3-dev:generate-import-lib PASS
librust-pyo3-dev:hashbrown PASS
librust-pyo3-dev:indexmap PASS
librust-pyo3-dev:indoc PASS
librust-pyo3-dev:inventory PASS
librust-pyo3-dev:macros FAIL non-zero exit status 101
librust-pyo3-dev:multiple-pymethods FAIL non-zero exit status 101
librust-pyo3-dev:nightly PASS
librust-pyo3-dev:num-bigint FAIL non-zero exit status 101
librust-pyo3-dev:num-complex PASS
librust-pyo3-dev:pyo3-macros PASS
librust-pyo3-dev:pyproto PASS
librust-pyo3-dev:serde FAIL non-zero exit status 101
librust-pyo3-dev:unindent PASS
librust-pyo3-dev:PASS

Bug#1020935: Old Version of go used to build git-lfs

[Stephen Gelman]

On Sep 28, 2022 at 4:49:29 PM, "Bower, Jesse (LNG-HBE)" <
jesse.bo...@lexisnexis.com> wrote:

> Package: git-lfs
>
> Version: 2.13.2-1+b5
>
> After I install git-lfs the docker image is seen as having the following 
> cve’s:
>
> CVE-2022-23806
> CVE-2021-38297
> CVE-2022-27664
> CVE-2022-30631
> CVE-2022-32189
> CVE-2022-30632
> CVE-2022-30635
> CVE-2022-28131
> CVE-2022-30630
> CVE-2022-30633
> CVE-2022-23773
> CVE-2022-24921
> CVE-2022-24675
> CVE-2022-28327
> CVE-2022-30580
> CVE-2021-41772
> CVE-2021-41771
> CVE-2021-44716
> CVE-2021-39293
> CVE-2022-23772
> CVE-2021-33194
> CVE-2021-33195
> CVE-2021-33196
> CVE-2021-33198
> CVE-2021-29923
>
> Seen from the version of go used to build git-lfs,
>
> "name": "go",
> "version": "1.15.9",
> "path": "/usr/bin/git-lfs",
> "layerTime": 0,
> "knownVulnerabilities": 72
>
> Example Dockerfile used for testing
>
> FROM debian:stable-slim
>
> RUN apt-get update && apt-get upgrade -y && apt-get install -y git-lfs
>
>
>
> I suggest that the version of go used to build git-lfs is updated to a
> current version.
>
>
>
> Thank you,
>
> Jesse Bower
>

Jesse,

The way that go packages are built in Debian is that they are required to
use the version of the go compiler in the current release. Therefore, any
CVEs that are patched there are also patched in this version of git-lfs. If
there are unpatched vulnerabilities with the debian go compiler, you will
instead need to file a bug against the golang-go package.

Stephen

Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.

[Sean Whitton]

control: severity -1 important

Hello,

On Tue 11 Oct 2022 at 05:05PM -07, Sean Whitton wrote:

> control: reassign -1 cl-ironclad
> control: retitle -1 cl-ironclad: fails to compile against recent SBCL on 
> 32-bit ARM architectures
>
> I intend to resolve this bug by disabling the failing compilation.
> SBCL upstream do not think there is evidence of a serious SBCL bug.

This reduces the severity of this bug, rather than resolving it.
SBCL is not the only CL implementation in Debian.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1021636: RFS: lexicon/3.9.4-1~bpo11+1 [Team] -- CLI for manipulating DNS records on various DNS providers (Python 3)

[Phil Morrell]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lexicon". It is a trivial
backport (dch --bpo) but it does need to go through NEW:

 * Package name : lexicon
   Version  : 3.9.4-1~bpo11+1
 * URL  : https://github.com/AnalogJ/lexicon
 * License  : MIT/Expat
 * Vcs  : 
https://salsa.debian.org/python-team/packages/python-lexicon
   Section  : python

The source builds the following binary packages:

  python3-lexicon - Manipulate DNS records on various DNS providers (Python 3)
  lexicon - CLI for manipulating DNS records on various DNS providers (Python 3)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/lexicon/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/l/lexicon/lexicon_3.9.4-1~bpo11+1.dsc

Changes since the last upload:

 lexicon (3.9.4-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.
 .
 lexicon (3.9.4-1) unstable; urgency=medium
 .
   * Team upload.
 .
   [ Ondřej Nový ]
   * d/control: Update Vcs-* fields with new Debian Python Team Salsa
 layout.
 .
   [ Sandro Tosi ]
   * Use the new Debian Python Team contact name and address
 .
   [ Ana Custura ]
   * New upstream version 3.3.17
 .
   [ Harlan Lieberman-Berg ]
   * New upstream version 3.9.4 (Closes: #1005686)
   * Update dependencies in d/control
   * Bump S-V, dh
   * Update tests run.
   * Add Rules-Requires-Root
   * Switch to pyproject plugin for pybuild
   * Add lintian override for very long lines in test dir

Regards,
--
  Phil Morrell


signature.asc
Description: PGP signature

Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.

[Sean Whitton]

control: reassign -1 cl-ironclad
control: retitle -1 cl-ironclad: fails to compile against recent SBCL on 32-bit 
ARM architectures

I intend to resolve this bug by disabling the failing compilation.
SBCL upstream do not think there is evidence of a serious SBCL bug.

-- 
Sean Whitton

Bug#1020999: mirrors.hit.edu.cn: tracefile

[Tianyu Chen]

Hi,


o trace file:
   I notice there is no tracefile matching your site name 
mirrors.hit.edu.cn in

   http://mirrors.hit.edu.cn/debian/project/trace/


I've re-checked our mirror and the tracefile is now available.

http://mirrors.hit.edu.cn/debian/project/trace/

https://mirror-master.debian.org/status/mirror-info/mirrors.hit.edu.cn.html

Best regards,

Tianyu Chen



OpenPGP_0x546B245B5949269D_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017941: greenbone-security-assistant downloads source from the network

[Andreas Beckmann]

Followup-For: Bug #1017941

A similar case is src:nvda2speechd (#1021390) and the solution there was
to move the package to non-free.

Adrian Bunk wrote to #1021390:
> AFAIK accessing the network from the buildds is simply forbidden.
>
> And what your package does is even worse:
> It executes a script downloaded from the internet,
> compromising the security of the buildds.
>
> Whoever controls sh.rustup.rs could for example provide a special 
> version of the script for Debian buildds that tries to find and
> upload the private keys used on the buildds.

I don't know whether greenbone-security-assistant executes untrusted
code on the buildd, but ...

Adrian Bunk later wrote to #1021390:
> I think in its current state the package is anyway non-free since it 
> does not fulfill the DFSG for the contents it ships in its binary
> packages.

And I thinks that's a very valid point as well as the package being not
autobuildable.

You should explicitly mark it as XS-AutoBuild: no.


Andreas

Bug#1021634: rx-java: Upgrade to 3.1.2 needed to support Bazel 5.x

[Olek Wojnar]

Source: rx-java
Version: 3.0.7+ds-2
Severity: wishlist
Tags: newcomer

Dear Prospective Debian Bazel contributor,

This package needs to be updated for the Bazel 5.x release. This *should* be
a fairly straightforward process. If you are interested, please send an email
to our mailing list [1] where we will be happy to help you with any questions.
Feel free to also join our team on Salsa [2] and claim the package you want  
to contribute to on our Bazel 5 Upgrade Tracker [3].

Thanks in advance for your contribution!

-The Debian Bazel Team


[1] debian-ba...@lists.debian.org
[2] https://salsa.debian.org/bazel-team
[3] https://salsa.debian.org/bazel-team/meta/-/wikis/Bazel-5-Upgrade

Bug#1021633: grpc-java: Upgrade to 1.41.0 needed to support Bazel 5.x

[Olek Wojnar]

Source: grpc-java
Version: 1.26.0+ds-1
Severity: wishlist
Tags: help

Dear Prospective Debian Bazel contributor,

This package needs to be updated for the Bazel 5.x release. This will likely
*NOT* be a straightforward process. If you are interested, please send an email
to our mailing list [1] where we will be happy to help you with any questions.
Feel free to also join our team on Salsa [2] and claim the package you want  
to contribute to on our Bazel 5 Upgrade Tracker [3].

Thanks in advance for your contribution!

-The Debian Bazel Team


[1] debian-ba...@lists.debian.org
[2] https://salsa.debian.org/bazel-team
[3] https://salsa.debian.org/bazel-team/meta/-/wikis/Bazel-5-Upgrade

Bug#1021632: checker-framework-java: Upgrade to 3.2.0 needed to support Bazel 5.x

[Olek Wojnar]

Source: checker-framework-java
Version: 3.0.1+ds2-3
Severity: wishlist
Tags: newcomer

Dear Prospective Debian Bazel contributor,

This package needs to be updated for the Bazel 5.x release. This *should* be
a fairly straightforward process. If you are interested, please send an email
to our mailing list [1] where we will be happy to help you with any questions.
Feel free to also join our team on Salsa [2] and claim the package you want  
to contribute to on our Bazel 5 Upgrade Tracker [3].

Thanks in advance for your contribution!

-The Debian Bazel Team


[1] debian-ba...@lists.debian.org
[2] https://salsa.debian.org/bazel-team
[3] https://salsa.debian.org/bazel-team/meta/-/wikis/Bazel-5-Upgrade

Bug#1021631: google-auto-value-java: Upgrade to 1.8.2 needed to support Bazel 5.x

[Olek Wojnar]

Source: google-auto-value-java
Version: 1.7.2-2
Severity: wishlist
Tags: newcomer

Dear Prospective Debian Bazel contributor,

This package needs to be updated for the Bazel 5.x release. This *should* be
a fairly straightforward process. If you are interested, please send an email
to our mailing list [1] where we will be happy to help you with any questions.
Feel free to also join our team on Salsa [2] and claim the package you want  
to contribute to on our Bazel 5 Upgrade Tracker [3].

Thanks in advance for your contribution!

-The Debian Bazel Team


[1] debian-ba...@lists.debian.org
[2] https://salsa.debian.org/bazel-team
[3] https://salsa.debian.org/bazel-team/meta/-/wikis/Bazel-5-Upgrade

Bug#1021630: google-auto-common-java: Upgrade to 1.1.2 needed to support Bazel 5.x

[Olek Wojnar]

Source: google-auto-common-java
Version: 0.10-2
Severity: wishlist
Tags: newcomer

Dear Prospective Debian Bazel contributor,

This package needs to be updated for the Bazel 5.x release. This *should* be
a fairly straightforward process. If you are interested, please send an email
to our mailing list [1] where we will be happy to help you with any questions.
Feel free to also join our team on Salsa [2] and claim the package you want
to contribute to on our Bazel 5 Upgrade Tracker [3].

Thanks in advance for your contribution!

-The Debian Bazel Team


[1] debian-ba...@lists.debian.org
[2] https://salsa.debian.org/bazel-team
[3] https://salsa.debian.org/bazel-team/meta/-/wikis/Bazel-5-Upgrade

Bug#1021629: texinfo: with HTML output, @minus{} is converted to a hyphen instead of a real minus character

[Vincent Lefevre]

Package: texinfo
Version: 6.8-6
Severity: minor
Tags: upstream
Forwarded: https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00046.html

With HTML output, @minus{} is converted to a hyphen instead of
a real minus character (U+2212 MINUS SIGN).

The Texinfo manual says:

11.8.9 '@minus' (-): Inserting a Minus Sign
---

Use the '@minus{}' command to generate a minus sign.  In a fixed-width
font, this is a single hyphen, but in a proportional font, the symbol is
the customary length for a minus sign--a little longer than a hyphen,
shorter than an em-dash:
[...]

I don't know whether commit 9190ec13c30 applies only to lists or
fixes the general problem.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages texinfo depends on:
ii  libc6   2.35-1
ii  libtext-unidecode-perl  1.30-2
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  perl5.34.0-5
ii  perl-base [perlapi-5.34.0]  5.34.0-5
ii  tex-common  6.17

texinfo recommends no packages.

Versions of packages texinfo suggests:
ii  texlive-base   2022.20220923-1
ii  texlive-fonts-recommended  2022.20220923-1
ii  texlive-latex-base 2022.20220923-1
ii  texlive-plain-generic  2022.20220923-1

-- no debconf information

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

Bug#1021628: android-platform-tools: FTBFS: error: no template named 'function' in namespace 'std'

[Andreas Beckmann]

Package: android-platform-tools
Version: 33.0.1-1~exp9
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

android-platform-tools/experimental recently started to FTBFS.
The version in sid is not affected.

...
clang++ -c -o packages/modules/adb/client/auth.o 
packages/modules/adb/client/auth.cpp -g -O2 
-ffile-prefix-map=/build/android-platform-tools-33.0.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC -std=gnu++2a 
-Wexit-time-destructors -Wno-non-virtual-dto
r -Wno-unused-parameter -Wno-missing-field-initializers -Wvla  -Wdate-time 
-D_FORTIFY_SOURCE=2 -DNDEBUG -UDEBUG -fmessage-length=0 -fno-exceptions 
-fno-strict-aliasing -no-canonical-prefixes  -Wno-c99-designator 
-Wno-gnu-designator -Wno-gnu-folding-constant  -DPLATFORM_T
OOLS_VERSION='"33.0.1"' -DADB_HOST=1 -DADB_VERSION='"33.0.1-1~exp9"' 
-DANDROID_BASE_UNIQUE_FD_DISABLE_IMPLICIT_CONVERSION=1 -Ipackages/modules/adb 
-Ipackages/modules/adb/crypto/include 
-Ipackages/modules/adb/pairing_auth/include 
-Ipackages/modules/adb/pairing_connection/
include -Ipackages/modules/adb/proto -Ipackages/modules/adb/tls/include 
-Isystem/core/diagnose_usb/include -Isystem/core/include 
-Isystem/core/libcrypto_utils/include -Isystem/core/libcutils/include 
-Isystem/libbase/include -I/usr/include/android
...
In file included from packages/modules/adb/client/auth.cpp:35:
packages/modules/adb/tls/include/adb/tls/tls_connection.h:51:31: error: no 
template named 'function' in namespace 'std'
using CertVerifyCb = std::function;
 ~^
packages/modules/adb/tls/include/adb/tls/tls_connection.h:52:28: error: no 
template named 'function' in namespace 'std'
using SetCertCb = std::function;
  ~^
packages/modules/adb/tls/include/adb/tls/tls_connection.h:67:40: error: unknown 
type name 'CertVerifyCb'
virtual void SetCertVerifyCallback(CertVerifyCb cb) = 0;
   ^
packages/modules/adb/tls/include/adb/tls/tls_connection.h:76:41: error: unknown 
type name 'SetCertCb'
virtual void SetCertificateCallback(SetCertCb cb) = 0;
^
...
4 errors generated.
make[2]: *** [debian/system/libadb.mk:120: packages/modules/adb/client/auth.o] 
Error 1


Looks like a missing #include that is no longer included transitively.


Andreas


android-platform-tools_33.0.1-1~exp9.log.gz
Description: application/gzip

Bug#1020999: mirrors.hit.edu.cn: tracefile

[Tianyu Chen]

Hi,


Due to institute's security policy, directory listing is current 
unavailable on all unencrypted HTTP traffic.


The tracefile is still available with TLS.


Best regards,

Tianyu Chen


On 9/30/22 18:28, Julien Cristau wrote:

Package: mirrors
X-Debbugs-Cc: Harbin Institute of Technology Linux User Group 

User: mirr...@packages.debian.org
Usertags: mirror-problem

Hi,

I was checking some things in the Debian mirror universe and noticed
a problem with your mirror:

o trace file:
   I notice there is no tracefile matching your site name mirrors.hit.edu.cn in
   http://mirrors.hit.edu.cn/debian/project/trace/

   Please use our ftpsync script to mirror Debian.

   It should produce the trace files we require, and do the mirroring in a way
   that ensures the mirror is in a consistent state even during updates.

   http://mirrors.hit.edu.cn/debian/project/ftpsync/ftpsync-current.tar.gz

Cheers,
Julien - Debian mirrors team


OpenPGP_0x546B245B5949269D_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021627: RFS: widelands/2:1.0-4~bpo11+1 [Team] -- fantasy real-time strategy game

[Phil Morrell]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "widelands". It is a trivial
backport (dch --bpo) but it does need to go through NEW:

 * Package name : widelands
   Version  : 2:1.0-4~bpo11+1
 * URL  : http://www.widelands.org/
 * License  : Eris, GPL-2+, CC-BY-SA-3.0, Apache2.0, GPL-2, 
SIL-Open-Font-License
 * Vcs  : https://salsa.debian.org/games-team/widelands
   Section  : games

The source builds the following binary packages:

  widelands - fantasy real-time strategy game
  widelands-data - fantasy real-time strategy game (data files)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/widelands/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/w/widelands/widelands_1.0-4~bpo11+1.dsc

Changes since the last upload:

 widelands (2:1.0-4~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.
 .
 widelands (2:1.0-4) unstable; urgency=medium
 .
   * Team upload.
   * Source only upload.
 .
 widelands (2:1.0-3) unstable; urgency=medium
 .
   * Team upload.
   * Properly transit previously shipped font to symlink of packaged font.
 (Closes: #1018966)
 .
 widelands (2:1.0-2) unstable; urgency=medium
 .
   * Team upload.
   * Source-only no-change upload to enable migration to testing.
 .
 widelands (2:1.0-1) unstable; urgency=medium
 .
   * New upstream release: The 1.0 Release!!
 - Some highlights from the hundreds of changes:
   - A new tribe: the Amazons
   - An add-on system
   - A third frisians scenario
   - Dynamic tribe loading to speed up game loading
   - Targeting individual map objects for removal
   - Mute/unmute messages by buildings
   - Fully redesigned main menu
   - Configurable keyboard shortcuts
   - Enhanced keyboard and mousewheel support in the UI
   - Long-term stable Lua API for game content designers
 - Closes: #992626
   * Update the packaging for this new version
 - Bump the epoch to 2. Version 1:21 was corresponding to build21
   upstream, but now upstream version is 1.0, so bumping the
   epoch is unavoidable.
 - Update d/watch for this new numbering schema (Closes: #1005370)
 - Add a build-dep on libcurl4-gnutls-dev.
 - Refresh patches.
   * Fix lintian overrides
   * Add a patch to fix some spelling issues reported by Lintian
 .
 widelands (1:21-2) unstable; urgency=medium
 .
   [ Stephen Kitt ]
   * Remove Enrico Tassi from uploaders. Closes: #995561.
 .
   [ Martin Quinson ]
   * d/p/gcc-12: Fix FTBFS with gcc-12. Closes: #1013066.
   * Don't depend on fonts-lklug-sinhala as this font is not used anymore.
   * Depend on culmus-fancy to get TaameyFrankCLM fonts.
   - Bump Standards-Version to 4.6.1 -- no changes needed.

Regards,
--
  Phil Morrell


signature.asc
Description: PGP signature

Bug#1021626: ITP: qzxing -- Qt/QML wrapper library for the ZXing barcode image processing library.

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: qzxing
  Version : 3.3.0
  Upstream Author : Nikos Ftylitakis
* URL : https://github.com/ftylitak/qzxing/
* License : Apache-2.0
  Programming Lang: C++
  Description : Qt/QML wrapper library for the ZXing barcode image 
processing library.

 Qt/QML wrapper library for the ZXing barcode image processing library.
 .
 Supports barcode decoding for the following types:
 .
UPC-A
UPC-E
EAN-8
EAN-13
ITF
Code 39
Code 93
Code 128 (GS1)
Codabar
QR Code
Data Matrix
Aztec (beta)
PDF 417
 .
 Supports barcode encoding for the following types:
 .
   QR Code
 .
 This package will be maintained by Debian's UBports Packaging Team.

Bug#1021625: nvidia-cuda-toolkit: CVE-2022-34667

[Andreas Beckmann]

Source: nvidia-cuda-toolkit
Severity: important
Tags: security

https://nvidia.custhelp.com/app/answers/detail/a_id/5373

CVE-2022-34667  NVIDIA CUDA Toolkit SDK contains a stack-based buffer
overflow vulnerability in cuobjdump, where an unprivileged remote
attacker could exploit this buffer overflow condition by persuading a
local user to download a specially crafted corrupted file and execute
cuobjdump against it locally, which may lead to a limited denial of
service and some loss of data integrity for the local user.

Fixed in 11.8

Andreas

Bug#1021624: lxd: Global configuration /etc/lxc/config.yaml is ignored

[Enrique Garcia]

Package: lxd
Version: 5.0.1-2
Severity: normal
X-Debbugs-Cc: cqu...@arcor.de

According to documentation in /usr/share/doc/lxd/remotes.md, the file
/etc/lxc/config.yml can be used to store the configuration of remotes. However
it seems as this file would be ignored.
The file seems to be correct, since the following workarounds do work:
$ LXD_GLOBAL_CONF=/etc/lxc lxc remote list
$ LXD_CONF=/etc/lxc lxc remote list


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES:es
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxd depends on:
ii  adduser  3.129
ii  attr 1:2.5.1-1
ii  ca-certificates  20211016
ii  dnsmasq  2.86-1.1
ii  init-system-helpers  1.65.2
ii  libacl1  2.3.1-1
ii  libc62.35-1
ii  libcap2  1:2.44-1
ii  libdqlite0   1.11.1-1
ii  libgcc-s112.2.0-3
ii  liblxc-common1:5.0.1-1
ii  liblxc1  1:5.0.1-1
ii  libsqlite3-0 3.39.3-1
ii  libudev1 251.4-3
ii  lxcfs5.0.0-1
ii  lxd-client   5.0.1-2
ii  rsync3.2.6-4
ii  squashfs-tools   1:4.5.1-1
ii  uidmap   1:4.11.1+dfsg1-2
ii  xz-utils 5.2.5-2.1

Versions of packages lxd recommends:
ii  apparmor  3.0.7-1

Versions of packages lxd suggests:
pn  btrfs-progs 
pn  ceph-common 
ii  gdisk   1.0.9-2
ii  lvm22.03.16-1
pn  lxd-agent   
ii  lxd-tools   5.0.1-2
pn  tomoyo-tools
pn  zfsutils-linux  

-- no debconf information

Bug#1016632: firmware-atheros: Missing binary in firmware-atheros package

[Ben Hutchings]

Control: reassign -1 src:linux 5.18.14-1
Control: retitle -1 ath10k: Spurious warning for missing calibration file

On Thu, 04 Aug 2022 10:46:05 +0200 marc  wrote:
> Package: firmware-atheros
> Version: 20210818-1
> Severity: normal
> X-Debbugs-Cc: m...@gallifrey-blr.fr
> 
> Dear Maintainer,
> 
> On the boot of my laptop (DELL Latitude 7480) I have one error
message.
> Here the result of "dmesg | grep -iE 'firmware|microcode'" :
[...]
> [    5.077307] ath10k_pci :02:00.0: firmware: failed to load ath10k/pre-
> cal-pci-:02:00.0.bin (-2)
> [    5.077342] firmware_class: See https://wiki.debian.org/Firmware for
> information about missing firmware
> [    5.077384] ath10k_pci :02:00.0: firmware: failed to load ath10k/cal-
> pci-:02:00.0.bin (-2)
[...]
> After some research on internet it appears some optional binary are
missing
> from firmware-atheros package.
> I don't have issues with my wifi card. Apparently it works.

I don't think there's anything we can provide.  This file seems like it
would have to be created for your specific computer since the name
includes the card's PCI address.  So this is a bug in the driver;
possibly our fault as we change the way missing firmware is logged.

Ben.

-- 
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.


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

Bug#1020500: glibc: flaky autopkgtest on armel: multiple different failures

[Aurelien Jarno]

Hi Paul,

A small update on this bug. Now that glibc 2.35-3 migrated to testing,
the only unsolved issue is that one:

On 2022-10-07 21:14, Paul Gevers wrote:
> On 07-10-2022 20:55, Aurelien Jarno wrote:
> > > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/23501044/log.gz
> > > 
> > > --
> > > FAIL: elf/tst-debug1
> > > original exit status 1
> > > Didn't expect signal from child: got `Bus error'
> > > --
> > 
> > I have not been able to reproducible this bug after 1M tests on
> > amdahl.d.o, an RPI3 (running an arm64 kernel) and a STM32MP1 board
> > (armhf). Would it be possible to give more details, like any
> > corresponding dmesg entry to have a better idea of the issue?
> 
> I'll try to have a look if I spot this again. The original dmesg is gone by
> now.

Cheers
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#1021623: inkscape: doesn't print masked images

[Jakub Wilk]

Package: inkscape
Version: 1.2.1+ds-1+b1

When I try to print the attached SVG file (which is a minimized version 
of real-world PDF document), I get an empty page.



-- System Information:
Architecture: i386

Versions of packages inkscape depends on:
ii  librsvg2-common2.54.5+dfsg-1
ii  python33.10.6-1
ii  lib2geom1.1.0  1.2-1
ii  libatkmm-1.6-1v5   2.28.3-1
ii  libboost-filesystem1.74.0  1.74.0-17
ii  libc6  2.35-3
ii  libcairo-gobject2  1.16.0-6
ii  libcairo2  1.16.0-6
ii  libcairomm-1.0-1v5 1.14.4-1
ii  libcdr-0.1-1   0.1.6-2+b1
ii  libfontconfig1 2.13.1-4.5
ii  libfreetype6   2.12.1+dfsg-3
ii  libgc1 1:8.2.2-3
ii  libgcc-s1  12.2.0-5
ii  libgdk-pixbuf-2.0-02.42.9+dfsg-1
ii  libglib2.0-0   2.74.0-2
ii  libglibmm-2.4-1v5  2.66.5-1
ii  libgomp1   12.2.0-5
ii  libgsl27   2.7.1+dfsg-3+b1
ii  libgspell-1-2  1.11.1-1
ii  libgtk-3-0 3.24.34-3
ii  libgtkmm-3.0-1v5   3.24.7-1
ii  libharfbuzz0b  5.2.0-2
ii  libjpeg62-turbo1:2.1.2-1+b1
ii  liblcms2-2 2.13.1-1+b1
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.3+b3
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangocairo-1.0-01.50.10+ds-1
ii  libpangoft2-1.0-0  1.50.10+ds-1
ii  libpangomm-1.4-1v5 2.46.3-1
ii  libpng16-161.6.38-2
ii  libpoppler-glib8   22.08.0-2.1
ii  libpoppler123  22.08.0-2.1
ii  libpotrace01.16-2
ii  libreadline8   8.2-1
ii  librevenge-0.0-0   0.0.4-6+b1
ii  libsigc++-2.0-0v5  2.10.8-1
ii  libsoup2.4-1   2.74.2-3
ii  libstdc++6 12.2.0-5
ii  libvisio-0.1-1 0.1.7-1+b2
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.8.1-2
ii  libxml22.9.14+dfsg-1+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.11.dfsg-4.1


--
Jakub Wilk

Bug#1014729: glibc 2.34 breaks wcc autopkgtest on amd64: open: Invalid argument

[Aurelien Jarno]

control: forwarded -1 https://github.com/endrazine/wcc/pull/39
control: tag -1 + patch

On 2022-07-12 12:46, Michael Hudson-Doyle wrote:
> On Tue, 12 Jul 2022 at 04:30, Aurelien Jarno  wrote:
> 
> > On 2022-07-11 10:06, Michael Hudson-Doyle wrote:
> > > It looks like a no-change rebuild fixed this in Ubuntu fwiw.
> >
> > Thanks, I confirm that in Debian too. Do you have an idea why? It could
> > be a missing or too loose dependency.
> >
> 
> No. I got as far as reading
> https://github.com/endrazine/wcc/blob/master/README.md and then was
> completely unsurprised that it depends on the details of everything. It
> would probably be quite fun to dig into why it's failing but I don't really
> have the time for that today.

This issue is due to the merge of libdl.so into libc.so. This makes wsh
to try to load unused weak symbols, which results in dlsym() to return
NULL. And that is not properly handled by wsh.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#932047: lightdm: greeter session support for elogind

[Sam Hartman]

> "Yves-Alexis" == Yves-Alexis Perez  writes:


I think we want something there that allows people to get third-party
packages into the pam config.
If common-session isn't going to be good enough, then I guess we'd need
to create something on the PAM side.
But let's explore whether common-session is good enough, because it does
look like other display managers have similar architecture and manage to
use common-session.



Here are my thoughts on testing common-session in the greeter config:

* Take a look at how things appear in logind--does the greeter appear as
  a session?  If so does anything break because of that?  (Withd Gnome,
  the greeter does not appear to appear in loginctl list-sessions)

* What selinux context do things appear in.  This only matters if
  selinux is already in your testing structure

* Does the structure  of keyrings look like you expect.

* Do you end up with a systemd for the greeter user (assuming you are
using systemd).  If so, do you want one?

My suspicion is that since this appears to be working for other display
managers, it's all fine.
But those are the areas where trouble is most likely to show up.

Bug#1021622: libwxsqlit3-3.0-dev: not coinstallable

[Sebastian Ramacher]

Package: libwxsqlite3-3.0-dev
Version: 3.4.1~dfsg-8
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

wxsqlite3 is currently unable to migrate to testing because
libwxsqlite3-3.0-dev is not installable.

$ apt install libwxsqlite3-3.0-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libwxsqlite3-3.2-dev : Breaks: libwxsqlite3-3.0-dev but 3.4.1~dfsg-8 is to be 
installed
E: Unable to correct problems, you have held broken packages

Cheers
-- 
Sebastian Ramacher

Bug#1021621: RM: nvda2speechd [arm64 armel armhf mips64el mipsel ppc64el s390x] -- ROM; will not be built by hand

[Samuel Thibault]

Package: ftp.debian.org
Severity: normal

Hello,

As discussed in 1021390, the nvda2speechd source package should not be
built on buildds since it uses external rust resources. I'll thus build
it by hand on my box. I don't plan to cross-build it beyond i386 and
amd64, so please remove the builds that happened to be done on buildds
and which I will not update.

Thanks,
Samuel

Bug#1021620: openssl: CVE-2022-3358

[Salvatore Bonaccorso]

Source: openssl
Version: 3.0.5-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.0.5-2

Hi,

The following vulnerability was published for openssl.

CVE-2022-3358[0]:
| OpenSSL supports creating a custom cipher via the legacy
| EVP_CIPHER_meth_new() function and associated function calls. This
| function was deprecated in OpenSSL 3.0 and application authors are
| instead encouraged to use the new provider mechanism in order to
| implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly
| handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(),
| EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as
| other similarly named encryption and decryption initialisation
| functions). Instead of using the custom cipher directly it incorrectly
| tries to fetch an equivalent cipher from the available providers. An
| equivalent cipher is found based on the NID passed to
| EVP_CIPHER_meth_new(). This NID is supposed to represent the unique
| NID for a given cipher. However it is possible for an application to
| incorrectly pass NID_undef as this value in the call to
| EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL
| encryption/decryption initialisation function will match the NULL
| cipher as being equivalent and will fetch this from the available
| providers. This will succeed if the default provider has been loaded
| (or if a third party provider has been loaded that offers this
| cipher). Using the NULL cipher means that the plaintext is emitted as
| the ciphertext. Applications are only affected by this issue if they
| call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in
| a call to an encryption/decryption initialisation function.
| Applications that only use SSL/TLS are not impacted by this issue.
| Fixed in OpenSSL 3.0.6 (Affected 3.0.0-3.0.5).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-3358
https://www.cve.org/CVERecord?id=CVE-2022-3358
[1] https://www.openssl.org/news/secadv/20221011.txt

Regards,
Salvatore

Bug#919914: gnome-tweaks now equates "don't suspend on lid close" with "don't lock on lid close" (security issue)

[Jeremy Bicha]

Control: severity -1 important

Let's downgrade.

Thank you,
Jeremy Bicha

On Tue, Oct 11, 2022 at 4:09 PM Paul Gevers  wrote:
>
> Hi all,
>
> I'm going to try and summarize what I believe is the situation of this bug.
>
> 1) There's a patch upstream for a long time already, however it's not
> merged.
> 2) The Debian maintainer is reluctant to apply the patch without
> upstream applying it *or* consensus in Debian that it's the right
> thing to do.
> 3) I don't believe consensus has been reached.
>
> As a result, without a call from authorities¹ this RC bug remains
> stalled. At this moment, as a member of the Release Team, I'll say that
> I'd like to see this bug resolved (patch applied, closed+wontfix or
> downgraded), but we'll not hold up the bookworm release if it's not.
>
> Paul
>
> ¹ the maintainers, the bug reporter or the Release Team

Bug#1021619: RFP: python3-lazy-loader -- load subpackages and functions on demand

[Yaroslav Halchenko]

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

* Package name: python3-lazy-loader
  Version : 0.1
  Upstream Author : Jarrod Millman 
* URL : https://github.com/scientific-python/lazy_loader
* License : BSD-3
  Programming Lang: Python-3
  Description : load subpackages and functions on demand

lazy_loader makes it easy to load subpackages and functions on demand.

I was told that used in skimage and networkx already.  Checked that introduced
in networkx networkx-2.7rc1~42 bundled inside the source code.  In debian we
still have 2.6.3, so with the next update it would get it.

lazy-loader is considered for adoption in other projects which would eventually
get into Debian as well.

Bug#1021618: node-xmldom: CVE-2022-37616

[Salvatore Bonaccorso]

Source: node-xmldom
Version: 0.7.5-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/xmldom/xmldom/issues/436
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-xmldom.

CVE-2022-37616[0]:
| A prototype pollution vulnerability exists in the function copy in
| dom.js in the xmldom (published as @xmldom/xmldom) package before
| 0.8.3 for Node.js via the p variable.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-37616
https://www.cve.org/CVERecord?id=CVE-2022-37616
[1] https://github.com/xmldom/xmldom/issues/436

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1021617: RM: obs-text-slideshow -- ROM; FTBFS, dead upstream

[Eriberto Mota]

Opsss... Incompatible with obs-studio 28.0.1, not 28.1.2.

Bug#1021616: obs-text-slideshow: FTBFS with OBS 28

[Eriberto Mota]

Opsss... obs-studio 28.0.1, not 28.1.2.

Bug#987602: ca-certificates bug 987602: ca-certificates-java,default-jre-headless,openjdk-11-jre-headless: get rid of the circular dependency

[Paul Gevers]

Hi all,

On Fri, 19 Mar 2021 12:24:03 +0100 Matthias Klose  wrote:

I committed Andreas' proposed changes to ca-certificates-java, however that
requires a corresponding upload to ca-certificates.


The upload of ca-certificates-java happened. Julien had objections to 
some of the changes in the MR [1], quoting:

"""
I'd rather not change the versioning scheme.

I have no plans to upgrade the bundle in stable, but if that is a worry 
then there can be a virtual package to track changes that affect the 
-java package.

"""

Can somebody with a better understanding of the situation comment on 
what *needs* to be done to fix this bug (and are not nice to haves)? (A 
breaks? more?) @Julien, are all commits in the MR acceptable *except* 
the versioning one?


Paul

[1] https://salsa.debian.org/debian/ca-certificates/-/merge_requests/6


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021614: notmuch: RFC2047-encoded special characters in display-name show up unquoted

[Jakub Wilk]

Attaching the reprocucer scripts, which somehow got lost in transport!?

--
Jakub Wilk
#!/bin/bash
set -e -u
tmpdir="$(mktemp -d)"
export NOTMUCH_DATABASE="$tmpdir"
notmuch --config '' new > /dev/null
mkdir -p "$NOTMUCH_DATABASE"/{cur,new,tmp}
notmuch --config '' insert > /dev/null
notmuch --config '' show '*' | grep ^From:
rm -rf "tmpdir"
#!/usr/bin/python3

import sys

import gi
gi.require_version('GMime', '3.0')
from gi.repository import GMime
GMime.init()

stream = GMime.StreamPipe.new(sys.stdin.fileno())
parser = GMime.Parser.new_with_stream(stream)
msg = parser.construct_message()
addrs = msg.get_from()
addrs = addrs.to_string(GMime.FormatOptions(), True)
print('From:', addrs)

Bug#1021617: RM: obs-text-slideshow -- ROM; FTBFS, dead upstream

[Joao Eriberto Mota Filho]

Package: ftp.debian.org
Severity: normal

The current source code of obs-text-slideshow FTBFS with obs-studio 28.1.2.
See #1021616.

The upstream declares the development as abandoned[1].

[1] https://github.com/jbwong05/obs-text-slideshow/issues/38

Regards,

Eriberto

Bug#1021616: obs-text-slideshow: FTBFS with OBS 28

[Joao Eriberto Mota Filho]

Package: obs-text-slideshow
Version: 1.5.2-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The current source code on Debian FTBFS with obs-studio 28.1.2.

dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake
-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None
-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles"
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
returned exit code 1
make: *** [debian/rules:11: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui failed

Eriberto

Bug#1021615: libimlib2: tga loading error

[Edgar Yllescas]

Package: libimlib2
Version: 1.7.4-2
Severity: normal
Tags: patch

imlib2 fails to load some tga images, the bug was first discovered and
determined on: https://codeberg.org/nsxiv/nsxiv/issues/378

it was also discovered that the issue affects multiple versions of imlib2
and may have been present since imlib2 first supported tga images, the bug
does affect the versions of imlib2 from debian stable up to the latest upstream
release at the time of writing (1.9.1), the patch has already been merged into
the upstream, on the meantime here is the patch inlined:


>From 322582c4d02d9ed98badd28218d54c86683d80b2 Mon Sep 17 00:00:00 2001
From: NRK 
Date: Sun, 9 Oct 2022 12:56:57 +0600
Subject: [PATCH] TGA loader: fix indexing in tgaflip

`y` needs to be multiplied by the width, not the height.

ref: https://codeberg.org/nsxiv/nsxiv/issues/378
---
 src/modules/loaders/loader_tga.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/modules/loaders/loader_tga.c
b/src/modules/loaders/loader_tga.c
index 992a8d8..e0312fa 100644
--- a/src/modules/loaders/loader_tga.c
+++ b/src/modules/loaders/loader_tga.c
@@ -481,9 +481,9 @@ tgaflip(uint32_t * in, int w, int h, int fliph, int flipv)
 x2 = fliph ? w - 1 : 0;
 for (x = 0; x < nx; x++, x2 += dx)
   {
- tmp = in[y * h + x];
- in[y * h + x] = in[y2 * h + x2];
- in[y2 * h + x2] = tmp;
+ tmp = in[y * w + x];
+ in[y * w + x] = in[y2 * w + x2];
+ in[y2 * w + x2] = tmp;
   }
  }
 }
--
2.35.1



-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libimlib2 depends on:
ii  libbz2-1.0   1.0.8-5
ii  libc62.34-3
ii  libfreetype6 2.12.1+dfsg-3
ii  libgif7  5.2.1-2.5
ii  libid3tag0   0.15.1b-14
ii  libjpeg62-turbo  1:2.1.2-1
ii  libpng16-16  1.6.37-5
ii  libtiff5 4.4.0-4
ii  libwebp7 1.2.2-2+b1
ii  libx11-6 2:1.8.1-2
ii  libx11-xcb1  2:1.8.1-2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1
ii  zlib1g   1:1.2.11.dfsg-4

libimlib2 recommends no packages.

libimlib2 suggests no packages.

-- no debconf information

Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT

[Aurelien Jarno]

On 2022-10-11 22:06, Johannes Schauer Marin Rodrigues wrote:
> Hi,
> 
> Quoting Aurelien Jarno (2022-10-11 21:55:47)
> > Ok, thanks for the details, I'll look at the patch.
> 
> thank you!
> 
> > Anyway that makes me wonder if we should ship that directory in the libc6

Note that it should be the libc-bin package, not the libc6 one.

> > package, just like apt ships /var/cache/apt and debconf ships
> > /var/cache/debconf.
> 
> In our DPKG_ROOT CI we compare a chroot tarball created the normal way with a
> tarball created with dpkg run with --force-script-chrootless. We added an
> additional mode that tries out if this whole thing also works when run without
> being the root user but run as the normal user under fakeroot and then we 
> found
> the missing /var/cache/ldconfig directory.
> 
> So if libc6 would ship that directory, I think my patch would still be needed.
> Because if `ldconfig -r` doesn't use the directory, then the last modification
> timestamps will differ between a chroot created the normal way and a chroot
> created without actually ever running chroot() (the DPKG_ROOT way).

From what I have understood from your explanation, if the directory
exists chroot_canon() will work, so `ldconfig -r` will be able to create
the aux-cache file in it.

I still think that the bug should be fixed on the glibc upstream side,
but that would allow to easy fix it on the package side, and it's
probably better to have a closer match of the dpkg database and the file
system.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#919914: gnome-tweaks now equates "don't suspend on lid close" with "don't lock on lid close" (security issue)

[Paul Gevers]

Hi all,

I'm going to try and summarize what I believe is the situation of this bug.

1) There's a patch upstream for a long time already, however it's not
   merged.
2) The Debian maintainer is reluctant to apply the patch without
   upstream applying it *or* consensus in Debian that it's the right
   thing to do.
3) I don't believe consensus has been reached.

As a result, without a call from authorities¹ this RC bug remains 
stalled. At this moment, as a member of the Release Team, I'll say that 
I'd like to see this bug resolved (patch applied, closed+wontfix or 
downgraded), but we'll not hold up the bookworm release if it's not.


Paul

¹ the maintainers, the bug reporter or the Release Team


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Aurelien Jarno (2022-10-11 21:55:47)
> Ok, thanks for the details, I'll look at the patch.

thank you!

> Anyway that makes me wonder if we should ship that directory in the libc6
> package, just like apt ships /var/cache/apt and debconf ships
> /var/cache/debconf.

In our DPKG_ROOT CI we compare a chroot tarball created the normal way with a
tarball created with dpkg run with --force-script-chrootless. We added an
additional mode that tries out if this whole thing also works when run without
being the root user but run as the normal user under fakeroot and then we found
the missing /var/cache/ldconfig directory.

So if libc6 would ship that directory, I think my patch would still be needed.
Because if `ldconfig -r` doesn't use the directory, then the last modification
timestamps will differ between a chroot created the normal way and a chroot
created without actually ever running chroot() (the DPKG_ROOT way).

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1021614: notmuch: RFC2047-encoded special characters in display-name show up unquoted

[Jakub Wilk]

Package: notmuch
Version: 0.37-1

The attached message has a bunch of RFC-2047-encoded special characters 
in the display-name part of the From field:


   $ grep ^From: weird-from.eml
   From: =?UTF-8?Q?=3Cfoo=40example.org=3E=2C?= 

When you show this message in notmuch, the special characters show up 
unquoted (and unencoded), so that it looks like there are two addresses 
in the From field:


   $ ./notmuch-show-from < weird-from.eml
   From: , 

I initially thought this is a GMime bug, but it seems GMime gets this 
right:


   $ ./gmime-show-from < weird-from.eml
   From: "," 


-- System Information:
Architecture: i386

Versions of packages notmuch depends on:
ii  libnotmuch5 0.37-1
ii  libc6   2.35-3
ii  libglib2.0-02.74.0-2
ii  libgmime-3.0-0  3.2.13+dfsg-2
ii  libtalloc2  2.3.4-1
ii  zlib1g  1:1.2.11.dfsg-4.1

--
Jakub Wilk
--- Begin Message ---
--- End Message ---

Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT

[Aurelien Jarno]

Hi,

On 2022-10-11 21:50, Johannes Schauer Marin Rodrigues wrote:
> Hi,
> 
> Quoting Aurelien Jarno (2022-10-11 21:41:05)
> > On 2022-10-11 07:57, Johannes Schauer Marin Rodrigues wrote:
> > > Package: glibc
> > > Version: 2.35-3
> > > Severity: normal
> > > Tags: patch
> > > 
> > > Hi,
> > > 
> > > when running libc-bin.postinst with DPKG_ROOT non-empty, ldconfig from
> > > the outside is used to operate on the chroot and thus ldconfig will
> > > never create the empty /var/cache/ldconfig directory inside the chroot.
> > 
> > I don't get why this is needed. The point of calling ldconfig -r is to
> > create that directory and create the aux-cache file in it. In my tests
> > ldconfig does create that directory properly when ran with -r.
> > 
> > > Please consider creating that directory if DPKG_ROOT is non-empty.
> > 
> > Even if it ends up that in some conditions yet to be found, the
> > directory is not created, this doesn't seems correct. This means that
> > aux-cache file is also not created, which is more problematic.
> 
> I now have a much better understanding about what is happening and filed this
> patch:
> 
> https://sourceware.org/pipermail/libc-alpha/2022-October/142592.html
> 
> The problem occurs only if the opt_chroot variable is not NULL. This happens
> when you pass -r but the chroot() call fails, for example because you are
> running as an unprivileged user with fakeroot. In that case, chroot_canon()
> will return NULL because /var/cache/ldconfig doesn't exist in the chroot yet.
> This leads to aux_cache_file being set to NULL and that means that in the end
> save_aux_cache() doesn't get called.

Ok, thanks for the details, I'll look at the patch.

Anyway that makes me wonder if we should ship that directory in the
libc6 package, just like apt ships /var/cache/apt and debconf ships
/var/cache/debconf.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#1019757: perl: Subroutine JSON::PP::Boolean::(-- redefined with 5.36

[Niko Tyni]

Control: tag -1 patch fixed-upstream
Control: forwarded -1 https://github.com/makamaka/JSON-PP/pull/79

On Thu, Sep 29, 2022 at 10:35:29PM +0300, Niko Tyni wrote:
> On Wed, Sep 14, 2022 at 07:57:01PM +0100, Niko Tyni wrote:
> > Package: perl
> > Version: 5.36.0-2
> > User: debian-p...@lists.debian.org
> > Usertags: perl-5.36-transition
> > Forwarded: https://github.com/Perl/perl5/issues/20246
> > X-Debbugs-Cc: libmetacpan-client-p...@packages.debian.org
> > Control: affects -1 libmetacpan-client-perl
> > Control: block 1019353 with -1
> > 
> > This warns with Perl >= 5.36:
> > 
> >   % perl -we 'use Cpanel::JSON::XS (); use JSON::PP'
> >   Subroutine JSON::PP::Boolean::(0+ redefined at 
> > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
> >   Subroutine JSON::PP::Boolean::(++ redefined at 
> > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
> >   Subroutine JSON::PP::Boolean::(-- redefined at 
> > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
> > 
> > I have filed https://github.com/makamaka/JSON-PP/issues/76 against
> > JSON::PP about this, but it's currently unclear if it should rather be
> > "fixed" on the Perl side ( https://github.com/Perl/perl5/issues/20246 ).

> I've also prodded the upstream ticket a bit, hoping that somebody would
> determine if it needs to be fixed in Perl or JSON::PP.

JSON::PP got fixed upstream in 4.12 with 
https://github.com/makamaka/JSON-PP/pull/79

The fix is already in the separate libjson-pp-perl package (thanks Gregor!)
I think I'll cherry-pick the patch for the version in 5.36 core as well.
Probably not worth fiddling with the Breaks version though. 
-- 
Niko

Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Aurelien Jarno (2022-10-11 21:41:05)
> On 2022-10-11 07:57, Johannes Schauer Marin Rodrigues wrote:
> > Package: glibc
> > Version: 2.35-3
> > Severity: normal
> > Tags: patch
> > 
> > Hi,
> > 
> > when running libc-bin.postinst with DPKG_ROOT non-empty, ldconfig from
> > the outside is used to operate on the chroot and thus ldconfig will
> > never create the empty /var/cache/ldconfig directory inside the chroot.
> 
> I don't get why this is needed. The point of calling ldconfig -r is to
> create that directory and create the aux-cache file in it. In my tests
> ldconfig does create that directory properly when ran with -r.
> 
> > Please consider creating that directory if DPKG_ROOT is non-empty.
> 
> Even if it ends up that in some conditions yet to be found, the
> directory is not created, this doesn't seems correct. This means that
> aux-cache file is also not created, which is more problematic.

I now have a much better understanding about what is happening and filed this
patch:

https://sourceware.org/pipermail/libc-alpha/2022-October/142592.html

The problem occurs only if the opt_chroot variable is not NULL. This happens
when you pass -r but the chroot() call fails, for example because you are
running as an unprivileged user with fakeroot. In that case, chroot_canon()
will return NULL because /var/cache/ldconfig doesn't exist in the chroot yet.
This leads to aux_cache_file being set to NULL and that means that in the end
save_aux_cache() doesn't get called.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1021364: RFS: ghostwriter/2.2.0-1 [RC] -- Distraction-free, themeable Markdown editor

[Nicholas D Steeves]

Sebastien Chavaux  writes:

> it's a bit of a mess, I made changes, in debian/copyright, unfortunately it
> makes build errors:
> *** No rule to make target '3rdparty/MathJax/bin/startup.js', needed by
> 'build/release/qrc_resources.cpp'.
> Stop.
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory '/build/ghostwriter-2.1.6+dfsg'
> dh_auto_build: error: make -j6 returned exit code 2
> make: *** [debian/rules:6: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2
> I: copying local configuration
> E: Failed autobuilding of package
>
>

Isn't libjs-mathjax MathJax2, and doesn't Ghostwriter needs MathJax3,
which is incompatible with MathJax2?

  
https://github.com/KDE/ghostwriter/blob/master/3rdparty/MathJax/src/package.json

Here is the RFP bug for MathJax3 for anyone who is interested in
packaging this important javascript library:
https://bugs.debian.org/950424

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1021577: libc-bin.postinst: please create /var/cache/ldconfig with DPKG_ROOT

[Aurelien Jarno]

Hi,

On 2022-10-11 07:57, Johannes Schauer Marin Rodrigues wrote:
> Package: glibc
> Version: 2.35-3
> Severity: normal
> Tags: patch
> 
> Hi,
> 
> when running libc-bin.postinst with DPKG_ROOT non-empty, ldconfig from
> the outside is used to operate on the chroot and thus ldconfig will
> never create the empty /var/cache/ldconfig directory inside the chroot.

I don't get why this is needed. The point of calling ldconfig -r is to
create that directory and create the aux-cache file in it. In my tests
ldconfig does create that directory properly when ran with -r.

> Please consider creating that directory if DPKG_ROOT is non-empty.

Even if it ends up that in some conditions yet to be found, the
directory is not created, this doesn't seems correct. This means that
aux-cache file is also not created, which is more problematic.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1021612: ephoto: fails to load single image file

[Gary M Witscher]

Package: ephoto
Version: 1.6.0-1
Severity: normal
X-Debbugs-Cc: g...@witscher.us

Dear Maintainer,

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

   * What led up to the situation?
When selecting an image to view/edit that happens to be in
the Pictures directory I needed to manualy search through that
directory for the image I wanted becaue ephoto loads the first
image from that directory. (which can be hundreds of
images).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
ephoto --help shows a provision for loading a directory
or a file. The file load does not work.

   * What was the outcome of this action?
When selecting an image to view/edit ephoto shows the
first image fom the directory where that image is located.

   * What outcome did you expect instead?
When selecting an image to view/edit I expected that image
to load.

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


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 ephoto depends on:
ii  libc6   2.35-1
ii  libecore-con1   1.26.3-1
ii  libecore-evas1  1.26.3-1
ii  libecore-file1  1.26.3-1
ii  libecore-ipc1   1.26.3-1
ii  libecore1   1.26.3-1
ii  libedje11.26.3-1
ii  libeet1 1.26.3-1
ii  libefreet-bin   1.26.3-1
ii  libefreet1a 1.26.3-1
ii  libeina1a   1.26.3-1
ii  libeio1 1.26.3-1
ii  libelementary1  1.26.3-1
ii  libevas11.26.3-1

ephoto recommends no packages.

ephoto suggests no packages.

-- no debconf information

Bug#1021502: lintian: incorrectly complains about debian-news-entry-has-unknown-version

[Niels Thykier]

Control: tags 1021608 wontfix

Axel Beckert:

[...]
Control: retitle -3 debhelper: Revert change to trim changelog.Debian.gz by 
default
Control: severity -3 wishlist

[...]


Hi Axel,

I note you have cloned a bug for doing a revert of the automatic 
trimming with an email that I interpreted as a interest in a permanent 
revert.


I am perfectly open towards the current implementation having bugs - and 
we can discuss whether some of them are bad enough to warrant a timely 
solution or *temporary* revert.


However, be advised that the change to introduce automatic trimming was 
discussed on debian-devel and the consensus of that mail thread was to 
my understand that we should enable automatic trimming.  Therefore, I am 
now wontfix'ing #1021608 on a conceptual basis.  If you with #1021608 
wanted to a temporary revert, feel free to remove the wontfix tag again.


If you disagree the automatic trimming in general, I will require that 
you have ensured that there is project wide consensus or the tech-ctte 
behind that revert.


Thanks,
~Niels

Bug#1015800: ?installed behaviour

[Phil Morrell]

Another example I came across today, "list all packages which are
installed from bullseye-backports" (originally using ?narrow, but it's
not needed). I was surprised that ?installed was listed under the
"PACKAGE PATTERNS" heading in the manpage.

$ aptitude search '?any-version(?installed ?origin(Backports))' | wc -l
10
$ apt list '?any-version(?installed ?origin(Backports))' | wc -l
252


signature.asc
Description: PGP signature

Bug#1021611: GuestStore and Guest Data Publisher plugins needed

[Bryce Harrington]

Source: open-vm-tools
Severity: wishlist

The GuestStore and Guest Data Publisher plugins (libguestStore.so and
libgdb.so respectively) are not being installed, but upstream intends
them to be included with the open-vm-tools package, as they're part of
the vmtoolsd service process.

This is also reported to Ubuntu:
  https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1992501

-- 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)
Foreign Architectures: i386

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

Bug#1021555: blueman: reverse tethering is broken with "local services" activated

[Damien BRUCKER]

Hello,

Yes, it's correct.

Here are the results of the following commands:

damien@damien-esprimop2560:~$ sudo iptables -t nat -L POSTROUTING
Chain POSTROUTING (policy ACCEPT)
target             prot opt source destination
MASQUERADE      all  --  10.89.114.0/24   anywhere

damien@damien-esprimop2560:~$ sudo iptables -t filter -L FORWARD
Chain FORWARD (policy ACCEPT)
target prot    opt source   destination
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere

damien@damien-esprimop2560:~$ cat /proc/sys/net/ipv4/ip_forward
1
damien@damien-esprimop2560:~$ ls /proc/sys/net/ipv4/conf/*/forwarding
/proc/sys/net/ipv4/conf/all/forwarding 
/proc/sys/net/ipv4/conf/default/forwarding 
/proc/sys/net/ipv4/conf/lo/forwarding
/proc/sys/net/ipv4/conf/bnep0/forwarding 
/proc/sys/net/ipv4/conf/enp3s0/forwarding 
/proc/sys/net/ipv4/conf/pan1/forwarding

damien@damien-esprimop2560:~$ cat /proc/sys/net/ipv4/conf/*/forwarding
1
1
1
1
1
1



Extract from /var/log/syslog:

Oct 11 20:43:41 damien-esprimop2560 systemd[1]: Starting Network Manager 
Script Dispatcher Service...
Oct 11 20:43:41 damien-esprimop2560 dbus-daemon[453]: [system] 
Successfully activated service 'org.freedesktop.nm_dispatcher'
Oct 11 20:43:41 damien-esprimop2560 systemd[1]: Started Network Manager 
Script Dispatcher Service.
Oct 11 20:43:41 damien-esprimop2560 NetworkManager[454]:   
[1665513821.1098] device (pan1): state change: ip-check -> secondaries 
(reason 'none', sys-iface-state: 'external')
Oct 11 20:43:41 damien-esprimop2560 NetworkManager[454]:   
[1665513821.1101] device (pan1): state change: secondaries -> activated 
(reason 'none', sys-iface-state: 'external')
Oct 11 20:43:41 damien-esprimop2560 NetworkManager[454]:   
[1665513821.1114] device (pan1): Activation: successful, device activated.
Oct 11 20:43:41 damien-esprimop2560 dnsmasq[4178]: démarrage avec le DNS 
désactivé (version 2.85)
Oct 11 20:43:41 damien-esprimop2560 dnsmasq[4178]: options à la 
compilation : IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua 
TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile
Oct 11 20:43:41 damien-esprimop2560 dnsmasq-dhcp[4178]: DHCP, plage 
d'adresses IP 10.89.114.2 -- 10.89.114.254, durée de bail 1h
Oct 11 20:43:41 damien-esprimop2560 dnsmasq-dhcp[4178]: DHCP, sockets 
bound exclusively to interface pan1
Oct 11 20:43:45 damien-esprimop2560 PackageKit: get-updates transaction 
/699_eddcbedc from uid 1000 finished with success after 615ms

Oct 11 20:43:50 damien-esprimop2560 tracker-store[3806]: OK
Oct 11 20:43:50 damien-esprimop2560 systemd[1261]: 
tracker-store.service: Succeeded.
Oct 11 20:43:51 damien-esprimop2560 systemd[1]: 
NetworkManager-dispatcher.service: Succeeded.


On Tue, 11 Oct 2022 00:04:37 +0200 Christopher Schramm 
 wrote:


> You do have a working IP connection but fail to reach any Internet
> targets, also by IP address. Is that correct?
>
> Please check (with sudo or similar):
>
> iptables -t nat -L POSTROUTING
>
> iptables -t filter -L FORWARD
>
> cat /proc/sys/net/ipv4/ip_forward
>
> ls /proc/sys/net/ipv4/conf/*/forwarding
>
> cat /proc/sys/net/ipv4/conf/*/forwarding
>

Bug#1006108: pipewire: No sound or clikey sound when PC started with monitor off

[alain]

Package: pipewire-pulse
Version: 0.3.59-1
Followup-For: Bug #1006108
X-Debbugs-Cc: compte.perso.de-al...@bbox.fr

hi :)  :)  :)

i don't know if i post at the right place .
sorry for the inconvenience .

i have no more sound too while using pipewire-pulse .
so , since the problem is still present , i remove it and all become ok .

i'm using linux-image-5.19.0-2-amd64 (sid) with gnome .

alain@sid:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:n/a
Codename:   bookworm

alain@sid:~$ sudo dpkg -l *pipewire*
[sudo] Mot de passe de alain :
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-
installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom   Version  Architecture Description
+++-=---===
ii  gstreamer1.0-pipewire:amd64   0.3.59-1 amd64GStreamer 1.0
plugin for the PipeWire multimedia server
ii  libpipewire-0.3-0:amd64   0.3.59-1 amd64libraries for the
PipeWire multimedia server
ii  libpipewire-0.3-0:i3860.3.59-1 i386 libraries for the
PipeWire multimedia server
ii  libpipewire-0.3-common0.3.59-1 all  libraries for the
PipeWire multimedia server - common files
ii  libpipewire-0.3-dev:amd64 0.3.59-1 amd64libraries for the
PipeWire multimedia server - development
ii  libpipewire-0.3-modules:amd64 0.3.59-1 amd64libraries for the
PipeWire multimedia server - modules
ii  libpipewire-0.3-modules:i386  0.3.59-1 i386 libraries for the
PipeWire multimedia server - modules
ii  pipewire:amd640.3.59-1 amd64audio and video
processing engine multimedia server
ii  pipewire:i386 0.3.59-1 i386 audio and video
processing engine multimedia server
ii  pipewire-bin  0.3.59-1 amd64PipeWire multimedia
server - programs
un  pipewire-doc(aucune description
n'est disponible)
ii  pipewire-media-session0.4.1-4  amd64example session
manager for PipeWire
ii  pipewire-pulse0.3.59-1 amd64PipeWire PulseAudio
daemon
ii  vlc-plugin-pipewire:amd64 3-2  amd64PipeWire audio
plugins for VLC

alain@sid:~$ pactl list sinks
Destination #35
État : RUNNING
Nom : auto_null
Description : Dummy Output
Pilote : PipeWire
Spécification de l’échantillon : float32le 2ch 48000Hz
Plan des canaux : front-left,front-right
Module du propriétaire : 4294967295
Sourdine : non
Volume : front-left: 65536 / 100% / 0,00 dB,   front-right: 65536 /
100% / 0,00 dB
balance 0,00
Volume de base : 65536 / 100% / 0,00 dB
Source du moniteur : auto_null.monitor
Latence : 0 usec, configuré 0 usec
Marqueurs : DECIBEL_VOLUME LATENCY
Propriétés :
node.name = "auto_null"
device.description = "Dummy Output"
audio.rate = "48000"
audio.channels = "2"
audio.position = "FL,FR"
media.class = "Audio/Sink"
factory.name = "support.null-audio-sink"
node.virtual = "true"
monitor.channel-volumes = "true"
factory.id = "18"
clock.quantum-limit = "8192"
client.id = "34"
node.driver = "true"
factory.mode = "merge"
audio.adapt.follower = ""
library.name = "audioconvert/libspa-audioconvert"
object.id = "33"
object.serial = "35"
Formats :
pcm

alain@sid:~$ aplay -l
 Liste des périphériques matériels PLAYBACK 
carte 0 : HDMI [HDA ATI HDMI], périphérique 3 : HDMI 0 [U32J59x]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : HDMI [HDA ATI HDMI], périphérique 7 : HDMI 1 [HDMI 1]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : HDMI [HDA ATI HDMI], périphérique 8 : HDMI 2 [U32J59x]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : HDMI [HDA ATI HDMI], périphérique 9 : HDMI 3 [HDMI 3]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : HDMI [HDA ATI HDMI], périphérique 10 : HDMI 4 [HDMI 4]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 0 : HDMI [HDA ATI HDMI], périphérique 11 : HDMI 5 [HDMI 5]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 1 : Generic [HD-Audio Generic], périphérique 0 : ALC1220 Analog [ALC1220
Analog]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 1 : 

Bug#1021610: RFS: bats-assert/2.0.0+git20220605.ffe84ea-1 [ITP] -- Helper library providing common assertions for Bats

[Gioele Barabucci]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: deb...@onerussian.com

Dear mentors,

I am looking for a sponsor for my package "bats-assert":

 * Package name : bats-assert
   Version  : 2.0.0+git20220605.ffe84ea-1
 * URL  : https://github.com/bats-core/bats-assert
 * License  : CC0-1.0
 * Vcs  : https://salsa.debian.org/bats-team/bats-assert
   Section  : devel

The source builds the following binary packages:

  bats-assert - Helper library providing common assertions for Bats

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/bats-assert/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bats-assert/bats-assert_2.0.0+git20220605.ffe84ea-1.dsc


Changes for the initial release:

 bats-assert (2.0.0+git20220605.ffe84ea-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1021609)

Regards,

--
Gioele Barabucci

Bug#934811: webrtc-audio-processing 1.0 available

[Thomas Uhle]

On Tue, 1 Feb 2022, Jonas Smedegaard wrote:


I have continued the work of Laurent Bigonville and believe to have a
worthy candidate targeted experimental.

One potential issue remaining is a lintian warning:

> W: libwebrtc-audio-processing1: package-name-doesnt-match-sonames 
libwebrtc-audio-coding-1-0 libwebrtc-audio-processing-1-0

I guess it is harmless, but I have been wrong before about SONAME
handling.


Well, I guess what lintian is trying to tell you is that the library name 
has changed with version 1.0.  Before the current version, it has been 
'libwebrtc_audio_processing.so.1', and now it is 
'libwebrtc-audio-processing-1.so.0'.  That is why lintian proposes to 
rename the binary package 'libwebrtc-audio-processing1' (which has been 
correct for the former library name) to 'libwebrtc-audio-processing-1-0'. 
Keeping the package name 'libwebrtc-audio-processing1' would risk to break 
any other binary packages like pulseaudio or libspa-0.2-modules because 
those binaries for the AEC module still link to 
libwebrtc_audio_processing.so.1 which is but removed during a version 
update.  By renaming the binary package, you could have both versions of 
the library installed side by side.




Please tell if someone from the Pulseaudio team is gonna take it from
here.  There has been quite silent on this bugreport for some time, so
if I don't hear a response I am likely to release what I have as an NMU
targeted experimental, with a follow-up targeted unstable (if all goes
well, obviously), but I would prefer to not take over maintenance of
this package.


Pushing the current version in experimental to unstable as-is would break 
pulseaudio, libspa-0.2-modules and gstreamer1.0-plugins-bad at least and 
scheduling a binNMU for these packages would not help as they are not yet 
ready for version 1.0 of webrtc-audio-processing.  It seems that the 
effort for PipeWire would be less than for PulseAudio, but at this very 
moment none of these would compile out of the box.


It might even make sense to consider to also rename 
'libwebrtc-audio-processing-dev' to 'libwebrtc-audio-processing-1-dev' if 
you want to push the new version to unstable because the path to the 
header files has changed as well as the name of the data file for 
pkg-config.  This way you could also install the development files from 
both versions side by side which might help the other projects to migrate 
to the new webrtc-audio-processing version at their own pace.


Last but not least, the binary package libwebrtc-audio-processing-dev 
needs to depend on libabsl-dev because some of the header files include 
header files from Abseil.


Best regards,

Thomas Uhle

Bug#1021576: linphone-desktop: Core dumped: Program terminated with signal SIGABRT, Aborted.

[ael]

> > Severity: normal
> >
> > After updating to linphone-common:all 5.0.37-6 and liblinphone10:amd64 
> > 5.0.37-6
> > as part of routine testing updates, I find that /usr/bin/linphone from
> > linphone-desktop aborts and dumps core as of today.
> >
> > Reportbug highlighted linphone-desktop_4.3.2-2+b1_amd64.deb
> > in unstable. Trying to install that failed on a depedency on
> > libqt5qml5_5.15.6+dfsg-2_amd64.deb
> >
> > Trying to install those broke again on a dependency on 
> > qtdeclarative-abi-5-15-6
> > which does not appear to exist.
> 
> The qtbase-abi-5-15-6 transition is still on-going[0], so any 5-15-6
> packages should not be installed yet.  You must downgrade any you have
> installed back to 5-15-4.

Thanks for the quick reply.

I had already downgraded back to 5-15-4. As noted above I tried to
use the unstable packages, and got a partial upgrade as you
gathered. I had alraedy cleaned out those packages and confirmed that
linphone still crashed.

> 
> > So linphone is broken on testing.
> >
> > $gdb -c core
> > does help much probably because I have set ulimit too small, and right
> > now I can't remember where ulimit gets set.

I have since increased unlimit, but gdb -c core gives the same lack of
information.

> > But it ends with
> > Core was generated by `linphone'.
> > Program terminated with signal SIGABRT, Aborted.
> 
> Did you maybe forget to attach some files before sending this message?
> I ask because your bug report is very light on details.  You only say
> that 5.0.37-6 crashes with SIGABRT, but not what version you used
> before and where it crashes.

Indeed. I was surprised that gdb gave so little information.
I was sure that I had linphone-desktop-dbgsym installed, but
somehow it was not present. Now installed, but gdb -c core still
not giving anything useful. I may need to install further -dbgsym
packages.

It does say "failed to read a valid object file image from memory".


>You don't provide any stderr output or
> logs either.  And if you have gdb installed and your APT preferences
> are on testing-debug you are clearly skilled enough to install -dbgsym
> packages and provide a stack backtrace.  I currently have no
> information I can work with.

Understood. I don't use gdb very often, so will need to refresh my
memory. This is a just a quick response untill I have time to
explore further.

But I emphasize that I just did my routine (normally daily)
apt-get upgrade and apt-get dist-upgrade, and that broke linphone.
I can't remember when I last used linphone, but it was within a few
days.

Hope to report much more soon...

Bug#1021609: ITP: bats-assert -- Helper library providing common assertions for Bats

[Gioele Barabucci]

Package: wnpp
Severity: wishlist
Owner: Gioele Barabucci 
X-Debbugs-Cc: debian-de...@lists.debian.org, gio...@svario.it

* Package name: bats-assert
  Version : 2.0.0
* URL : https://github.com/bats-core/bats-assert
* License : CC0
  Programming Lang: Bash
  Description : Helper library providing common assertions for Bats

bats-assert provides various ready-made assertions that can be used
to make Bats tests simpler to understand and to debug.

For example:

* assert_success: exit status is 0.
* assert_output: output contains given content.
* assert_line: a specific line of output contains given content.

--
Gioele Barabucci

Bug#932047: lightdm: greeter session support for elogind

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2022-10-11 at 10:02 -0600, Sam Hartman wrote:
> If including common-session will work, I think that's a good improvement
> for everyone.
> It is closer to best practice, and it means that as PAM profiles are
> added over time, they will work for lightdm as well.

Ok, but...
> 
> Whether that works depends on the architecture of the greeter.
> If the greeter has one process that does the initial authentication and
> then forks off an entire different set of processes not descended from
> the greeter that run the session, then including common-session might
> not work so well.

That's the case.
> 
> I'm kind of confused though because it looks like  1.26.0-8's sources
> already include common-session in data/pam/lightdm.

Yes, because there are two PAM sessions:
- - one for the greeter itself, running as the lightdm user
- - one for the logged in user

The user session already includes common-session but the greeter itself uses a
more stripped PAM configuration since it's only used for the login screen. So
I'm unsure if an “interactive user” PAM session is really a good idea here.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmNFtc0ACgkQ3rYcyPpX
RFu7BAgAoWJnJlzOocZHXVF1fZpYHPkHytKbvCWlm22qcSuEsdg+sBlKN+UtNK2n
xnb1oY4qffVtCORVNicKlwP+3OuL8WsW9vwHpni3V3oLuMoG474dT3iP9YGc2nW8
tgeK1TNpUuYiNGGGwcoUI+NlJY8mqYmbOxNVrbGNz7M7fLnd4jDPNdzCfh00bxMQ
W/MR5n/C+DlfXmoG+CQBudKRQpbNqXxl/POm2lphmf4do+oVfpFT7CPekwvzyp/H
/eHEV/rkjPTRzDnlsuhKSsLWebK9+ye+gUJfUJLDc6Hrx3RVnr4ZULKrrtbMg5d+
JivFke0rBEELT4xJUhEQukxRUo12Rw==
=+dab
-END PGP SIGNATURE-

Bug#975490: u-boot-sunxi: A64-Olinuxino-eMMC boot stuck at "Starting kernel ..."

[Vagrant Cascadian]

On 2022-10-11, Philip Rinn wrote:
> OK, I used a custom bootstrap script now and that works:

For clarity, sounds like you used u-boot-menu (at my suggestion), which
does not use boot scripts...

> U-Boot 2022.10+dfsg-1 (Oct 04 2022 - 00:06:38 +) Allwinner Technology
>
> CPU:   Allwinner A64 (SUN50I)
> Model: Olimex A64-Olinuxino-eMMC
> DRAM:  2 GiB
> Core:  74 devices, 20 uclasses, devicetree: separate
> WDT:   Not starting watchdog@1c20ca0
> MMC:   mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1
> Loading Environment from FAT... Unable to use mmc 0:1...
> In:serial
> Out:   serial
> Err:   serial
> Net:   eth0: ethernet@1c3
> starting USB...
> Bus usb@1c1a000: USB EHCI 1.00
> Bus usb@1c1a400: USB OHCI 1.0
> Bus usb@1c1b000: USB EHCI 1.00
> Bus usb@1c1b400: USB OHCI 1.0
> scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
> scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
> scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
> scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
> scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found /boot/extlinux/extlinux.conf
> Retrieving file: /boot/extlinux/extlinux.conf
> U-Boot menu
> 1:  Debian GNU/Linux bookworm/sid 5.19.0-2-arm64
> 2:  Debian GNU/Linux bookworm/sid 5.19.0-2-arm64 (rescue target)
> Enter choice: 1:Debian GNU/Linux bookworm/sid 5.19.0-2-arm64
> Retrieving file: /boot/initrd.img-5.19.0-2-arm64
> Retrieving file: /boot/vmlinuz-5.19.0-2-arm64
> append: root=/dev/mmcblk0p1 ro quiet
> Retrieving file: 
> /usr/lib/linux-image-5.19.0-2-arm64/allwinner/sun50i-a64-olinuxino-emmc.dtb
> Moving Image from 0x4008 to 0x4020, end=4200
> ## Flattened Device Tree blob at 4fa0
> Booting using the fdt blob at 0x4fa0
> Loading Ramdisk to 48196000, end 49d7 ... OK
> Loading Device Tree to 4818b000, end 48195370 ... OK
>
> Starting kernel ...
>
> [3.943010] sun50i-a64-pinctrl 1c20800.pinctrl: request() failed for pin 40
...
> [5.065265] sunxi-mmc 1c1.mmc: Error applying setting, reverse things 
> back
> [5.236700] sunxi-mmc 1c11000.mmc: data error, sending stop command
> [6.244813] sunxi-mmc 1c11000.mmc: send stop command failed
> [   11.139614] lima 1c4.gpu: error -ENODEV: dev_pm_opp_set_regulators: no 
> regulator (mali) found
>
> Debian GNU/Linux bookworm/sid debian ttyS0
>
> debian login:

Ok, some success!


> I did use
>
> TARGET=/usr/lib/u-boot/a64-olinuxino-emmc/ u-boot-install-sunxi64 ${SDCARD}

Why did you have to specify TARGET? Was it not able to detect the
correct board? Or were you running u-boot-install-sunxi64 that from
another system?


That said, if u-boot-menu's generated /boot/extlinux/extlinux.conf is
correctly parsed by u-boot, I'm at a loss why flash-kernel's generated
boot script wouldn't work... (they both basically end load the
kernel/initrd/dtb into ram and call "booti $kernel_addr_r
$ramdisk_addr_r $fdt_addr_r"). I've seen this before, and don't recall
coming up with a resolution.

Wild guess; maybe the flash-kernel boot.scr gets the wrong console
settings (e.g. serial vs. hdmi or whatnot), while u-boot-menu just uses
the default console specified in the .dtb?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1021502: lintian: incorrectly complains about debian-news-entry-has-unknown-version

[Axel Beckert]

Control: clone -1 -2
Control: reassign -2 debhelper 13.10
Control: clone -2 -3
Control: retitle -2 debhelper: Also trim (or delete) NEWS.Debian.gz if 
changelog.Debian.gz is trimmed
Control: block -1 by -2
Control: retitle -3 debhelper: Revert change to trim changelog.Debian.gz by 
default
Control: severity -3 wishlist
Control: tag -1 + wontfix

Hi,

gregor herrmann wrote:
> > The report does not look right: it seems to me that version 0.1.14 is
> > indeed present in the changelog file of my package!
> 
> Well, yes and no. It's in debian/changelog in the source package but
> as debhelper has started to trim the changelog in binary packages
> (13.10, dh_installchangelogs), it's probbaly not in
> /usr/share/doc//changelog.Debian.gz.

Urgs. IMHO it is a really bad idea to set this as default as such a
change does only make sense for a few packages with really large
changelog entries like e.g. the Linux kernel. (So doing this
automatically size-based, e.g. if the uncompressed debian/changelog is
over 1 MB, the trim it by default to the release-date of oldstable,
would be ok IMHO.)

At least I regularily read changelog.Debian.gz files (usually by
searching in them with "/") and are always very annoyed if I notice
that they're truncated like e.g. on Ubuntu. Always to have to check if
they are truncated before searching in them and then consult the
source package for getting the full changelog is IMHO inacceptable.

It is though nice to see a standardized possibility to truncate Debian
changelogs in debhelper for those packages which actually need it. But
doing this by default is IMHO a horrible idea.

> > Please investigate and fix this bug in lintian.

I see no possibility how to do that in Lintian except for switching
the check from a binary to a source package check. Not sure if this is
that easily doable. Additionally it will become more complex as it
would have each per-binary-package debian/.NEWS files
separately. (It would also invalidate any lintian override about it.)

But I actually would prefer to not have to do that at all as IMHO that
tag is validly emitted and this is IMHO a newly introduced bug in
debhelper. Cloning an according (wishlist) bug report against
debhelper

> Or maybe dh_installchangelogs should trim NEWS.Debian as well?

Definitely (and not just IMHO), this is a bug in debhelper. And
debhelper probably should even delete NEWS.Debian.gz completely if
there are only ancient entries in there. (Actually with these files
trimming by default IMHO even makes sense — but not for
changelog.Debian.gz.)

Cloning another bug report (same severity as this bug report, i.e.
#1021502) against debhelper for not trimming NEWS.Debian.gz as well
and blocking this bug report with it.

But better just don't enable changelog.Debian.gz trimming by default
at all or use the version proposed in MR !79 instead of the one from
!80. MR !79 IMHO is much more sensitive than !80.

IMHO trimming changelog.Debian.gz should not be enabled without either
an explicitly set option (and never by default, except maybe
size-based) or at least only with a dh compat level bump (as suggested
in !79).

The current situation is IMHO a rather bad surprise for many package
maintainers as well as many users (as it was back then in Ubuntu as
well).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#1019981: subversion: "svn propedit" loses changes in case of a network failure / remote attack

[Vincent Lefevre]

Control: severity -1 important

On 2022-09-19 03:27:56 +0200, Vincent Lefevre wrote:
> Perhaps not a security issue because any temporary network failure
> can affect svn. But note that the most common case is a remote attack
> (at least with Debian's default sshd configuration). On my server, I
> can see that since September 11, a "beginning MaxStartups throttling"
> occurred 3 times (each case apparently due to an attack from a single
> IP, according to the logs).

This is at least an important bug. This is the third time in less
than a month I lose data I've just written without *any way* to
recover them!!!

Each time after an attack via SSH.

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

Bug#1016773: can this bug be closed?

[Scott Kitterman]

On October 11, 2022 5:15:21 PM UTC, Thorsten Alteholz  
wrote:
>Hi Paul,
>
>On 10.10.22 20:12, Paul Gevers wrote:
>> On 10-10-2022 19:21, Thorsten Alteholz wrote:
>>> dak tells me that there is nothing left to do for this bug. So can it be 
>>> closed now?
>> 
>> I see this:
>> paul@mulciber ~ $ rmadison -s unstable pypy-six python-six
>> pypy-six   | 1.16.0-3  | unstable   | all
>> python-six | 1.16.0-3  | unstable   | all
>
>oh, ramdison knows more about the packages.
>pypy-six is gone now, but python-six is rebellious:
>
>Checking reverse dependencies...
># Broken Depends:
>gnat-gps: gnat-gps [amd64 arm64 mips64el ppc64el s390x]
>
>
>
>What shall I do here?

I removed it (it was in the cruft report).  Anything python 2 is, or will be 
shortly, broken, so there's no need to keep python-six around.

Scott K

Bug#1016773: can this bug be closed?

[Paul Gevers]

Hi Thorsten,

On 11-10-2022 19:15, Thorsten Alteholz wrote:

Checking reverse dependencies...
# Broken Depends:
gnat-gps: gnat-gps [amd64 arm64 mips64el ppc64el s390x]



What shall I do here?


gnat-gps is already uninstallable, removing one more Depends won't hurt 
I guess. On the other hand, if you don't mind the cruft in unstable, I 
don't care really.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021606: libyuv: FTBFS on hppa - broken googletest

[John David Anglin]

Source: libyuv
Version: 0.0~git20220923.b9adaef-1
Severity: normal
Tags: ftbfs patch

Dear Maintainer,

The following tests fail on hppa:

[--] Global test environment tear-down
[==] 3211 tests from 8 test suites ran. (1597834 ms total)
[  PASSED  ] 3169 tests.
[  FAILED  ] 42 tests, listed below:
[  FAILED  ] LibYUVConvertTest.TestNoDither
[  FAILED  ] LibYUVConvertTest.TestDither
[  FAILED  ] LibYUVConvertTest.I420ToARGBToRGB565_Any
[  FAILED  ] LibYUVConvertTest.I420ToARGBToRGB565_Unaligned
[  FAILED  ] LibYUVConvertTest.I420ToARGBToRGB565_Invert
[  FAILED  ] LibYUVConvertTest.I420ToARGBToRGB565_Opt
[  FAILED  ] LibYUVConvertTest.I422ToARGBToRGB565_Any
[  FAILED  ] LibYUVConvertTest.I422ToARGBToRGB565_Unaligned
[  FAILED  ] LibYUVConvertTest.I422ToARGBToRGB565_Invert
[  FAILED  ] LibYUVConvertTest.I422ToARGBToRGB565_Opt
[  FAILED  ] LibYUVConvertTest.ARGBToAR30ToARGB_Any
[  FAILED  ] LibYUVConvertTest.ARGBToAR30ToARGB_Unaligned
[  FAILED  ] LibYUVConvertTest.ARGBToAR30ToARGB_Invert
[  FAILED  ] LibYUVConvertTest.ARGBToAR30ToARGB_Opt
[  FAILED  ] LibYUVConvertTest.ABGRToAR30ToABGR_Any
[  FAILED  ] LibYUVConvertTest.ABGRToAR30ToABGR_Unaligned
[  FAILED  ] LibYUVConvertTest.ABGRToAR30ToABGR_Invert
[  FAILED  ] LibYUVConvertTest.ABGRToAR30ToABGR_Opt
[  FAILED  ] LibYUVConvertTest.AR30ToARGBToABGR_Any
[  FAILED  ] LibYUVConvertTest.AR30ToARGBToABGR_Unaligned
[  FAILED  ] LibYUVConvertTest.AR30ToARGBToABGR_Invert
[  FAILED  ] LibYUVConvertTest.AR30ToARGBToABGR_Opt
[  FAILED  ] LibYUVConvertTest.AR30ToABGRToARGB_Any
[  FAILED  ] LibYUVConvertTest.AR30ToABGRToARGB_Unaligned
[  FAILED  ] LibYUVConvertTest.AR30ToABGRToARGB_Invert
[  FAILED  ] LibYUVConvertTest.AR30ToABGRToARGB_Opt
[  FAILED  ] LibYUVConvertTest.ARGBToAB30ToARGB_Any
[  FAILED  ] LibYUVConvertTest.ARGBToAB30ToARGB_Unaligned
[  FAILED  ] LibYUVConvertTest.ARGBToAB30ToARGB_Invert
[  FAILED  ] LibYUVConvertTest.ARGBToAB30ToARGB_Opt
[  FAILED  ] LibYUVConvertTest.ABGRToAB30ToABGR_Any
[  FAILED  ] LibYUVConvertTest.ABGRToAB30ToABGR_Unaligned
[  FAILED  ] LibYUVConvertTest.ABGRToAB30ToABGR_Invert
[  FAILED  ] LibYUVConvertTest.ABGRToAB30ToABGR_Opt
[  FAILED  ] LibYUVConvertTest.AB30ToARGBToABGR_Any
[  FAILED  ] LibYUVConvertTest.AB30ToARGBToABGR_Unaligned
[  FAILED  ] LibYUVConvertTest.AB30ToARGBToABGR_Invert
[  FAILED  ] LibYUVConvertTest.AB30ToARGBToABGR_Opt
[  FAILED  ] LibYUVConvertTest.AB30ToABGRToARGB_Any
[  FAILED  ] LibYUVConvertTest.AB30ToABGRToARGB_Unaligned
[  FAILED  ] LibYUVConvertTest.AB30ToABGRToARGB_Invert
[  FAILED  ] LibYUVConvertTest.AB30ToABGRToARGB_Opt

42 FAILED TESTS
  YOU HAVE 40 DISABLED TESTS

I believe these are caused by broken googletest on big-endian architectures.
Please add hppa to the list of arches with broken googletest.

Thanks,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.14+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
--- rules.save  2022-10-11 17:05:53.037246365 +
+++ rules   2022-10-11 17:06:19.267489103 +
@@ -26,7 +26,7 @@
 endif
 
 # Known broken googletest
-ifneq (,$(filter $(DEB_HOST_ARCH), armel s390x powerpc ppc64 sparc64))
+ifneq (,$(filter $(DEB_HOST_ARCH), armel hppa s390x powerpc ppc64 sparc64))
   LIBYUV_TEST_FLAG = OFF
 endif
 

Bug#1021605: persepolis: Systemd dependencies

[Bardot Jerome]

Package: persepolis
Version: 3.0.1-1.1
Severity: important
X-Debbugs-Cc: bardot.jer...@gmail.com

Dear Maintainer,

It's look like the package need systemd … (throught recommends)
Can you please fix it ?

A default installation should not rely on a specific software that can break
all others software.

thx


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages persepolis depends on:
ii  aria2 1.36.0-1
ii  libnotify-bin 0.8.1-1
ii  libqt5svg55.15.4-2
ii  python3   3.10.6-1
ii  python3-pyqt5 5.15.7+dfsg-1
ii  python3-requests  2.27.1+dfsg-1

Versions of packages persepolis recommends:
pn  pulseaudio   
ii  python3-psutil   5.9.2-1
ii  python3-setproctitle 1.3.1-1
ii  sound-theme-freedesktop  0.8-2

persepolis suggests no packages.

Bug#975490: u-boot-sunxi: A64-Olinuxino-eMMC boot stuck at "Starting kernel ..."

[Philip Rinn]

Hi,

OK, I used a custom bootstrap script now and that works:

U-Boot SPL 2022.10+dfsg-1 (Oct 04 2022 - 00:06:38 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.7(debug):
NOTICE:  BL31: Built : 03:28:37, Aug  6 2022
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x209e1f0, model: Olimex A64-Olinuxino-eMMC
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
INFO:PMIC: Probing AXP803 on RSB
INFO:PMIC: aldo1 voltage: 2.800V
INFO:PMIC: dcdc1 voltage: 3.300V
INFO:PMIC: dcdc5 voltage: 1.360V
INFO:PMIC: dcdc6 voltage: 1.100V
INFO:PMIC: dldo1 voltage: 3.300V
INFO:PMIC: dldo2 voltage: 3.300V
INFO:PMIC: dldo3 voltage: 2.800V
INFO:PMIC: dldo4 voltage: 3.300V
INFO:PMIC: fldo1 voltage: 1.200V
INFO:PMIC: Enabling DC SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: cortex_a53: CPU workaround for 1530924 was applied
SCP/INF: Crust v0.5.1
INFO:PSCI: Suspend is available via SCPI
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9


U-Boot 2022.10+dfsg-1 (Oct 04 2022 - 00:06:38 +) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Olimex A64-Olinuxino-eMMC
DRAM:  2 GiB
Core:  74 devices, 20 uclasses, devicetree: separate
WDT:   Not starting watchdog@1c20ca0
MMC:   mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1
Loading Environment from FAT... Unable to use mmc 0:1...
In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@1c3
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
U-Boot menu
1:  Debian GNU/Linux bookworm/sid 5.19.0-2-arm64
2:  Debian GNU/Linux bookworm/sid 5.19.0-2-arm64 (rescue target)
Enter choice: 1:Debian GNU/Linux bookworm/sid 5.19.0-2-arm64
Retrieving file: /boot/initrd.img-5.19.0-2-arm64
Retrieving file: /boot/vmlinuz-5.19.0-2-arm64
append: root=/dev/mmcblk0p1 ro quiet
Retrieving file: 
/usr/lib/linux-image-5.19.0-2-arm64/allwinner/sun50i-a64-olinuxino-emmc.dtb

Moving Image from 0x4008 to 0x4020, end=4200
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
   Loading Ramdisk to 48196000, end 49d7 ... OK
   Loading Device Tree to 4818b000, end 48195370 ... OK

Starting kernel ...

[3.943010] sun50i-a64-pinctrl 1c20800.pinctrl: request() failed for pin 40
[3.943042] sun50i-a64-pinctrl 1c20800.pinctrl: pin-40 (1c28000.serial) 
status -517
[3.943063] sun50i-a64-pinctrl 1c20800.pinctrl: could not request pin 40 
(PB8) from group PB8  on device 1c20800.pinctrl
[3.943085] dw-apb-uart 1c28000.serial: Error applying setting, reverse 
things back

[3.943661] sun50i-a64-pinctrl 1c20800.pinctrl: request() failed for pin 40
[3.943681] sun50i-a64-pinctrl 1c20800.pinctrl: pin-40 (1c28000.serial) 
status -517
[3.943701] sun50i-a64-pinctrl 1c20800.pinctrl: could not request pin 40 
(PB8) from group PB8  on device 1c20800.pinctrl
[3.943722] dw-apb-uart 1c28000.serial: Error applying setting, reverse 
things back

[4.659095] sun50i-a64-pinctrl 1c20800.pinctrl: request() failed for pin 160
[4.659141] sun50i-a64-pinctrl 1c20800.pinctrl: pin-160 (1c0f000.mmc) status 
-517
[4.659162] sun50i-a64-pinctrl 1c20800.pinctrl: could not request pin 160 
(PF0) from group PF0  on device 1c20800.pinctrl

[4.659185] sunxi-mmc 1c0f000.mmc: Error applying setting, reverse things 
back
[4.659427] sun50i-a64-pinctrl 1c20800.pinctrl: request() failed for pin 192
[4.659448] sun50i-a64-pinctrl 1c20800.pinctrl: pin-192 (1c1.mmc) status 
-517
[4.659467] sun50i-a64-pinctrl 1c20800.pinctrl: could not request pin 192 
(PG0) from group PG0  on device 1c20800.pinctrl

[4.659494] sunxi-mmc 1c1.mmc: Error applying setting, reverse things 
back
[4.659683] sun50i-a64-pinctrl 1c20800.pinctrl: request() failed for pin 69
[4.659705] sun50i-a64-pinctrl 1c20800.pinctrl: pin-69 (1c11000.mmc) status 
-517
[4.659726] sun50i-a64-pinctrl 1c20800.pinctrl: could not request pin 69 
(PC5) from group PC5  on device 1c20800.pinctrl

[4.659750] sunxi-mmc 1c11000.mmc: Error applying setting, reverse things 
back
[4.877347] 

Bug#1016773: can this bug be closed?

[Thorsten Alteholz]

Hi Paul,

On 10.10.22 20:12, Paul Gevers wrote:

On 10-10-2022 19:21, Thorsten Alteholz wrote:
dak tells me that there is nothing left to do for this bug. So can it 
be closed now?


I see this:
paul@mulciber ~ $ rmadison -s unstable pypy-six python-six
pypy-six   | 1.16.0-3  | unstable   | all
python-six | 1.16.0-3  | unstable   | all


oh, ramdison knows more about the packages.
pypy-six is gone now, but python-six is rebellious:

Checking reverse dependencies...
# Broken Depends:
gnat-gps: gnat-gps [amd64 arm64 mips64el ppc64el s390x]



What shall I do here?

  Thorsten

Bug#249832: /bin/ls: Re: coreutils should use IEEE standard prefixes to denote powers of 1024

[scar]

Package: coreutils
Version: 9.1-1
Followup-For: Bug #249832
X-Debbugs-Cc: s...@riseup.net

Dear Maintainer,

Why's this simple fix still a problem today?

The failure to use correct prefixes is still a cause for major confusion 
amongst individuals especially when sharing data, and especially when other 
programs are involved that do correctly report file sizes.

K, M, G, T, etc. have NEVER referred to base-2 values until they were 
incorrectly introduced into the computing world, who knows, probably 50 years 
ago or more.  Someday maybe all computer programs will properly report file 
sizes.

Please make corrections so that '-h' flag correctly uses prefixes Ki, Mi, Gi, 
Ti, etc.  Or change -h default behavior to report base-10 values and add 
another flag to report base-2 values+prefixes.

Actually it was IEC 60027-2, which has been superceded by ISO/IEC 8, that 
IEEE adopted most likely.


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 coreutils depends on:
ii  libacl1  2.3.1-1
ii  libattr1 1:2.5.1-1
ii  libc62.35-2
ii  libgmp10 2:6.2.1+dfsg1-1
ii  libselinux1  3.4-1+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#481845: Workaround script

[Enrico Zini]

Hello,

this issue is sadly still a problem.

For those who may hit the same troublesome spot, I'm attaching the
script I'm using as a replacement, which is a lot less flexible (or one
could say, has a lot of hardcodable flexibility), but has a very low
memory footprint


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 
#!/usr/bin/python3

import argparse
from collections import defaultdict
import datetime
import mailbox
import sys


def main():
today = datetime.date.today()
this_month = today.replace(day=1)
parser = argparse.ArgumentParser(description="Make monthly archives of 
maildir contents")
parser.add_argument("--until", action="store", 
default=this_month.strftime("%Y-%m"),
help="stop archiving before this month")
parser.add_argument("maildir", action="store", help="maildir to archive")
args = parser.parse_args()

until = datetime.datetime.strptime(args.until, "%Y-%m").date()

src = mailbox.Maildir(args.maildir)

by_month = defaultdict(list)
for key in src.keys():
dt = datetime.datetime.fromtimestamp(int(key.split('.')[0])).date()
if dt >= until:
continue
by_month[dt.strftime("%Y-%m")].append(key)

for month, keys in sorted(by_month.items()):
dst = mailbox.mbox(args.maildir + "-" + month)
try:
dst.lock()
for key in keys:
email = src[key]
dst.add(email)
finally:
dst.flush()
dst.unlock()
dst.close()

for key in keys:
del src[key]
print(month, len(keys))

return


if __name__ == "__main__":
sys.exit(main())


signature.asc
Description: PGP signature

Bug#859739: RFP: pm-graph -- performance analysis of boot, suspend, and resume

[Antoine Beaupré]

On 2017-04-07 11:42:54, Todd Brandt wrote:
> On Thu, 06 Apr 2017 22:20:04 + Bart Martens 
>  wrote:
>> noowner 859739
>> stop
>>
>> A wnpp bug of type RFP should not have an owner.
>
> I understand. I originally tagged it as ITP because I wanted to own it 
> but require a sponsor. If you require a sponsor is ITP even allowed?

yes, I would think so. you can create a Debian package even if you're
not part of Debian per se, and then the sponsor is the person who
actually reviews the work and uploads it in Debian.

So in that sense, yes, it makes sense for an ITP to require a sponsor.

This looks like a really interesting tool, are you still planning on
packaging it?

A.

-- 
Imagine a world in which every single person on the planet is given
free access to the sum of all human knowledge.
 - Jimmy Wales, co-founder of Wikipedia

Bug#1021604: ITP: httpstat -- visualize curl statistics

[Blair Noctis]

Package: wnpp
Severity: wishlist
Owner: Blair Noctis 
X-Debbugs-Cc: debian-de...@lists.debian.org, n...@sail.ng

* Package name: httpstat
  Version : 1.3.2
  Upstream Author : Xiao Meng 
* URL : https://github.com/reorx/httpstat
* License : MIT
  Programming Lang: Python
  Description : visualize curl statistics

This command line tool shows statistics of a curl request, including response
headers and time used by each stage of the request, in a simple graph.


This tool helps analyze time cost of HTTP and other requests.
It's a Python package and fits in the Python team packaging process.

-- 
Regards,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021502: lintian: incorrectly complains about debian-news-entry-has-unknown-version

[gregor herrmann]

On Sun, 09 Oct 2022 19:37:12 +0200, Francesco Poli (wintermute) wrote:

> Running "lintian -EviIL +pedantic" on the .changes file generates
> the following report:
> 
>   N:
>   W: apt-listbugs: debian-news-entry-has-unknown-version 0.1.14 
> [usr/share/doc/apt-listbugs/NEWS.Debian.gz:1]
>   N:

Same here:

W: libjson-perl: debian-news-entry-has-unknown-version 2.50-1 
[usr/share/doc/libjson-perl/NEWS.Debian.gz:1]

> The report does not look right: it seems to me that version 0.1.14 is
> indeed present in the changelog file of my package!

Well, yes and no. It's in debian/changelog in the source package but
as debhelper has started to trim the changelog in binary packages
(13.10, dh_installchangelogs), it's probbaly not in
/usr/share/doc//changelog.Debian.gz.
 
> Please investigate and fix this bug in lintian.

Agreed, that's confusing and lintian should do Something™ about it.

Or maybe dh_installchangelogs should trim NEWS.Debian as well?
Cc'ing the debhelper maintainers …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1021576: linphone-desktop: Core dumped: Program terminated with signal SIGABRT, Aborted.

[Dennis Filder]

Control: tags -1 + moreinfo
X-Debbugs-Cc: ael 

On Mon, Oct 10, 2022 at 07:16:18PM +0100, ael wrote:
> Package: linphone-desktop
> Version: 4.3.2-2+b1
> Severity: normal
>
> After updating to linphone-common:all 5.0.37-6 and liblinphone10:amd64 
> 5.0.37-6
> as part of routine testing updates, I find that /usr/bin/linphone from
> linphone-desktop aborts and dumps core as of today.
>
> Reportbug highlighted linphone-desktop_4.3.2-2+b1_amd64.deb
> in unstable. Trying to install that failed on a depedency on
> libqt5qml5_5.15.6+dfsg-2_amd64.deb
>
> Trying to install those broke again on a dependency on 
> qtdeclarative-abi-5-15-6
> which does not appear to exist.

The qtbase-abi-5-15-6 transition is still on-going[0], so any 5-15-6
packages should not be installed yet.  You must downgrade any you have
installed back to 5-15-4.

> So linphone is broken on testing.
>
> $gdb -c core
> does help much probably because I have set ulimit too small, and right
> now I can't remember where ulimit gets set.
>
> But it ends with
> Core was generated by `linphone'.
> Program terminated with signal SIGABRT, Aborted.

Did you maybe forget to attach some files before sending this message?
I ask because your bug report is very light on details.  You only say
that 5.0.37-6 crashes with SIGABRT, but not what version you used
before and where it crashes.  You don't provide any stderr output or
logs either.  And if you have gdb installed and your APT preferences
are on testing-debug you are clearly skilled enough to install -dbgsym
packages and provide a stack backtrace.  I currently have no
information I can work with.

The change in 5.0.37-6 was tiny and I doubt it broke something.  But
maybe you're running into #1021125: liblinphone10:amd64 5.0.37-6 is
already linked against soci/4.0.3-1, but liblime0 5.0.37+dfsg-4 is
still linked against soci/4.0.1-5 and there was an ABI break.  You'd
have to downgrade to 5.0.37-5 and soci 4.0.1-5 and wait until either
that bug gets fixed or lime will be rebuilt and reuploaded.

Regards.

0: https://release.debian.org/transitions/html/qtbase-abi-5-15-6.html

Bug#932047: lightdm: greeter session support for elogind

[Sam Hartman]

Hi.

If including common-session will work, I think that's a good improvement
for everyone.
It is closer to best practice, and it means that as PAM profiles are
added over time, they will work for lightdm as well.

Whether that works depends on the architecture of the greeter.
If the greeter has one process that does the initial authentication and
then forks off an entire different set of processes not descended from
the greeter that run the session, then including common-session might
not work so well.

I'm kind of confused though because it looks like  1.26.0-8's sources
already include common-session in data/pam/lightdm.

Bug#1021520: guymager: reproducible-builds: date in guymager manpage

[Vagrant Cascadian]

On 2022-10-11, Michael Prokop wrote:
> * Vagrant Cascadian [Sun Oct 09, 2022 at 05:41:19PM -0700]:
>
>> The date is embedded in /usr/share/man/man1/guymager.1.gz:
>> 
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/guymager.html
>> 
>>   TH·guymager·1·"2023-11-10"·"version·0.8.13-1
>>   vs.
>>   TH·guymager·1·"2022-10-09"·"version·0.8.13-1
>> 
>> The attached patch to the upstream manuals/rebuild.sh file fixes this by
>> using SOURCE_DATE_EPOCH to determine the date to embed in the manpage.
>> 
>> According to my local tests, with this patch applied guymager should
>> build reproducibly on tests.reproducible-builds.org once it migrates to
>> bookworm/testing! There are other outstanding issues with build-paths,
>> which are only tested on unstable/experimental.
>
> Thanks for your patch, Vagrant. I applied it and added another
> change on top of yours, so manually invoking manuals/rebuild.sh
> still works, and converted it into a quilt patch.
>
> Would you mind taking a quick look at
> https://salsa.debian.org/pkg-security-team/guymager/-/merge_requests/1
> to check, whether this makes sense for you?

Nice! Looks good to me!

> (The failing reprotest in the pipeline seems to come from the
> guymager binary itself, AFAICS)

This is probably due to the build paths. I didn't figure out exactly
what was triggering that or how to avoid it in this case; it seemed to
be passing the -ffile-prefix-map build flag in at least some compiler
invocations, but maybe there are some corner-cases which ignore the
relevent *FLAGS variables. Long-term, it would be nice to avoid
embedding build paths too, but for now fixing at least timestamps will
help!

You can probably configure your salsa-ci reprotest job to exclude build
paths for now, as tests.reproducible-builds.org will catch that when
testing unstable or experimental:

  
https://salsa.debian.org/salsa-ci-team/pipeline#adding-extra-arguments-to-reprotest

At least, until we figure that part out... :)

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1019721: libopenmpi-dev: Cannot uninstall rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran': No such file or directory

[Andreas Beckmann]

Control: notfixed -1 4.1.4-2
Control: notfixed -1 4.1.4-2.1~

Clearing the fixed versions because the bts does not know about the 
binNMU concept (and does not understand binNMU versions) and currently 
considers the bug as still present.

Closed w/o fixed versions is interpreted as "fixed or invalid".

Andreas

Bug#1015179: Please update ppxlib to latest upstream

[julien . puydt]

Hi,

Le mardi 11 octobre 2022 à 11:26 +0200, Stéphane Glondu a écrit :
> 
> Le 11/10/2022 à 08:26, julien.pu...@gmail.com a écrit :
> > > > Could you package the latest upstream?
> > 
> > I did as much as I could and I think I nailed it:
> 
> Thank you for taking care of this.
> 
> > ** packaging: ocaml-sexplib0 (protected on salsa)
> > [...]
> > ** packaging: janest-base (protected on salsa)
> > [...]
> >     new version 0.15.0 (protected on salsa)
> 
> I've set you as Maintainer in the ocaml-team group on salsa. It
> should allow you to push to all packages.
> 

Thanks, I'll try.

> > Now how does one manage transition within the OCaml team?
> 
> It depends on the transition...
> 
> For "small" transitions (i.e. not involving OCaml itself), I just
> upload the new base package and wait for the reverse-dependencies to
> be broken in:
> 
>    https://release.debian.org/transitions/html/ocaml.html
> 
> Then, I upload or binNMU the broken packages, level by level.
> 

I think I'll do that for this one.

> Sometimes, when I suspect big breakage, I prepare the transition by 
> recompiling on my own machine reverse-dependencies, as you seem to
> have done.

And I did it by hand and by trial-and-error... that was awful :-/

> For OCaml itself, I've documented how I prepare transitions:
>  
> https://salsa.debian.org/debian/ben/-/tree/master/examples/ocaml-transition-scripts
> 

That looks like a useful script ; the fact that it only works for full
transitions can be annoying.


In https://salsa.debian.org/ocaml-team/dh-coq/-/tree/master/tools ,
you'll see I:

- prepare transitions with coq-planif-transition, which doesn't do much
work for me, except it tells me which packages will be of concern and
in which order I should build things -- by hand! That would need
improvements...

- actually manage transitions with coq-wanna-build, so that I only have
to file a transition bug to the release team with what this script gave
me and wait for the upload ack ; here is a recent example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019536

As I mentioned above, I think I'll work things by hand for this
specific ppxlib transition, but in the future, perhaps it's possible to
adapt my Coq scripts to the OCaml ecosystem?

Cheers,

J.Puydt

Bug#1021603: libpmix2: mca_base_component_repository_open: unable to open mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or directory (ignored)

[Andreas Beckmann]

Package: libpmix2
Version: 4.2.1-2
Severity: serious

Hi,

the new pmix version in sid causes autopkgtest regressions, e.g.

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openmpi/26943322/log.gz

autopkgtest [01:13:33]: test check_shared_objs: [---
[ci-284-796c5454:01766] mca_base_component_repository_open: unable to open 
mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or 
directory (ignored)
autopkgtest [01:13:34]: test check_shared_objs: ---]
autopkgtest [01:13:34]: test check_shared_objs:  - - - - - - - - - - results - 
- - - - - - - - -
check_shared_objsFAIL non-zero exit status 1

I see similar errors when rebuilding src:p4est while the tests are
running. This works fine with the version in testing.


Andreas

Bug#1021581: linux-image-amd64: 5.18 regression: hibernate works but does not power off computer

[Diederik de Haas]

On dinsdag 11 oktober 2022 11:41:58 CEST Patrick Jaap wrote:
> An internet research found this similar regression
> https://lore.kernel.org/lkml/YqE22nS9k2+AldI6@llamedos.localdomain/ 
> but the fix does not apply to my machine.

FTR: that patch is included upstream in 5.19+, but 5.18 does not have it.

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

Bug#1021353: RFS: zvbi/0.2.37-1 -- Vertical Blanking Interval (VBI) utilities

[Ileana Dumitrescu]

Hi!

> The symbols look wrong:
> Defining and leaking basic syscall wrappers suggests something is pretty
wrong.

Running a readelf -s on libzvbi.so.0 does not show the exporting of
these functions, but libzvbi-chains.so does export these functions. I
looked into why this was and found the answer in src/chains.c and
daemon/chains.c: "This is a small wrapper which executes the VBI
application given on the command line while overloading several C
library calls (such as open(2) and read(2)) so that the application
can be forced to access VBI devices via the VBI proxy instead of
device files directly." So, exporting these functions is required for
the proxy to work with applications that do not implement zvbi's proxy
interface. I can add these symbols to the libzvbi0.symbols file or
suppress the dpkg-gensymbols warning, as these functions are not part
of the main library's public interface. Note that this symbols issue
has appeared in previous upstream releases as well. So I will suppress
the dpkg-gensymbols diff to avoid future confusion.

> Also: you may drop the lsb-base Depends altogether; lintian will complain
> until its next release but if you know the future you can avoid changing the
> same thing twice :)

> An upstreamish issue but since you might have a way to contact upstream:
> W: libzvbi-dev: national-encoding [usr/include/libzvbi.h]
> As we don't even support ancient encodings anymore, everyone who reads the
> header will get mojibake.  Could you please convert everything to UTF-8?

Thank you for the feedback and for sponsoring! I am the upstream
maintainer so I just made both these changes and uploaded an updated
package to mentors :) I should have noticed the encoding warning but
only ran lintian on the source .deb package.

Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

Bug#783086: Project archived

[Blair Noctis]

Hi,

This packaged is archived on GitHub. Its README recommends oauthlib as an
alternative, which is already packaged as python3-oauthlib (python-oauthlib
seems to be its deprecated version).

-- 
Regards,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019445: shotcut: Shotcut crashes on startup with error: File already exists in database: opencv-caffe.proto

[Matteo Calorio]

Sure, thanks, here it is!

strace shotcut.tar.gz
Description: application/gzip

Bug#1021601: vlc: VAAPI hardware acceleration no more available

[Fabien Motta]

Package: vlc
Version: 3.0.17.4-4+b1
Severity: normal

Dear Maintainer,

With vlc version 3.0.17, VA-API hardware acceleration seems lost. 
It is not shown in the menu Tools/Preferences/Codecs/Hardware Decoding, only 
"Auto / VDPAU / Disable" are available. 
Moreover it is not used when "Auto" is selected: there is no "using VAAPI" 
message with vlc -vv with an h264 video,  
which my intel hd graphics module can handle, and intel_gpu_top shows no 
"video" activity.

Command "vlc -vv" shows no --enable-vaapi or disable-vaapi option.

On another machine under debian bullseye, the vlc version is 3.0.16 and VAAPI 
acceleration is available. 

When I tried to compile vlc from source, ./configure warned that it did not 
find libavcodec/vaapi.h. I looked at the libavcodec
versions: on debian bullseye it is 4.4, on sid it is 5.1. I did not investigate 
further.

Have a good day.  

FM

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


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-rt-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 vlc depends on:
ii  vlc-bin  3.0.17.4-4+b1
ii  vlc-plugin-base  3.0.17.4-4+b1
ii  vlc-plugin-qt3.0.17.4-4+b1
ii  vlc-plugin-video-output  3.0.17.4-4+b1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.17.4-4
ii  vlc-plugin-access-extra3.0.17.4-4+b1
ii  vlc-plugin-notify  3.0.17.4-4+b1
ii  vlc-plugin-samba   3.0.17.4-4+b1
ii  vlc-plugin-skins2  3.0.17.4-4+b1
ii  vlc-plugin-video-splitter  3.0.17.4-4+b1
ii  vlc-plugin-visualization   3.0.17.4-4+b1

Versions of packages vlc suggests:
pn  vlc-plugin-fluidsynth  
ii  vlc-plugin-jack3.0.17.4-4+b1
pn  vlc-plugin-pipewire
pn  vlc-plugin-svg 

Versions of packages libvlc-bin depends on:
ii  libc62.35-1
ii  libvlc5  3.0.17.4-4+b1

Versions of packages libvlc5 depends on:
ii  libc62.35-1
ii  libvlccore9  3.0.17.4-4+b1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.17.4-4+b1

Versions of packages vlc-bin depends on:
ii  libc6   2.35-1
ii  libvlc-bin  3.0.17.4-4+b1
ii  libvlc5 3.0.17.4-4+b1

Versions of packages vlc-plugin-access-extra depends on:
ii  libc62.35-1
ii  libsrt1.5-gnutls 1.5.1-1
ii  libvlccore9 [vlc-plugin-abi-3-0-0f]  3.0.17.4-4+b1
ii  libvncclient10.9.13+dfsg-4
ii  libxcb-composite01.15-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.6.0-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.7.2-1
ii  libass9  1:0.16.0-1
ii  libavahi-client3 0.8-6
ii  libavahi-common3 0.8-6
ii  libavc1394-0 0.5.4-5
ii  libavcodec59 7:5.1.2-1
ii  libavformat-extra59 [libavformat59]  7:5.1.2-1
ii  libavutil57  7:5.1.2-1
ii  libbluray2   1:1.3.3-1
ii  libc62.35-1
ii  libcairo21.16.0-6
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-2+b1
ii  libdav1d61.0.0-2
ii  libdbus-1-3  1.14.2-1
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.3-1
ii  libebml5 1.4.2-2
ii  libfaad2 2.10.0-2
ii  libflac8 1.3.4-2
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libfribidi0  1.0.8-2.1
ii  libgcc-s112.2.0-3
ii  libgcrypt20  1.10.1-2
ii  libglib2.0-0 2.74.0-1
ii  libgnutls30  3.7.7-2
ii  libgpg-error01.45-2
ii  libharfbuzz0b5.2.0-2
ii  libixml101:1.8.4-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  libkate1 0.4.1-11
ii  liblirc-client0  0.10.1-7
ii  liblua5.2-0

Bug#924848: telegram-cli: NMU 1.3.1+git20160323.6547c0b21-3.1

[Bastian Germann]

On Fri, 11 Feb 2022 18:04:54 +0100 Axel Beckert  wrote:

Hi,

according to https://tracker.debian.org/pkg/telegram-cli, telegram-cli
is threatened to be removed from testing due to an RC bug in the
wolfssl source package. But at least in the resulting binary package,
I see no relation to wolfssl, not even indirectly via libtgl.

The only occurrences of wolfssl in the telegram-cli source package
seem in the Debian packaging:


I have replaced the build dependency with libssl-dev.
There will be no Depends generated on libssl but it still influences the build 
by finding the headers.
The NMU debdiff is attached.diff -Nru telegram-cli-1.3.1+git20160323.6547c0b21/debian/changelog 
telegram-cli-1.3.1+git20160323.6547c0b21/debian/changelog
--- telegram-cli-1.3.1+git20160323.6547c0b21/debian/changelog   2021-11-07 
12:39:00.0 +0100
+++ telegram-cli-1.3.1+git20160323.6547c0b21/debian/changelog   2022-10-11 
09:21:06.0 +0200
@@ -1,3 +1,10 @@
+telegram-cli (1.3.1+git20160323.6547c0b21-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with libssl (Closes: #924848).
+
+ -- Bastian Germann   Tue, 11 Oct 2022 09:21:06 +0200
+
 telegram-cli (1.3.1+git20160323.6547c0b21-3) unstable; urgency=low
 
   * Fix FTBFS for write with wrong size. (Closes: #997272)
diff -Nru telegram-cli-1.3.1+git20160323.6547c0b21/debian/control 
telegram-cli-1.3.1+git20160323.6547c0b21/debian/control
--- telegram-cli-1.3.1+git20160323.6547c0b21/debian/control 2019-01-20 
08:26:45.0 +0100
+++ telegram-cli-1.3.1+git20160323.6547c0b21/debian/control 2022-10-11 
09:21:06.0 +0200
@@ -11,7 +11,7 @@
liblua5.2-dev,
libreadline-dev,
libtgl-0.0.0.20160623-dev,
-   libwolfssl-dev,
+   libssl-dev,
lua-lgi,
lua5.2,
zlib1g-dev
diff -Nru telegram-cli-1.3.1+git20160323.6547c0b21/debian/rules 
telegram-cli-1.3.1+git20160323.6547c0b21/debian/rules
--- telegram-cli-1.3.1+git20160323.6547c0b21/debian/rules   2019-01-20 
08:26:45.0 +0100
+++ telegram-cli-1.3.1+git20160323.6547c0b21/debian/rules   2022-10-11 
09:21:06.0 +0200
@@ -16,7 +16,7 @@
 
 override_dh_auto_configure:
ln -s -f /etc/mime.types $(CURDIR)/mime.types
-   dh_auto_configure -- --disable-openssl 
OPENSSL_INCLUDES="-I/usr/include/wolfssl -DWC_NO_HARDEN"
+   dh_auto_configure
 
 build-orig:
mkdir -p $(PACKAGE_NAME)-$(VERSION)

Bug#709682: RFP: python-github -- Python library for the full Github API

[Emmanuel Arias]

Hi everyone,

Seems that the package is already in Debian [0]

[0] https://tracker.debian.org/pkg/pygithub

Cheers,
Emmanuel

Bug#1021599: RFS: windows2usb/0.2.1-1 [ITP] -- script to write Microsoft Windows installation images to USB

[Lance Lin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "windows2usb". It is presently hosted 
at: https://salsa.debian.org/linqigang/windows2usb

Once the package is uploaded, I would appreciate it if the repo could be moved 
to https://salsa.debian.org/debian/windows2usb. My salsa ID is: linqigang

 * Package name : windows2usb
   Version  : 0.2.1-1
   Upstream contact : Valdikss 
 * URL  : https://github.com/ValdikSS/windows2usb
 * License  : Apache-2.0
 * Vcs  : https://salsa.debian.org/debian/windows2usb
   Section  : utils

The source builds the following binary packages:

  windows2usb - script to write Microsoft Windows installation images to USB

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/windows2usb/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/w/windows2usb/windows2usb_0.2.1-1.dsc

Changes for the initial release:

 windows2usb (0.2.1-1) unstable; urgency=low
 .
   * Initial release (Closes: #1014507)

Regards,
-- 


Lance Lin 
GPG Fingerprint:  4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7

signature.asc
Description: OpenPGP digital signature

Bug#1021598: Updating the rust-tabwriter Uploaders list

[Mattia Rizzolo]

Source: rust-tabwriter
Version: 1.2.1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Matt Kraai  has retired, so can't work on
the rust-tabwriter package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1021597: Updating the rust-ena Uploaders list

[Mattia Rizzolo]

Source: rust-ena
Version: 0.14.0-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Matt Kraai  has retired, so can't work on
the rust-ena package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1021596: Updating the rust-docopt Uploaders list

[Mattia Rizzolo]

Source: rust-docopt
Version: 1.1.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Matt Kraai  has retired, so can't work on
the rust-docopt package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1021593: Updating the rust-cargo-lichking Uploaders list

[Mattia Rizzolo]

Source: rust-cargo-lichking
Version: 0.7.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Matt Kraai  has retired, so can't work on
the rust-cargo-lichking package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1021595: Updating the rust-derive-new Uploaders list

[Mattia Rizzolo]

Source: rust-derive-new
Version: 0.5.8-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Matt Kraai  has retired, so can't work on
the rust-derive-new package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1021594: Updating the rust-cargo-metadata Uploaders list

[Mattia Rizzolo]

Source: rust-cargo-metadata
Version: 0.14.2-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Matt Kraai  has retired, so can't work on
the rust-cargo-metadata package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1021592: Updating the rust-bytesize Uploaders list

[Mattia Rizzolo]

Source: rust-bytesize
Version: 1.1.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Matt Kraai  has retired, so can't work on
the rust-bytesize package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature