Bug#1030277: [dget] Can’t parse deb822-style .sources files

[David Prévot]

Control: forcemerge 976673 -1

Le 02/02/2023 à 03:14, Tianyu Chen a écrit :

On Wed, Feb 01, 2023 at 10:40:08PM +0100, David Prévot wrote:

[…]

$ dget apt
no repository found in /etc/apt/sources.list or sources.list.d at /usr/bin/dget 
line 378.


Is this a duplicate with #976673?


Indeed, thanks. No idea how I missed it, sorry.

Regards.

Bug#1030040: release-notes: usrmerge and dist-upgrade

[Paul Gevers]

Hi Justin,

Thanks for bringing this up.

On 30-01-2023 17:05, Justin B Rye wrote:

  a) Doing a combined dist-upgrade and usrmerge is so reliable that
everybody should simply do it this way (thus using the latest
usrmerge).


That's what I think has to be the case. So unless we are aware of issues 
we can't solve, I'd say this is my baseline. I don't want to release 
knowing that this is not OK. Proponents of the merge have been saying 
that Ubuntu didn't receive bugs years ago when they did their merge and 
usrmerge got better since then.



Whatever advice we end up giving, the same section could also mention
the detail that if you don't want all of usrmerge's dependencies
installed - not that there are many - you can replace it with the
special dummy package usr-is-merged on bookworm.


*After* the merge (and I'm pretty sure that without the merge, 
usr-is-merged fails to install). Not merging is no longer supported.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030298: pyopencl: FTBFS on i386: = 1 failed, 304 passed, 7 skipped, 1 deselected, 2 xfailed, 31 warnings in 736.25s (0:12:16) =

[Sebastian Ramacher]

Source: pyopencl
Version: 2022.3.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=pyopencl=i386=2022.3.1-2%2Bb1=1675322850=0

=== short test summary info 
FAILED test_clmath.py::test_fmod[>]
= 1 failed, 304 passed, 7 skipped, 1 deselected, 2 xfailed, 31 warnings in 
736.25s (0:12:16) =
E: pybuild pybuild:388: test: plugin custom failed with: exit code=1: 
PYTHONPATH=/<>/.pybuild/cpython3_3.11/build cp -r 
/<>/test /<>/.pybuild/cpython3_3.11/build && cd 
/<>/.pybuild/cpython3_3.11/build/test && python3.11 -m pytest 
--verbosity=2 -k 'not test_event_set_callback' && rm -rf 
/<>/.pybuild/cpython3_3.11/build/test
Traceback (most recent call last):
  File "/usr/bin/pybuild", line 386, in main
run(func, i, version, c)
  File "/usr/bin/pybuild", line 324, in run
result = func(context, args)
 ^^^
  File "/usr/share/dh-python/dhpython/build/base.py", line 290, in wrapped_func
raise Exception(msg)
Exception: exit code=1: 
PYTHONPATH=/<>/.pybuild/cpython3_3.11/build cp -r 
/<>/test /<>/.pybuild/cpython3_3.11/build && cd 
/<>/.pybuild/cpython3_3.11/build/test && python3.11 -m pytest 
--verbosity=2 -k 'not test_event_set_callback' && rm -rf 
/<>/.pybuild/cpython3_3.11/build/test
rm -fr -- /tmp/dh-xdg-rundir-Y5upF5ES
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 -s 
custom "--test-args=PYTHONPATH={build_dir} cp -r {dir}/test {build_dir} && cd 
{build_dir}/test && {interpreter} -m pytest --verbosity=2 -k 'not 
test_event_set_callback' && rm -rf {build_dir}/test" returned exit code 13
make[1]: *** [debian/rules:49: override_dh_auto_test] Error 25

Cheers
-- 
Sebastian Ramacher

Bug#1030297: pytango: FTBFS: = 364 failed, 689 passed, 26 xfailed, 2 warnings, 40 errors in 176.40s (0:02:56) =

[Sebastian Ramacher]

Source: pytango
Version: 9.3.6-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=pytango=amd64=9.3.6-2%2Bb1=1675322420=0

=== short test summary info 
FAILED tests/test_async.py::test_async_command_polled[int]
FAILED tests/test_async.py::test_async_command_polled[float]
FAILED tests/test_async.py::test_async_command_polled[str]
FAILED tests/test_async.py::test_async_command_polled[bool]
FAILED tests/test_async.py::test_async_command_polled[(int,)]
FAILED tests/test_async.py::test_async_command_polled[(float,)]
FAILED tests/test_async.py::test_async_command_polled[(str,)]
FAILED tests/test_async.py::test_async_command_with_polled_callback[int]
FAILED tests/test_async.py::test_async_command_with_polled_callback[float]
FAILED tests/test_async.py::test_async_command_with_polled_callback[str]
FAILED tests/test_async.py::test_async_command_with_polled_callback[bool]
FAILED tests/test_async.py::test_async_command_with_polled_callback[(int,)]
FAILED tests/test_async.py::test_async_command_with_polled_callback[(float,)]
FAILED tests/test_async.py::test_async_command_with_polled_callback[(str,)]
FAILED tests/test_async.py::test_async_command_with_pushed_callback[int]
FAILED tests/test_async.py::test_async_command_with_pushed_callback[float]
FAILED tests/test_async.py::test_async_command_with_pushed_callback[str]
FAILED tests/test_async.py::test_async_command_with_pushed_callback[bool]
FAILED tests/test_async.py::test_async_command_with_pushed_callback[(int,)]
FAILED tests/test_async.py::test_async_command_with_pushed_callback[(float,)]
FAILED tests/test_async.py::test_async_command_with_pushed_callback[(str,)]
FAILED tests/test_server.py::test_empty_device[Synchronous]
FAILED tests/test_server.py::test_empty_device[Asyncio]
FAILED tests/test_server.py::test_empty_device[Gevent]
FAILED tests/test_server.py::test_set_state[ON-Synchronous]
FAILED tests/test_server.py::test_set_state[ON-Asyncio]
FAILED tests/test_server.py::test_set_state[ON-Gevent]
FAILED tests/test_server.py::test_set_state[OFF-Synchronous]
FAILED tests/test_server.py::test_set_state[OFF-Asyncio]
FAILED tests/test_server.py::test_set_state[OFF-Gevent]
FAILED tests/test_server.py::test_set_state[CLOSE-Synchronous]
FAILED tests/test_server.py::test_set_state[CLOSE-Asyncio]
FAILED tests/test_server.py::test_set_state[CLOSE-Gevent]
FAILED tests/test_server.py::test_set_state[OPEN-Synchronous]
FAILED tests/test_server.py::test_set_state[OPEN-Asyncio]
FAILED tests/test_server.py::test_set_state[OPEN-Gevent]
FAILED tests/test_server.py::test_set_state[INSERT-Synchronous]
FAILED tests/test_server.py::test_set_state[INSERT-Asyncio]
FAILED tests/test_server.py::test_set_state[INSERT-Gevent]
FAILED tests/test_server.py::test_set_state[EXTRACT-Synchronous]
FAILED tests/test_server.py::test_set_state[EXTRACT-Asyncio]
FAILED tests/test_server.py::test_set_state[EXTRACT-Gevent]
FAILED tests/test_server.py::test_set_state[MOVING-Synchronous]
FAILED tests/test_server.py::test_set_state[MOVING-Asyncio]
FAILED tests/test_server.py::test_set_state[MOVING-Gevent]
FAILED tests/test_server.py::test_set_state[STANDBY-Synchronous]
FAILED tests/test_server.py::test_set_state[STANDBY-Asyncio]
FAILED tests/test_server.py::test_set_state[STANDBY-Gevent]
FAILED tests/test_server.py::test_set_state[FAULT-Synchronous]
FAILED tests/test_server.py::test_set_state[FAULT-Asyncio]
FAILED tests/test_server.py::test_set_state[FAULT-Gevent]
FAILED tests/test_server.py::test_set_state[INIT-Synchronous]
FAILED tests/test_server.py::test_set_state[INIT-Asyncio]
FAILED tests/test_server.py::test_set_state[INIT-Gevent]
FAILED tests/test_server.py::test_set_state[RUNNING-Synchronous]
FAILED tests/test_server.py::test_set_state[RUNNING-Asyncio]
FAILED tests/test_server.py::test_set_state[RUNNING-Gevent]
FAILED tests/test_server.py::test_set_state[ALARM-Synchronous]
FAILED tests/test_server.py::test_set_state[ALARM-Asyncio]
FAILED tests/test_server.py::test_set_state[ALARM-Gevent]
FAILED tests/test_server.py::test_set_state[DISABLE-Synchronous]
FAILED tests/test_server.py::test_set_state[DISABLE-Asyncio]
FAILED tests/test_server.py::test_set_state[DISABLE-Gevent]
FAILED tests/test_server.py::test_set_state[UNKNOWN-Synchronous]
FAILED tests/test_server.py::test_set_state[UNKNOWN-Asyncio]
FAILED tests/test_server.py::test_set_state[UNKNOWN-Gevent]
FAILED tests/test_server.py::test_set_status[Synchronous]
FAILED tests/test_server.py::test_set_status[Asyncio]
FAILED tests/test_server.py::test_set_status[Gevent]
FAILED tests/test_server.py::test_identity_command[int-Synchronous]
FAILED tests/test_server.py::test_identity_command[int-Asyncio]
FAILED tests/test_server.py::test_identity_command[int-Gevent]
FAILED tests/test_server.py::test_identity_command[float-Synchronous]
FAILED 

Bug#1030285: bsdutils: logger: regressed to reusing initial timestamp

[Chris Hofstaedtler]

Control: tags -1 upstream wontfix
Control: found -1 2.29.2-1+deb9u1

* Thorsten Glaser  [230202 03:21]:
> I *know* we had this bug already, and it got fixed at some time,
> but apparently a regression was introduced and this bug shows up
> again in sid: long-running logger(1) sessions do not receive an
> updated timestamp for later lines:

This is a design decision of upstream, introduced in 2015 (so,
before buster):

logger.c line 964ff:

/* note: we never re-generate the syslog header here, even if we
 * generate multiple messages. If so, we think it is the right thing
 * to do to report them with the same timestamp, as the user actually
 * intended to send a single message.
 */

https://github.com/util-linux/util-linux/commit/2b3f40c5978569f15e30836cf99f34f31c163d1c#diff-288c0fc14bc650526985c9f780a50739c397d1c5ca39aa1046b224e9efd3d619R519
(by Rainer Gerhards, aka rsyslog developer)

Good luck,
Chris

Bug#990447: Similar problems

[Pascal Hambourg]

On 02/02/2023 at 00:33, Phil Dibowitz wrote:


And I've run `grub-install` with my EFI dir mounted. What's interesting 
is the version in EFI is different than the version staged by the package:


```
# sum /usr/lib/shim/shimx64.efi /boot/EFI/EFI/debian/shimx64.efi
47979   918 /usr/lib/shim/shimx64.efi
36147   913 /boot/EFI/EFI/debian/shimx64.efi
```


You must compare with /usr/lib/shim/shimx64.efi.signed from shim-signed.

Bug#1030296: ITP: libobject-extend-perl -- add and override per-object methods

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libobject-extend-perl
  Version : 0.4.0
  Upstream Author : chocolateboy 
* URL : https://metacpan.org/release/Object-Extend
* License : Artistic
  Programming Lang: Perl
  Description : add and override per-object methods

Object::Extend allows objects to be extended with per-object methods, 
similar to the use of singleton methods in Ruby. Object methods are 
added to an object-specific shim class (known as an eigenclass), which 
extends the object's original class. The original class is left unchanged.


I find this Perl package useful to override methods in existing objects.

Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libobject-extend-perl

Bug#1030295: tomopy: please fix build on atomic architectures

[Gianfranco Costamagna]

Source: tomopy
Version: 1.10.4+ds1-7
tags: patch

Hello, looks like tomopy is FTBFS on architectures where libatomic is needed

I created a patch from CheckAtomic.cmake (cmake-extras-modules package), and I 
plan to submit upstream

diff -Nru tomopy-1.10.4+ds1/debian/patches/fix-build.patch 
tomopy-1.10.4+ds1/debian/patches/fix-build.patch
--- tomopy-1.10.4+ds1/debian/patches/fix-build.patch1970-01-01 
00:00:00.0 +
+++ tomopy-1.10.4+ds1/debian/patches/fix-build.patch2023-02-01 
10:07:39.0 +
@@ -0,0 +1,146 @@
+Description: Link with latomic where needed
+Author: Gianfranco Costamagna 
+Bug-Debian: https://bugs.debian.org/
+Forwarded:
+Last-Update: 2023-02-01
+
+Index: tomopy-1.10.4+ds1/CMakeLists.txt
+===
+--- tomopy-1.10.4+ds1.orig/CMakeLists.txt
 tomopy-1.10.4+ds1/CMakeLists.txt
+@@ -40,6 +40,7 @@
+ include(BuildSettings)
+ include(Packages)
+ include(ClangFormat)
++include(CheckAtomic)
+
+ 

+ #   tomopy source
+Index: tomopy-1.10.4+ds1/PTL/cmake/Modules/Packages.cmake
+===
+--- tomopy-1.10.4+ds1.orig/PTL/cmake/Modules/Packages.cmake
 tomopy-1.10.4+ds1/PTL/cmake/Modules/Packages.cmake
+@@ -165,6 +165,9 @@
+
+ endif()
+
++if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB OR NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB)
++list(APPEND EXTERNAL_LIBRARIES "atomic")
++endif()
+
+ 

+ #
+Index: tomopy-1.10.4+ds1/cmake/Modules/CheckAtomic.cmake
+===
+--- /dev/null
 tomopy-1.10.4+ds1/cmake/Modules/CheckAtomic.cmake
+@@ -0,0 +1,95 @@
++# SPDX-FileCopyrightText: 2003-2018 University of Illinois at 
Urbana-Champaign.
++#
++# SPDX-License-Identifier: BSD-3-Clause
++
++#[===[.rst:
++CheckAtomic
++---
++
++Check if the compiler supports std:atomic out of the box or if libatomic is
++needed for atomic support. If it is needed libatomicis added to
++``CMAKE_REQUIRED_LIBRARIES``. So after running CheckAtomic you can use
++std:atomic.
++
++Since 5.75.0.
++#]===]
++
++include(CheckCXXSourceCompiles)
++include(CheckLibraryExists)
++
++# Sometimes linking against libatomic is required for atomic ops, if
++# the platform doesn't support lock-free atomics.
++
++function(check_working_cxx_atomics varname)
++  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
++  set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -std=c++11")
++  check_cxx_source_compiles("
++  #include 
++  std::atomic x;
++  std::atomic y;
++  std::atomic z;
++  int main() {
++++z;
++++y;
++return ++x;
++  }
++  " ${varname})
++  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
++endfunction()
++
++function(check_working_cxx_atomics64 varname)
++  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
++  set(CMAKE_REQUIRED_FLAGS "-std=c++11 ${CMAKE_REQUIRED_FLAGS}")
++  check_cxx_source_compiles("
++  #include 
++  #include 
++  std::atomic x (0);
++  int main() {
++uint64_t i = x.load(std::memory_order_relaxed);
++return 0;
++  }
++  " ${varname})
++  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
++endfunction()
++
++# Check for (non-64-bit) atomic operations.
++if(MSVC)
++  set(HAVE_CXX_ATOMICS_WITHOUT_LIB True)
++elseif(LLVM_COMPILER_IS_GCC_COMPATIBLE)
++  # First check if atomics work without the library.
++  check_working_cxx_atomics(HAVE_CXX_ATOMICS_WITHOUT_LIB)
++  # If not, check if the library exists, and atomics work with it.
++  if(NOT HAVE_CXX_ATOMICS_WITHOUT_LIB)
++check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
++if(HAVE_LIBATOMIC)
++  list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
++  check_working_cxx_atomics(HAVE_CXX_ATOMICS_WITH_LIB)
++  if (NOT HAVE_CXX_ATOMICS_WITH_LIB)
++message(FATAL_ERROR "Host compiler must support std::atomic!")
++  endif()
++else()
++  message(FATAL_ERROR "Host compiler appears to require libatomic, but cannot 
find it.")
++endif()
++  endif()
++endif()
++
++# Check for 64 bit atomic operations.
++if(MSVC)
++  set(HAVE_CXX_ATOMICS64_WITHOUT_LIB True)
++elseif(LLVM_COMPILER_IS_GCC_COMPATIBLE)
++  # First check if atomics work without the library.
++  check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITHOUT_LIB)
++  # If not, check if the library exists, and atomics work with it.
++  if(NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB)
++check_library_exists(atomic __atomic_load_8 "" HAVE_CXX_LIBATOMICS64)
++if(HAVE_CXX_LIBATOMICS64)
++  list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
++  check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITH_LIB)
++  if (NOT HAVE_CXX_ATOMICS64_WITH_LIB)
++

Bug#1030276: debvm: Add tool to generate qemu images

[Helmut Grohne]

Control: tags -1 + wontfix

Hi Gioele,

On Wed, Feb 01, 2023 at 11:07:25PM +0100, Gioele Barabucci wrote:
> The current output of `debvm-create` is a file containing an ext4 partition.
> In order to run the VM a tool like `debvm-run` is needed.
> 
> It would be nice if there were a tool in the `debvm` family that could turn
> that partition into a complete disk (with a bootloader, etc) stored in a
> `qcow2` image, so that it could be run with a simple:
> 
>kvm vm.qcow2

As much as I'd like that kind of ease of use. I don't think this is
feasible in a sane way.

Quite fundamentally, just running kvm requires a bootloader to be
installed inside the image. Bootloaders are quite architecture-specific,
so debvm avoids them and leverages qemu as bootloader. An image created
by debvm does not contain a bootloader nor partition table. Adding them
retroactively is not a simple affair - much less architecture-generic.

> (If the output of `debvm-create` were a tarball, creating an full-disk image
> would be as easy as following the guestfish-based instructions in the
> manpage of mmdebstrap.)

guestfish is not a light-weight dependency and comes with a lot of
non-trivial requirements. One of these requirements is being native-only
as inherited from supermin.

I think you are looking for a different tool here. For full disk images,
the added complexity by mkosi or vagrant probably makes sense. I
acknowledge that the image format used by debvm is not generic. That is
part of its design compromise. In fact, the format is quite specific and
thus documented in README.md.

Also note that adding a mode where debvm would construct a tarball is
not that helpful either. For instance, the image created parses the TERM
variable from the kernel command line and inserts it into the serial
console shell. This only works, because debvm-run passes TERM along.
This is something a direct kvm invocation cannot do. There is a reason
that debvm wraps both mmdebstrap and qemu rather than just one of them.

Helmut

Bug#1029143: liburiparser-dev: Add uriparser-config.cmake to support cmake based builds

[Jörg Frings-Fürst]

fixed 1029143 uriparser/0.9.7+dfsg-2
thanks



Hello,

fixed in version 0.9.7+dfsg-2.


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1030294: ITP: libbiblio-document-parser-perl -- document parsing framework

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libbiblio-document-parser-perl
  Version : 1.10
  Upstream Author : Tim Brody 
* URL : https://metacpan.org/release/Biblio-Document-Parser
* License : GPL-2+
  Programming Lang: Perl
  Description : document parsing framework

Biblio::Document::Parser provides generic methods that should be overridden by
specific parsers. This class should not be used directly, but rather be
overridden by specific parsers. Parsers that extend the Document::Parser
class should at least override the parse method.

See also:
 Biblio::Document::Parser
 Biblio::Document::Parser::Brody
 Biblio::Document::Parser::Standard

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030293: gummi: please bump to latest stable release

[Alexander van der Meij]

Package: gummi
Version: 0.8.1-1+b1

Hi upstream for Gummi here. Hereby requesting for the gummi package to
get bumped to the latest stable (0.8.3). There are some important fixes
in the two releases since 0.8.1 - most notably fixes to some terrible
>10 year old parsing code which likely causes debian bug #1012150.
Please contact me if I can be of help. Thanks!

Bug#1030292: Cannot bind to privileged port

[Daniel Richard G.]

Package: apt-cacher-ng
Version: 3.7.4-1+b2
Severity: important

I want to run apt-cacher-ng on port 80 for a dedicated caching server.

After configuring via debconf to use that port, and restarting, nothing
is listening at localhost:80. I see the following in syslog:

2023-02-02T00:10:04.728949-05:00 image-debian64 systemd[1]: Starting 
apt-cacher-ng.service - Apt-Cacher NG software download proxy...
2023-02-02T00:10:04.740737-05:00 image-debian64 apt-cacher-ng[668]: 
Couldn't bind socket: Permission denied
2023-02-02T00:10:04.740858-05:00 image-debian64 apt-cacher-ng[668]: 
Couldn't bind socket: Permission denied
2023-02-02T00:10:04.743750-05:00 image-debian64 systemd[1]: Started 
apt-cacher-ng.service - Apt-Cacher NG software download proxy.

If this is a limitation of the current package, then it should be noted
in the documentation and debconf prompt.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1030291: ITP: libbiblio-counter-perl -- COUNTER Codes of Practice report processing

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libbiblio-counter-perl
  Version : 0.11
  Upstream Author : Paul Hoffman 
* URL : https://metacpan.org/release/Biblio-COUNTER
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : COUNTER Codes of Practice report processing

Biblio::COUNTER provides modules for handling COUNTER reports.

Because the COUNTER Codes of Practice are so poorly written and documented,
with incomplete specifications and inconsistent terminology, it has been
necessary to make certain assumptions and normalizations in the code and
documentation of this module.

First, all reports must be in plain text, tab- or comma-delimited format;
Excel spreadsheets are not allowed. (To convert an Excel spreadsheet to
tab-delimited text, consider using Spreadsheet::ParseExcel::Simple.

(XML formats may be handled in a future version of this module.)

See also:
 https://www.projectcounter.org/
 https://metacpan.org/pod/Spreadsheet::ParseExcel::Simple

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[Paul Wise]

On Wed, 2023-02-01 at 21:32 +0100, Sven Joachim wrote:

> Somehow, but how exactly?  Good question that was brought up on
> debian-devel[2], alas without replies yet.

The apt developers have come up with something for this:

https://salsa.debian.org/apt-team/apt/-/merge_requests/282

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1030290: python3-gtts: Outdated, no longer works

[Matthew Gabeler-Lee]

Package: python3-gtts
Version: 2.0.3-4
Severity: important

The current version of this package no longer works:

gtts.tts - WARNING - Unable to get language list: 'NoneType' object is not 
subscriptable
Usage: gtts-cli [OPTIONS] 
Try 'gtts-cli -h' for help.

Error: Unable to find token seed! Did https://translate.google.com change?

Searching upstream finds e.g. https://github.com/pndurette/gTTS/issues/354
suggesting that this is fixed upstream and the package just needs an update.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 
'oldstable'), (490, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-2-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 python3-gtts depends on:
ii  python33.11.1-2
ii  python3-bs44.11.1-3
ii  python3-click  8.1.3-2
ii  python3-gtts-token 1.1.3-3
ii  python3-pkg-resources  65.6.3-1
ii  python3-requests   2.28.1+dfsg-1
ii  python3-six1.16.0-4

python3-gtts recommends no packages.

python3-gtts suggests no packages.

-- no debconf information

Bug#1030279: ITP: hud -- Backend for the Unity/Lomiri HUD

[Paul Wise]

On Thu, 2023-02-02 at 00:14 +0100, Mike Gabriel wrote:

> * Package name    : hud

This seems too generic, perhaps it should be lomiri-hud?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1030212: puppet-agent: conffiles not removed: /etc/init.d/puppet-agent /etc/default/puppet-agent

[Jérôme Charaoui]

Le 2023-02-01 à 23 h 14, Paul Wise a écrit :

On Wed, 2023-02-01 at 08:22 -0500, Jérôme Charaoui wrote:


Specifically, I added to d/puppet-agent.maintscript:

  mv_conffile /etc/default/puppet-agent /etc/default/puppet 7.21.0-2~
  mv_conffile /etc/init.d/puppet-agent /etc/init.d/puppet 7.21.0-2~

Do you know why this isn't working as intended?


According to the dpkg-maintscript-helper manual page:

    If the conffile has not been shipped for several versions, and you
    are now modifying the maintainer scripts to clean up the obsolete
    file, prior-version should be based on the version of the package
    that you are now preparing, not the first version of the package
    that lacked the conffile.

    For example, for a conffile removed in version 2.0-1 of a package,

    prior-version should be set to 2.0-1~. This will cause the conffile
    to be removed even if the user rebuilt the previous version 1.0-1 as
    1.0-1local1. Or a package switching a path from a symlink (shipped
    in version 1.0-1) to a directory (shipped in version 2.0-1), but
    only performing the actual switch in the maintainer scripts in
    version 3.0-1, should set prior-version to 3.0-1~.

So 7.22.0-3~ should have been used for the version number, but
for the next upload it should be 7.22.0-4~ or similar instead.


Thanks for the clarification. I think you meant that I should have used 
prior-version "7.21.0-3~" instead of "7.21.0.2~", because the first 
version of the package with the service renamed was "7.21.0-3", and that 
is also the version where I added those lines in d/puppet-agent.maintscript.


I'll adjust the prior-version to "7.22.0-4~" in my next upload, 
hopefully that fixes things.


-- Jérôme

Bug#1030289: Problems with the debian entry of the efi partition in the bios of my laptop.

[Lester Carballo Perez]

Package: installation-reports

Boot method: USB
Image version: 
https://chuangtzu.ftp.acc.umu.se/debian-cd/current/amd64/iso-dvd/debian-11.6.0-amd64-DVD-1.iso
and 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-dvd/firmware-testing-amd64-DVD-1.iso
Date: 31 of January of 2023.

Machine: Laptop Acer Predator Helios 300 Model: PH315-52-78VL
Processor: Core i7 9750H
Memory: 32 Gigabytes Kingstom.
Partitions:
Filesystem Type 1K-blocks   Used Available Use% Mounted on
tmpfs  tmpfs  3270700   2152   3268548   1% /run
/dev/nvme0n1p6 ext4 251539272   10365464 228323480   5% /
tmpfs  tmpfs 16353496  0  16353496   0% /dev/shm
tmpfs  tmpfs 5120  4  5116   1% /run/lock
/dev/nvme0n1p7 ext4 150566544 107648 142737732   1% /home
/dev/nvme0n1p8 ext41006443296  324054732 631190356  34% /Data
/dev/nvme0n1p2 vfat 98304  59777 38527  61% /boot/efi
/dev/sda1  fuseblk 1953513468 1299611536 653901932  67% /Datos
tmpfs  tmpfs  3270696   2420   3268276   1% /run/user/1000

Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor
Host Bridge/DRAM Registers [8086:3ec4] (rev 07)
00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core
Processor PCIe Controller (x16) [8086:1901] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation
CoffeeLake-H GT2 [UHD Graphics 630] [8086:3e9b]
00:04.0 Signal processing controller [1180]: Intel Corporation Xeon
E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem
[8086:1903] (rev 07)
00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6
/ E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
[8086:1911]
00:12.0 Signal processing controller [1180]: Intel Corporation Cannon
Lake PCH Thermal Controller [8086:a379] (rev 10)
00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB
3.1 xHCI Host Controller [8086:a36d] (rev 10)
00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared
SRAM [8086:a36f] (rev 10)
00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Lake
PCH Serial IO I2C Controller #0 [8086:a368] (rev 10)
00:15.1 Serial bus controller [0c80]: Intel Corporation Cannon Lake
PCH Serial IO I2C Controller #1 [8086:a369] (rev 10)
00:16.0 Communication controller [0780]: Intel Corporation Cannon Lake
PCH HECI Controller [8086:a360] (rev 10)
00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake Mobile
PCH SATA AHCI Controller [8086:a353] (rev 10)
00:1b.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI
Express Root Port #21 [8086:a32c] (rev f0)
00:1d.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI
Express Root Port #13 [8086:a334] (rev f0)
00:1d.5 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI
Express Root Port #14 [8086:a335] (rev f0)
00:1f.0 ISA bridge [0601]: Intel Corporation HM470 Chipset LPC/eSPI
Controller [8086:a30d] (rev 10)
00:1f.3 Audio device [0403]: Intel Corporation Cannon Lake PCH cAVS
[8086:a348] (rev 10)
00:1f.4 SMBus [0c05]: Intel Corporation Cannon Lake PCH SMBus
Controller [8086:a323] (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake
PCH SPI Controller [8086:a324] (rev 10)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116M
[GeForce GTX 1660 Ti Mobile] [10de:2191] (rev ff)
01:00.1 Audio device [0403]: NVIDIA Corporation TU116 High Definition
Audio Controller [10de:1aeb] (rev ff)
01:00.2 USB controller [0c03]: NVIDIA Corporation TU116 USB 3.1 Host
Controller [10de:1aec] (rev ff)
01:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU116 USB
Type-C UCSI Controller [10de:1aed] (rev ff)
06:00.0 Non-Volatile memory controller [0108]: Kingston Technology
Company, Inc. Device [2646:5013] (rev 01)
07:00.0 Ethernet controller [0200]: Qualcomm Atheros Killer E2500
Gigabit Ethernet Controller [1969:e0b1] (rev 10)
08:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6
AX210/AX211/AX411 160MHz [8086:2725] (rev 1a)

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [0]
Detect network card:[0]
Configure network:  [0]
Detect CD:  [ ]
Load installer modules: [0]
Detect hard drives: [0]
Partition hard drives:  [0]
Install base system:[0]
Clock/timezone setup:   [0]
User/password setup:[0]
Install tasks:  [0]
Install boot loader:[0]
Overall install:[0]

Comments/Problems:

The problem is that the efi entry of debian is shown incorrectly in
the bios (a blank line instead of the name) or the bios doesn't not
responded correctly (showing a wrong numbers of entries and labels) or
the bios doesn't load when the Debian entry of the efi partition is
selected. In the last case it only shows a blank screen and I need to
power off the laptop.

I noticed this problem when 

Bug#1030212: puppet-agent: conffiles not removed: /etc/init.d/puppet-agent /etc/default/puppet-agent

[Paul Wise]

On Wed, 2023-02-01 at 08:22 -0500, Jérôme Charaoui wrote:

> Specifically, I added to d/puppet-agent.maintscript:
> 
>  mv_conffile /etc/default/puppet-agent /etc/default/puppet 7.21.0-2~
>  mv_conffile /etc/init.d/puppet-agent /etc/init.d/puppet 7.21.0-2~
> 
> Do you know why this isn't working as intended?

According to the dpkg-maintscript-helper manual page:

   If the conffile has not been shipped for several versions, and you
   are now modifying the maintainer scripts to clean up the obsolete
   file, prior-version should be based on the version of the package
   that you are now preparing, not the first version of the package
   that lacked the conffile.
   
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1 as
   1.0-1local1. Or a package switching a path from a symlink (shipped
   in version 1.0-1) to a directory (shipped in version 2.0-1), but
   only performing the actual switch in the maintainer scripts in
   version 3.0-1, should set prior-version to 3.0-1~.

So 7.22.0-3~ should have been used for the version number, but
for the next upload it should be 7.22.0-4~ or similar instead.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1030288: dpkg should depend on debhelper >= 13.10 to build

[Tianyu Chen]

Package: dpkg
Version: 1.19.7.11-1+dde
Severity: normal

Hi,

When build dpkg 1.21.19 on Deepin 23 alpha, it shows that dpkg fails to
build on dh_installchangelogs --no-trim. The --no-trim option was
introduced in debhelper 13.10. dpkg should depeng on debhelper >= 13.10
to avoid build failures.

Best regards,
Tianyu Chen

-- Package-specific info:
System tainted due to merged-usr-via-symlinks.

-- System Information:
Distributor ID: Deepin
Description:Deepin 23
Release:23
Codename:   beige
Architecture: x86_64

Kernel: Linux 5.18.17-amd64-desktop-hwe (SMP w/16 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information


signature.asc
Description: PGP signature

Bug#995718: grub2: enable RISC-V support: patch Merge Request

[YF X]

Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org


Hi, I have made a MR for these patches, could you please take a look at them?

https://salsa.debian.org/grub-team/grub/-/merge_requests/31

Many thanks.

Yifan Xu

Bug#1030287: simple-cdd: What if reprepro_retries is reached?

[Arnaud Rebillout]

Package: simple-cdd
Version: 0.6.8
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: vagr...@debian.org

Dear Maintainer,

Looking at tools/mirror/reprepro [1], I see that this script runs
'reprepro update' in a loop, until reprepro_retries (default: 20) is
reached.

However, it's a bit strange that, if ever reprepro_retries is reached,
the code doesn't error out with a message such as "There are still
dependencies missing after $i attempts!". Instead, the script silently
keeps going, and exits with zero, as if there was no problem.

I'd suggest to either:
- error out when reprepro_retries is reached, as suggested above.
- if it's not considered an error, at least print a message to say that
  reprepro_retries was reached, and clarify that it's not a problem.

This is not a theoretical situation. I looked at the logs from the Kali
Linux daily builds, and for some builds it took 20 attempts, so it seems
likely that for some builds it would have taken more attempts.

I can submit a patch if needed,

Thanks!

[1]: 
https://salsa.debian.org/debian/simple-cdd/-/blob/master/tools/mirror/reprepro

Bug#999485: firmware-brcm80211: Please add brcmfmac43456-sdio.* files as it's not just used in RPi devices

[Gunnar Wolf]

Hi!

Diederik de Haas dijo [Tue, Jan 31, 2023 at 10:33:41PM +0100]:
> > Would they fit into a separate source package not associated with
> > raspi-config?
> 
> I do strongly think they do not belong in the raspi-firmware package for the 
> reason I retitled this bug and retitled my response Subject. Another reason 
> is 
> that the raspi-firmware package makes (several) assumptions, namely that they 
> are only used/usable on RPi devices and have a /boot/firmware directory 
> (where 
> a FAT partition is mounted, although that part is not checked for).
> I have previously expressed my concerns/doubts about that, but that's outside 
> the scope of this bug.
> It also looks 'weird' to install the raspi-firmware package while you only 
> care 
> about the wifi firmware and not care about RPi's at all.

Right, I agree this should be a package of its own. I didn't know
raspi-nonfree came from a "coherent" set of firmware sources provided
by a single upstream. It is a distorsion that peopleinterested in
brcmfmac firmware have to install raspi-firmware if they have
different hardware.

> > The other option is that they get included upstream in
> > linux-firmware.git by upstream?
> 
> Gunnar knows I'm not much of a fan of Raspberry Pi Foundation (RPF) and that 
> was confirmed once again by their typical reaction to this exact request. 
> 
> I'm too 'lazy' to look it up, so I'll paraphrase it:
> "It works for us (so fsck off). Can't you just use our files?"

I doubt we will find true RPF fans here 


signature.asc
Description: PGP signature

Bug#1030286: ITP: libtext-capitalize-perl -- routines for title-like formatting of strings

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtext-capitalize-perl
  Version : 1.5
  Upstream Author : Joseph Brenner 
* URL : https://metacpan.org/release/Text-Capitalize
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : routines for title-like formatting of strings

Text::Capitalize provides some routines for title-like formatting of strings.
The simple capitalize function just makes the initial character of each word
uppercase, and forces the rest to lowercase.

The capitalize_title function applies English title case rules (discussed
below) where only the "important" words are supposed to be capitalized. There
are also some customization features provided to allow the user to choose 
variant
rules.

See also:
 https://metacpan.org/pod/Text::Autoformat
 https://metacpan.org/pod/Lingua::EN::NameParse

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1030193: lintian: Overriding for prefer-uscan-symlink is not possible

[Axel Beckert]

Control: reassign -1 libregexp-wildcards-perl 1.05-3
Control: retitle -1 libregexp-wildcards-perl: Does not escape backslash before 
fullstop, but elsewhere
Control: affects -1 lintian
Control: tag -1 upstream

Hi Eriberto,

Joao Eriberto Mota Filho wrote:
> Package: lintian
> Version: 2.116.2
[…]
> After this change[2], lintian said me:
> 
> X: obs-downstream-keyer source: prefer-uscan-symlink filenamemangle 
> s/.*muted..([\d\.]+)..span./@PACKAGE@-$1\.tar\.gz/ [debian/watch:19]
> 
> After I make an override, litian said me:
> 
> W: obs-downstream-keyer source: mismatched-override prefer-uscan-symlink 
> filenamemangle s/.*muted..([\d\.]+)..span./@PACKAGE@-$1\.tar\.gz/ 
> [debian/watch:19] [debian/source/lintian-overrides:4]
> X: obs-downstream-keyer source: prefer-uscan-symlink filenamemangle 
> s/.*muted..([\d\.]+)..span./@PACKAGE@-$1\.tar\.gz/ [debian/watch:19]

Can reproduce if I copy the emitted tag literally into
debian/source/lintian-overrides although it should work as override:

  prefer-uscan-symlink filenamemangle 
s/.*muted..([\d\.]+)..span./@PACKAGE@-$1\.tar\.gz/ [debian/watch:19]

With a bit of debug code (I added "die $re if $glob =~ /file/;" into
lib/Lintian/Utils.pm around line 404) it shows me that the override
was converted into this regular expression:

  filenamemangle 
s\/\..*muted\.\.\(\[\\d\.\]\+\)\.\.span\.\/\@PACKAGE\@\-\$1\.tar\.gz\/ 
\[debian\/watch\:19\]

Looks as expected to me on a first glance, but actually all occurences
of "\." are not properly converted to "\\\." while "\d" is properly
converted to "\\d". I can also reproduce with this minimal reproducer:

  $ perl -MRegexp::Wildcards -E 'my $rw = Regexp::Wildcards->new(type => 
"jokers"); say $rw->convert(q{\.\d})'
  \.\\d

So this actually seems to be a bug in libregexp-wildcards-perl. Hence
reassigning.

> Consequently, is not possible to make an override for
> prefer-uscan-symlink filenamemangle.

Sure it is, just replace all the ugly stuff with an asterisk or omit
all parameters after the tag name. All these overrides work for me:

  prefer-uscan-symlink filenamemangle s/*/ [debian/watch:19]
  prefer-uscan-symlink filenamemangle * [debian/watch:19]
  prefer-uscan-symlink filenamemangle *
  prefer-uscan-symlink

> I think that lintian is interpreting my REGEX.

Yes and no. It interprets only "*" and "?" and these have the same
meaning as with shell wildcards. It's actually the "jokers" mode of
the Perl module Regexp::Wildcards.

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

Bug#1030277: [dget] Can’t parse deb822-style .sources files

[Tianyu Chen]

On Wed, Feb 01, 2023 at 10:40:08PM +0100, David Prévot wrote:
> dget parser assumes one-line-style format of sources.list:
> 
> $ dget apt
> no repository found in /etc/apt/sources.list or sources.list.d at 
> /usr/bin/dget line 378.

Is this a duplicate with #976673?

Best regards,
Tianyu Chen


signature.asc
Description: PGP signature

Bug#1030285: bsdutils: logger: regressed to reusing initial timestamp

[Thorsten Glaser]

Package: bsdutils
Version: 1:2.38.1-4
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I *know* we had this bug already, and it got fixed at some time,
but apparently a regression was introduced and this bug shows up
again in sid: long-running logger(1) sessions do not receive an
updated timestamp for later lines:

root@ara4:~ # tail -F /var/log/syslog&
root@ara4:~ # (echo foo; sleep 5; echo bar) | logger -t baz
Feb  2 02:04:24 ara4 baz: foo
Feb  2 02:04:24 ara4 baz: bar

Compare bullseye:

tglase@x61w:~ $ (echo foo; sleep 5; echo bar) | logger -t baz
Feb  2 03:04:45 x61w baz: foo
Feb  2 03:04:50 x61w baz: bar

I use “dæmonprogram | logger -t nameofthat” quite often, and
having output with ancient timestamps suddenly show up in logs
is confusing (especially fail2ban very much dislikes that).

For the sake of completeness, the bullseye system uses
inetutils-syslogd 2:2.0-1+deb11u1, the sid system has
inetutils-syslogd 2:2.4-2, but TTBOMK the timestamp is
generated by logger(1), not the syslog dæmon (that would
be weird).


-- System Information:
Debian Release: bookworm/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k

Kernel: Linux 6.1.0-2-m68k (UP)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages bsdutils depends on:
ii  libc62.36-4+ports
ii  libsystemd0  252.4-1

Versions of packages bsdutils recommends:
ii  bsdextrautils  2.38.1-4

bsdutils suggests no packages.

-- no debconf information

Bug#807071: util-linux: please allow term-utils/script.c without signalfd (needed for kFreeBSD and Hurd)

[Thorsten Glaser]

Karel Zak dixit:

>On Thu, Oct 24, 2019 at 12:38:51AM +, Thorsten Glaser wrote:
>> you were involved in changing script(1) to use signalfd, which
>> is apparently Linux-specific but util-linux also is used, at
>> least in Debian, on other kernels, such as the FreeBSD and Hurd
>> ones (FSVO “kernel”, for the latter).
>
>The problem is that with signalfd it's more reliable than when
>classic signals interrupt any syscall, but I have no problem to
>support any #ifdefs for non-signalfd systems.
>
>I have added this request to our TODO file. We'll see.

How’s this progressing?

Thanks in advance,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Thorsten Glaser]

Package: nodejs
Version: 18.13.0+dfsg1-1
Severity: serious
Tags: upstream
Justification: breaks on release architecture
X-Debbugs-Cc: t...@mirbsd.de
Control: affects -1 src:dygraphs

During reproducible-builds testing, I found that one of my packages,
the one with nodejs used during build, worked on amd64 (which the
arch:all packages are built on), i386, armhf(!) but not on arm64.
Testing on the porterbox reveals that indeed nodejs fails there.

To reproduce, easiest way:

$ apt-get source dygraphs  # = 2.2.0-4
$ cd dygraphs-2.2.0
$ babeljs --config-file $PWD/babel.config.json --compact false --source-maps 
inline -d tests5 auto_tests

Omitting --compact false and --source-maps inline can also be done,
the bug is triggered nevertheless:

RangeError: Maximum call stack size exceeded
 
at NodePath.getScope 
(/usr/share/nodejs/@babel/traverse/lib/path/index.js:84:11) 

at NodePath.setScope 
(/usr/share/nodejs/@babel/traverse/lib/path/context.js:115:21)  

at NodePath.setContext 
(/usr/share/nodejs/@babel/traverse/lib/path/context.js:128:8)   
  
at NodePath.pushContext 
(/usr/share/nodejs/@babel/traverse/lib/path/context.js:183:8)   
 
at TraversalContext.visitQueue 
(/usr/share/nodejs/@babel/traverse/lib/context.js:78:14)  
at TraversalContext.visitSingle 
(/usr/share/nodejs/@babel/traverse/lib/context.js:65:19) 
at TraversalContext.visit 
(/usr/share/nodejs/@babel/traverse/lib/context.js:109:19)   
   
at traverseNode 
(/usr/share/nodejs/@babel/traverse/lib/traverse-node.js:18:17)  
 
at NodePath.visit 
(/usr/share/nodejs/@babel/traverse/lib/path/context.js:86:52)   
   
at TraversalContext.visitQueue 
(/usr/share/nodejs/@babel/traverse/lib/context.js:86:16)  

There are numerous references to nodejs failing in this way on arm64
platforms, normal Linux but even on Android as well, on the internet;
h01ger said several other nodejs-using packages FTBFS on arm64 in the
same way during reproducible-builds testing.

I consider this an architecture-specific release-critical bug. Maybe
having a reproducer and access to a porterbox will allow a nodejs
maintainer to track this down.



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-21-arm64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages nodejs depends on:
ii  libc6   2.36-8
ii  libnode108  18.13.0+dfsg1-1

Versions of packages nodejs recommends:
ii  ca-certificates  20211016
pn  nodejs-doc   

Versions of packages nodejs suggests:
pn  npm  

-- no debconf information

Bug#1030283: reportbug: byobu-select-session does not honor .always-select, creates minimal screen session

[Jon Brase]

Package: byobu
Version: 5.133-1
Severity: normal

Dear Maintainer,

I use zsh as my login shell and have the following line in
.zprofile on two machines:

[[ -o interactive ]] && byobu-select-session && exit 0

One machine runs Ubuntu 20.04, and byobu-select-session works as
expected on that machine. The other runs Debian 11. On the
Debian 11 machine, byobu-select session exhibits the following
behavior on login:

1) Despite ~/.byobu/.always-select being present, the session
selection menu is only presented if multiple screen sessions
already exist.

2) The screen session that is created appears to be identical to
that created by an invocation of vanilla screen: no status bar
is present and byobu-specific keybindings are ignored. This does
*not* occur if byobu is launched directly, only if it is
launched through byobu-select-session

The default ~/.byobu/profile on the affected machine sourced a
non-existent file in ~/.byobu. In an attempt to resolve the
issue, I replaced it with the ~/.byobu/profile from the Ubuntu
machine where byobu-select-session is working, this had no
effect.

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

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

Versions of packages byobu depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  gawk   1:5.1.0-1
ii  gettext-base   0.21-4
ii  iproute2   5.10.0-4
ii  python33.9.2-3
ii  python3-newt   0.52.21-4+b3
ii  tmux   3.1c-1+deb11u1

Versions of packages byobu recommends:
ii  less551-2
ii  pastebinit  1.5.1-1
pn  run-one 
ii  sensible-utils  0.0.14

Versions of packages byobu suggests:
pn  apport  
pn  ccze
pn  gnome-terminal | xterm  
ii  gnupg   2.2.27-2+deb11u2
ii  lsb-release 11.1.0
ii  po-debconf  1.0.21+nmu1
ii  screen  4.8.0-6
pn  speedometer 
pn  ttf-ubuntu-font-family  
pn  update-notifier-common  
ii  vim 2:8.2.2434-3+deb11u1
pn  wireless-tools  

-- debconf information excluded

Bug#1030282: non-free-firmware needs to be mentioned

[Osamu Aoki]

Source: debian-reference
Version: 2.99
Severity: normal

On /etc/apt/sources.list, we now need to mention non-free-firmware 
  * add non-free-firmware to example /e/a/s.l
  * add description of non-free-firmware

Also, since GNOME has migrated to use pipewire, this may need updates:
  * remove standard from pulseaudio side description
  * remove experimental from pipewire side description
  * pipewire-audio-client-libraries -> pipewire-alsa, pipewire-jack

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/12 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1030253: gnome-control-center: Creating a user via "gnome-control-center user-accounts" results in a user with shell set to nologin

[Simon McVittie]

Control: severity -1 serious
Control: tags -1 + patch pending

On Wed, 01 Feb 2023 at 19:53:32 +, Simon McVittie wrote:
> If I understand correctly, what gnome-control-center wants to do is
> to create a user with an invalid password (unable to log in), and then
> as a separate D-Bus transaction, do something to its password: either
> change the password, or put it into a state where the user can log in
> unauthenticated and will be prompted for a new password.
> 
> Probably it should now be using --disabled-password instead of
> --disabled-login to get that effect? adduser maintainers: is my guess
> correct?

Looking at adduser source code, it seems I was right about that being
the desired change. Fix pending in
https://salsa.debian.org/freedesktop-team/accountsservice/-/commit/9a479abc241af68ea2fc7e8ec896ac0ab2a39c58

> For now I'm only escalating this to important, but I think it probably
> deserves to be RC for accountsservice.

This triggered #1030262, which I think is enough to make it RC.

smcv

Bug#1030224: Inverted test for /etc/runit/no.emulate.sysv in /etc/runit/2

[Lorenzo]

Hi,

On Wed, 1 Feb 2023 11:35:17 +0100
Andras Korn  wrote:

> (I still also think that /etc/sv is the wrong place to check; the
> directory monitored by runsvdir, e.g. /etc/service, could contain a
> symlink to a service that resides somewhere else, not in /etc/sv/,
> and the existence of such a symlink should also cause the initscript
> invocation to be skipped.)

Please see my last message/idea in #1022837 and comment there
> 
> For this particular issue in /etc/runit/2, I recommend just replacing
> the || with &&, so the snippet becomes:

Done in git, will be in *-54, thanks for catching this

> András
> 

Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login

[Simon McVittie]

Control: retitle -1 accountsservice: User that seemed to have been deleted via 
gnome-control-center can still login
Control: reassign -1 accountsservice 22.08.8-1
Control: affects -1 gnome-control-center
Control: forwarded -1 
https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/107

On Wed, 01 Feb 2023 at 22:32:40 +, Simon McVittie wrote:
> When accountsservice is deciding whether an account is local, it assumes
> that the only accounts that are local are the ones in its list of accounts
> from /etc/shadow, *after* filtering.
...
> I think this is a bug.

I think this is the main cause here, and from source code inspection,
there are probably ways to trigger it even without Debian's patches.
Reported upstream as
https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/107

> gnome-control-center is not exactly helping here, by not having a
> particularly clear indication of whether it thinks an account is local
> or remote

I reported https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2326
but I think that's out-of-scope for this bug report (and realistically
we are not going to redesign this piece of UI before bookworm). If anyone
wants to work on that, please take it upstream.

smcv

Bug#1030281: puppet-agent: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: puppet-agent
Version: 7.22.0-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for puppet-agent's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


puppet-agent_7.22.0-3.pt.po.gz
Description: application/gzip

Bug#1029752: tests fail with nmh 1.8~RC-2, blocking nmh from entering testing

[Alexander Zangerl]

severity 1029752 normal
thanks

to expand on this issue a little: the autopkgtest is legitimately
indicating a regression in nmh, where a set-but-empty $HOME
is treated differnt (= as fatal exception) from an unset $HOME variable.

this has triggered a long discussion on upstream's mailing list
about the desirable/least-surprising behaviour.

stephen's already adjusted xlbiff's behaviour for greater robustness
in a pending release.

for consistency i've also addressed this in nmh version 1.8~RC2-2,
which falls back to getpw*() for both set-but-empty and unset $HOME.

regards
az





-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
> Hi, my name is Rebecca, and I'm a computing whore. -- Rebecca Gray
If I pay you twenty bucks, will you blow my EPROM? -- Joe


signature.asc
Description: Digital Signature

Bug#1030271: dpkg-buildpackage: misleading error message when no signing key available

[Thorsten Glaser]

Guillem Jover dixit:

>report. Is this about the "secret key not available" vs the
>"key is not signature-capable"?

Yes, exactly: “secret key not available” is correct, the key
is only on one separate machine, “key is not signature-capable”
(reported by dpkg-buildpackage) is wrong. Sorry for not being
clear initially.

This is cosmetic, of course.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#990447: Similar problems

[Phil Dibowitz]

I'm also unable to update to the latest uefi-dbx:

```
$ fwupdmgr update
...
Blocked executable in the ESP, ensure grub and shim are up to date: 
/boot/EFI/EFI/debian/shimx64.efi Authenticode checksum 
[af79b14064601bc0987d4747af1e914a228c05d622ceda03b7a4f67014fee767] is 
present in dbx

```

I am on the latest shims though:

```
root@rider:/boot/EFI/EFI/debian# dpkg -l | awk '/ shim/ {print $1" 
"$2"\t\t"$3}'

ii node-set-immediate-shim  2.0.0-2
ii shim-helpers-amd64-signed1+15.6+1
ii shim-signed:amd641.38+15.4-7
ii shim-signed-common   1.38+15.4-7
ii shim-unsigned15.7-1
```

And I've run `grub-install` with my EFI dir mounted. What's interesting 
is the version in EFI is different than the version staged by the package:


```
# sum /usr/lib/shim/shimx64.efi /boot/EFI/EFI/debian/shimx64.efi
47979   918 /usr/lib/shim/shimx64.efi
36147   913 /boot/EFI/EFI/debian/shimx64.efi
```

I even explicitly ran it with `--uefi-secure-boot` to ensure it installs 
the shim binary.


--
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#1030225: /etc/runit/2 assumes it runs in an environment that can mount filesystems

[Lorenzo]

Hi,

On Wed, 1 Feb 2023 11:43:43 +0100
Andras Korn  wrote:


> /etc/runit/2 ships with this snippet:
> 
> mkdir -p /run/runit/supervise
> mkdir -p /run/runit/sv
> mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv
> cp -a /etc/sv/* /run/runit/sv/  #TODO do this with
> 'CPSV_DIR=/run/runit/sv cpsv --sync'
> 
> If runit is used in an unprivileged container,
with runit you mean runit as init or simply respawn runsvdir via stage
2?

The mount can be moved to stage 1, where other mount invocations already
happen; however this will cause a relevant difference when runit is
used as init vs when only stage 2/runsvdir is run..

> the mount command may
> fail. Currently this is just a cosmetic problem (/lib/runit/sv will
> not be a separate filesystem and an error will be printed), but
> please don't start depending on this mount succeeding.

Noted; that was a preliminary step for a development that didn't
happen so far (because of the complexity, the freeze approaching and
also because of your comments in #1022837); for now I'm just removing or
commenting those lines, for the future (after bookworm releaee) I still
have to think about it.
> 
> Please also provide some reasoning (e.g. in a README.Debian file) why
> you're doing this at all, what the motivation is.

I'm not going to write a README.Debian for something that is not there
(yet), but I'm providing one here:

 ---RATIONALE-

> mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv
the idea is to have a copy of services there and to run services there,
like /etc/service points to /etc/runit/runsvdir/deafult.run that
contains links to directories in /run/runit/sv/

without that mount line:
Problem 1: run is mounted 'noexec', so each runsv fails
Problem 2: there are mechanism (cpsv) that copy services in /run
 and by limiting the size I want to avoid that an abuse of such
 mechanism could result in eating all space in /run mount (very
 unlikely but still..)

Reasons why I'm thinking of running services in /run/runit/sv/ :

A) anything in /etc/sv is a conffile, so special care is needed when
  upgrade happens to detect and not overwrite local changes. That is
  handled by dpkg or ucf, but they work on files, while a service for
  runit is a directory. I think ideally the entire service should be
  considered locally modified if the run file (or finish, or control/*
  and probably also log/run) has local changes.
  I can think of many ways to break a service by retaining the local
  version of a run file while finish or control/* are changed/upgraded.
  

B) related to A, but different problem: think of what happens if a
  foo service crashes while dpkg is upgrading (file by file) the service
  directory: the automatic restart performed by runsv can exec a mix of
  old and new files inside foo directory, with unexpected results like
  in A, but temporary (only during the upgrade).
  Ideally the entire service directory should be updated atomically but
  that requires to address the old.directory with a symlink, creating a
  new.directory on upgrade and swap the symlink old-->new.
  
Also a plus would be a setup that works on a system where /etc is
stateless or mounted readonly.

As a possible solution to A and B I thought something like:

A 3 layer services setup, like
  [stock]  /usr/share/runit/sv/  --> original copy managed by dpkg
  [local]  /etc/sv/  --> local modified copy, if any
  [live]   /run/runit/sv/--> copy supervised by runsv
  where /etc/sv can be empty, and [live] is populated with copies of
  services from [local] if any, from [stock] otherwise.

the above allow me (maintainer) to upgrade the [live] copy for service
foo with [stock] unless [local] foo exists; much simpler than when
the service in under /etc/sv
It also separates service directories supervised by runsv and services
directories managed by dpkg (necessary to fix both A and B).

Also to address B /run/runit/sv can be a symlink to a timestamped
/run/runit/sv.time dir that contains copies of services dirs; each
upgrade adds a new sv.time dir  and switches the symlink to the
new sv.time(you can roll back a service dir upgrade, there will be
multiple sv.time under /run/runit and so on); again it avoid the added
complexity of conffiles ( and a pile of sv.time dirs that accumulates
under /etc/)



right now I'm taking some time to think about this: nobody complained
so far about A or B [1], no runit user requested any of the above
features; there is added complexity with this setup and it requires a
relevant effort on my side. Also,some people will likely be unhappy
about this. Overall I'm tempted to just sit and wait until someone
complains and spend my time to solve other runit issues meanwhile.

[1] I think a large number of users and dpkg-provide services are
needed to trigger A or B; none of the two is true right 

Bug#1030280: general: General non-recognized errors (im novice) after the installation: drivers, battery, booting errors...

[Miguel González Jiménez]

Package: general
Severity: normal
X-Debbugs-Cc: migui...@hotmail.com

Dear Maintainer,

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

   * What led up to the situation?
After the installation, I proceed to use the hardware and no correct firmware 
had been installed. Couldn't use neither the touchpad, the wifi card (AX200 
Intel) nor several screen caracteristics.
I've tried to install its drivers but they dont work. I think something went 
wrong during the installation. Besides, battery is running out quite fast and 
fans are most of the time active. After installing wifi card Intel drivers, 
booting errors has became to show up on the log booting screen, refeering bugs 
about usb and bluetooth ports.
The partition on the solid disk (what also holds Windows 10) has been made fine 
I think.

Bug#1017533:

[Nicholas Brown]

This was resolved in dh-cargo 29

Bug#1030279: ITP: hud -- Backend for the Unity/Lomiri HUD

[Mike Gabriel]

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

* Package name: hud
  Version : 14.10+17.10.20170619
  Upstream Author : Canonical Ltd.
* URL : 
https://code.launchpad.net/~indicator-applet-developers/hud/trunk.15.10
* License : GPL-3
  Programming Lang: C++
  Description : Backend for the Unity/Lomiri HUD

 Unity HUD is a heads-up-display interface for controlling the behavior of
 applications as well as Unity via typed-in commands. It provides access to
 all applications menu via a single central interface, in order to simplify
 application usage and make menus more accessible.
 .
 This package is needed by Lomiri's Action API.
 .
 The package will be maintained by the UBports Packaging Team.

Bug#667616: greedy brltty

[Samuel Thibault]

Lukasz Stelmach, le mer. 01 févr. 2023 11:27:41 +0100, a ecrit:
> Recently installed Debian 11 still has this problem.

If you had your serial adapter plugged in during installation, yes,
sure. Otherwise we need your installation logs to determine why brltty
got installed on your system.

Samuel

Bug#1030092: nvme-cli: nvme list json output contains wrapped-around negative integers

[Daniel Swarbrick]

Just following up on this; I see that nvme-cli 2.3-2 fixes the build, 
and I can confirm that the numeric values no longer wrap around to 
negative values.


As an aside, I also noticed that the JSON output "string" numeric values 
(e.g. the 128-bit NVMe counters which would lose accuracy if rendered as 
float64 JSON numbers) are now localized, i.e. include thousands 
separators. This is a bit peculiar to see in machine-readable JSON 
output, but easily worked around by setting LC_NUMERIC=C.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030278: puppetserver: please patch the output of "puppetserver ca --help" to refer to the path Debian uses

[Louis-Philippe Véronneau]

Package: puppetserver
Severity: wishlist
Version: 7.9.4-1

Dear maintainers,

When running "puppetserver ca --help", the help message includes the 
following line:


migrate Migrate the existing CA directory to /etc/puppetserver/ca

We are not using the `/etc/puppetserver` path in Debian, and instead 
chose to use `/etc/puppet/puppetserver`.


This should be patched not to confuse people.

Cheers,

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1029594: Fails to authenticate mit o365

[Carsten Schoenert]

Am Wed, Feb 01, 2023 at 03:24:14PM + schrieb Nicola Chiapolini:
> Control: severity -1 serious
> 
> Hi Carsten
> 
> I am increasing the severity again. This bit me today. 
> I rely on apt-listbugs to protect me from such problems and with the default 
> settings "normal" is not sufficient to trigger listbugs. 
> Yesterday, #1030112 triggered listbugs, so today I was happy to see that the 
> problem is fixed and upgraded. So I try to help others...
> (Since the only reason I use Thunderbird in the first place is to access 
> o365, this bug might even be considered grave ;-)

I'm considering this issue is normaly just of severity important.

Quoting https://www.debian.org/Bugs/Developer.en.html

important
a bug which has a major effect on the usability of a package, without 
rendering it completely unusable to everyone

And that's what this issue is about, most of the users can use
Thunderbird without problems.

But, using severity important would allow to migrate the package to
testing and more users would be affected by the issue. So I'm fine with
keeping the current severity.

On the other hand you should consider to not use unstable as prefered
Debian release in case you are depening an always usable packages.

Currently I still don't have an idea when a fixed version will be
available.

Regards
Carsten

Bug#1030249: unexpected "prefclean output on ..." emails since bookworm upgrade

[Francesco Poli]

Control: severity -1 wishlist


On Wed, 01 Feb 2023 10:25:21 -0500 Antoine Beaupre wrote:

> Package: apt-listbugs
> Version: 0.1.40
> Severity: minor

Hello Antoine!
Thanks for your bug report.   :-)

> 
> Since I'm running bookworm, apt-listbugs started pestering me with
> emails that look like this:
> 
> Date: Wed, 01 Feb 2023 07:25:20 -0500
> From: apt-listbugs timer 
> To: r...@anarc.at
> Subject: prefclean output on curie
> 
> /usr/libexec/apt-listbugs/prefclean:
>  Paquets corrigés : breeze kactivitymanagerd ksshaskpass kwayland-integration 
> polkit-kde-agent-1
> 
> That "Paquets corrigés" string there means "Fixed packages" in
> english.

Yes, it's in the French translation catalog of messages.

> I've traced it down to /usr/libexec/apt-listbugs/aptcleanup,
> itself called from /usr/libexec/apt-listbugs/prefclean which
> specifically makes a point of explicitely writing an email if you're
> running under systemd.

It does so, in order to provide an equivalent functionality with
respect to the cron.daily job, which runs if you are _not_ running
under systemd.
By default, cron jobs have their output sent by (local) mail, if any
output is produced.
When I implemented the equivalent systemd timer, I had to manually
implement the output-mailing feature...

I must admit that I am somewhat surprised that you see all these mail
notifications about fixed packages as something new.
apt-listbugs has notified root by (local) mail about fixed packages for
ages. Through the cron job mechanism and, starting from 2019, through
the manually-implemented mailing in the systemd timer.

So, I wonder what has changed in your box, when you began to see these
mail notifications...

> 
> I'd love a way to turn that stuff off or, preferably, have it logged
> normally in syslog/journald. I don't need to be told when those things
> are fixed: I'm assuming apt-listbugs will do its job correctly unless
> otherwise noted. In other words, this is not a failure condition, it's
> actually a *success* condition, and I don't really need to be told
> about those.

Well, it's the first time that someone complains about these mail
notifications.

Personally, I like to be informed, when a bug that I feared has been
fixed, and the fixed package can finally be upgraded on my box.

Anyway, that's a matter of preference, I must admit.
Hence, it may make sense to implement an option to silence those
notifications...

> 
> Could we make this a knob at least? It looks like aptcleanup looks at
> the apt preferences to that might be a good place, but prefclean is
> where the decision is actually mean on how to treat the aptclean
> output, so I'm not sure how best this could be done...

I think that the best place where I can implement the option is
probably an APT preference to be read (via 'apt-config') by aptcleanup,
which would suppress its " Fixed packages:" output.

But I am afraid that this is not the right time to implement that for
bookworm.
I won't introduce such a change during the freeze.
I will probably do so for trixie, after bookworm is released.

In the meanwhile, you could try the attached patch as temporary
workaround for your specific case (the "I do not want any mail
notifications" case).
Please let me know whether it works as intended.

Bye.


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


bug1030249_tempworkaround.diff.xz
Description: application/xz


pgpcMgs0FKmxm.pgp
Description: PGP signature

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[David Kalnischkies]

On Wed, Feb 01, 2023 at 09:32:47PM +0100, Sven Joachim wrote:
> > Maybe the next time he uses apt*, somehow the system should tell him...
> 
> Somehow, but how exactly?

fwiw I intend to have apt print a notice at the end of each
'apt(-get) update' call if certain conditions are met in bookworm.

My branch with details can be found here:
https://salsa.debian.org/apt-team/apt/-/merge_requests/282

It is marked Draft as I mainly need to a) figure out which firmware
packages from bullseye (will have been) moved in bookworm to
non-free-firmware for one of my targeted scenarios and b) have a
reasonably detailed entry in the release notes to link to explaining
what to actually do as I really don't want to get into details in
a one-line message… will be hard enough to cover all bases in a few
paragraphs after all.


A stub for the release-notes can be found in
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/138
although as I noted in a comment there I would prefer a more
detailed §5 entry rather than linking to a rather short §4.


The code isn't exactly rocket-science (although a bit lengthy) & as I
am reusing already existing messages it could theoretically be
backported to bullseye and pushed in a stable update so that users
would see it while upgrading instead of on some run after the upgrade,
but for the moment I am not planing to push for that. I might have if
someone had shown any interest in the idea months ago[0].


The message is rather cryptic, but its intent is to catch unaware
sid/testing users and those stable users who don't read release notes,
so that is borderline okay. If the goalpost is instead moved to every
user of Debian the messages should really not be that cryptic, but that
would mean more work & more diff (not just by me, but e.g. translators).
At this point in time it seems better to focus this energy on the
release notes. Or, on discussing if gmake users are affected, too, …


Best regards

David Kalnischkies

[0] https://lists.debian.org/debian-devel/2022/10/msg00217.html


signature.asc
Description: PGP signature

Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login

[Simon McVittie]

On Wed, 01 Feb 2023 at 21:07:09 +, Simon McVittie wrote:
> Looking briefly at the gnome-control-center code, I think this indicates
> that act_user_is_local_account() is returning false, so instead of deleting
> a local user, gnome-control-center is telling accountsservice to
> "uncache" a remotely-managed (enterprise) user? I don't know what practical
> effect that has, but it doesn't sound like a true "delete" operation?

This seems to be a side-effect of new user accounts accidentally being
created with nologin as their shell (#1030253). This indirectly makes
accountsservice, and therefore gnome-control-center, think that it's
a remotely-managed account (from LDAP or equivalent).

When accountsservice reads /etc/passwd and /etc/shadow, it ignores local
accounts that do not appear to belong to a "human" user (this includes
accounts with nologin as their shell, among others). (It also ignores
local human users above an arbitrary limit of 50, to avoid having a
ridiculously long list.)

However, there are several reasons why accountsservice might have a user
account in its in-memory list, and one of those reasons is that it recently
created the account itself. The accounts listed in its D-Bus API are the
union of everything it has found from multiple sources.

When accountsservice is deciding whether an account is local, it assumes
that the only accounts that are local are the ones in its list of accounts
from /etc/shadow, after filtering. Pseudocode:

local = empty set
interesting = empty set

for account in /etc/shadow:
if account appears human and number of accounts found so far < 50:
local.add(account)
interesting.add(account)

for account in other sources:
interesting.add(account)

for account in interesting:
account.LocalAccount = bool(account in local)

return interesting

I think this is a bug. It should look more like this pseudocode:

local = empty set
interesting = empty set

for account in /etc/shadow:
local.add(account)

if account appears human and number of accounts found so far < 50:
interesting.add(account)

for account in other sources:
interesting.add(account)

for account in interesting:
account.LocalAccount = bool(account in local)

return interesting

or maybe even:

interesting = empty set

for account in /etc/shadow:
if account appears human and number of accounts found so far < 50:
interesting.add(account)

for account in other sources:
interesting.add(account)

for account in interesting:
account.LocalAccount = (getspnam(account.UserName) != NULL)

return interesting

gnome-control-center is not exactly helping here, by not having a
particularly clear indication of whether it thinks an account is local
or remote, and using the same button for deleting a local account (which
literally does delete the account) and removing a remote account from the
cache (which just forgets about the account as being locally relevant,
but does not attempt to delete it from LDAP or whatever remote accounts
database it's using). This is not ideal, but I don't think it's RC
for gnome-control-center.

Meanwhile, gdm3 only lists accountsservice accounts (local or remote)
in its GUI, but lets other accounts log in via "Not listed?". Because
accountsservice wrongly thinks your account is remote, and you used
gnome-control-center to remove the "remote" account from the cache
of interesting accounts, gdm3 stopped listing it.

However, it's still possible to log in with that account, because gdm3
doesn't check whether users' shells are listed in /etc/shells or not.
(Should it? Other entry-point services don't, except indirectly by trying
to run the user's shell and having nologin fail as a result.)

smcv

Bug#1029834: dpkg: cycle found while processing triggers

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Sat, 2023-01-28 at 14:30:15 +0100, Jörg-Volker Peetz wrote:
> Package: dpkg
> Version: 1.21.19
> Severity: normal

> upgrading the openjdk-17 packages on my system with
> 
> # aptitude -t sid install ~Uopenjdk
> 
> gives this error messages:
> 
> dpkg: cycle found while processing triggers:
>  chain of packages whose triggers are or may be responsible:
>   ca-certificates-java -> ca-certificates-java -> ca-certificates-java
>  packages' pending triggers which are or may be unresolvable:
>   ca-certificates-java: /usr/lib/jvm
> dpkg: error processing package ca-certificates-java (--configure):
>  triggers looping, abandoned
> Setting up openjdk-17-jdk-headless:amd64 (17.0.6+10-1) ...
> Setting up ca-certificates-java (20230103) ...
> done.
> Setting up openjdk-17-jre:amd64 (17.0.6+10-1) ...
> Setting up openjdk-17-jdk:amd64 (17.0.6+10-1) ...
> Errors were encountered while processing:
>  ca-certificates-java
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Any ideas?

Was there any other error during the unpack or installation in
general? Do you have the full log of that upgrade session? From what
version were you upgrading from?

Do you perhaps have a backup of the status files from just before that
upgrade session? (Either the /var/lib/dpkg/status-old if you have not
done anything else package-wise since then, or perhaps under
/var/backups.)

Otherwise this unfortunately seems a bit non-actionable to me. :/

Thanks,
Guillem

Bug#1030277: [dget] Can’t parse deb822-style .sources files

[David Prévot]

Package: devscripts
Version: 2.22.2
Severity: normal
Control: user devscri...@packages.debian.org
Control: usertags -i + dget

Hi,

dget parser assumes one-line-style format of sources.list:

$ dget apt
no repository found in /etc/apt/sources.list or sources.list.d at /usr/bin/dget 
line 378.

Regards

taffit

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Empty.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates'), (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.18
ii  fakeroot  1.30.1-1.1
ii  file  1:5.44-2
ii  gnupg 2.2.40-1
ii  gnupg22.2.40-1
ii  gpgv  2.2.40-1
ii  libc6 2.36-8
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.67-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.1-1
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-4

Versions of packages devscripts recommends:
ii  apt 2.5.5
ii  curl7.87.0-2
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.12.24
ii  dput-ng [dput]  1.35
ii  equivs  2.3.1
ii  libdistro-info-perl 1.3
ii  libdpkg-perl1.21.18
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.26-2
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-2
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
ii  licensecheck3.3.5-1
ii  lintian 2.116.1
ii  man-db  2.11.2-1
ii  patch   2.7.6-7
ii  pristine-tar1.50
ii  python3-apt 2.5.2
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-3
ii  python3-requests2.28.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  5.10-1
ii  unzip   6.0-27
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.0

Versions of packages devscripts suggests:
pn  adequate  
ii  at3.2.5-1+b1
ii  autopkgtest   5.27
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20220412cvs-1
ii  build-essential   12.9
pn  check-all-the-things  
pn  cvs-buildpackage  
ii  debhelper 13.11.4
ii  diffoscope233
pn  disorderfs
ii  dose-extra7.0.0-1+b2
pn  duck  
pn  elpa-devscripts   
ii  faketime  0.9.10-2.1
pn  gnuplot   
pn  how-can-i-help
ii  libauthen-sasl-perl   2.1600-3
pn  libdbd-pg-perl
ii  libfile-desktopentry-perl 0.22-3
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3300-2
ii  libyaml-syck-perl 1.34-2+b1
ii  mailutils [mailx] 1:3.15-3+b2
ii  mmdebstrap1.3.1-2
pn  mozilla-devscripts
ii  mutt  2.2.9-1
ii  openssh-client [ssh-client]   1:9.1p1-2
pn  piuparts  
ii  postgresql-client 15+246
ii  postgresql-client-11 [postgresql-client]  11.18-0+deb10u1
ii  postgresql-client-13 [postgresql-client]  13.9-0+deb11u1
ii  postgresql-client-15 [postgresql-client]  15.1-1+b1
pn  

Bug#1030271: dpkg-buildpackage: misleading error message when no signing key available

[Guillem Jover]

Control: tag -1 moreinfo

On Wed, 2023-02-01 at 21:40:23 +0100, Thorsten Glaser wrote:
> Package: dpkg
> Version: 1.21.19
> Severity: minor
> X-Debbugs-Cc: t...@mirbsd.de

> gpg: skipped "Thorsten Glaser ": secret key not available
> gpg: dpkg-sign.IRqYlate/dygraphs_2.2.0-4.dsc: clearsign failed: secret key 
> not available
> dpkg-buildpackage: error: failed to sign dygraphs_2.2.0-4.dsc file: key is 
> not signature-capable
> 
> The error message is a bit misleading here.

Could you expand a bit, it's not directly obvious from the short
report. Is this about the "secret key not available" vs the
"key is not signature-capable"? Either of them? Something else?

Thanks,
Guillem

Bug#1030276: debvm: Add tool to generate qemu images

[Gioele Barabucci]

Package: debvm
Version: 0.2.6
Severity: wishlist

The current output of `debvm-create` is a file containing an ext4 
partition. In order to run the VM a tool like `debvm-run` is needed.


It would be nice if there were a tool in the `debvm` family that could 
turn that partition into a complete disk (with a bootloader, etc) stored 
in a `qcow2` image, so that it could be run with a simple:


   kvm vm.qcow2

(If the output of `debvm-create` were a tarball, creating an full-disk 
image would be as easy as following the guestfish-based instructions in 
the manpage of mmdebstrap.)


Regards,

--
Gioele Barabucci

Bug#1026126: (no subject)

[Junichi Uekawa]

found that cargo debstatus has a bug that it drops optional dependencies from 
the dependency tree and I still have bunch of optional dependencies (gdbstub 
etc) to go.

Bug#1030255: debvm: debvm-create: Please use the VM name for the filesystem

[Gioele Barabucci]

Control: tag -1 - moreinfo

On 01/02/23 21:20, Helmut Grohne wrote:

On Wed, Feb 01, 2023 at 06:21:40PM +0100, Gioele Barabucci wrote:

The filesystems of the VMs created by `debvm-create` are all named "debvm".

Would it be possible to use `$VMNAME` also for the filesystem label?


This is more tricky that it looks. debvm-run uses the label "debvm" to
locate the root filesystem.


I only looked at `debvm-create` and ignored `debvm-run`. It makes sense 
for "debvm" to act as a well-known entrypoint that allows `debvm-run` to 
quickly check if the image comes from `debvm-create`.



I also do not quite see how debvm-run would communicate the location
of the rootfs to the kernel unless using the label.


Perhaps by reading the label of the passed image via `e2label`?

Anyway, feel free to close this bug report: I believe it is not worth 
spending your time over this issue.


Regards,

--
Gioele Barabucci

Bug#1030275: nmu: dtkcore_5.6.2.2-1~exp1, deepin-qt5dxcb-plugin_5.0.71-1~exp1

[Andreas Beckmann]

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

nmu dtkcore_5.6.2.2-1~exp1 . ANY . experimental . -m "Rebuild against 
qtbase-abi-5-15-18"
nmu deepin-qt5dxcb-plugin_5.0.71-1~exp1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-15-18"

These still depend on the no longer available qtbase-abi-5-15-6.

Andreas

Bug#1030220: xrayutilities: missing dependency on python3-h5py breaks armel tests

[Stefano Rivera]

Control: clone -1 -2
Control: reassign -2 src:python-h5py 3.7.0-3
Control: retitle -2 Provide PyDist overrides for h5py?

Hi Drew (2023.01.31_18:48:32_-0400)
> xrayutilities does have Build-Depends: python3-h5py. Evidentally
> dh-python3 isn't able to determine the correct dependency for h5py
> (likely it gets confused by python3-h5py-serial).  Until that's fixed,
> python3-xrayutilities should declare 
> Depends: python3-h5py
> explicitly.

This sounds like an issue in the way the python3-h5py package is
structured.

python3-h5py-serial has the .egg-info, so that's the dependency that's
being generated.

You can customize this with a PyDist override file, see:
/usr/share/doc/dh-python/README.PyDist

Maybe it would make sense to have a pydist like so:
h5py python3-h5py; PEP386

That way any package declaring a Python requires on h5py will get a
binary dependency on python3-h5py.

Thanks,

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1019942: pacpl: has unnecessary dependency; please update package's dependencies

[Matteo Cypriani]

Control: forwarded -1 vor...@gmail.com

Hi Thomas,

Thank you for your report. I have contacted Philip Lyons, PACPL's author, to 
have him confirm that libcddb-perl is not required, and remove the dependency 
in the next release.

Cheers,
  Matteo

Le vendredi 16 septembre 2022, 19:32:53 CET Thomas Uhle a écrit :
> Package: pacpl
> Version: 6.1.2-2
> Severity: normal
> 
> Dear maintainer,
> 
> by installing pacpl, also libcddb-perl was to be installed but has never
> been used.  pacpl uses libcddb-get-perl instead that was also installed.
> So could you please update debian/control and drop libcddb-perl from
> dependencies.
> 
> Thank you in advance!
> 
> Best regards,
> 
> Thomas Uhle
> 
> 
> -- System Information:
> Debian Release: 11.5
>APT prefers stable-updates
>APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable') Architecture: arm64 (aarch64)
> Foreign Architectures: armhf
> 
> Kernel: Linux 5.10.0-17-arm64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to
> /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages pacpl depends on:
> ii  libaudio-flac-header-perl 2.4-3+b3
> ii  libaudio-scan-perl1.01-1+b3
> ii  libcddb-perl  1.222-1.1
> ii  libcddb-get-perl  2.28-3
> ii  libmp3-tag-perl   1.13-1.2
> ii  libparallel-forkmanager-perl  2.02-1
> ii  libstring-shellquote-perl 1.04-1
> ii  perl  5.32.1-4+deb11u2
> ii  vorbis-tools  1.4.0-11+b1
> 
> Version of packages pacpl recommends:
> ii  cdparanoia3.10.2+debian-13.1
> ii  faad  2.10.0-1
> ii  ffmpeg10:4.4.2-dmo0~bpo11+3
> ii  flac  1.3.3-2+deb11u1
> ii  lame  1:3.100-dmo2
> un  mplayer   
> un  musepack-tools
> ii  normalize-audio   0.7.7-16
> ii  opus-tools0.1.10-1
> ii  sndfile-programs  1.0.31-2
> un  sox   
> un  speex 
> un  wavpack   
> 
> Version of packages pacpl suggests:
> un  faac 
> un  flake
> un  twolame  



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

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[Jérémy Lal]

A placeholder package in main could prompt users to enable needed
source component ?

Le mer. 1 févr. 2023 à 21:36, Sven Joachim  a écrit :

> Control: reassign -1 release-notes
>
> On 2023-02-01 08:30 +0800, Dan Jacobson wrote:
>
> > Package: general
> >
> > The average user will not notice his firmware is not updating any more.
>
> Unless they pay close attention to apt(itude)'s messages, that is
> probably true.
>
> > So he must do Google Search.
> > https://www.google.com/search?q=debian+firmware+non-free
> > which leads to
> > https://wiki.debian.org/Firmware
> > which says
> > ...a new repository component non-free-firmware...
> >
> > So that means he needs to add it to /etc/apt/sources.list.d/
> > Ah ha!
>
> The release notes for Bookworm should and will certainly mention that.
> I think this is where this bug is actually actionable, so I am
> reassigning it there.
>
> > Yes, he should be regularly subscribed to debian-user, but that's too
> > much.
>
> I have sent a heads-up message[1] there a few days ago, but as you said it
> got lost in all the other topics discussed there.
>
> > Or https://lists.debian.org/debian-announce/, but that's too many boring
> > messages too.
>
> There was not even a prominent notice there, at least not in the past
> few weeks.
>
> > Yes, he uses apt-listchanges, but that won't tell him this.
> >
> > So I'm saying that Debian needs a mechanism to have his computer tell
> > him to do this.
> >
> > Maybe the next time he uses apt*, somehow the system should tell him...
>
> Somehow, but how exactly?  Good question that was brought up on
> debian-devel[2], alas without replies yet.
>
> Cheers,
>Sven
>
>
> 1. https://lists.debian.org/debian-user/2023/01/msg00706.html
> 2. https://lists.debian.org/debian-devel/2023/01/msg00312.html
>
>

Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login

[Simon McVittie]

Control: reassign -1 gnome-control-center,accountsservice
Control: found -1 gnome-control-center 1:43.2-2
Control: found -1 accountsservice 22.08.8-1

(Quoting full bug report for accountsservice maintainers)

On Wed, 01 Feb 2023 at 20:56:08 +0200, Timo Lindfors wrote:
> Steps to reproduce:
> 1) Run "gnome-control-center user-accounts"
> 2) Click "Unlock..."
> 3) Enter root password
> 4) Click "Add User..."
> 5) Enter "demo2" as Name and Username and click "Add".
> 6) Click "Remove User..."
> 7) Click "Delete" when prompted.
> 8) Logout
> 9) Select "Not listed?" and login as "demo2". Set the new password when 
> prompted.
> 10) Hit the GUI key and type terminal, right click to access terminal 
> preferences
> 11) Set the custom command in Unnamed/Command to /bin/bash
> 12) Start terminal
> 
> Expected results:
> 9) Login fails since the user has been deleted
> 
> Actual results:
> 9) Login succeeds even though the user was deleted from the UI.
> 
> More info:
> 
> This issue is particularly scary since both the settings application
> and the login screen do not show the user after it has been
> deleted. This gives the user the impression that the deletion actually
> succeeded.

The prompt for "Remove User..." says "Are you sure you want to revoke
remotely managed demo2's account?" which is unexpected: I didn't create
this as a remotely managed user, I created it as a local user. This might
indicate that gnome-control-center has got confused about the correct way
to delete the account.

Another clue that the wrong thing is happening is that I wasn't prompted
for whether to delete the user's home directory and mail spool.

Looking briefly at the gnome-control-center code, I think this indicates
that act_user_is_local_account() is returning false, so instead of deleting
a local user, gnome-control-center is telling accountsservice to
"uncache" a remotely-managed (enterprise) user? I don't know what practical
effect that has, but it doesn't sound like a true "delete" operation?

This seems like at least partially an accountsservice bug: I would have
expected that it would reject attempts to do enterprise-single-signon
operations on a local Unix user.

smcv

Bug#1030252: debvm: debvm-create does not set all default ext4 features

[Gioele Barabucci]

On 01/02/23 21:45, Helmut Grohne wrote:

On Wed, Feb 01, 2023 at 06:07:25PM +0100, Gioele Barabucci wrote:

debvm-create converts the ext2 filesystem created by mmdebstrap to ext4
using the following tune2fs command:

 tune2fs ... -O extents,uninit_bg,dir_index,has_journal "$IMAGE"

The ext4 filesystem created in this way does not have some of the features
that a filesystem created with mkfs.ext4 would have:

My (debatable) expectation is that the ext4 filesystem would have at least
all features of a standard ext4 filesystem.


This kinda is right. We could slightly improve this, but in the end we
want to replace genext2fs with mkfs.ext4 and that depends on it
supporting tarball input. So do you think we should mess with the
tune2fs invocation in the interim or is it good enough for now?


Hi,

personally I stumbled upon this problem because my tests require 
`dir_nlink` (more than 65k subdirs per directory) and that feature was 
not enabled. Maybe other people have use-cases that depend on other 
missing features, but I doubt it.


IMO just copying the current set of features is enough as an interim 
solution to this minor (and temporary) problem.


Regards,

--
Gioele Barabucci

Bug#1030272: bugs.debian.org: Failed to forcibly merge 1004579

[Sven Joachim]

Package: bugs.debian.org
Severity: normal

I just tried to merge #1004579 and #1030190 and received an error
message.

On 2023-02-01 20:57 +, Debian Bug Tracking System wrote:

> Processing control commands:
>
>> reassign -1 src:mplayer
> Bug #1030190 [mplayer] mplayer uninstallable
> Bug reassigned from package 'mplayer' to 'src:mplayer'.
> No longer marked as found in versions mplayer/2:1.4+ds1-3.
> Ignoring request to alter fixed versions of bug #1030190 to the same values 
> previously set
>> forcemerge 1004579 -1
> Bug #1004579 [src:mplayer] mplayer: FTBFS with ffmpeg 5.0
> Bug #1030190 [src:mplayer] mplayer uninstallable
> Severity set to 'serious' from 'critical'
> Failed to forcibly merge 1004579: Failure while trying to adjust bugs,
> please report this as a bug: Not altering archived bugs; see
> unarchive..
>  at /usr/local/lib/site_perl/Debbugs/Control.pm line 2133.

As suggested, I hereby report this as a bug.  Note that #1004579 is not
marked as archived in the BTS web interface[1].


1. https://bugs.debian.org/1004579

Bug#1030190: mplayer uninstallable

[Sven Joachim]

Control: reassign -1 src:mplayer
Control: forcemerge 1004579 -1

On 2023-02-01 09:13 +0800, Dan Jacobson wrote:

> Package: mplayer
> Version: 2:1.4+ds1-3+b2
> Severity: critical
>
> The following packages have unmet dependencies:
>  mplayer : Depends: libavcodec58 (>= 7:4.4) which is a virtual package and is 
> not provided by any available package
>Depends: libavformat58 (>= 7:4.4) which is a virtual package and 
> is not provided by any available package
>Depends: libavutil56 (>= 7:4.4) which is a virtual package and is 
> not provided by any available package
>Depends: libpostproc55 (>= 7:4.4) which is a virtual package and 
> is not provided by any available package
>Depends: libswresample3 (>= 7:4.4) which is a virtual package and 
> is not provided by any available package
>Depends: libswscale5 (>= 7:4.4) which is a virtual package and is 
> not provided by any available package
>
> The following actions will resolve these dependencies:
>
>  Keep the following packages at their current version:
> 1) mplayer [Not Installed]
>
> *** No more solutions available ***
>
> In sources.list I have
> deb http://.../debian/ unstable main contrib non-free non-free-firmware

Yep, the package is not installable because it FTBFS[1].  That does not
make the bug critical[2] though - a not installed package does not break
anything beyond itself and its reverse dependencies.

Use mpv instead of mplayer, it works.

Cheers,
   Sven

1. https://bugs.debian.org/1004579
2. https://www.debian.org/Bugs/Developer#severities

Bug#1030222: [DSE-Dev] Bug#1030222: selint: please restrict check only where valgrind is available

[Amin Bandali]

Amin Bandali writes:

> Hello there,
>
> You might find it more convenient to depend on 'valgrind-if-available'
> rather than 'valgrind' itself, per the attached patch.  It also skips
> tests that need valgrind, for problematic arches.  What do you think?

To be fully clear, by "it" in "it also skips" I was referring to my
attached patch, not the act of depending on valgrind-if-available.

Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

[Paul Gevers]

Hi,

Sorry it took so long.

On 02-01-2022 01:43, Iain Lane wrote:

On Sat, Jan 01, 2022 at 10:05:21PM +0100, Paul Gevers wrote:

Hi Raphael,

On 01-01-2022 21:37, Raphael Hertzog wrote:

On Fri, 31 Dec 2021, Paul Gevers wrote:

Otherwise I would like to suggest to create two entries, one with
"Pin: release a=foo" and one with "Pin: release n=foo" so that
we are sure to match on any of the 3 fields.


I'll have to check and think about this. I remember that I had lots of
issues with coming up with changes to autopkgtest that also worked for
Ubuntu, as they use the same Codename for the real Suite and the *-proposed
Suite (which they call pocket). I don't recall if that was with respect to
pinning or other aspects of autopkgtest and it's requirement to manipulate
where packages should be installed from. Before committing your proposal I
need to understand that I'm not breaking existing valid configurations too.


I saw a comment mentionning this, but it was related to the "--apt-pocket"
option and I didn't change that part, which still uses the "a=foo" syntax.

https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/adt_testbed.py#L1263


Right, thanks for referencing that line as it has the bug number where the
relevant information was. As the --pin-packages option will already have the
*-pocket in the name, I think this would work for Ubuntu too. CC-ing Iain
for a sanity check on our reasoning.


Thanks for copying me on this. Julian might be a good one also.


Done now.


I fear I've probably forgotten most of these details, so please pardon
me for this response… Wasn't the problem for Ubuntu that 'Pin: release
foo' also applies to foo-proposed too? I think 'Pin: release
foo-proposed' will work as intended though, right?  Is the latter what
we'll start generating with this? Seeing some example generated pins
(before / after the patch) would be great to help reason about this.


The patch also removes the "a=" from the pinning for the default release 
(at 990) and I think that will break Ubuntu's setup as the packages from 
the proposed pocket will suddenly satisfy this pin too. What you (Iain) 
discussed above works for the pocket/foo-proposed part, but I think 
Raphael needs the other part too. I fear that without additional 
options, we can't really fix this.



I guess a test covering this for all of the Ubuntu, Debian & Kali cases
would be helpful in terms of confidence both with this change and making
any future changes here. The one thing I do remember is that it's hairy,
like all the pinning stuff in autopkgtest. :-)


Yes. In the same area; for Debian I once had a proposal to set the 
Default-Release instead of using the pinning, but that broke Ubuntu's 
case. It would have reduced another hairy part of autopkgtest 
tremendously, where a lot of sed/awk/grep-ing happens in the testbed to 
figure out which version of the source to install for the test. But 
alas, autopkgtest needs to support the Ubuntu archive.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[Debian/GNU]

On 2/1/23 20:53, Ansgar wrote:

So he must do Google Search.


Do you think this problem only affects make users?


jeez... my remark was meant to spell:
> Do you think this problem only affects *male* users?

but autocompletion kicked in.




I would expect at least ninja-build users to be affected as well unless
they use a VM.



so i'm rephrasing this (with tongue-in-cheek) as:
> Do you think this problem only affects kunoichi-build users?

Bug#1030252: debvm: debvm-create does not set all default ext4 features

[Helmut Grohne]

Control: forwarded -1 https://github.com/tytso/e2fsprogs/pull/118

On Wed, Feb 01, 2023 at 06:07:25PM +0100, Gioele Barabucci wrote:
> debvm-create converts the ext2 filesystem created by mmdebstrap to ext4
> using the following tune2fs command:
> 
> tune2fs ... -O extents,uninit_bg,dir_index,has_journal "$IMAGE"
> 
> The ext4 filesystem created in this way does not have some of the features
> that a filesystem created with mkfs.ext4 would have:
> 
> $ truncate -s "1GiB" e2
> $ /sbin/mkfs.ext2 e2
> $ /sbin/tune2fs -O extents,uninit_bg,dir_index,has_journal e2
> 
> $ truncate -s "1GiB" e4
> $ /sbin/mkfs.ext4 e4
> 
> $ diff -U7 <(/sbin/dumpe2fs ./e2 | grep -m1 feat | tr ' ' '\n')
><(/sbin/dumpe2fs ./e4 | grep -m1 feat | tr ' ' '\n')
> 
>  has_journal
>  ext_attr
>  resize_inode
>  dir_index
>  filetype
>  extent
> +64bit
> +flex_bg
>  sparse_super
>  large_file
> -uninit_bg
> +huge_file
> +dir_nlink
> +extra_isize
> +metadata_csum
> 
> My (debatable) expectation is that the ext4 filesystem would have at least
> all features of a standard ext4 filesystem.

This kinda is right. We could slightly improve this, but in the end we
want to replace genext2fs with mkfs.ext4 and that depends on it
supporting tarball input. So do you think we should mess with the
tune2fs invocation in the interim or is it good enough for now?

Helmut

Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

[Thorsten Glaser]

Package: dpkg
Version: 1.21.19
Followup-For: Bug #733029
X-Debbugs-Cc: t...@mirbsd.de

Yes, please. The default signing just leads to error messages…
and we nowadays upload source-only anyway, so no builds should
be signed by default, only those explicitly created to publish.

-- Package-specific info:

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-8
ii  liblzma5 5.4.1-0.1
ii  libmd0   1.0.4-2
ii  libselinux1  3.4-1+b5
ii  libzstd1 1.5.2+dfsg2-3
ii  tar  1.34+dfsg-1.1
ii  zlib1g   1:1.2.13.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.5.5
pn  debsig-verify  

-- no debconf information

Bug#1030222: [DSE-Dev] Bug#1030222: selint: please restrict check only where valgrind is available

[Amin Bandali]

Hello there,

You might find it more convenient to depend on 'valgrind-if-available'
rather than 'valgrind' itself, per the attached patch.  It also skips
tests that need valgrind, for problematic arches.  What do you think?

diff --git a/debian/control b/debian/control
index 44fca69..a130223 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends: autoconf-archive,
libconfuse-dev,
pkg-config,
uthash-dev,
-   valgrind 
+   valgrind-if-available 
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: https://github.com/SELinuxProject/selint
diff --git a/debian/rules b/debian/rules
index 3a18158..2409916 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=+lto
 
 ifneq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
@@ -14,6 +16,10 @@ override_dh_auto_configure:
 	dh_auto_configure -- --enable-werror $(CONFIGURE_ARGS)
 
 execute_after_dh_auto_test:
+ifneq (,$(filter $(DEB_HOST_ARCH), mips64el mipsel))
+# Skip the tests requiring valgrind on problematic architectures
+	sed -i '/^@test "\(valgrind\|Broken config\)" {/a \	skip' end-to-end.bats
+endif
 	cd tests/functional/ && bats end-to-end.bats
 
 ifneq (, $(filter cross, $(DEB_BUILD_PROFILES)))

Bug#1029845: harfbuzz: non-distributable font included in source

[Salvatore Bonaccorso]

Hi Andres,

On Wed, Feb 01, 2023 at 03:47:03AM -0500, Andres Salomon wrote:
> Hi Security Team & Jeremy,
> 
> I had originally planned to ask the release team about fixing #1029845 (the
> bug below) in bullseye via t-p-u. However, it would appear that there's also
> an outstanding security bug in harfbuzz (CVE-2022-33068, tracked at
> #1013673). So instead, maybe it's better if we group the font removal and
> the security fix together and upload something like what I've attached (a
> debdiff against 2.7.4-1) to bullseye-security. What do folks think?

Note that CVE-2022-33068 is no-dsa, so the security fix can just be
batched in in the bullseye-pu update and fixed in the next point
release.

Regards,
Salvatore

Bug#1030271: dpkg-buildpackage: misleading error message when no signing key available

[Thorsten Glaser]

Package: dpkg
Version: 1.21.19
Severity: minor
X-Debbugs-Cc: t...@mirbsd.de

gpg: skipped "Thorsten Glaser ": secret key not available
gpg: dpkg-sign.IRqYlate/dygraphs_2.2.0-4.dsc: clearsign failed: secret key not 
available
dpkg-buildpackage: error: failed to sign dygraphs_2.2.0-4.dsc file: key is not 
signature-capable

The error message is a bit misleading here.


-- Package-specific info:

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-8
ii  liblzma5 5.4.1-0.1
ii  libmd0   1.0.4-2
ii  libselinux1  3.4-1+b5
ii  libzstd1 1.5.2+dfsg2-3
ii  tar  1.34+dfsg-1.1
ii  zlib1g   1:1.2.13.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.5.5
pn  debsig-verify  

-- no debconf information

Bug#1030173: Document breaking changes in NEWS.Debian

[Vincent Bernat]

On 2023-01-31 23:09, Lee Garrett wrote:


I've written a NEWS file for you:


Thanks, it will be part of the next upload.

Bug#1030208: Acknowledgement (statsmodels: FTBFS with scipy 1.10 on 32-bit: int64 -> int32 cast)

[Rebecca N. Palmer]

Control: merge -1 1030210 1030221

Not obviously known upstream.

It's due to the test passing an int64 array to np.bincount (which casts 
to native-size int).  Hence, we can probably get it to pass by 
explicitly casting to int32 in the test code, but I haven't tried that yet.


I don't know exactly what caused this array to be int64 instead of int32.

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[Brad Basile]

UNSUBSCRIBE

E-MAIL Change Notice: My E-Mail address has changed to 
bbas...@eventidecommunications.com


Brad B.
Eventide Inc.
bbas...@eventidecommunications.com 
Tel: 201-641-1200 X 2590


-Original Message-
From: Ansgar  
Sent: Wednesday, February 1, 2023 2:54 PM
To: IOhannes m zmölnig ; 1030...@bugs.debian.org
Subject: Bug#1030189: Let regular users know need to put non-free-firmware in 
sources.list

On Wed, 2023-02-01 at 20:13 +0100, IOhannes m zmölnig wrote:
> Am 1. Februar 2023 01:30:10 MEZ schrieb Dan Jacobson
> :
> > So he must do Google Search.
> 
> Do you think this problem only affects make users?

I would expect at least ninja-build users to be affected as well unless they 
use a VM.

Ansgar



smime.p7s
Description: S/MIME cryptographic signature

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[Sven Joachim]

Control: reassign -1 release-notes

On 2023-02-01 08:30 +0800, Dan Jacobson wrote:

> Package: general
>
> The average user will not notice his firmware is not updating any more.

Unless they pay close attention to apt(itude)'s messages, that is
probably true.

> So he must do Google Search.
> https://www.google.com/search?q=debian+firmware+non-free
> which leads to
> https://wiki.debian.org/Firmware
> which says
> ...a new repository component non-free-firmware...
>
> So that means he needs to add it to /etc/apt/sources.list.d/
> Ah ha!

The release notes for Bookworm should and will certainly mention that.
I think this is where this bug is actually actionable, so I am
reassigning it there.

> Yes, he should be regularly subscribed to debian-user, but that's too
> much.

I have sent a heads-up message[1] there a few days ago, but as you said it
got lost in all the other topics discussed there.

> Or https://lists.debian.org/debian-announce/, but that's too many boring
> messages too.

There was not even a prominent notice there, at least not in the past
few weeks.

> Yes, he uses apt-listchanges, but that won't tell him this.
>
> So I'm saying that Debian needs a mechanism to have his computer tell
> him to do this.
>
> Maybe the next time he uses apt*, somehow the system should tell him...

Somehow, but how exactly?  Good question that was brought up on
debian-devel[2], alas without replies yet.

Cheers,
   Sven


1. https://lists.debian.org/debian-user/2023/01/msg00706.html
2. https://lists.debian.org/debian-devel/2023/01/msg00312.html

Bug#1027132: git-doc: Error in `/usr/share/doc-base/git-doc.git-index-format', line 9: all `Format' sections are invalid

[Thorsten Glaser]

Package: git-doc
Version: 1:2.39.1-0.1
Followup-For: Bug #1027132
X-Debbugs-Cc: t...@mirbsd.de

This is still pertinent. In addition, the file is named weirdly;
I suspect a broken rename or something. In bpo, the file is named
properly but the same error presents:

$ install-docs --verbose --check /usr/share/doc-base/git-index-format
Warning in `/usr/share/doc-base/git-index-format', line 9: file mask 
`/usr/share/doc/git-doc/technical/index-format.txt' does not match any files.
Error in `/usr/share/doc-base/git-index-format', line 9: all `Format' sections 
are invalid.
/usr/share/doc-base/git-index-format: Fatal error found, the file won't be 
registered.



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

Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

git-doc depends on no packages.

git-doc recommends no packages.

Versions of packages git-doc suggests:
ii  git1:2.39.1-0.1
pn  git-cvs
pn  git-email  
pn  git-svn
pn  gitk   
pn  gitweb 

-- no debconf information

Bug#1004729: bind9-dyndb-ldap: fails to load dyndb-ldap backend

[Matej Zagiba]

Dear Maintainers,

 this bug is NOT FIXED, which manifests right now.

packake bind9-dyndb-ldap is now broken both in stable and unstable.

In stable:

 bind9-dyndb-ldap is in version 11.6-3 and this package depends on 
bind9-libs >= 1:9.16.15. Reality is, that bind9-dyndb-ldap actually 
depends on bind9-libs == 1:9.16.15. Which is no longer available, so 
package install but fails to load (bringing bind9 down whit itself.)


In unstable:

 bind9-dyndb-ldap is in version 11.10-2 and this package depends on 
bind9-libs ==  1:9.18.10-2. Which is no longer available.

bind9-dyndb-ldap is not installable on fresh installs of unstable, or
which is even worse, bind9 will not upgrade to latest version, so 
leaving systems vulnerable to handful of CVEs.


I believe real problem lies in package management procedures - there 
should be trigger to recompile and repackage (and retest) 
bind9-dyndb-ldap after each version change and/or repackage of 
bind9-libs. This action should be done automatically. Otherwise 
bind9-dyndb-ldap will be permanently broken.



Should I open another bug?

Bug#1030270: libreoffice: FTBFS with "nodoc" build profile

[Vagrant Cascadian]

Package: src:libreoffice
Version: 4:7.5.0~rc3-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Building libreoffice with DEB_BUILD_PROFILES=nodoc fails, attempting to
symlink documentation files that do not exist when... building without
the documentation.

I noticed this trying to build libreoffice from experimental, but it may
also affect older versions.

The attached patch fixed building with "nodoc" for me, though I have not
tested extensively.

Being able to build without documentation will help sort out other
reproducible builds issues in libreoffice.

live well,
  vagrant
From 5b7f2fbfed32799343c1f69df30da77c212549dc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 1 Feb 2023 20:12:52 +
Subject: [PATCH] debian/rules: Do not add documentation symlinks when not
 building documentation.

This fixes building with the "nodoc" build profile.
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index f9e2ace888..932b242e46 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3428,7 +3428,7 @@ ifeq "$(DEB_VENDOR)" "Debian"
 	install -m644 debian/templates/*.otp $(PKGDIR)-common/$(OODIR)/share/template/en-US/presnt/
 endif
 
-ifeq "$(PACKAGE_SDK)" "y"
+ifeq "$(PACKAGE_SDK_DOCS)" "y"
 	# add symlinks for docs and examples
 	cd $(PKGDIR)-dev-doc/$(OOSDKDIR) && \
 		rm -rf docs && \
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1030255: debvm: debvm-create: Please use the VM name for the filesystem

[Helmut Grohne]

Control: tag -1 + moreinfo

On Wed, Feb 01, 2023 at 06:21:40PM +0100, Gioele Barabucci wrote:
> The filesystems of the VMs created by `debvm-create` are all named "debvm".
> 
> Would it be possible to use `$VMNAME` also for the filesystem label?

This is more tricky that it looks. debvm-run uses the label "debvm" to
locate the root filesystem. If I were to change the label here,
debvm-run would have to guess it somehow. That seems non-trivial and
prone for errors. The label being debvm is part of interface.

At this time, I do not quite see why you would want to change the label
and I also do not quite see how debvm-run would communicate the location
of the rootfs to the kernel unless using the label. Do you have an
answer for either questions?

(Please do remove the moreinfo tag with your response.)

Helmut

Bug#1030254: debvm: Please support "--variant=custom" VMs

[Helmut Grohne]

Control: retitle -1 allow not installing the init package

Hi Gioele,

On Wed, Feb 01, 2023 at 06:17:05PM +0100, Gioele Barabucci wrote:
> Currently debvm unconditionally creates images using `--variant=apt`. This
> is OK for most usages, but prevents the use of debvm for the creation of
> test VMs that, for example, do not contain all essential packages.
> `mmdebstrap` provides the `custom` variant for the generation of such VMs.
> 
> Would it be possible to provide an option to use the `custom` variant
> instead of the `apt` variant?

This one is actually simple. debvm-create conveniently passes all
options behind a double dash along to mmdebstrap. It does so after
passing its own options. If you pass --variant=custom there, mmdebstrap
gets two --variant options and the last one (i.e. yours) wins.

> (The `--include=init` option should also be avoided for custom images.)

I distill that this is the actual request and retitle the bug
accordingly.

Helmut

Bug#1030269: freezer: python3 dependency issues

[Sebastian Ramacher]

Source: freezer
Version: 13.0.0-1.1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

python3-freezer is an arch: all package that should work with all
versions of the python3 interpreter. Nevertheless, it currently has a
dependency on python3.10 (and rebuilding it produces one on python3.11).

So, freezer needs a sourceful upload for the python3.11-only transition.

Cheers
-- 
Sebastian Ramacher

Bug#1029842: ITP: randombytes -- Library generating fresh randomness

[Sam Hartman]

> "Jan" == Jan Mojzis  writes:
Jan> If I understand it correctly, CC0-style public-domain
Jan> declaration in debian/copyright solves the problem.  (learned
Jan> here:
Jan> https://lists.debian.org/debian-mentors/2017/09/msg00171.html)

I'm not entirely sure I agree with Don, and he was also being short.
I agree that a cc0 style declaration made by the original author makes
everything fine.
I do not think you can make a cc0 style declaration on behalf of someone
else.


signature.asc
Description: PGP signature

Bug#1029842: ITP: randombytes -- Library generating fresh randomness

[Jan Mojzis]

> On 28. 1. 2023, at 21:42, Sam Hartman  wrote:
> 
>> "Jan" == Jan Mojzis  writes:
> 
> * Package name: randombytes
>  Version : 20230126
>  Upstream Author : Daniel J. Bernstein
> * URL : https://randombytes.cr.yp.to/
> * License : Public domain
> 
> Public domain is problematic  as a license.
> At least under US copyright law, there are very few circumstances when
> something can actually be public domain.
> One example is software written by US government employees.
> But I don't think any of those circumstances apply to this library.
> So I'm not sure the license is okay.

If I understand it correctly, CC0-style public-domain declaration in 
debian/copyright solves the problem.
(learned here: https://lists.debian.org/debian-mentors/2017/09/msg00171.html)

~~~
License: public-domain-CC0-1.0
 Public domain.
 .
 Upstream library is marked as public-domain 
https://randombytes.cr.yp.to/index.html.
 .
 Public-domain mark does not have the same meaning in all jurisdictions,
 to avoid confusion, please follow CC0 1.0 Universal.
 The complete text of the CC0 license, version 1.0,
 can be found in /usr/share/common-licenses/CC0-1.0.
~~~

Or am I wrong?

> 
> I'll  also admit to being skepticle of the utility of such a library
> given the getrandom() API in libc.

The library internally uses getrandom().
The primary bonus is in portability and usability. The library (namely 
randombytes-kernel) uses one of the variants
getrandom(), getentropy(), "/dev/urandom" and the user/aplication doesn't need 
to care what resource is on a given operating system available.
And the user/aplication also doesn't have to worry about whether the system has 
enough entropy (e.g. /dev/urandom initialized).
Randombytes() simply waits/blocks until there is enough entropy.

Jan

Bug#1030268: fparser: python3 dependency issues

[Sebastian Ramacher]

Source: fparser
Version: 0.0.16-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

python3-fparser is an arch: all package that should work with all
versions of the python3 interpreter. Nevertheless, it currently has a
dependency on python3.10 (and rebuilding it produces one on python3.11). 

So, fparser needs a sourceful upload for the python3.11-only transition.
With the attached python3-fparser, this should no longer be necessary
for future transitions.

Cheers
-- 
Sebastian Ramacher
diff -Nru fparser-0.0.16/debian/changelog fparser-0.0.16/debian/changelog
--- fparser-0.0.16/debian/changelog 2022-06-19 10:53:09.0 +0200
+++ fparser-0.0.16/debian/changelog 2023-02-01 20:50:45.0 +0100
@@ -1,3 +1,10 @@
+fparser (0.0.16-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * 
+
+ -- Sebastian Ramacher   Wed, 01 Feb 2023 20:50:45 +0100
+
 fparser (0.0.16-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru fparser-0.0.16/debian/rules fparser-0.0.16/debian/rules
--- fparser-0.0.16/debian/rules 2022-06-19 10:53:09.0 +0200
+++ fparser-0.0.16/debian/rules 2023-02-01 20:50:40.0 +0100
@@ -7,20 +7,8 @@
 %:
dh $@  --buildsystem=pybuild
 
-PYVERS=$(shell py3versions -sv)
-
-override_dh_auto_install:
-   set -e && for py3vers in $(PYVERS) ; do \
- python$$py3vers setup.py install --install-layout=deb \
-   --root $(CURDIR)/debian/python3-fparser; \
- done
-   -find . -name __pycache__ -exec rm -rf {} \;
-
-
 override_dh_auto_test:
@echo "Some tests currently fail; ignore for this release"
 
 override_dh_auto_clean:
-   # dh_auto_clean avoid bug where this calls python, not python3
-   python3 setup.py clean
rm -fr build src/fparser.egg-info

Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login

[Simon McVittie]

On Wed, 01 Feb 2023 at 20:56:08 +0200, Timo Lindfors wrote:
> 6) Click "Remove User..."
> 7) Click "Delete" when prompted.

Do you happen to know what this actually does, behind the scenes?

> This issue is particularly scary

It's too late now, but in future, if you're reporting an otherwise
undisclosed security vulnerability, please report it privately so that
the information isn't immediately available to attackers.

smcv

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[Ansgar]

On Wed, 2023-02-01 at 20:13 +0100, IOhannes m zmölnig wrote:
> Am 1. Februar 2023 01:30:10 MEZ schrieb Dan Jacobson
> :
> > So he must do Google Search.
> 
> Do you think this problem only affects make users?

I would expect at least ninja-build users to be affected as well unless
they use a VM.

Ansgar

Bug#1030253: gnome-control-center: Creating a user via "gnome-control-center user-accounts" results in a user with shell set to nologin

[Simon McVittie]

Control: reassign -1 accountsservice 22.08.8-1
Control: severity -1 important

(Quoting full text for Cc'd packages' maintainers)

On Wed, 01 Feb 2023 at 19:09:07 +0200, Timo Lindfors wrote:
> Steps to reproduce:
> 1) Run "gnome-control-center user-accounts"
> 2) Click "Unlock..."
> 3) Enter root password
> 4) Click "Add User..."
> 5) Enter "demo2" as Name and Username and click "Add".
> 6) Select "Switch User..." from gnome power menu
> 7) Login as "demo2"
> 8) Enter new password when prompted
> 9) Start a browser
> 10) Start a terminal
> 
> Expected results:
> 9) Browser starts
> 10) Terminal starts
> 
> Actual results:
> 9) Browser starts
> 10) Terminal starts but immediately closes
> 
> More info:
> 
> This issue does not occur in Debian 11 so it is a
> regression. /etc/passwd contains the following line:
> 
> demo2:x:1002:1002:demo2,,,:/home/demo2:/usr/sbin/nologin
> 
> It seems that gnome-control-center calls accounts-daemon over dbus to
> create the user. It does not specify the shell in the dbus
> call. accounts-daemon eventually ends up calling
> 
> adduser --quiet --disabled-login --gecos demo2 demo2
> 
> It seems that the behavior of adduser has changed. In Debian 11 this
> creates a user with a shell but in adduser 3.130 it creates a user
> with shell set to nologin.
> 
> Please reassign if you believe this issue should be assigned to
> accounts-daemon or adduser.

I'm pretty sure this is not a gnome-control-center bug: creating a
user via accounts-daemon's D-Bus API should have sufficiently sensible
defaults that this doesn't happen (and gnome-control-center doesn't have
UI for the equivalent of chsh, so it shouldn't be second-guessing what
the default shell is).

I believe the adduser behaviour change is intentional, in
,
which would point to this being an accountsservice (accounts-daemon) bug:
it needs updating to work correctly with the adduser behaviour change.

If I understand correctly, what gnome-control-center wants to do is
to create a user with an invalid password (unable to log in), and then
as a separate D-Bus transaction, do something to its password: either
change the password, or put it into a state where the user can log in
unauthenticated and will be prompted for a new password.

Probably it should now be using --disabled-password instead of
--disabled-login to get that effect? adduser maintainers: is my guess
correct?

For now I'm only escalating this to important, but I think it probably
deserves to be RC for accountsservice.

smcv

Bug#804722: git-buildpackage: import-dsc creates impractical merge commits after new upstream releases

[Sven Joachim]

On 2022-07-10 14:34 +0200, Gioele Barabucci wrote:

> All that is needed to do two-step merge (first merge the upstream branch, then
> apply the debian diff) is to do a merge at the right moment in 
> `import_dsc.py`.
>
> The following quick-and-dirty patch adds such a merge.
>
> --- /usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py.orig   
> 2022-07-10 13:14:48.358945384 +0200
> +++ /usr/lib/python3/dist-packages/gbp/scripts/import_dsc.py
> 2022-07-10 14:22:25.030125614 +0200
> @@ -520,20 +520,23 @@ def main(argv):
>  commit = import_upstream(repo, sources[0], dsc, options)
>  imported = True
>
>  if not repo.has_branch(options.debian_branch):
>  if options.create_missing_branches:
>  repo.create_branch(options.debian_branch, commit)
>  else:
>  raise GbpError("Branch %s does not exist, use 
> --create-missing-branches" %
> options.debian_branch)
>
> +tag = os.popen("git tag --list 'upstream/*' --sort=-v:refname | 
> head -n1").read().rstrip()
> +os.system(f'git merge {tag} --strategy-option theirs -m "Merge 
> tag \'{tag}\'"')
> +
>  if dsc.diff or dsc.deb_tgz:
>  apply_debian_patch(repo, sources[0], dsc, commit, options)
>  else:
>  gbp.log.warn("Didn't find a diff to apply.")
>
>  if imported and options.pristine_tar:
>  repo.create_pristine_tar_commits(commit, sources)
>  if repo.get_branch() == options.debian_branch or repo.empty:
>  # Update HEAD if we modified the checked out branch
>  repo.force_head(options.debian_branch, hard=True)

Having just imported a large package history of 100+ .dsc's, I
definitely agree that this creates a much nicer history, at the cost of
increased verbosity.  The result was definitely worth it, thank you very
much!

Cheers,
   Sven

Bug#992852: Patch available

[Jeremy Sowden]

Control: forwarded -1 https://gitlab.com/shorewall/code/-/merge_requests/11
Control: tags -1 patch confirmed upstream

I've created a patch and sent it upstream.  Upstream has not yet merged
it, but the response has been positive.

J.


signature.asc
Description: PGP signature

Bug#1030266: O: peek -- Simple animated GIF screen recorder with GUI

[Boyuan Yang]

Package: wnpp
Severity: normal

I would like to orphan package peek ( https://tracker.debian.org/pkg/peek ).
Its upstream has announced the deprecation of this software; see
https://github.com/phw/peek/issues/1191 . Therefore, I do not plan to
maintain (and do packaging) for peek given current condition.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: peek
Binary: peek
Version: 1.5.1+git20211214-1
Build-Depends: debhelper-compat (= 13), desktop-file-utils ,
gettext, libglib2.0-dev, libgtk-3-dev, libkeybinder-3.0-dev, libxml2-utils,
meson, python3, txt2man, valac
Architecture: any
Standards-Version: 4.6.0
Format: 3.0 (quilt)
Files:
 bec6100717249bb0a0c57386c74e37dc 1997 peek_1.5.1+git20211214-1.dsc
 afe6bcd2b35162c8825e1a7bddad2720 2670135 peek_1.5.1+git20211214.orig.tar.gz
 af750ad3d54ec5018180d0c543e18dc1 7252 peek_1.5.1+git20211214-
1.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/peek
Vcs-Git: https://salsa.debian.org/debian/peek.git
Checksums-Sha256:
 883dbd31a5dbaee178df3b50d0a0d007d77062fee4408c21a874058585f18a0a 1997
peek_1.5.1+git20211214-1.dsc
 70b5a524ac1d1e23bff6d1d51f1dbc542578ba7bce8583e071ae3f7c01ad6a60 2670135
peek_1.5.1+git20211214.orig.tar.gz
 fc8ca824e44997ae0684094dce0248facd6c9f66ab0c6127f14b62226a67ab1d 7252
peek_1.5.1+git20211214-1.debian.tar.xz
Homepage: https://github.com/phw/peek
Package-List: 
 peek deb graphics optional arch=any
Directory: pool/main/p/peek
Section: misc

Thanks,
Boyuan Yang


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

Bug#1030265: RFS: ruby-mdl/0.12.0-3 -- Markdown lint tool

[Norwid Behrnd]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ruby-mdl":

 * Package name : ruby-mdl
   Version  : 0.12.0-3
   Upstream contact : ["p...@ipom.com"]
 * URL  : https://github.com/markdownlint/markdownlint
 * License  : MIT
 * Vcs  : https://salsa.debian.org/nbehrnd/ruby-mdl
   Section  : text

The source builds the following binary packages:

  ruby-mdl - Markdown lint tool

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

  https://mentors.debian.net/package/ruby-mdl/

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

  dget -x
  https://mentors.debian.net/debian/pool/main/r/ruby-mdl/ruby-mdl_0.12.0-3.dsc

Changes since the last upload:

 ruby-mdl (0.12.0-3) unstable; urgency=medium
 .
   * correct maintainership and address
   * correct upstream/metadata, addresses
   * provide two scripts to collect contributor list debian/copyright
   * use consistently ruby-mdl in/by man page to refer to the package
   * move package from section ruby to section text

Regards,

Norwid

Bug#1029594: Fails to authenticate mit o365

[Enrico Tröger]

Hi,

> (Since the only reason I use Thunderbird in the first place is to
> access o365, this bug might even be considered grave ;-)

upstream is handling this bug in
https://bugzilla.mozilla.org/show_bug.cgi?id=1810760 and it seems a
working fix is available and so we will hopefully see a new release in
the next few days.

Regards,
Enrico

Bug#1030264: bullseye-pu: package at-spi2-core/2.38.0-4+deb11u1

[Samuel Thibault]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: at-spi2-c...@packages.debian.org
Control: affects -1 + src:at-spi2-core

[ Reason ]
stable is affected by bug #890833: under some conditions, the
at-spi2-core accessibility daemons don't manage to quit, and thus
on system shutdown, systemd stays stuck for 90s until giving up and
hard-killing it.

The exact conditions have not been determined, but anyway since there is
no state to save etc., it's fine with just killing it early, rather than
annoying users.

[ Impact ]
They may encounter a 90s delay on shutting down their computer.

[ Tests ]
As the conditions are rare, we couldn't test it.

[ Risks ]
The code is very trivial, it just sets a timeout.

[ 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 ]
It just adds a TimeoutStopSec to the systemd unit. It sets it to 5s,
just like similar widgets of the gnome desktop.
diff -Nru at-spi2-core-2.38.0/debian/changelog 
at-spi2-core-2.38.0/debian/changelog
--- at-spi2-core-2.38.0/debian/changelog2021-04-22 13:10:24.0 
+0200
+++ at-spi2-core-2.38.0/debian/changelog2023-01-25 23:30:27.0 
+0100
@@ -1,3 +1,9 @@
+at-spi2-core (2.38.0-4+deb11u1) bullseye; urgency=medium
+
+  * patches/timeoutstop: Set stop timeout to 5s (Closes: #890833).
+
+ -- Samuel Thibault   Wed, 25 Jan 2023 23:30:27 +0100
+
 at-spi2-core (2.38.0-4) unstable; urgency=medium
 
   * Re-upload to get arch:all built on buildd.
diff -Nru at-spi2-core-2.38.0/debian/patches/series 
at-spi2-core-2.38.0/debian/patches/series
--- at-spi2-core-2.38.0/debian/patches/series   2021-04-22 00:09:27.0 
+0200
+++ at-spi2-core-2.38.0/debian/patches/series   2023-01-25 23:30:27.0 
+0100
@@ -3,3 +3,4 @@
 test_disable_teamspaces
 tests
 double-free
+timeoutstop
diff -Nru at-spi2-core-2.38.0/debian/patches/timeoutstop 
at-spi2-core-2.38.0/debian/patches/timeoutstop
--- at-spi2-core-2.38.0/debian/patches/timeoutstop  1970-01-01 
01:00:00.0 +0100
+++ at-spi2-core-2.38.0/debian/patches/timeoutstop  2023-01-25 
23:30:27.0 +0100
@@ -0,0 +1,27 @@
+commit 145f9c53ca9ed73d0edb39abac12141cd40a2526
+Author: Samuel Thibault 
+Date:   Wed Jan 25 20:07:12 2023 +0100
+
+at-spi-dbus-bus service: set stop timeout to 5s
+
+As reported on
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890833
+
+sometimes the at-spi bus may hang, and system shutdown then gets stuck.
+We'd better avoid hanging the whole system shutdown just for this, and
+just wait for 5s, like many other gnome user service pieces.
+
+Of course, at-spi2-core shouldn't be getting stuck, but better avoid
+hurting people, which makes them tend to just disable accessibility...
+
+---
+ bus/at-spi-dbus-bus.service.in |1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/bus/at-spi-dbus-bus.service.in
 b/bus/at-spi-dbus-bus.service.in
+@@ -5,3 +5,4 @@ Description=Accessibility services bus
+ Type=dbus
+ BusName=org.a11y.Bus
+ ExecStart=@libexecdir@/at-spi-bus-launcher
++TimeoutStopSec=5

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[IOhannes m zmölnig]

Am 1. Februar 2023 01:30:10 MEZ schrieb Dan Jacobson :
>So he must do Google Search.

Do you think this problem only affects make users?


mfh.her.fsr
IOhannes

Bug#1028091: mc: Subshell not starting on heavily modified zsh shell

[Thorsten Bonow]

Hi,

this has already been fixed upstream in version 4.8.29:

https://midnight-commander.org/ticket/3121

Toto

-- 
Sent from my GNU Emacs running on GNU/Linux

Bug#1029968: Info received (Bug#1029968: Info received (Bug#1029968: Info received (Bug#1029968: Acknowledgement (bttv/v4l: WARNING: CPU: 6 PID: 6164 at mm/vmalloc.c:487 __vmap_pages_range_noflush+0x3

[Diederik de Haas]

Control: forwarded -1 
https://lore.kernel.org/linux-iommu/Y9qSwkLxeMpffZK%2F@gallifrey/

On Wednesday, 1 February 2023 18:46:43 CET Dr. David Alan Gilbert wrote:
> I sent this upstream report:
> https://lore.kernel.org/linux-iommu/Y9qSwkLxeMpffZK%2F@gallifrey/T/#u

Thanks :-) Updated bug accordingly.

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

Bug#1030263: telegram-desktop: Telegram-Desktop ignores Shift-Key

[Arne Wichmann]

Package: telegram-desktop
Version: 4.5.3+ds-1+b1
Severity: normal

Hi.

Since the latest upgrade, telegram-desktop ignores the shift-modifier on my
system.

cu

AW

-- Package-specific info:

-- System Information:
Debian Release: 11.1
  APT prefers testing
  APT policy: (90, 'testing'), (90, 'stable'), (50, 'unstable'), (40, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.4 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.iso885915, LC_CTYPE=en_GB.iso885915 (charmap=ISO-8859-15), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages telegram-desktop depends on:
ii  libabsl20220623   20220623.1-1
ii  libavcodec59  7:5.1.2-1
ii  libavformat59 7:5.1.2-1
ii  libavutil57   7:5.1.2-1
ii  libc6 2.36-8
ii  libgcc-s1 10.2.1-6
ii  libglib2.0-0  2.74.5-1
ii  libglibmm-2.68-1  2.74.0-2
ii  libhunspell-1.7-0 1.7.0-3
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  libkf5coreaddons5 5.101.0-1
ii  liblz4-1  1.9.3-2
ii  libminizip1   1.1-8+b1
ii  libopenal11:1.19.1-2
ii  libopus0  1.3.1-0.1
ii  libqrcodegencpp1  1.6.0-1
ii  libqt5core5a [qtbase-abi-5-15-8]  5.15.8+dfsg-2
ii  libqt5gui55.15.8+dfsg-2
ii  libqt5network55.15.8+dfsg-2
ii  libqt5qml55.15.8+dfsg-2
ii  libqt5quickwidgets5   5.15.8+dfsg-2
ii  libqt5svg55.15.8-2
ii  libqt5waylandcompositor5  5.15.8-2
ii  libqt5widgets55.15.8+dfsg-2
ii  librlottie0-1 0.1+dfsg-2
ii  libsigc++-3.0-0   3.4.0-1
ii  libssl3   3.0.7-2
ii  libstdc++612.2.0-14
ii  libswresample47:5.1.2-1
ii  libswscale6   7:5.1.2-1
ii  libvpx7   1.12.0-1
ii  libwayland-client01.21.0-1
ii  libx11-6  2:1.8.3-3
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-record01.14-3
ii  libxcb-screensaver0   1.14-3
ii  libxcb1   1.14-3
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1.1
ii  libxfixes31:5.0.3-2
ii  libxrandr22:1.5.1-1
ii  libxtst6  2:1.2.3-1.1
ii  libxxhash00.8.0-2
ii  qt5-image-formats-plugins 5.15.2-2
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans   1.11-1.1
ii  libwebkit2gtk-4.0-37  2.38.3-1~deb11u1

telegram-desktop suggests no packages.

Versions of packages telegram-desktop is related to:
pn  xdg-desktop-portal  
pn  xdg-desktop-portal-backend  

-- no debconf information
[2023.02.01 11:50:25] Launched version: 4005003, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2023.02.01 11:50:25] Executable dir: /usr/bin/, name: telegram-desktop
[2023.02.01 11:50:25] Initial working dir: /home/aw/
[2023.02.01 11:50:25] Working dir: /home/aw/.local/share/TelegramDesktop/
[2023.02.01 11:50:25] Command line: telegram-desktop
[2023.02.01 11:50:25] Executable path before check: /usr/bin/telegram-desktop
[2023.02.01 11:50:25] Logs started
[2023.02.01 11:50:25] Launcher filename: org.telegram.desktop.desktop
[2023.02.01 11:50:25] We use allocator from /lib/x86_64-linux-gnu/libc.so.6
[2023.02.01 11:50:25] Connecting local socket to 
/tmp/87a6964082b9339a3cac3aa763854bc5-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2023.02.01 11:50:25] This is the only instance of Telegram, starting server 
and app...
[2023.02.01 11:50:25] Moved logging from 
'/home/aw/.local/share/TelegramDesktop/log_start0.txt' to 
'/home/aw/.local/share/TelegramDesktop/log.txt'!
[2023.02.01 11:50:25] Primary screen DPI: 96.2922
[2023.02.01 11:50:25] System tray available: [FALSE]
[2023.02.01 11:50:25] Icon theme: hicolor
[2023.02.01 11:50:25] Fallback icon theme: hicolor
[2023.02.01 11:50:25] App Info: reading settings...
[2023.02.01 11:50:25] App Info: reading encrypted settings...
[2023.02.01 11:50:26] Lang Info: Loaded cached, keys: 4561
[2023.02.01 11:50:26] Audio Info: Failed to load pipewire 0.3 stubs.
[2023.02.01 11:50:26] OpenAL Logging Level: (not set)
[2023.02.01 11:50:26] Audio Playback Devices: ALSA Default;HDA Intel PCH, 
ALC892 Analog (CARD=PCH,DEV=0);HDA Intel PCH, ALC892 Digital 
(CARD=PCH,DEV=1);HDA Intel PCH, HDMI 0 (CARD=PCH,DEV=3);HDA Intel PCH, HDMI 1 
(CARD=PCH,DEV=7);HDA Intel PCH, HDMI 2 (CARD=PCH,DEV=8)

Bug#1030262: gnome-control-center: User deleted via "gnome-control-center user-accounts" can still login

[Timo Lindfors]

Package: gnome-control-center
Version: 1:43.2-2
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: timo.lindf...@iki.fi, timo.lindf...@iki.fi, Debian Security Team 


Steps to reproduce:
1) Run "gnome-control-center user-accounts"
2) Click "Unlock..."
3) Enter root password
4) Click "Add User..."
5) Enter "demo2" as Name and Username and click "Add".
6) Click "Remove User..."
7) Click "Delete" when prompted.
8) Logout
9) Select "Not listed?" and login as "demo2". Set the new password when 
prompted.
10) Hit the GUI key and type terminal, right click to access terminal 
preferences
11) Set the custom command in Unnamed/Command to /bin/bash
12) Start terminal

Expected results:
9) Login fails since the user has been deleted

Actual results:
9) Login succeeds even though the user was deleted from the UI.

More info:

This issue is particularly scary since both the settings application
and the login screen do not show the user after it has been
deleted. This gives the user the impression that the deletion actually
succeeded.


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

Kernel: Linux 6.1.0-2-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.08.8-1+b1
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-2.1
ii  desktop-base  12.0.2
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:43.2-2
ii  gnome-desktop3-data   43.1-1
ii  gnome-settings-daemon 43.0-4
ii  gsettings-desktop-schemas 43.0-1
ii  libaccountsservice0   22.08.8-1+b1
ii  libadwaita-1-01.2.1-2
ii  libc6 2.36-8
ii  libcairo2 1.16.0-7
ii  libcolord-gtk4-1  0.3.0-3
ii  libcolord21.4.6-2.1
ii  libcups2  2.4.2-1+b2
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.14.1-3
ii  libgcr-base-3-1   3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.5-1
ii  libgnome-bg-4-2   43.1-1
ii  libgnome-bluetooth-ui-3.0-13  42.5-2
ii  libgnome-desktop-4-2  43.1-1
ii  libgnome-rr-4-2   43.1-1
ii  libgnutls30   3.7.8-4
ii  libgoa-1.0-0b 3.46.0-1
ii  libgoa-backend-1.0-1  3.46.0-1
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.36-2
ii  libgtk-4-14.8.3+ds-1+b1
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0237-2
ii  libibus-1.0-5 1.5.27-4
ii  libkrb5-3 1.20.1-1
ii  libmalcontent-0-0 0.11.0-3
ii  libmm-glib0   1.20.4-1
ii  libnm01.40.10-1
ii  libnma-gtk4-0 1.10.6-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libpolkit-gobject-1-0 122-2
ii  libpulse-mainloop-glib0   16.1+dfsg1-2+b1
ii  libpulse0 16.1+dfsg1-2+b1
ii  libpwquality1 1.4.5-1+b1
ii  libsecret-1-0 0.20.5-3
ii  libsmbclient  2:4.17.5+dfsg-1
ii  libsnapd-glib-2-1 1.63-4
ii  libudisks2-0  2.9.4-4
ii  libupower-glib3   0.99.20-2
ii  libwacom9 2.5.0-1
ii  libx11-6  2:1.8.3-3
ii  libxi62:1.8-1+b1
ii  libxml2   2.9.14+dfsg-1.1+b3
ii  webp-pixbuf-loader0.0.5-5

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-5+b1
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.28.1-1
ii  gnome-bluetooth-sendto42.5-2
ii  gnome-online-accounts 3.46.0-1
ii  gnome-remote-desktop  43.3-1
ii  gnome-user-docs   43.0-1
ii  gnome-user-share  43.0-1
ii  iso-codes 4.12.0-1
ii  libcanberra-pulse 0.30-10
ii  libnss-myhostname 252.4-2
ii  libspa-0.2-bluetooth  0.3.65-1
ii  malcontent-gui0.11.0-3
ii  network-manager-gnome 1.30.0-2
ii  polkitd   122-2
ii  power-profiles-daemon 0.12-1+b1
ii  realmd0.17.1-1
ii  rygel 0.42.0-2
ii  rygel-tracker 0.42.0-2
ii  system-config-printer-common  1.5.18-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   43.3-1
pn  gstreamer1.0-pulseaudio  
ii  pkexec   122-2
ii  x11-xserver-utils 

Bug#1030256: [Pkg-puppet-devel] Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet

[Jérôme Charaoui]

I think this is occurring because the test is being run as "root".

I don't know how common that is in build environments, but it's not 
something that I have or think I should have in my build (sbuild) or 
test (autopkgtest) environments.


Is there some flag we could use to tell reproducible-builds to build 
this package as a regular user instead of root?


If not I might have to patch the test suite to work around some of the 
logic in there, which I'm not too excited about.


Perhaps an alternative would be to add "puppet-agent" as a build 
dependency, because that package will create a "puppet" user in the 
environment.


Thanks,

-- Jérôme