Bug#1035852: Updated patch series for version jhove version 1.28.0

[tony mancill]

Hi Elias,

Thank you for your work to update jhove.

I will review the patches and help with the upload, although not until
after the bookworm release (which is just over a week away).

Cheers,
tony

On Thu, Jun 01, 2023 at 04:23:33PM +0200, Elias Oltmanns wrote:
> Hi there,
> 
> meanwhile, version 1.28.0 has been released upstream. Please find the
> updated patch series below.
> 
> Also, I have realised that I am probably not asking for a NMU because I
> am not a Debian developer myself. Can anyone review the patches and help
> to get a new version uploaded?
> 
> Thank you in advance,
> 
> Elias

> From ea1161185c01a2510ba6c7d07b0d98009b78d5b4 Mon Sep 17 00:00:00 2001
> From: Elias Oltmanns 
> Date: Wed, 19 Apr 2023 10:00:55 +0200


signature.asc
Description: PGP signature

Bug#1037031: gdb: std::length_error with tab-completion on Meson-built Rust program

[Duncan McIntosh]

Package: gdb
Version: 13.1-3
Severity: normal
X-Debbugs-Cc: duncan82...@live.ca

Dear Maintainer,

I have a small project built with C and Rust using Meson. When I build
the project and try to set a breakpoint with tab-completion, GDB exits
with a std::length_error, seemingly only for some symbols.

I can't produce it with a Cargo-built program, but I can with a skeleton
Meson project, which I'll refer to for the rest of this report:

$ mkdir proj  # or whatever
$ cd $_
$ meson init -l rust
[...]
$ meson setup build
[...]
$ meson compile -C build
[...]
$ gdb ./build/proj
[...]
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /tmp/proj/build/proj.
(gdb) b q
*** nothing happens, just beeping
*** (if target is run first, includes e.g. 'qsort')
(gdb) b a
Display all 145 possibilities? (y or n) y
[... symbols, including 'abbrev.rs' and
 'alloc::alloc::box_free::h293b7814a118f9bc' ...]
(gdb) b c
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_M_replace


Fatal signal: Aborted
- Backtrace -
[below]
-
A fatal error internal to GDB has been detected, further
debugging is not possible.  GDB will now terminate.

This is a bug, please report it.  For instructions, see:
.

Aborted (core dumped)

The executable does work in lldb. Most of the rest of GDB probably
works, too; the completion seems to be the only broken thing.

A bunch of letters aside from 'c' (e.g. 'l', 'w') also crash; my guess
is that there's a bunch of functions that mess GDB up, and they're in
core:: or similar.

I'm running rustc from rustup, version
rustc 1.72.0-nightly (d59363ad0 2023-06-01)
I originally found it with
rustc 1.71.0-nightly (5ea3f0ae0 2023-05-23)

I've attached the backtrace below; my apologies for the missing symbols
before the abort(). It seems to be in a C++ destructor, but I can't
figure out which (or which package provides the symbols in question.)

- Backtrace -
0x55f3d0ab340e gdb_internal_backtrace_1
/build/gdb-kUlB6r/gdb-13.1/gdb/bt-utils.c:122
0x55f3d0ab340e _Z22gdb_internal_backtracev
/build/gdb-kUlB6r/gdb-13.1/gdb/bt-utils.c:168
0x55f3d0bbc601 handle_fatal_signal
/build/gdb-kUlB6r/gdb-13.1/gdb/event-top.c:956
0x7fbab3a5af8f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7fbab3aa9ccc __pthread_kill_implementation
./nptl/pthread_kill.c:44
0x7fbab3a5aef1 __GI_raise
../sysdeps/posix/raise.c:26
0x7fbab3a45471 __GI_abort
./stdlib/abort.c:79
0x7fbab3c9d918 ???
0x7fbab3ca8e19 ???
0x7fbab3ca7e88 ???
0x7fbab3ca85a5 ???
0x7fbab49ce933 ???
0x7fbab49cf38c ???
0x55f3d09f9f49 _ZNKSt14default_deleteI13location_specEclEPS0_
/usr/include/c++/12/bits/unique_ptr.h:95
0x55f3d09f9f49 _ZNSt10unique_ptrI13location_specSt14default_deleteIS0_EED4Ev
/usr/include/c++/12/bits/unique_ptr.h:396
0x55f3d09f9f49 
_Z18location_completerP16cmd_list_elementR18completion_trackerPKcS4_
/build/gdb-kUlB6r/gdb-13.1/gdb/completer.c:1042
0x55f3d0b131ca complete_line_internal_1
/build/gdb-kUlB6r/gdb-13.1/gdb/completer.c:1438
0x55f3d0b13245 complete_line_internal
/build/gdb-kUlB6r/gdb-13.1/gdb/completer.c:1457
0x55f3d0b1339a gdb_completion_word_break_characters_throw
/build/gdb-kUlB6r/gdb-13.1/gdb/completer.c:1907
0x55f3d0b1339a _Z36gdb_completion_word_break_charactersv
/build/gdb-kUlB6r/gdb-13.1/gdb/completer.c:1945
0x7fbab4c3dec5 _rl_find_completion_word
./complete.c:1091
0x7fbab4c3f263 rl_complete_internal
./complete.c:2027
0x7fbab4c3443f _rl_dispatch_subseq
./readline.c:916
0x7fbab4c34a8c readline_internal_char
./readline.c:675
0x7fbab4c52644 rl_callback_read_char
./callback.c:272
0x55f3d0bbd7fd gdb_rl_callback_read_char_wrapper_noexcept
/build/gdb-kUlB6r/gdb-13.1/gdb/event-top.c:188
0x55f3d0bbd98f gdb_rl_callback_read_char_wrapper
/build/gdb-kUlB6r/gdb-13.1/gdb/event-top.c:221
0x55f3d0bbcd0c stdin_event_handler
/build/gdb-kUlB6r/gdb-13.1/gdb/event-top.c:541
0x55f3d0fa41d5 gdb_wait_for_event
/build/gdb-kUlB6r/gdb-13.1/gdbsupport/event-loop.cc:716
0x55f3d0fa4cb2 _Z16gdb_do_one_eventi
/build/gdb-kUlB6r/gdb-13.1/gdbsupport/event-loop.cc:264
0x55f3d0c862f9 start_event_loop
/build/gdb-kUlB6r/gdb-13.1/gdb/main.c:411
0x55f3d0c862f9 captured_command_loop
/build/gdb-kUlB6r/gdb-13.1/gdb/main.c:471
0x55f3d0c87f74 captured_main
/build/gdb-kUlB6r/gdb-13.1/gdb/main.c:1330
0x55f3d0c87f74 _Z8gdb_mainP18captured_main_args
/build/gdb-kUlB6r/gdb-13.1/gdb/main.c:1345
0x55f3d0a16ca9 main
/build/gdb-kUlB6r/gdb-13.1/gdb/gdb.c:32
-


-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 

Bug#1037030: posix_spawn_file_actions_init(3) missing?

[Rob Browning]

Package: manpages-dev
Version: 6.03-2

posix_spawn(3) mentions it, but it doesn't appear to be in manpages-dev.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#1037029: spyder: Saving files window does not respect current active Gnome dark mode

[zezamoral]

Package: spyder
Version: 5.4.2+ds-5
Severity: minor
X-Debbugs-Cc: sazamor...@gmail.com

Dear Maintainer,


   * What led up to the situation?
Saving files with gnome dark mode enabled

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Saving a new file/project from the IDE.

   * What was the outcome of this action?
White window dialog during a gnome dark mode session

   * What outcome did you expect instead?
Dark theme window when saving a file in gnome dark mode enabled


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

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

Versions of packages spyder depends on:
ii  python3 3.11.2-1+b1
ii  python3-spyder  5.4.2+ds-5

spyder recommends no packages.

Versions of packages spyder suggests:
pn  python3-spyder-unittest  

Versions of packages python3-spyder depends on:
ii  ipython3   8.5.0-4
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libjs-mathjax  2.7.9+dfsg-1
ii  pyflakes3  2.5.0-1
ii  pylint 2.16.2-2
ii  python33.11.2-1+b1
ii  python3-atomicwrites   1.4.1-1
ii  python3-autopep8   2.0.1-1
ii  python3-chardet5.1.0+dfsg-2
ii  python3-cloudpickle2.2.0-1
ii  python3-cookiecutter   1.7.3-3
ii  python3-diff-match-patch   20200713-2
ii  python3-docutils   0.19+dfsg-6
ii  python3-flake8 5.0.4-4
ii  python3-intervaltree   3.0.2-1.1
ii  python3-ipython8.5.0-4
ii  python3-jedi   0.18.2-1
ii  python3-jellyfish  0.8.9-1+b4
ii  python3-jsonschema 4.10.3-1
ii  python3-keyring23.9.3-2
ii  python3-mccabe 0.7.0-1
ii  python3-nbconvert  6.5.3-3
ii  python3-numpydoc   1.5.0-1
ii  python3-parso  0.8.3-1
ii  python3-pexpect4.8.0-4
ii  python3-pickleshare0.7.5-5
ii  python3-pkg-resources  66.1.1-1
ii  python3-psutil 5.9.4-1+b1
ii  python3-pycodestyle2.10.0-1
ii  python3-pydocstyle 6.2.3-3
ii  python3-pygments   2.14.0+dfsg-1
ii  python3-pylint-venv2.3.0-2
ii  python3-pyls-spyder0.4.0-2
ii  python3-pylsp  1.7.1-1
ii  python3-pylsp-black1.2.1-2
ii  python3-pyqt5  5.15.9+dfsg-1
ii  python3-pyqt5.qtwebengine  5.15.6-1
ii  python3-qdarkstyle 3.1+ds1-1
ii  python3-qstylizer  0.2.2-1
ii  python3-qtawesome  1.2.2+dfsg-1
ii  python3-qtconsole  5.4.0-1
ii  python3-qtpy   2.3.0-1
ii  python3-rope   1.7.0-1
ii  python3-rtree  1.0.1-1
ii  python3-setuptools 66.1.1-1
ii  python3-sphinx 5.3.0-4
ii  python3-spyder-kernels 2.4.2-1
ii  python3-textdistance   4.5.0-1
ii  python3-three-merge0.1.1-4
ii  python3-watchdog   2.2.1-1
ii  python3-xdg0.28-2
ii  python3-zmq24.0.1-4+b1
ii  spyder-common  5.4.2+ds-5
ii  yapf3  0.32.0-1

python3-spyder recommends no packages.

Versions of packages python3-spyder suggests:
pn  cython3 
ii  python3-matplotlib  3.6.3-1+b1
ii  python3-numpy   1:1.24.2-1
pn  python3-pandas  
ii  python3-pil 9.4.0-1.1+b1
pn  python3-scipy   
ii  python3-sympy   1.11.1-1

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.36-9
ii  libgcc-s1 12.2.0-14
ii  libpython3.11 3.11.2-6
ii  libqt5core5a [qtbase-abi-5-15-8]  5.15.8+dfsg-11
ii  libqt5dbus5   5.15.8+dfsg-11
ii  libqt5designer5   5.15.8-2
ii  libqt5gui55.15.8+dfsg-11
ii  libqt5help5   5.15.8-2
ii  libqt5network55.15.8+dfsg-11
ii  libqt5printsupport5   5.15.8+dfsg-11
ii  libqt5test5   5.15.8+dfsg-11
ii  libqt5widgets55.15.8+dfsg-11
ii  libqt5xml55.15.8+dfsg-11
ii  libstdc++612.2.0-14
ii  python3   3.11.2-1+b1
ii  python3-pyqt5.sip 12.11.1-1

-- no debconf information

Bug#1037028: warzone2100: Update to version 4.3.5, to enable multiplayer again

[Linus Lüssing]

Package: warzone2100
Version: 4.3.3-3
Severity: normal
X-Debbugs-Cc: linus.luess...@c0d3.blue

Hi,

There've been two more releases, the latest version now is 4.3.5. It
would be great if the package could be updated accordingly to allow
joining multiplayer games again.

Regards, Linus


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Versions of packages warzone2100 depends on:
ii  libasound2  1.2.8-1+b1
ii  libc6   2.36-9
ii  libcurl3-gnutls 7.88.1-9
ii  libdecor-0-00.1.1-2
ii  libdrm2 2.4.114-1+b1
ii  libfreetype62.12.1+dfsg-5
ii  libfribidi0 1.0.8-2.1
ii  libgbm1 23.1.0-1
ii  libgcc-s1   12.2.0-14
ii  libharfbuzz0b   6.0.0+dfsg-3
ii  libminiupnpc17  2.2.4-1+b1
ii  libogg0 1.3.5-3
ii  libopenal1  1:1.19.1-2
ii  libopus01.3.1-3
ii  libphysfs1  3.0.2-6
ii  libpng16-16 1.6.39-2
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsamplerate0  0.2.2-3
ii  libsodium23 1.0.18-1
ii  libsqlite3-03.40.1-2
ii  libstdc++6  12.2.0-14
ii  libtheora0  1.1.1+dfsg.1-16.1+b1
ii  libvorbis0a 1.3.7-1
ii  libvorbisfile3  1.3.7-1
ii  libwayland-client0  1.21.0-1
ii  libwayland-cursor0  1.21.0-1
ii  libwayland-egl1 1.21.0-1
ii  libx11-62:1.8.4-2
ii  libxcursor1 1:1.2.1-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxi6  2:1.8-1+b1
ii  libxkbcommon0   1.5.0-1
ii  libxrandr2  2:1.5.2-2+b1
ii  libxss1 1:1.2.3-1
ii  warzone2100-data4.3.3-3
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages warzone2100 recommends:
ii  warzone2100-music  4.3.3-3

warzone2100 suggests no packages.

-- no debconf information

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Limonciello, Mario]

[AMD Official Use Only - General]

> -Original Message-
> From: Nick Hastings 
> Sent: Thursday, June 1, 2023 7:02 PM
> To: Karol Herbst 
> Cc: Limonciello, Mario ; Lyude Paul
> ; Lukas Wunner ; Salvatore
> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> Wysocki ; Len Brown ; linux-
> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> regressi...@lists.linux.dev
> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
>
> Hi,
>
> * Karol Herbst  [230602 03:10]:
> > On Thu, Jun 1, 2023 at 7:21 PM Limonciello, Mario
> >  wrote:
> > > > -Original Message-
> > > > From: Karol Herbst 
> > > > Sent: Thursday, June 1, 2023 12:19 PM
> > > > To: Limonciello, Mario 
> > > > Cc: Nick Hastings ; Lyude Paul
> > > > ; Lukas Wunner ; Salvatore
> > > > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > > > Wysocki ; Len Brown ; linux-
> > > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > > regressi...@lists.linux.dev
> > > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> system)
> > > >
> > > > On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
> > > >  wrote:
> > > > >
> > > > > [AMD Official Use Only - General]
> > > > >
> > > > > > -Original Message-
> > > > > > From: Karol Herbst 
> > > > > > Sent: Thursday, June 1, 2023 11:33 AM
> > > > > > To: Limonciello, Mario 
> > > > > > Cc: Nick Hastings ; Lyude Paul
> > > > > > ; Lukas Wunner ; Salvatore
> > > > > > Bonaccorso ; 1036...@bugs.debian.org; Rafael
> J.
> > > > > > Wysocki ; Len Brown ; linux-
> > > > > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > > > > regressi...@lists.linux.dev
> > > > > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video
> _OSI
> > > > > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> > > > system)
> > > > > >
> > > > > > On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> > > > > > >
> > > > > > > Lyude, Lukas, Karol
> > > > > > >
> > > > > > > This thread is in relation to this commit:
> > > > > > >
> > > > > > > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> > > > > > >
> > > > > > > Nick has found that runtime PM is *not* working for nouveau.
> > > > > > >
> > > > > >
> > > > > > keep in mind we have a list of PCIe controllers where we apply a
> > > > > > workaround:
> > > > > >
> > > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> > > > > > /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> > > > > >
> > > > > > And I suspect there might be one or two more IDs we'll have to add
> > > > > > there. Do we have any logs?
> > > > >
> > > > > There's some archived onto the distro bug.  Search this page for
> > > > "journalctl.log.gz"
> > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530
> > > > >
> > > >
> > > > interesting.. It seems to be the same controller used here. I wonder
> > > > if the pci topology is different or if the workaround is applied at
> > > > all.
> > >
> > > I didn't see the message in the log about the workaround being applied
> > > in that log, so I guess PCI topology difference is a likely suspect.
> > >
> >
> > yeah, but I also couldn't see a log with the usual nouveau messages,
> > so it's kinda weird.
> >
> > Anyway, the output of `lspci -tvnn` would help
>
> % lspci -tvnn
> -[:00]-+-00.0  Intel Corporation Device [8086:3e20]
>+-01.0-[01]00.0  NVIDIA Corporation TU117M [GeForce GTX 1650
> Mobile / Max-Q] [10de:1f91]

So the bridge it's connected to is the same that the quirk *should have been* 
triggering.

May 29 15:02:42 xps kernel: pci :00:01.0: [8086:1901] type 01 class 0x060400

Since the quirk isn't working and this is still a problem in 6.4-rc4 I suggest 
opening a
Nouveau drm bug to figure out why.

>+-02.0  Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630]
> [8086:3e9b]
>+-04.0  Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core
> Processor Thermal Subsystem [8086:1903]
>+-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 /
> 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911]
>+-12.0  Intel Corporation Cannon Lake PCH Thermal Controller
> [8086:a379]
>+-14.0  Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host 
> Controller
> [8086:a36d]
>+-14.2  Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f]
>+-15.0  Intel Corporation Cannon Lake PCH Serial IO I2C Controller 
> #0
> [8086:a368]
>+-15.1  Intel Corporation Cannon Lake PCH Serial IO I2C Controller 
> #1
> [8086:a369]
>+-16.0  Intel Corporation Cannon Lake PCH HECI Controller 
> [8086:a360]
>+-17.0  Intel Corporation Cannon Lake Mobile PCH SATA AHCI 
> Controller
> [8086:a353]
>

Bug#1037027: bsdtar tiny mistake

[Budi]

Package: bsdtar

its help message

First option must be a mode specifier:
  -c Create  -r Add/Replace  -t List  -u Update  -x Extract
Common Options:
  -b #  Use # 512-byte records per I/O block
  -f   Location of archive (default /dev/st0)
  -vVerbose
  -wInteractive
Create: bsdtar -c [options] [ |  | @ | -C  ]
  ,   add these items to archive
  -z, -j, -J, --lzma  Compress archive with gzip/bzip2/xz/lzma
  --format {ustar|pax|cpio|shar}  Select archive format
  --exclude   Skip files that match pattern
  -C   Change to  before processing remaining files
  @  Add entries from  to output
List: bsdtar -t [options] []
If specified, list only entries that match
Extract: bsdtar -x [options] []
If specified, extract only entries that match
  -kKeep (don't overwrite) existing files
  -mDon't restore modification times
  -OWrite entries to stdout, don't restore to disk
  -pRestore permissions (including ACLs, owner, file flags)

isn't supposed

 -C   Change to  before processing remaining files


line in/under Extract: bsdtar -x .

as tested works on:  bsdtar -xf ..
not work on  bsdtar -cf ...

Bug#991428: Consider migrating to original 7-Zip for Linux

[yokota]

Hello,

I'm maintaining 7zip package.

> The 7zip is available for bookworm.
>
> Features that its Debian configuration is currently lacking but that are 
> available:
> * Creating SFX archives (missing 7zCon.sfx)
> * rar module in non-free

SFX is supported since 7zip 22.01+dfsg-9.

rar module provided by another package and currently in ITP at:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036990
I need a mentor/sponsor to upload this package.

rar module is currently availale at:
 https://salsa.debian.org/yokota/7zip-rar
Build yourself to try it.

--
YOKOTA Hiroshi

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Nick Hastings]

Hi,

* Karol Herbst  [230602 03:10]:
> On Thu, Jun 1, 2023 at 7:21 PM Limonciello, Mario
>  wrote:
> > > -Original Message-
> > > From: Karol Herbst 
> > > Sent: Thursday, June 1, 2023 12:19 PM
> > > To: Limonciello, Mario 
> > > Cc: Nick Hastings ; Lyude Paul
> > > ; Lukas Wunner ; Salvatore
> > > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > > Wysocki ; Len Brown ; linux-
> > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > regressi...@lists.linux.dev
> > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of 
> > > system)
> > >
> > > On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
> > >  wrote:
> > > >
> > > > [AMD Official Use Only - General]
> > > >
> > > > > -Original Message-
> > > > > From: Karol Herbst 
> > > > > Sent: Thursday, June 1, 2023 11:33 AM
> > > > > To: Limonciello, Mario 
> > > > > Cc: Nick Hastings ; Lyude Paul
> > > > > ; Lukas Wunner ; Salvatore
> > > > > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > > > > Wysocki ; Len Brown ; linux-
> > > > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > > > regressi...@lists.linux.dev
> > > > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > > > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> > > system)
> > > > >
> > > > > On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> > > > > >
> > > > > > Lyude, Lukas, Karol
> > > > > >
> > > > > > This thread is in relation to this commit:
> > > > > >
> > > > > > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> > > > > >
> > > > > > Nick has found that runtime PM is *not* working for nouveau.
> > > > > >
> > > > >
> > > > > keep in mind we have a list of PCIe controllers where we apply a
> > > > > workaround:
> > > > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> > > > > /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> > > > >
> > > > > And I suspect there might be one or two more IDs we'll have to add
> > > > > there. Do we have any logs?
> > > >
> > > > There's some archived onto the distro bug.  Search this page for
> > > "journalctl.log.gz"
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530
> > > >
> > >
> > > interesting.. It seems to be the same controller used here. I wonder
> > > if the pci topology is different or if the workaround is applied at
> > > all.
> >
> > I didn't see the message in the log about the workaround being applied
> > in that log, so I guess PCI topology difference is a likely suspect.
> >
>
> yeah, but I also couldn't see a log with the usual nouveau messages,
> so it's kinda weird.
>
> Anyway, the output of `lspci -tvnn` would help

% lspci -tvnn
-[:00]-+-00.0  Intel Corporation Device [8086:3e20]
   +-01.0-[01]00.0  NVIDIA Corporation TU117M [GeForce GTX 1650 
Mobile / Max-Q] [10de:1f91]
   +-02.0  Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] 
[8086:3e9b]
   +-04.0  Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
Processor Thermal Subsystem [8086:1903]
   +-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 
6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911]
   +-12.0  Intel Corporation Cannon Lake PCH Thermal Controller 
[8086:a379]
   +-14.0  Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host 
Controller [8086:a36d]
   +-14.2  Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f]
   +-15.0  Intel Corporation Cannon Lake PCH Serial IO I2C Controller 
#0 [8086:a368]
   +-15.1  Intel Corporation Cannon Lake PCH Serial IO I2C Controller 
#1 [8086:a369]
   +-16.0  Intel Corporation Cannon Lake PCH HECI Controller [8086:a360]
   +-17.0  Intel Corporation Cannon Lake Mobile PCH SATA AHCI 
Controller [8086:a353]
   +-1b.0-[02-3a]00.0-[03-3a]--+-00.0-[04]00.0  Intel 
Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016] 
[8086:15d9]
   |   +-01.0-[05-39]--
   |   \-02.0-[3a]00.0  Intel 
Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 
2016] [8086:15db]
   +-1c.0-[3b]00.0  Intel Corporation Wi-Fi 6 AX200 [8086:2723]
   +-1c.4-[3c]00.0  Realtek Semiconductor Co., Ltd. RTS525A PCI 
Express Card Reader [10ec:525a]
   +-1d.0-[3d]00.0  Samsung Electronics Co Ltd NVMe SSD Controller 
SM981/PM981/PM983 [144d:a808]
   +-1f.0  Intel Corporation Cannon Lake LPC Controller [8086:a30e]
   +-1f.3  Intel Corporation Cannon Lake PCH cAVS [8086:a348]
   +-1f.4  Intel Corporation Cannon Lake PCH SMBus Controller 
[8086:a323]
   \-1f.5  Intel Corporation Cannon Lake PCH SPI Controller
   [8086:a324]


Regards,

Nick.

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Nick Hastings]

Hi,

* Limonciello, Mario  [230602 01:18]:
> +Lyude, Lukas, Karol
> 
> On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > 
> > * Nick Hastings  [230530 16:01]:
> > > * Mario Limonciello  [230530 13:00]:
> > 
> > > > As you're actually loading nouveau, can you please try nouveau.runpm=0 
> > > > on
> > > > the kernel command line?
> > > I'm not intentionally loading it. This machine also has intel graphics
> > > which is what I prefer. Checking my
> > > /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > > I see:
> > > 
> > > blacklist nvidia
> > > blacklist nvidia-drm
> > > blacklist nvidia-modeset
> > > blacklist nvidia-uvm
> > > blacklist ipmi_msghandler
> > > blacklist ipmi_devintf
> > > 
> > > So I thought I had blacklisted it but it seems I did not. Since I do not
> > > want to use it maybe it is better to check if the lock up occurs with
> > > nouveau blacklisted. I will try that now.
> > I blacklisted nouveau and booted into a 6.1 kernel:
> > % uname -a
> > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) 
> > x86_64 GNU/Linux
> > 
> > It has been running without problems for nearly two days now:
> > % uptime
> >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27
> > 
> > Regards,
> > 
> > Nick.
> 
> Thanks, that makes a lot more sense now.
> 
> Nick, Can you please test if nouveau works with runtime PM in the
> latest 6.4-rc?

I reported this twice already. I guess it was lost since for some
reason emails in this thread are not being trimmed. I'll repeat here:

I did eventually see a lockup of this kernel. On the console I saw:

[  151.035036] vfio-pci :01:00.0 Unable to change power state from D3cold 
to D0, device inaccessible

I did not see the other two lines that were present in earlier lock ups.

Regards,

Nick.

Bug#1026126: update on crosvm dependencies

[David Heidelberg]

Thanks for your work, I would love to pick the crosvm from Salsa and 
compile it for our Mesa3D CI builds at some point!


David

On Mon, 08 May 2023 14:21:29 +0900 Junichi Uekawa  
wrote:


>
> more dependencies, named-lock and bitreader uploaded to NEW queue.
>
>

--
David Heidelberg
Consultant Software Engineer

Bug#1037006: opensnitch: Upstream change enables ebpf compilation

[Pijgn]

On Thursday, June 1, 2023 6:22:14 PM EDT Gustavo Iñiguez Goya wrote:
> Petter is correct: we fall back to proc when ebpf can't be used.
> There's no difference in setting it to proc or let it fail.

> The error is "open /etc/opensnitchd/opensnitch.o: no such file or
> directory" This causes the settings not to be saved, because the
> default monitor method is 'ebpf' and it fails loading the module.

> Changing it to 'proc' applies the configuration.

So the only difference between 'ebpf' and 'proc' in Debian right now is 
whether 'Debug invalid connections' fails mysteriously when enabled?

> The main problem is to decide how the modules should be distributed:
> precompiled or compiled on every machine. The latter would add extra
> dependencies: clang, llvm, kernel headers, etc.

> And as part of the 'opensnitch' package or as a new package?

If the modules cannot be distributed precompiled, I would expect a 
separate Suggested package to depend on any development libraries.

In that case the default method in bookworm should be changed to 'proc' 
so that users must explicitly choose 'ebpf' before seeing this error.

Bug#1037026: bugs.debian.org: Thinkpad button led issue

[Anonymous thinkpad guy]

Package: bugs.debian.org
Severity: normal
X-Debbugs-Cc: raga_plonge...@icloud.com

Dear Maintainer,

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

   * What led up to the situation?
I wanted to mute the mic of mmy computer with the f4 button, and the
led of the button should turn on, but it doesn't.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?
The led on the mute mic button to turn on

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

Bug#1037006: opensnitch: Upstream change enables ebpf compilation

[Gustavo Iñiguez Goya]

Hi all,

On Thu, 1 Jun 2023 at 18:25, Pijgn  wrote:
>
> [Petter Reinholdtsen]
> > I believe this is a misunderstanding. Even if the default setting is
> > ebpf, it will fall back to using proc when it fail to find the ebpf
> > module.
>
> My testing suggests this is not reliable with the default eBPF setting.

Petter is correct: we fall back to proc when ebpf can't be used. There's
no difference in setting it to proc or let it fail.

> Applying the 'Debug invalid connections' setting (in the absence of the
> module) only produces an error message about the file not existing.

The error is "open /etc/opensnitchd/opensnitch.o: no such file or directory"
This causes the settings not to be saved, because the default monitor
method is 'ebpf' and it fails loading the module.

Changing it to 'proc' applies the configuration.

>
> Clicking the Save button allows the option state to persist between
> invocations of the settings dialog, but it does not survive a reboot and
> wireguard is silently denied regardless. I suppose that could be a bug
> against the GUI package; I did not test it headless.

It fails applying the configuration, so the settings are not saved to disk.
Changing the option in /etc/opensnitchd/default-config.json works as expected.

On the other hand, this error only applies to the Node tab. Changing the rest
of the settings (from their respective tabs) works as expected.

>
> It may be possible to use /etc/opensnitchd/system-fw.json as a
> workaround, but I did not try that since I was satisfied with the results
> of the procedure outlined at the beginning of this bug report.
>
> > I believe upstream would be pleased with help with this even if it do
> > not make it into bookworm.
>
> I think I used the 'upstream' tag wrong. The eBPF build process has
> already received a Debian-specific fix upstream, which will be part of
> OpenSnitch 1.6.0 when it is released. In this case, any patches would
> only be meaningful for bookworm, to exclude unrelated changes.
>
> I am interested in working on the patches to implement this fix, but if
> the change will not be compliant with bookworm update policy then the
> default monitor should be set to proc instead before it is too late.
>

The main problem is to decide how the modules should be distributed:
precompiled or compiled on every machine. The latter would add extra
dependencies: clang, llvm, kernel headers, etc.

And as part of the 'opensnitch' package or as a new package?

-- 

Clave Pública:
gpg --keyserver pgp.rediris.es --recv-keys BCF6BE9C

Bug#986730: RE : RFP publictransport

[matthias . geiger1024]

Hi Martin.

It seems like upstream moved here: https://gitlab.com/maevemi/publictransport/
>From Cargo.toml the only  issue apparent to me is hafas-client-rs not being on 
>crates.io  as that is the platform the rust-teams' tooling 
>is built around.

Since I maintain the gtk-rs stack in debian I'm going out on a limb and 
claiming all gtk-rs related packages will be in debian soon (tm) (realistically 
Jan 2024 ?). 

Regards,---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1037025: unblock: opensc/0.23.0-0.3

[Bastian Germann]

Package: release.debian.org
Control: affects -1 + src:opensc
X-Debbugs-Cc: ope...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package opensc.

[ Reason ]
Fixes CVE-2023-2977.

[ Risks ]
None.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock opensc/0.23.0-0.3diff -Nru opensc-0.23.0/debian/changelog opensc-0.23.0/debian/changelog
--- opensc-0.23.0/debian/changelog  2023-02-13 17:13:20.0 +0100
+++ opensc-0.23.0/debian/changelog  2023-06-01 22:30:18.0 +0200
@@ -1,3 +1,10 @@
+opensc (0.23.0-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix CVE-2023-2977 with upstream patch.
+
+ -- Bastian Germann   Thu, 01 Jun 2023 22:30:18 +0200
+
 opensc (0.23.0-0.2) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru 
opensc-0.23.0/debian/patches/0004-pkcs15init-correct-left-length-calculation.patch
 
opensc-0.23.0/debian/patches/0004-pkcs15init-correct-left-length-calculation.patch
--- 
opensc-0.23.0/debian/patches/0004-pkcs15init-correct-left-length-calculation.patch
  1970-01-01 01:00:00.0 +0100
+++ 
opensc-0.23.0/debian/patches/0004-pkcs15init-correct-left-length-calculation.patch
  2023-06-01 22:30:18.0 +0200
@@ -0,0 +1,57 @@
+Origin: 
https://github.com/OpenSC/OpenSC/commit/81944d1529202bd28359bede57c0a15deb65ba8a
+From: fullwaywang 
+Date: Mon, 29 May 2023 10:38:48 +0800
+Subject: pkcs15init: correct left length calculation to fix buffer overrun bug.
+ Fixes #2785
+
+From https://github.com/OpenSC/OpenSC/issues/2785:
+The newly found issue exists in pkcs15-init module. Like the original bug in 
libopensc,
+cardos_have_verifyrc_package in pkcs15-cardos.c scans an ans1 buffer for 2 
tags.
+The pointer p is moved after each sc_asn1_find_tag invocation,
+which results in the miscalculation of the length of left bytes in buffer
+and hence reading beyond the end of the buffer.
+
+CVE-2023-2977 was assigned for this issue.
+---
+ src/pkcs15init/pkcs15-cardos.c | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/src/pkcs15init/pkcs15-cardos.c b/src/pkcs15init/pkcs15-cardos.c
+index 9715cf390f..f41f73c349 100644
+--- a/src/pkcs15init/pkcs15-cardos.c
 b/src/pkcs15init/pkcs15-cardos.c
+@@ -872,7 +872,7 @@ static int cardos_have_verifyrc_package(sc_card_t *card)
+   sc_apdu_t apdu;
+ u8rbuf[SC_MAX_APDU_BUFFER_SIZE];
+ int   r;
+-  const u8  *p = rbuf, *q;
++  const u8  *p = rbuf, *q, *pp;
+   size_tlen, tlen = 0, ilen = 0;
+ 
+   sc_format_apdu(card, , SC_APDU_CASE_2_SHORT, 0xca, 0x01, 0x88);
+@@ -888,13 +888,13 @@ static int cardos_have_verifyrc_package(sc_card_t *card)
+   return 0;
+ 
+   while (len != 0) {
+-  p = sc_asn1_find_tag(card->ctx, p, len, 0xe1, );
+-  if (p == NULL)
++  pp = sc_asn1_find_tag(card->ctx, p, len, 0xe1, );
++  if (pp == NULL)
+   return 0;
+   if (card->type == SC_CARD_TYPE_CARDOS_M4_3) {
+   /* the verifyRC package on CardOS 4.3B use Manufacturer 
ID 0x01 */
+   /* and Package Number 0x07  
*/
+-  q = sc_asn1_find_tag(card->ctx, p, tlen, 0x01, );
++  q = sc_asn1_find_tag(card->ctx, pp, tlen, 0x01, );
+   if (q == NULL || ilen != 4)
+   return 0;
+   if (q[0] == 0x07)
+@@ -902,7 +902,7 @@ static int cardos_have_verifyrc_package(sc_card_t *card)
+   } else if (card->type == SC_CARD_TYPE_CARDOS_M4_4)  {
+   /* the verifyRC package on CardOS 4.4 use Manufacturer 
ID 0x03  */
+   /* and Package Number 0x02  
*/
+-  q = sc_asn1_find_tag(card->ctx, p, tlen, 0x03, );
++  q = sc_asn1_find_tag(card->ctx, pp, tlen, 0x03, );
+   if (q == NULL || ilen != 4)
+   return 0;
+   if (q[0] == 0x02)
diff -Nru opensc-0.23.0/debian/patches/series 
opensc-0.23.0/debian/patches/series
--- opensc-0.23.0/debian/patches/series 2023-02-13 17:13:04.0 +0100
+++ opensc-0.23.0/debian/patches/series 2023-06-01 22:30:18.0 +0200
@@ -1,3 +1,4 @@
 0001-Use-sysconfdir-opensc-for-opensc.conf.patch
 0002-Fix-private-key-import.patch
 0003-Log-OpenSSL-errors.patch
+0004-pkcs15init-correct-left-length-calculation.patch

Bug#986232: ITP organicmaps

[matthias . geiger1024]

Hi Frederico,

are you still working on this ?

I did a quick breakdown of which libraries might need packaging and ran a 
testbuild:

Embedded libs already in debian:

agg:  libagg2-dev
freetype:  libfreetype6-dev
glm:  libglm-dev
jansson:  libjansson-dev
GL:  libgl-dev
icu:  libicu-dev
kdtree++:  libkdtree++-dev
minizip:  libminizip-dev
stb_image:  libstb-dev
Vulkan-Headers:  libvulkan-dev
protobuf:  libprotobuf-dev
utfcpp:  libutfcpp-dev
bsdiff-courgette:  bsdiff and libdivsufsort-dev
boost:  libboost1.81-dev 
expat:  libexpat1-dev
gflags:  libgflags-dev
googletest:  libgtest-dev
pugixml:  libpugixml-dev

Embedded libraries that would packaging

just_gtfs: a single header, can probably stay since it was forked from maps.me
libtess2: NOT in debian: https://github.com/memononen/libtess2
open-location-code: NOT in debian, https://github.com/google/open-location-code
skarupke: NOT in debian: https://github.com/skarupke/flat_hash_map
fast_double_parser: NOT in debian: https://github.com/lemire/fast_double_parser
osrm: seems to stem from organic maps themselves ?
robust: NOT in debian, a single c file taken from here:  
http://www.cs.cmu.edu/~quake/robust.html 
vulkan_wrapper: I think this is not needed for a linux-only build since it's an 
AOSP header
liboauthcpp: NOT in debian: https://github.com/sirikata/liboauthcpp
opening_hours: NOT in debian. no idea where the source is
sdf_image: NOT in debian: https://github.com/memononen/SDF
succinct: NOT in debian: https://github.com/ot/succinct

relevant snippet of build log so far:
-
-- Found Threads: TRUE  
CMake Error at CMakeLists.txt:307 (add_subdirectory):
  add_subdirectory given source "3party/expat/expat" which is not an existing
  directory.


CMake Error at CMakeLists.txt:315 (add_subdirectory):
  add_subdirectory given source "3party/jansson/jansson/" which is not an
  existing directory.


CMake Error at CMakeLists.txt:316 (target_include_directories):
  Cannot specify include directories for target "jansson" which is not built
  by this project.


CMake Error at CMakeLists.txt:319 (add_subdirectory):
  add_subdirectory given source "3party/gflags" which is not an existing
  directory.


CMake Error at CMakeLists.txt:320 (target_compile_options):
  Cannot specify compile options for target "gflags_nothreads_static" which
  is not built by this project.


CMake Error at CMakeLists.txt:328 (add_subdirectory):
  add_subdirectory given source "3party/pugixml" which is not an existing
  directory.


CMake Error at CMakeLists.txt:331 (add_subdirectory):
  add_subdirectory given source
  "/<>/3party/protobuf"
  which is not an existing directory.


CMake Error at CMakeLists.txt:334 (add_subdirectory):
  add_subdirectory given source "3party/agg" which is not an existing
  directory.


CMake Error at CMakeLists.txt:335 (add_subdirectory):
  add_subdirectory given source "3party/bsdiff-courgette" which is not an
  existing directory.


-- Found the following ICU libraries:
--   uc (required): /usr/lib/x86_64-linux-gnu/libicuuc.so
--   i18n (required): /usr/lib/x86_64-linux-gnu/libicui18n.so
--   data (required): /usr/lib/x86_64-linux-gnu/libicudata.so
-- Found ICU: /usr/include (found version "72.1") 
-- Found Freetype: /usr/lib/x86_64-linux-gnu/libfreetype.so (found version 
"2.12.1") 
CMake Error at CMakeLists.txt:345 (add_subdirectory):
  add_subdirectory given source "3party/liboauthcpp" which is not an existing
  directory.


CMake Error at CMakeLists.txt:346 (add_subdirectory):
  add_subdirectory given source "3party/minizip" which is not an existing
  directory.


CMake Error at CMakeLists.txt:347 (add_subdirectory):
  add_subdirectory given source "3party/opening_hours" which is not an
  existing directory.


CMake Error at CMakeLists.txt:348 (add_subdirectory):
  add_subdirectory given source "3party/sdf_image" which is not an existing
  directory.


CMake Error at CMakeLists.txt:349 (add_subdirectory):
  add_subdirectory given source "3party/stb_image" which is not an existing
  directory.


CMake Error at CMakeLists.txt:350 (add_subdirectory):
  add_subdirectory given source "3party/succinct" which is not an existing
  directory.


CMake Error at CMakeLists.txt:351 (add_subdirectory):
  add_subdirectory given source "3party/open-location-code" which is not an
  existing directory.


CMake Error at CMakeLists.txt:352 (add_subdirectory):
  add_subdirectory given source "3party/vulkan_wrapper" which is not an
  existing directory.


CMake Error at CMakeLists.txt:355 (add_subdirectory):
  add_subdirectory given source "3party/libtess2" which is not an existing
  directory.


-- Found Python3: /usr/bin/python3 (found version "3.11.2") found components: 
Interpreter 
-- Found python to use in qt/, shaders/ and 3party/: /usr/bin/python3
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so   
CMake Error at drape/drape_tests/CMakeLists.txt:35 (add_subdirectory):
  add_subdirectory given source
  

Bug#1037023: blueman: missing dependency (Failed to load module "xapp-gtk3-module")

[Marc Lehmann]

Package: blueman
Version: 2.3.5-2+b1
Severity: normal

Dear Maintainer,

when gir1.2-xapp-1.0 is not installed, bluerman-manager displays the following 
message and immediately exits:

Gtk-Message: 22:49:13.732: Failed to load module "xapp-gtk3-module" 
 |

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

Kernel: Linux 6.1.30-schmorp (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 blueman depends on:
ii  adwaita-icon-theme  43-1
ii  bluez   5.66-1
ii  bluez-obexd 5.66-1
ii  dbus1.14.6-1
ii  dbus-user-session [default-dbus-session-bus]1.14.6-1
ii  dbus-x11 [dbus-session-bus] 1.14.6-1
ii  dconf-gsettings-backend [gsettings-backend] 0.40.0-4
ii  gir1.2-gdkpixbuf-2.02.42.10+dfsg-1+b1
ii  gir1.2-glib-2.0 1.74.0-3
ii  gir1.2-gtk-3.0  3.24.37-2
ii  gir1.2-nm-1.0   1.42.4-1
ii  gir1.2-pango-1.01.50.12+ds-1
ii  gnome-icon-theme3.12.0-5
ii  libbluetooth3   5.66-1
ii  libc6   2.36-9
ii  libpulse-mainloop-glib0 16.1+dfsg1-2+b1
ii  librsvg2-common 2.54.5+dfsg-1
ii  lxqt-notificationd [notification-daemon]1.2.0-1
ii  mate-icon-theme 1.26.0-1
ii  mate-notification-daemon [notification-daemon]  1.26.0-1
ii  notification-daemon 3.20.0-4+b1
ii  plasma-workspace [notification-daemon]  4:5.27.5-2
ii  polkitd 122-3
ii  python3 3.11.2-1+b1
ii  python3-cairo   1.20.1-5+b1
ii  python3-gi  3.42.2-3+b1
ii  python3-gi-cairo3.42.2-3+b1
ii  xfce4-notifyd [notification-daemon] 0.7.3-1

Versions of packages blueman recommends:
ii  pulseaudio-module-bluetooth  16.1+dfsg1-2+b1

blueman suggests no packages.

-- no debconf information

Bug#1037024: nmu: modsecurity-apache_2.9.7-1

[Ervin Hegedüs]

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

Hello,

we uploaded the package modsecurity_apache
(libapache2-mod-security2) after the new upstream release, but
meanwhile an other package on which this package depends has a
new version (libapr).

Now the module complains during the startup process, and users
wondering why.

Please rebuild modsecurity-apache against libbar1 1.7-2.

nmu libapache2-mod-security2 . ANY . unstable . -m "Rebuild with updated apr"



Regards,


a.

Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed

[Andreas Beckmann]

Control: tag -1 patch

On 01/06/2023 12.31, Andreas Beckmann wrote:

That worked for me for zoph, but a new failure occurred in tt-rss.
I'm now trying a transitional mariadb-server-10.5 package which seems to 
work for both these cases. Will do a complete set of piuparts upgrade 
tests for all upgrade paths involving mariadb-server-10.5


First round of tests was successful, i.e. no new regressions so far.
(tests with apt-get upgrade && apt-get full-upgrade or 
--install-recommends are still running)
I attach the mariadb-server-10.5 package I tested with, it is missing 
adjustments of the description and a useful commit message.

Can you try that in your salsa setup?


AndreasFrom dab6d5731b4ca771f45852e825c906330417a97c Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Thu, 1 Jun 2023 11:39:59 +0200
Subject: [PATCH] add transitional mariadb-server-10.5 package

---
 debian/control | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/debian/control b/debian/control
index 6a35515d970..48328809812 100644
--- a/debian/control
+++ b/debian/control
@@ -293,7 +293,7 @@ Breaks: mariadb-client-10.0,
 mariadb-server-10.2,
 mariadb-server-10.3,
 mariadb-server-10.4,
-mariadb-server-10.5,
+mariadb-server-10.5 (<< 1:10.11),
 mariadb-server-10.6,
 mysql-client-5.5,
 mysql-client-5.6,
@@ -327,7 +327,7 @@ Replaces: mariadb-client-10.0,
   mariadb-server-10.2,
   mariadb-server-10.3,
   mariadb-server-10.4,
-  mariadb-server-10.5,
+  mariadb-server-10.5 (<< 1:10.11),
   mariadb-server-10.6,
   mysql-client-5.5,
   mysql-client-5.6,
@@ -372,7 +372,7 @@ Breaks: mariadb-client-10.1,
 mariadb-server-10.2,
 mariadb-server-10.3,
 mariadb-server-10.4,
-mariadb-server-10.5,
+mariadb-server-10.5 (<< 1:10.11),
 mariadb-server-10.6,
 mariadb-server-core-10.0,
 mariadb-server-core-10.1,
@@ -400,7 +400,7 @@ Replaces: mariadb-client-10.1,
   mariadb-server-10.2,
   mariadb-server-10.3,
   mariadb-server-10.4,
-  mariadb-server-10.5,
+  mariadb-server-10.5 (<< 1:10.11),
   mariadb-server-10.6,
   mariadb-server-core-10.0,
   mariadb-server-core-10.1,
@@ -484,7 +484,7 @@ Breaks: cqrlog (<< 1.9.0-5~),
 mariadb-server-10.2,
 mariadb-server-10.3,
 mariadb-server-10.4,
-mariadb-server-10.5,
+mariadb-server-10.5 (<< 1:10.11),
 mariadb-server-10.6,
 mariadb-server-5.5,
 mariadb-tokudb-engine-10.0,
@@ -506,7 +506,7 @@ Replaces: handlersocket-mysql-5.5,
   mariadb-server-10.2,
   mariadb-server-10.3,
   mariadb-server-10.4,
-  mariadb-server-10.5,
+  mariadb-server-10.5 (<< 1:10.11),
   mariadb-server-10.6,
   mariadb-server-5.5,
   mariadb-tokudb-engine-10.0,
@@ -532,6 +532,18 @@ Description: MariaDB database server binaries
  .
  This package includes the server binaries.
 
+Package: mariadb-server-10.5
+Architecture: any
+Depends: mariadb-server (>= 1:10.11),
+ ${shlibs:Depends}
+Description: MariaDB database server binaries
+ MariaDB is a fast, stable and true multi-user, multi-threaded SQL database
+ server. SQL (Structured Query Language) is the most popular database query
+ language in the world. The main goals of MariaDB are speed, robustness and
+ ease of use.
+ .
+ This package includes the server binaries.
+
 Package: mariadb-backup
 Architecture: any
 Breaks: mariadb-backup-10.1,
-- 
2.20.1

Bug#993370: sent to NEW

[Antoine Beaupré]

Control: tags -1 +patch +pending

I pushed the package to NEW, and the `debian/2.3.0-1` tag to:

https://salsa.debian.org/emacsen-team/rg-el

let's see what FTP masters think.

a.
-- 
Voter, c'est abdiquer
- Élisée Reclus

Bug#1035748: unblock: modsecurity/3.0.9-1

[Ervin Hegedüs]

Hi Salvatore,

On Thu, Jun 01, 2023 at 10:24:28PM +0200, Salvatore Bonaccorso wrote:
> Hi Paul,
> 
> > Yet there is a huge amount of white space changes and other changes that
> > look gratuitous. This is really not looking like a targeted fix. @Salvatore,
> > can we do a targeted security upload via security?
> 
> The targeted should be (Alberto, Ervin can you confirm)
> https://github.com/SpiderLabs/ModSecurity/commit/db84d8cf771d39db578707cd03ec2b60f74c9785
> . While it would have been nice to start with modsecurity without
> (known) security issues open in bookworm, I guess at this point of the
> release preparation and soon entering  the last week, skip it and the
> CVE can be fixed in the first bookworm point release.

yes, this is a critical bug, which leads to an unexpected
behavior (the attacker can DOS-ed the whole Nginx).

But - as I explained in my other e-mail - libmodsecurity3 has a
complex codebase, with a language (grammar) parser. This can
cause a huge diff's, unfortunately.

> Regards,
> Salvatore
> 
> p.s.: The PCRE to PCRE2 switch is one other aspect why it would have
>   been nice to have 3.0.9 in bookworm.

Exactly.

We upload this library earlier, but meanwhile Nginx bumped the
PCRE version (finally!) to PCRE2. We *MUST* to update this
package too to ingore the other unexpected behaviors.



Thanks,


a.

Bug#984976: mumble: Keyboard shortcuts can't be assigned

[Jake Byrd]

Package: mumble
Version: 1.3.4-4
Followup-For: Bug #984976
X-Debbugs-Cc: jacobb...@gmail.com

Dear Maintainer,

Doing the same steps as listed previously by others that have reported on this
bug with version 1.3.4-1 this bug still exist in 1.3.4-4.

Best Regards
Jacob


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

Kernel: Linux 6.3.0-0-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 mumble depends on:
ii  libasound21.2.8-1+b1
ii  libavahi-compat-libdnssd1 0.8-10
ii  libc6 2.36-9
ii  libgcc-s1 12.2.0-14
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3
ii  libprotobuf32 3.21.12-3
ii  libpulse0 16.1+dfsg1-2+b1
ii  libqt5core5a  5.15.8+dfsg-11
ii  libqt5dbus5   5.15.8+dfsg-11
ii  libqt5gui55.15.8+dfsg-11
ii  libqt5network55.15.8+dfsg-11
ii  libqt5sql55.15.8+dfsg-11
ii  libqt5sql5-sqlite 5.15.8+dfsg-11
ii  libqt5svg55.15.8-3
ii  libqt5widgets55.15.8+dfsg-11
ii  libqt5xml55.15.8+dfsg-11
ii  libsndfile1   1.2.0-1
ii  libspeechd2   0.11.4-2
ii  libspeex1 1.2.1-2
ii  libspeexdsp1  1.2.1-1
ii  libssl3   3.0.9-1
ii  libstdc++612.2.0-14
ii  libx11-6  2:1.8.4-2
ii  libxi62:1.8-1+b1
ii  lsb-release   12.0-1

mumble recommends no packages.

Versions of packages mumble suggests:
pn  mumble-server  
ii  speech-dispatcher  0.11.4-2

-- no debconf information

Bug#1024523: yad packaging

[Bastian Germann]

Am 01.06.23 um 20:06 schrieb Alexis:

Thank you so much

I had to find someone with permissions to upload to the repository.

If possible, please upload the Yad 7.2 sources available on https://deb.picalibre.org/src/yad/ 
 or its mirror https://deb2.picalibre.org/src/yad/ 
 (binaries on https://deb.picalibre.org/pool/main/y/yad 
/ and https://deb2.picalibre.org/pool/main/y/yad/ 
 )


I will have a look at them but for now upload to experimental.
Please see the GitHub issue that I posted on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919785
This was brought to my attention after the upload.
Please make sure that the update to 7.2 does not result in a regression, as 
claimed by the issue.


It has some extra patches of its own. We have been testing these binaries on 
different architectures, all good.

Best regards

El 2023-05-30 17:11, Bastian Germann escribió:


Hi Alexis,

To get the ball rolling I went ahead with importing the 7.2 release into 
experimental.
Please hand in an unstable upload when the bookworm release is done.

Thanks,
Bastian

Bug#1035748: unblock: modsecurity/3.0.9-1

[Ervin Hegedüs]

hi there,

sorry to join this conversation :),

On Thu, Jun 01, 2023 at 09:52:06PM +0200, Paul Gevers wrote:
> control: tags -1 moreinfo
> 
> Hi,
> 
> On 28-05-2023 21:30, Alberto Gonzalez Iniesta wrote:
> > 2) The risks on the release quality are almost zero. Only
> > libnginx-mod-http-modsecurity depends on it (being modsecurity a
> > library).
> 
> That's not the only part that we mean here. We also mean, how big is the
> risk we introduce new *unknown* issues.

I think there is absolutely no risk. Bot package (libmodsecurity3
and libnginx-mod-http-modsecurity) is totally new packages, we
won't introduce any "unknown" issues.

Or - sorry to say - I don't see what issues do you think about.

> > 4) No idea
> 
> Then I don't think so. If your upstream would have a decent stable update
> policy, they wouldn't introduce so many gratuitous changes (e.g. white space
> only).

Unfortunately the vendor releases new versions randomly. :(
 
> > 6) Yes
> 
> I fail to spot it. Can you please point which version?

Hmmm... I don't think so (I mean the correct answer for the 6th
question is no). As I noted above, both packages are totally new.

(But the demand is very big)
 
> > 7) Its too long but mainly because of line numbers being updated in code
> > comments, like:
> > -#line 1459 "seclang-parser.yy"
> > +#line 1461 "seclang-parser.yy"
> > 8) Not that many code changes
> 
> Yet there is a huge amount of white space changes and other changes that
> look gratuitous. This is really not looking like a targeted fix. @Salvatore,
> can we do a targeted security upload via security?

these files (which created the huge diff) are generated by Bison.
These describe the grammar for the SecLang configuration syntax.

This is how a compiler works: if the developer adds a new token,
change a small behavior, then it can result a huge diff.

(A side note: not these files (above) have huge diff, but the
derived ones: seclang-parser.cc, seclang-parser.hh,
seclang-scanner.cc)

 
> > 9) Not that difficult :-)
> 
> Might be, but impossible to review between all the cruft.

The mentioned files have huge diff, but those diff's are because
of those files are compiled.

You can consider these like a .am file, which generated from a
.in file with help of autotools.

I'm not sure anyone wants to review a .am file :)


Sorry again,

and thanks for your time/help.



a.

 

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[Theodore Ts'o]

severity 1035543 normal
retitle 1035543 e2fsprogs: on an upgrade from bullseye e2scrub-reap.service may 
be wanted by default.target instead of multi-user.target
thanks

On Thu, Jun 01, 2023 at 07:40:25PM +0100, James Addison wrote:
> > So it's not a big deal; is that correct so this patch is not worth
> > trying to shoehorn in beform Bookworm ships, and this particular patch
> > can be safely downgraded from important, right?
> 
> I think all of that is true, yep.

OK, I've reset this to normal.

> Also, arguing against my own revert-patch: I think it could be said
> that multi-user is the "better" target to use here, because the
> default could be "graphical" or some later-reached system state
> whereas this is a relatively low-level (if small) system cleanup
> service.

Right, that's I believe the point of bug #991349; it's possible that
the system adminsitrator might manually set default.target to point to
graphical.target, per [1].  And since multi-user.target is a subset of
graphical.target, it makes sense to make the Wanted-by to be
multi-user.target.

[1] https://www.baeldung.com/linux/systemd-target-multi-user

And so it's fair to keep this bug open, but I think it makes it a
normal bug, with the resumption that hopefully it can be fixed via 
deb-systemd-helper or init-system-helpers.

In this particular case, since we *always* want it to be
default.target, since the whole *point* is to clean up after a failed
e2scrub, it seems really unlikely to me that the system administrator
would change this.  So this is one where it's probably fair for the
postinstall script to just fix the wanted-by link **always** if the
the systemd unit file says Wanted-by: default.target, and the symlink
is inconsistent with it.

Maybe this will mess with some kind of hidden systemd rules of the
road, but quite frankly, the fact that this is causing so much pain
and confusion, I'm not sure I care.

> I'd agree with downgrading the severity to below RC (and it's your
> package, so feel free, I think?  maybe even close it?).  If anyone
> arrives here/reports other bugs as a result of experiencing it, I
> think we can let them know that it's safe to remove the legacy
> 'default.target' symlink (does that sound correct too?).

I think so.  The symlink should *never* be considered normative,
right?  The unit file should be considered the single source of truth.
If the system administrator wants to do something weird, they are
supposed to copy /lib/systemd/system/e2scrub_reap.service to
/etc/systemd/system/e2scrub_reap.service, and if the symlink is
inconsistent with what's in the unit file (with the one in
/etc/systemd/...  if it exists taking precedence over the one in
/lib/systemd/..., we should just fix the symlink.

So this should be fixable in deb-systemd-helper, or I can just
implement a Big Fat Hammer in e2fsprogs's postinst script.

Does that sound right?

- Ted

Bug#1035748: unblock: modsecurity/3.0.9-1

[Salvatore Bonaccorso]

Hi Paul,

On Thu, Jun 01, 2023 at 09:52:06PM +0200, Paul Gevers wrote:
> control: tags -1 moreinfo
> 
> Hi,
> 
> On 28-05-2023 21:30, Alberto Gonzalez Iniesta wrote:
> > 2) The risks on the release quality are almost zero. Only
> > libnginx-mod-http-modsecurity depends on it (being modsecurity a
> > library).
> 
> That's not the only part that we mean here. We also mean, how big is the
> risk we introduce new *unknown* issues.
> 
> > 4) No idea
> 
> Then I don't think so. If your upstream would have a decent stable update
> policy, they wouldn't introduce so many gratuitous changes (e.g. white space
> only).
> 
> > 6) Yes
> 
> I fail to spot it. Can you please point which version?
> 
> > 7) Its too long but mainly because of line numbers being updated in code
> > comments, like:
> > -#line 1459 "seclang-parser.yy"
> > +#line 1461 "seclang-parser.yy"
> > 8) Not that many code changes
> 
> Yet there is a huge amount of white space changes and other changes that
> look gratuitous. This is really not looking like a targeted fix. @Salvatore,
> can we do a targeted security upload via security?

The targeted should be (Alberto, Ervin can you confirm)
https://github.com/SpiderLabs/ModSecurity/commit/db84d8cf771d39db578707cd03ec2b60f74c9785
. While it would have been nice to start with modsecurity without
(known) security issues open in bookworm, I guess at this point of the
release preparation and soon entering  the last week, skip it and the
CVE can be fixed in the first bookworm point release.

Regards,
Salvatore

p.s.: The PCRE to PCRE2 switch is one other aspect why it would have
  been nice to have 3.0.9 in bookworm.

Bug#1031799: New patches to fix search for hip-lang

[Cordell Bloor]

tag 1031799 patch
thanks

Brad King has mostly fixed this problem upstream [1]. I've opened a pull 
request [2] that backports his patch series and adds another small fix 
required to close this bug.


Sincerely,
Cory Bloor

[1]: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8525
[2]: https://salsa.debian.org/cmake-team/cmake/-/merge_requests/12

Bug#1037022: rime-data-jyut6ping3: Words/Characters not sorted by frequency (vocabulary file missing)

[Anthony Fok]

Package: rime-data-jyut6ping3
Version: 0.0~git20230209.e0295fa-1
Severity: important
Tags: patch
X-Debbugs-Cc: f...@debian.org

Recently, the Jyut6ping3 Cantonese input method became very awkward to
use because the vocabularies (words and characters) are not sorted by
frequency order.

It turns out that, starting with upstream snapshot 0.0~git20230209.e0295fa
(or thereabouts in early February 2023), upstream maintainers has switched
from using the preset vocabulary file in /usr/share/rime-data/essay.txt
(from the rime-essay package) to a Cantonese-specific vocabulary file
in /usr/share/rime-data/essay-cantonese.txt which unfortunately was not
installed in rime-data-jyut6ping3 0.0~git20230209.e0295fa-1.

Installing /usr/share/rime-data/essay-cantonese.txt resolves the issue;
see the attached install-essay-cantonese.patch.

Cheers,

Anthony Fok

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

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

Versions of packages rime-data-jyut6ping3 depends on:
ii  rime-data-cangjie5 0.0~git20210223.8dfad9e-3+b1
ii  rime-data-emoji0.0~git20230219.68dc116-1
ii  rime-data-loengfan 0.0~git20220303.987ac95-1
ii  rime-data-luna-pinyin  0.0~git20230204.79aeae2-2
ii  rime-data-stroke   0.0~git20230204.c8bc405-1

rime-data-jyut6ping3 recommends no packages.

rime-data-jyut6ping3 suggests no packages.

-- no debconf information
diff --git a/debian/rime-data-jyut6ping3.install 
b/debian/rime-data-jyut6ping3.install
index 5a9f221..79fb3e9 100644
--- a/debian/rime-data-jyut6ping3.install
+++ b/debian/rime-data-jyut6ping3.install
@@ -2,3 +2,4 @@ build/jyut6ping3* usr/share/rime-data/build/
 jyut6ping3*.yaml usr/share/rime-data/
 opencc usr/share/rime-data/
 symbols_cantonese.yaml /usr/share/rime-data/
+essay-cantonese.txt /usr/share/rime-data/

Bug#694154: debian-installer: Preseeding isn't possible for partman-crypto (encrypted LVM)

[Cyril Brulebois]

James Addison  (2023-06-01):
> I haven't used (wasn't aware of!) that before, and don't currently have a
> commandline mail client installed, but I'll try that out in future, yep -
> thanks.  Be prepared to wait a while until I migrate stuff though
> (fortunately for everyone here, I'm probably going to be sending much less
> communication now that bookworm is nearing done and dusted).

Alright, thanks for considering. I'm very happy you've followed up to a
bunch of new and old bug reports, but I must confess that bunch of lines
at the top kind of draw the attention away from the actual bts command
(if any), and having to carry recipients over from X-Debbugs-Cc to Cc
manually is a bit cumbersome, that's why I thought I should ask.

I'm definitely *not* asking you to stop working the way you did so far,
I was really just wondering whether you considered a different approach.

> Sometimes I'm uncertain how much action to take on behalf of a
> maintainer, especially without a sense of consensus, and/or without
> being familiar with the details; also some packages and bugs feel more
> important than others - any of those factors can make me more cautious
> (and even then I'm inconsistent, no doubt).

I understand the feeling completely! And caution is good!

For what it's worth, if you find a bug that's “evidently” closed because
a missing feature was implemented, and if you have a version to close
the bug report with, please feel free to do so, with -done & Version:
pseudo-header. It's easy enough to issue a reopen command if that turned
out to be a mistake.


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


signature.asc
Description: PGP signature

Bug#1035748: unblock: modsecurity/3.0.9-1

[Paul Gevers]

control: tags -1 moreinfo

Hi,

On 28-05-2023 21:30, Alberto Gonzalez Iniesta wrote:

2) The risks on the release quality are almost zero. Only
libnginx-mod-http-modsecurity depends on it (being modsecurity a
library).


That's not the only part that we mean here. We also mean, how big is the 
risk we introduce new *unknown* issues.



4) No idea


Then I don't think so. If your upstream would have a decent stable 
update policy, they wouldn't introduce so many gratuitous changes (e.g. 
white space only).



6) Yes


I fail to spot it. Can you please point which version?


7) Its too long but mainly because of line numbers being updated in code
comments, like:
-#line 1459 "seclang-parser.yy"
+#line 1461 "seclang-parser.yy"
8) Not that many code changes


Yet there is a huge amount of white space changes and other changes that 
look gratuitous. This is really not looking like a targeted fix. 
@Salvatore, can we do a targeted security upload via security?



9) Not that difficult :-)


Might be, but impossible to review between all the cruft.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037021: opensc: CVE-2023-2977

[Salvatore Bonaccorso]

Source: opensc
Version: 0.23.0-0.2
Severity: important
Tags: security upstream
Forwarded: https://github.com/OpenSC/OpenSC/issues/2785
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for opensc.

CVE-2023-2977[0]:
| A vulnerbility was found in OpenSC. This security flaw cause a buffer
| overrun vulnerability in pkcs15 cardos_have_verifyrc_package. The
| attacker can supply a smart card package with malformed ASN1 context.
| The cardos_have_verifyrc_package function scans the ASN1 buffer for 2
| tags, where remaining length is wrongly caculated due to moved
| starting pointer. This leads to possible heap-based buffer oob read.
| In cases where ASAN is enabled while compiling this causes a crash.
| Further info leak or more damage is possible.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-2977
https://www.cve.org/CVERecord?id=CVE-2023-2977
[1] https://github.com/OpenSC/OpenSC/issues/2785
[2] 
https://github.com/OpenSC/OpenSC/commit/81944d1529202bd28359bede57c0a15deb65ba8a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Brian Vaughan]

I hadn't even noticed Synaptic kept logs.

There was one other set of updates, after the last time I saw the error 
in Spyder:


Commit Log for Wed May 31 16:06:10 2023


Upgraded the following packages:
chromium (113.0.5672.126-1) to 114.0.5735.90-1
chromium-common (113.0.5672.126-1) to 114.0.5735.90-1
chromium-sandbox (113.0.5672.126-1) to 114.0.5735.90-1
libgc1 (1:8.2.2-3) to 1:8.2.4-1
libnautilus-extension4 (43.2-1) to 43.4-1
libssl-dev (3.0.8-1) to 3.0.9-1
libssl3 (3.0.8-1) to 3.0.9-1
libssl3:i386 (3.0.8-1) to 3.0.9-1
needrestart (3.6-3) to 3.6-4
openssl (3.0.8-1) to 3.0.9-1
signal-desktop (6.19.0) to 6.20.0
syncthing-gtk (0.9.4.4+ds+git20221205+12a9702d29ab-1) to 
0.9.4.4+ds+git20221205+12a9702d29ab-2

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Julian Gilbey]

On Thu, Jun 01, 2023 at 09:02:54AM -0700, Brian Vaughan wrote:
> I have good news and bad news.
> 
> The good news is that the issue seems to have been fixed as of today. I
> don't get the error popup, and Help > Dependencies shows pylsp_black
> installed and at version 1.21.
> 
> The bad news is I'm not sure what fixed it. I realized I made the mistake of
> following my daily routine of updating my system, which is not a good idea
> when troubleshooting. I checked the changelog dates on the dependencies for
> python3-spyder, and the most recently updated were python3-pygments on April
> 19, and python3-cookiecutter and python3-sphinx on March 29.
> 
> The only updates today were chromium, chromium-common, and chromium-sandbox,
> updated to 114.0.5735.90-2. Maybe those are indirect dependencies?

Oh :(  Well, I'm glad it's now working, but as you say, it will be
probably now be impossible to identify the source of the bug.  I had a
quick look at the previous version of the chromium packages, and
there's nothing obvious there, so that's almost certainly not the
cause.

I wonder whether it's a package you updated yesterday that fixed
things?  You could check the aptitude logs (assuming you used
aptitude).

Best wishes,

   Julian

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Cyril Brulebois]

Hi everyone,

Thanks for tracking down why the strange vt102 thing happens, and why it
mostly happens/was mostly reported on arm64 hardware… The patch below
(or further variations should there be any) looks mergeable to me.

Emanuele Rocca  (2023-06-01):
> On 2023-05-31 05:46, Samuel Thibault wrote:
> > I'd rather see a patch like
> > 
> > if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then
> > # Busybox's init uses a global TERM across all consoles.
> > # If the serial console is the default such as on arm64, that
> > # will force vt102 on the Linux VT. Fix this back so we get
> > # colors, utf-8, etc.
> > TERM=linux
> > fi
> > 
> > (to be tested etc.)
> 
> The following patch works. I've built a netboot image with patched
> rootskel, see attached screenshots for before and after the cure.
> 
> diff -Nur rootskel-1.135/src/lib/debian-installer.d/S40term-linux 
> /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux
> --- rootskel-1.135/src/lib/debian-installer.d/S40term-linux 2011-01-20 
> 01:05:16.0 +0100
> +++ 
> /home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux 
>   2023-06-01 15:05:32.514361854 +0200
> @@ -1,5 +1,13 @@
>  export LANG=C
> 
> +if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then
> +   # Busybox's init uses a global TERM across all consoles.
> +# If the serial console is the default such as on arm64, that
> +# will force vt102 on the Linux VT. Fix this back so we get

Indentation looks sketchy :)

> +   # colors, utf-8, etc.
> +   TERM=linux
> +fi
> +

Do we have other ttys than just tty1 that people might want to switch
to, and that might benefit from a similar adjustment? In any case, I'd
assume people can just use screen's windows to get more consoles, so it
might not matter…


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


signature.asc
Description: PGP signature

Bug#1037019: network-manager requires rfkill but that is not in the apt dependencies

[Michael Creutz]

Package: network-manager
Version: 1.14.6-2+deb10u1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   Installing wireless on an old system from the network installer failed
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 installing rfkill fixed the problem

* What was the outcome of this action?
 it works now 
 
   * What outcome did you expect instead?
 I expected apt to handle the issue

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


-- System Information:
Debian Release: 10.13
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-21-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.20-0+deb10u1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-3
ii  libbluetooth3  5.50-1.2~deb10u2
ii  libc6  2.28-10+deb10u1
ii  libcurl3-gnutls7.64.0-4+deb10u2
ii  libglib2.0-0   2.58.3-2+deb10u3
ii  libgnutls303.6.7-4+deb10u8
ii  libjansson42.12-1
ii  libmm-glib01.10.0-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.6-2+deb10u1
ii  libpam-systemd 241-7~deb10u8
ii  libpolkit-agent-1-00.105-25+deb10u1
ii  libpolkit-gobject-1-0  0.105-25+deb10u1
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0241-7~deb10u8
ii  libteamdctl0   1.28-1
ii  libudev1   241-7~deb10u8
ii  libuuid1   2.33.1-0.1
ii  lsb-base   10.2019051400
ii  policykit-10.105-25+deb10u1
ii  udev   241-7~deb10u8
ii  wpasupplicant  2:2.7+git20190128+0c1e29f-6+deb10u3

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1+deb10u1
ii  iptables 1.8.2-4
ii  isc-dhcp-client  4.4.1-2+deb10u1
ii  modemmanager 1.10.0-1
ii  ppp  2.4.7-2+4.1+deb10u1

Versions of packages network-manager suggests:
pn  libteam-utils  

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed [not included]

-- no debconf information

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Alper Nebi Yasak]

On 01/06/2023 16:27, Emanuele Rocca wrote:
> Hi again,
> 
> On 2023-05-31 05:46, Samuel Thibault wrote:
>> The problem is that both are frown-prone. I guess there is a reason why
>> on arm the default console is set to the serial port, e.g. for simpler
>> debugging or something like that.
> 
> Also worth mentioning: there is no bug on real hardware (eg: RPi 3B+).
> 
> So far I think we've only heard about people getting this issue with
> qemu.

I've had this problem on my chromebook (rk3399-gru-kevin) since forever.
I don't know what's best here, but wanted to provide more context in
case it helps. Thank you all for working on it.


There's actually two different things that can make Linux set a serial
port as the preferred console on arm64 systems:

- An SPCR table on devices using ACPI
- A /chosen stdout-path property on devices using device-tree

I had once tried to change it on the kernel side, going through that
email thread [1] might make the how-and-why clearer. (I've silently
given up on that series)

Furthermore, the same thing happens in the installed system as well,
which will ask for your encryption password over a serial console that
you have no access to [2] unless you have ended up installing plymouth
transitively through a desktop environment.

Adding console=tty0 would persist into the installed system and fix
that, so I'm used to doing that as a workaround on my own systems. But
that disables the serial console on device-tree systems, so doing it by
default is a problem for SBCs etc. where people might genuinely be
trying to install over serial. (I'd still like it for "Graphical
Install" entries [3], but that's orthogonal to this).


[1] Prefer working VT console over SPCR and device-tree stdout-path
https://lore.kernel.org/lkml/20200513143755.GM17734@linux-b0ei/

[2] initramfs-tools: prefers serial console over framebuffer console
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952452

[3] arm64 graphical installer fixes merge request
https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/17

Bug#1037018: rust-buffered-reader: RUSTSEC-2023-0039: Out-of-bounds array access leads to panic

[Salvatore Bonaccorso]

Source: rust-buffered-reader
Version: 1.1.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.0.1-1

Hi

RUSTSEC-2023-0039 affects rust-buffered-reader (no CVE assigned):

[1] https://rustsec.org/advisories/RUSTSEC-2023-0039.html
[2] 
https://lists.sequoia-pgp.org/hyperkitty/list/annou...@lists.sequoia-pgp.org/thread/SN2E3QRT4DMQ5JNEK6VIN6DJ5SH766DI/
[3] 
https://gitlab.com/sequoia-pgp/sequoia/-/commit/f6307652fb2cbf4e0fbd3f897b1ec70863fcfa61

Regards,
Salvatore

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[James Addison]

On Thu, 1 Jun 2023 at 15:48, Theodore Ts'o  wrote:
>
> In addition to Bookworm being hard frozen, I question the importance
> of this patch, the bug priority, and whether the title is correct.
> After all, at least with respect to e2fsprogs systemd unit *will*
> still be enabled.  It will just be enabled using
> ../multi-user.target/wanted instead of ../default.target/wanted.
>
> Ok, piuparts whines about it, and I agree that it's ideal if things
> are the stame regardless of whether the distro is freshly installed or
> uprgaded --- but e2scrub-repeat.service will *still* be enabled,
> right?  And so the bug title is misleaing, right?
>
> So it's not a big deal; is that correct so this patch is not worth
> trying to shoehorn in beform Bookworm ships, and this particular patch
> can be safely downgraded from importanted, right?

I think all of that is true, yep.

Also, arguing against my own revert-patch: I think it could be said
that multi-user is the "better" target to use here, because the
default could be "graphical" or some later-reached system state
whereas this is a relatively low-level (if small) system cleanup
service.

It's taken me too long to figure all this out, but retrospectively I
suppose my preference order here was:

1. Fix comprehensively in deb-systemd-helper.
2. Revert the original change (but I thought of / suggested that too late).
3. Apply a package-specific workaround (but I didn't find one that I
was comfortable with suggesting).

I'd agree with downgrading the severity to below RC (and it's your
package, so feel free, I think?  maybe even close it?).  If anyone
arrives here/reports other bugs as a result of experiencing it, I
think we can let them know that it's safe to remove the legacy
'default.target' symlink (does that sound correct too?).

Without getting too much into opinions on systemd itself: I think
declarative systems are good, but that managing stateful transitions
between multiple declared states can be challenging.  Not impossible,
and with sufficient bugreporting and fixing, it can be made solid - so
that's something to continue on after the release.

(and yep, I claimed I wouldn't look at this bug again for a while..
and I was tempted not to.. but I think clearing it from the RC queue
is probably worthwhile)

Bug#1037006: opensnitch: Upstream change enables ebpf compilation

[Pijgn]

[Petter Reinholdtsen]
> I believe this is a misunderstanding. Even if the default setting is
> ebpf, it will fall back to using proc when it fail to find the ebpf
> module.

My testing suggests this is not reliable with the default eBPF setting. 
Applying the 'Debug invalid connections' setting (in the absence of the 
module) only produces an error message about the file not existing.

Clicking the Save button allows the option state to persist between 
invocations of the settings dialog, but it does not survive a reboot and 
wireguard is silently denied regardless. I suppose that could be a bug 
against the GUI package; I did not test it headless.

It may be possible to use /etc/opensnitchd/system-fw.json as a 
workaround, but I did not try that since I was satisfied with the results 
of the procedure outlined at the beginning of this bug report.

> I believe upstream would be pleased with help with this even if it do
> not make it into bookworm.

I think I used the 'upstream' tag wrong. The eBPF build process has 
already received a Debian-specific fix upstream, which will be part of 
OpenSnitch 1.6.0 when it is released. In this case, any patches would 
only be meaningful for bookworm, to exclude unrelated changes.

I am interested in working on the patches to implement this fix, but if 
the change will not be compliant with bookworm update policy then the 
default monitor should be set to proc instead before it is too late.

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Karol Herbst]

On Thu, Jun 1, 2023 at 7:21 PM Limonciello, Mario
 wrote:
>
> [AMD Official Use Only - General]
>
> > -Original Message-
> > From: Karol Herbst 
> > Sent: Thursday, June 1, 2023 12:19 PM
> > To: Limonciello, Mario 
> > Cc: Nick Hastings ; Lyude Paul
> > ; Lukas Wunner ; Salvatore
> > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > Wysocki ; Len Brown ; linux-
> > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > regressi...@lists.linux.dev
> > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
> >
> > On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
> >  wrote:
> > >
> > > [AMD Official Use Only - General]
> > >
> > > > -Original Message-
> > > > From: Karol Herbst 
> > > > Sent: Thursday, June 1, 2023 11:33 AM
> > > > To: Limonciello, Mario 
> > > > Cc: Nick Hastings ; Lyude Paul
> > > > ; Lukas Wunner ; Salvatore
> > > > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > > > Wysocki ; Len Brown ; linux-
> > > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > > regressi...@lists.linux.dev
> > > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> > system)
> > > >
> > > > On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> > > >  wrote:
> > > > >
> > > > > +Lyude, Lukas, Karol
> > > > >
> > > > > On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > > > > > Hi,
> > > > > >
> > > > > > * Nick Hastings  [230530 16:01]:
> > > > > >> * Mario Limonciello  [230530 13:00]:
> > > > > > 
> > > > > >>> As you're actually loading nouveau, can you please try
> > > > nouveau.runpm=0 on
> > > > > >>> the kernel command line?
> > > > > >> I'm not intentionally loading it. This machine also has intel 
> > > > > >> graphics
> > > > > >> which is what I prefer. Checking my
> > > > > >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > > > > >> I see:
> > > > > >>
> > > > > >> blacklist nvidia
> > > > > >> blacklist nvidia-drm
> > > > > >> blacklist nvidia-modeset
> > > > > >> blacklist nvidia-uvm
> > > > > >> blacklist ipmi_msghandler
> > > > > >> blacklist ipmi_devintf
> > > > > >>
> > > > > >> So I thought I had blacklisted it but it seems I did not. Since I 
> > > > > >> do not
> > > > > >> want to use it maybe it is better to check if the lock up occurs 
> > > > > >> with
> > > > > >> nouveau blacklisted. I will try that now.
> > > > > > I blacklisted nouveau and booted into a 6.1 kernel:
> > > > > > % uname -a
> > > > > > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1
> > > > (2023-05-08) x86_64 GNU/Linux
> > > > > >
> > > > > > It has been running without problems for nearly two days now:
> > > > > > % uptime
> > > > > >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 
> > > > > > 1.27
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Nick.
> > > > >
> > > > > Thanks, that makes a lot more sense now.
> > > > >
> > > > > Nick, Can you please test if nouveau works with runtime PM in the
> > > > > latest 6.4-rc?
> > > > >
> > > > > If it works in 6.4-rc, there are probably nouveau commits that need
> > > > > to be backported to 6.1 LTS.
> > > > >
> > > > > If it's still broken in 6.4-rc, I believe you should file a bug:
> > > > >
> > > > > https://gitlab.freedesktop.org/drm/nouveau/
> > > > >
> > > > >
> > > > > Lyude, Lukas, Karol
> > > > >
> > > > > This thread is in relation to this commit:
> > > > >
> > > > > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> > > > >
> > > > > Nick has found that runtime PM is *not* working for nouveau.
> > > > >
> > > >
> > > > keep in mind we have a list of PCIe controllers where we apply a
> > > > workaround:
> > > >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> > > > /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> > > >
> > > > And I suspect there might be one or two more IDs we'll have to add
> > > > there. Do we have any logs?
> > >
> > > There's some archived onto the distro bug.  Search this page for
> > "journalctl.log.gz"
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530
> > >
> >
> > interesting.. It seems to be the same controller used here. I wonder
> > if the pci topology is different or if the workaround is applied at
> > all.
>
> I didn't see the message in the log about the workaround being applied
> in that log, so I guess PCI topology difference is a likely suspect.
>

yeah, but I also couldn't see a log with the usual nouveau messages,
so it's kinda weird.

Anyway, the output of `lspci -tvnn` would help

> >
> > But yeah, I'd kinda love for somebody with better knowledge on all of
> > this to figure out what exactly is going wrong, but everytime this
> > gets investigated Intel says "our hardware has no bugs", the ACPI
> > folks dig for months and find nothing and I end up figuring out some
> > weirdo workaround I don't understand. 

Bug#1037017: ITP: python-seedir -- Package for creating, editing, and reading folder tree diagrams.

[Andrey Rakhmatullin]

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

* Package name: python-seedir
  Version : 0.4.2
  Upstream Contact: Tom Earnest 
* URL : https://github.com/earnestt1234/seedir
* License : MIT
  Programming Lang: Python
  Description : Package for creating, editing, and reading folder tree
diagrams.

The general logic of seedir is based on representing directories in 3 different
forms: real directories on a computer, text diagrams of directories, and "fake
directories" (manipulable Python folder objects). seedir provides tools for
going in between these formats.

This is a test dependency for new python3-sybil.

It will be maintained in the DPT.

Bug#1036885: unblock: hipsparse/5.3.3+dfsg-2

[Christian Kastner]

control: tags -1 - moreinfo

Hi Paul,

On 2023-06-01 08:54, Paul Gevers wrote:
> Please upload hipsparse to tpu (targeting bookworm in the changelog)
> with no other changes than a changelog entry on top of what you have in
> unstable. Please use the version number 5.3.3+dfsg-2~deb12u1.

Thank you for considering this.

> Remove the moreinfo tag once the upload has happened. The upload window
> is tight. The *migration* needs to happen before Sunday.

Done. I hope I made it into the time window.

Best,
Christian

Bug#1024523: yad packaging

[Alexis]

Thank you so much

I had to find someone with permissions to upload to the repository.

If possible, please upload the Yad 7.2 sources available on 
https://deb.picalibre.org/src/yad/ or its mirror 
https://deb2.picalibre.org/src/yad/ (binaries on 
https://deb.picalibre.org/pool/main/y/yad/ and 
https://deb2.picalibre.org/pool/main/y/yad/ )


It has some extra patches of its own. We have been testing these 
binaries on different architectures, all good.


Best regards

El 2023-05-30 17:11, Bastian Germann escribió:


Hi Alexis,

To get the ball rolling I went ahead with importing the 7.2 release 
into experimental.

Please hand in an unstable upload when the bookworm release is done.

Thanks,
Bastian

Bug#964075: Bookworm: issue still exists/regression

[Tobias Wendorff]

# summary
Regarding bug #964075, I would like to inform that the issue still
exists with upcoming Debian Bookworm (or is a regression):

"Tor was compiled with zstd 1.5.2, but is running with zstd 1.5.4. For
safety, we'll avoid using advanced zstd functionality."

# packages affected (checked on 2023-06-01)
- tor v0.4.7.13-1
- libzstd1:amd64 v1.5.4+dfsg2-5

# additional information
It seems that the Tor package needs to be recompiled to address the issue.

I acknowledge that this is an unusual situation, and I would like to
raise the bug severity to "Important" to reflect the impact of this issue.

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Limonciello, Mario]

[AMD Official Use Only - General]

> -Original Message-
> From: Karol Herbst 
> Sent: Thursday, June 1, 2023 12:19 PM
> To: Limonciello, Mario 
> Cc: Nick Hastings ; Lyude Paul
> ; Lukas Wunner ; Salvatore
> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> Wysocki ; Len Brown ; linux-
> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> regressi...@lists.linux.dev
> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
>
> On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
>  wrote:
> >
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Karol Herbst 
> > > Sent: Thursday, June 1, 2023 11:33 AM
> > > To: Limonciello, Mario 
> > > Cc: Nick Hastings ; Lyude Paul
> > > ; Lukas Wunner ; Salvatore
> > > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > > Wysocki ; Len Brown ; linux-
> > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > regressi...@lists.linux.dev
> > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> system)
> > >
> > > On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> > >  wrote:
> > > >
> > > > +Lyude, Lukas, Karol
> > > >
> > > > On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > > > > Hi,
> > > > >
> > > > > * Nick Hastings  [230530 16:01]:
> > > > >> * Mario Limonciello  [230530 13:00]:
> > > > > 
> > > > >>> As you're actually loading nouveau, can you please try
> > > nouveau.runpm=0 on
> > > > >>> the kernel command line?
> > > > >> I'm not intentionally loading it. This machine also has intel 
> > > > >> graphics
> > > > >> which is what I prefer. Checking my
> > > > >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > > > >> I see:
> > > > >>
> > > > >> blacklist nvidia
> > > > >> blacklist nvidia-drm
> > > > >> blacklist nvidia-modeset
> > > > >> blacklist nvidia-uvm
> > > > >> blacklist ipmi_msghandler
> > > > >> blacklist ipmi_devintf
> > > > >>
> > > > >> So I thought I had blacklisted it but it seems I did not. Since I do 
> > > > >> not
> > > > >> want to use it maybe it is better to check if the lock up occurs with
> > > > >> nouveau blacklisted. I will try that now.
> > > > > I blacklisted nouveau and booted into a 6.1 kernel:
> > > > > % uname -a
> > > > > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1
> > > (2023-05-08) x86_64 GNU/Linux
> > > > >
> > > > > It has been running without problems for nearly two days now:
> > > > > % uptime
> > > > >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27
> > > > >
> > > > > Regards,
> > > > >
> > > > > Nick.
> > > >
> > > > Thanks, that makes a lot more sense now.
> > > >
> > > > Nick, Can you please test if nouveau works with runtime PM in the
> > > > latest 6.4-rc?
> > > >
> > > > If it works in 6.4-rc, there are probably nouveau commits that need
> > > > to be backported to 6.1 LTS.
> > > >
> > > > If it's still broken in 6.4-rc, I believe you should file a bug:
> > > >
> > > > https://gitlab.freedesktop.org/drm/nouveau/
> > > >
> > > >
> > > > Lyude, Lukas, Karol
> > > >
> > > > This thread is in relation to this commit:
> > > >
> > > > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> > > >
> > > > Nick has found that runtime PM is *not* working for nouveau.
> > > >
> > >
> > > keep in mind we have a list of PCIe controllers where we apply a
> > > workaround:
> > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> > > /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> > >
> > > And I suspect there might be one or two more IDs we'll have to add
> > > there. Do we have any logs?
> >
> > There's some archived onto the distro bug.  Search this page for
> "journalctl.log.gz"
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530
> >
>
> interesting.. It seems to be the same controller used here. I wonder
> if the pci topology is different or if the workaround is applied at
> all.

I didn't see the message in the log about the workaround being applied
in that log, so I guess PCI topology difference is a likely suspect.

>
> But yeah, I'd kinda love for somebody with better knowledge on all of
> this to figure out what exactly is going wrong, but everytime this
> gets investigated Intel says "our hardware has no bugs", the ACPI
> folks dig for months and find nothing and I end up figuring out some
> weirdo workaround I don't understand. And apparently also nobody is
> able to hand out docs explaining in detail how that runtime
> suspend/resume stuff is supposed to work.
>
> I have a Dell XPS 9560 where the added workaround in nouveau fixed the
> problem and I know it's fixed on a bunch of other systems. So if
> anybody is willing to publish docs and/or actually debug it with
> domain knowledge, please go ahead.
>
> > > And could anybody test if adding the
> > > controller in play here does resolve the 

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Karol Herbst]

On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
 wrote:
>
> [AMD Official Use Only - General]
>
> > -Original Message-
> > From: Karol Herbst 
> > Sent: Thursday, June 1, 2023 11:33 AM
> > To: Limonciello, Mario 
> > Cc: Nick Hastings ; Lyude Paul
> > ; Lukas Wunner ; Salvatore
> > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > Wysocki ; Len Brown ; linux-
> > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > regressi...@lists.linux.dev
> > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
> >
> > On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> >  wrote:
> > >
> > > +Lyude, Lukas, Karol
> > >
> > > On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > > > Hi,
> > > >
> > > > * Nick Hastings  [230530 16:01]:
> > > >> * Mario Limonciello  [230530 13:00]:
> > > > 
> > > >>> As you're actually loading nouveau, can you please try
> > nouveau.runpm=0 on
> > > >>> the kernel command line?
> > > >> I'm not intentionally loading it. This machine also has intel graphics
> > > >> which is what I prefer. Checking my
> > > >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > > >> I see:
> > > >>
> > > >> blacklist nvidia
> > > >> blacklist nvidia-drm
> > > >> blacklist nvidia-modeset
> > > >> blacklist nvidia-uvm
> > > >> blacklist ipmi_msghandler
> > > >> blacklist ipmi_devintf
> > > >>
> > > >> So I thought I had blacklisted it but it seems I did not. Since I do 
> > > >> not
> > > >> want to use it maybe it is better to check if the lock up occurs with
> > > >> nouveau blacklisted. I will try that now.
> > > > I blacklisted nouveau and booted into a 6.1 kernel:
> > > > % uname -a
> > > > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1
> > (2023-05-08) x86_64 GNU/Linux
> > > >
> > > > It has been running without problems for nearly two days now:
> > > > % uptime
> > > >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27
> > > >
> > > > Regards,
> > > >
> > > > Nick.
> > >
> > > Thanks, that makes a lot more sense now.
> > >
> > > Nick, Can you please test if nouveau works with runtime PM in the
> > > latest 6.4-rc?
> > >
> > > If it works in 6.4-rc, there are probably nouveau commits that need
> > > to be backported to 6.1 LTS.
> > >
> > > If it's still broken in 6.4-rc, I believe you should file a bug:
> > >
> > > https://gitlab.freedesktop.org/drm/nouveau/
> > >
> > >
> > > Lyude, Lukas, Karol
> > >
> > > This thread is in relation to this commit:
> > >
> > > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> > >
> > > Nick has found that runtime PM is *not* working for nouveau.
> > >
> >
> > keep in mind we have a list of PCIe controllers where we apply a
> > workaround:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> > /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> >
> > And I suspect there might be one or two more IDs we'll have to add
> > there. Do we have any logs?
>
> There's some archived onto the distro bug.  Search this page for 
> "journalctl.log.gz"
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530
>

interesting.. It seems to be the same controller used here. I wonder
if the pci topology is different or if the workaround is applied at
all.

But yeah, I'd kinda love for somebody with better knowledge on all of
this to figure out what exactly is going wrong, but everytime this
gets investigated Intel says "our hardware has no bugs", the ACPI
folks dig for months and find nothing and I end up figuring out some
weirdo workaround I don't understand. And apparently also nobody is
able to hand out docs explaining in detail how that runtime
suspend/resume stuff is supposed to work.

I have a Dell XPS 9560 where the added workaround in nouveau fixed the
problem and I know it's fixed on a bunch of other systems. So if
anybody is willing to publish docs and/or actually debug it with
domain knowledge, please go ahead.

> > And could anybody test if adding the
> > controller in play here does resolve the problem?
> >
> > > If you recall we did 24867516f06d because 5775b843a619 was
> > > supposed to have fixed it.
> > >
>

Bug#1036818: [pkg-lxc-devel] Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat

[Pierre-Elliott Bécue]

De : Mathias Gibbens 
À : Paul Gevers ; 1036...@bugs.debian.org
Cc : Pierre-Elliott Bécue ; Evgeni Golov ; 
Jochen Sprickerhof 
Date : 1 juin 2023 13:33:33
Objet : Re: [pkg-lxc-devel] Bug#1036818: linux on armel/armhf: Perl library 
unable to access get CPU info from /proc/cpu or kstat

> On Mon, 2023-05-29 at 20:03 +0200, Paul Gevers wrote:
>> We have three layers here. The bare metal is arm64. It hosts several
>> arm* QEMU VM. Inside the VM we run the lxc. I put the output of all
>> three at the bottom. *Maybe* it's relevant that the bare metal still
>> runs bullseye while the VM's run bookworm. I'll also share the
>> content for an arm64 host (which is a VM where I don't have access to
>> the bare metal.)
> 
> [snip]
> 
>> # generating the container and showing inside
>> debian@ci-worker-armhf-01:~$ sudo lxc-copy -N elbrus
>> autopkgtest-unstable-armhf && sudo lxc-start elbrus && sudo lxc-
>> attach elbrus
>> root@elbrus:/# cat /proc/cpuinfo
>> root@elbrus:/# ls -al /proc/cpuinfo
>> -r--r--r-- 1 root root 3878 May 29 17:48 /proc/cpuinfo
> 
>   Yeah, that's definitely not right! I don't currently have an
> armel/armhf system to test on, but did try using the abel.d.o
> porterbox. lxcfs requires elevated permissions to start, which I don't
> have on that box.
> 
>   Some other things we can look at -- are there any errors/warnings in
> the lxcfs service journal and/or the system's dmesg that is running
> lxcfs? It might also be useful to start lxcfs with debugging (`-d`) if
> there's nothing being logged about populating /proc/cpuinfo.
> 
>   I should have time this weekend when I can spin up a qemu vm to test
> in, if we're not able to get a root cause identified before then.
> 
> Mathias
I can probably grant you privileges on abel as soon as I get an ack from my 
fellow DSA mates.

-- 
Pierre-Elliott Bécue

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Limonciello, Mario]

[AMD Official Use Only - General]

> -Original Message-
> From: Karol Herbst 
> Sent: Thursday, June 1, 2023 11:33 AM
> To: Limonciello, Mario 
> Cc: Nick Hastings ; Lyude Paul
> ; Lukas Wunner ; Salvatore
> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> Wysocki ; Len Brown ; linux-
> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> regressi...@lists.linux.dev
> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
>
> On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
>  wrote:
> >
> > +Lyude, Lukas, Karol
> >
> > On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > > Hi,
> > >
> > > * Nick Hastings  [230530 16:01]:
> > >> * Mario Limonciello  [230530 13:00]:
> > > 
> > >>> As you're actually loading nouveau, can you please try
> nouveau.runpm=0 on
> > >>> the kernel command line?
> > >> I'm not intentionally loading it. This machine also has intel graphics
> > >> which is what I prefer. Checking my
> > >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > >> I see:
> > >>
> > >> blacklist nvidia
> > >> blacklist nvidia-drm
> > >> blacklist nvidia-modeset
> > >> blacklist nvidia-uvm
> > >> blacklist ipmi_msghandler
> > >> blacklist ipmi_devintf
> > >>
> > >> So I thought I had blacklisted it but it seems I did not. Since I do not
> > >> want to use it maybe it is better to check if the lock up occurs with
> > >> nouveau blacklisted. I will try that now.
> > > I blacklisted nouveau and booted into a 6.1 kernel:
> > > % uname -a
> > > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1
> (2023-05-08) x86_64 GNU/Linux
> > >
> > > It has been running without problems for nearly two days now:
> > > % uptime
> > >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27
> > >
> > > Regards,
> > >
> > > Nick.
> >
> > Thanks, that makes a lot more sense now.
> >
> > Nick, Can you please test if nouveau works with runtime PM in the
> > latest 6.4-rc?
> >
> > If it works in 6.4-rc, there are probably nouveau commits that need
> > to be backported to 6.1 LTS.
> >
> > If it's still broken in 6.4-rc, I believe you should file a bug:
> >
> > https://gitlab.freedesktop.org/drm/nouveau/
> >
> >
> > Lyude, Lukas, Karol
> >
> > This thread is in relation to this commit:
> >
> > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> >
> > Nick has found that runtime PM is *not* working for nouveau.
> >
>
> keep in mind we have a list of PCIe controllers where we apply a
> workaround:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
>
> And I suspect there might be one or two more IDs we'll have to add
> there. Do we have any logs?

There's some archived onto the distro bug.  Search this page for 
"journalctl.log.gz"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530

> And could anybody test if adding the
> controller in play here does resolve the problem?
>
> > If you recall we did 24867516f06d because 5775b843a619 was
> > supposed to have fixed it.
> >

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Lorenzo]

Hi Alexandru,

On Thu, 01 Jun 2023 12:05:51 +
Alexandru Mihail  wrote:

> Hi Nicholas,
> I've uploaded again to mentors, the (now gone) lintian warning
> complained about missing the SystemD service for the package. I've
> added one from scratch and upon initial testing it performs OK. I
> modified debian/rules to take the service into consideration though
> this raises some concerns for non-systemd Debian installations. I
> assume further modifications are required to intelligently enable or
> ignore the service (use old init.d mechanism).

(looking at your rules file)
override_dh_installinit:
dh_installinit --no-stop-on-upgrade --no-start --name=mini-httpd

override_dh_installsystemd:
dh_installsystemd --name=mini-httpd

if the '--no-stop-on-upgrade --no-start' is to avoid a conflict between
the systemd service and the init.d file, you don't need that: debhelper
generated scripts should do the right thing.
If you look at generated maintscripts you see that systemctl calls are
guarded by a test for /run/systemd/system (it imply that systemd is the
running init); the equivalent code for sysvinit (invoke.rc.d) is not
guarded but that's ok since other inits are supposed to mask
initscripts and systemd already does that.

Regards,
Lorenzo

> Kind regards,
> Alexandru Mihail
> 

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Karol Herbst]

On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
 wrote:
>
> +Lyude, Lukas, Karol
>
> On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > Hi,
> >
> > * Nick Hastings  [230530 16:01]:
> >> * Mario Limonciello  [230530 13:00]:
> > 
> >>> As you're actually loading nouveau, can you please try nouveau.runpm=0 on
> >>> the kernel command line?
> >> I'm not intentionally loading it. This machine also has intel graphics
> >> which is what I prefer. Checking my
> >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> >> I see:
> >>
> >> blacklist nvidia
> >> blacklist nvidia-drm
> >> blacklist nvidia-modeset
> >> blacklist nvidia-uvm
> >> blacklist ipmi_msghandler
> >> blacklist ipmi_devintf
> >>
> >> So I thought I had blacklisted it but it seems I did not. Since I do not
> >> want to use it maybe it is better to check if the lock up occurs with
> >> nouveau blacklisted. I will try that now.
> > I blacklisted nouveau and booted into a 6.1 kernel:
> > % uname -a
> > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) 
> > x86_64 GNU/Linux
> >
> > It has been running without problems for nearly two days now:
> > % uptime
> >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27
> >
> > Regards,
> >
> > Nick.
>
> Thanks, that makes a lot more sense now.
>
> Nick, Can you please test if nouveau works with runtime PM in the
> latest 6.4-rc?
>
> If it works in 6.4-rc, there are probably nouveau commits that need
> to be backported to 6.1 LTS.
>
> If it's still broken in 6.4-rc, I believe you should file a bug:
>
> https://gitlab.freedesktop.org/drm/nouveau/
>
>
> Lyude, Lukas, Karol
>
> This thread is in relation to this commit:
>
> 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
>
> Nick has found that runtime PM is *not* working for nouveau.
>

keep in mind we have a list of PCIe controllers where we apply a
workaround: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682

And I suspect there might be one or two more IDs we'll have to add
there. Do we have any logs? And could anybody test if adding the
controller in play here does resolve the problem?

> If you recall we did 24867516f06d because 5775b843a619 was
> supposed to have fixed it.
>

Bug#1037006: opensnitch: Upstream change enables ebpf compilation

[Petter Reinholdtsen]

[Pijgn]
> With the default setting to use eBPF monitoring, the option to 'Debug
> invalid connections' has no effect unless
> /etc/opensnitchd/opensnitch.o exists.

I believe this is a misunderstanding. Even if the default setting is
ebpf, it will fall back to using proc when it fail to find the ebpf
module.

> If these changes are small enough to eventually include in bookworm
> then it would definitely be worth patching.

I believe upstream would be pleased with help with this even if it do
not make it into bookworm.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1037006: opensnitch: Upstream change enables ebpf compilation

[Pijgn]

[Petter Reinholdtsen]
> I use opensnitch with NFS on Debian Bookworm, and have not noticed it
> is making NFS unusable.  How did you end up with this conclusion?

I may be in error here. Having personally confirmed that wireguard was 
broken by the default opensnitch configuration in Debian, I only assumed 
that NFS would be equally affected by the missing eBPF module. [0]

> I had problems with UDP traffic and Minecraft earlier, as seen in
> https://github.com/evilsocket/opensnitch/issues/813 >, but
> managed to get it working by enabling 'Debug invalid connections' in
> the Nodes tab of the preferences.

With the default setting to use eBPF monitoring, the option to 'Debug 
invalid connections' has no effect unless /etc/opensnitchd/opensnitch.o 
exists. Since the eBPF method requires this module to achieve parity 
with proc monitoring, an alternative to patching the build process would 
be an emergency change of that default before the Debian 12 release.

> When that is said, I would very much like to see ebpf support in
> Debian. I know upstream is working on figuring this out and that
> patches would be most welcome.  Perhaps you can provide some?

My initial bug report lists what I believe to be the minimum changes 
that need to be ported from upstream to enable drop-in eBPF support for 
our current version. If these changes are small enough to eventually 
include in bookworm then it would definitely be worth patching.

Otherwise, the proc method should be made the default for this release 
and eBPF considered unsupported in Debian until opensnitch 1.6.0+.

[0] https://github.com/evilsocket/opensnitch/pull/513

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Limonciello, Mario]

+Lyude, Lukas, Karol

On 5/31/2023 6:40 PM, Nick Hastings wrote:

Hi,

* Nick Hastings  [230530 16:01]:

* Mario Limonciello  [230530 13:00]:



As you're actually loading nouveau, can you please try nouveau.runpm=0 on
the kernel command line?

I'm not intentionally loading it. This machine also has intel graphics
which is what I prefer. Checking my
/etc/modprobe.d/blacklist-nvidia-nouveau.conf
I see:

blacklist nvidia
blacklist nvidia-drm
blacklist nvidia-modeset
blacklist nvidia-uvm
blacklist ipmi_msghandler
blacklist ipmi_devintf

So I thought I had blacklisted it but it seems I did not. Since I do not
want to use it maybe it is better to check if the lock up occurs with
nouveau blacklisted. I will try that now.

I blacklisted nouveau and booted into a 6.1 kernel:
% uname -a
Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) 
x86_64 GNU/Linux

It has been running without problems for nearly two days now:
% uptime
  08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27

Regards,

Nick.


Thanks, that makes a lot more sense now.

Nick, Can you please test if nouveau works with runtime PM in the
latest 6.4-rc?

If it works in 6.4-rc, there are probably nouveau commits that need
to be backported to 6.1 LTS.

If it's still broken in 6.4-rc, I believe you should file a bug:

https://gitlab.freedesktop.org/drm/nouveau/


Lyude, Lukas, Karol

This thread is in relation to this commit:

24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")

Nick has found that runtime PM is *not* working for nouveau.

If you recall we did 24867516f06d because 5775b843a619 was
supposed to have fixed it.

Bug#1037016: mk-build-deps fails if the package version is 0

[Robie Basak]

Package: devscripts
Version: 2.23.4
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

If the version of a package is 0, then mk-build-deps creates
$src-build-deps_1.0_all.deb instead of $src-build-deps_0_all.deb. If -i
is used, then it additionally attempts to install
$src-build-deps_0_all.deb, and this fails because of the previous
unexpected output.

AIUI, 0 is a perfectly valid package version according to Debian Policy,
and so should work.

This came up because I used 0 in a template. Of course it wouldn't last
long in a real package!

Minimal steps to reproduce:

# mkdir debian
# cat > debian/changelog
test (0) UNRELEASED; urgency=medium

  * Test mk-build-deps

 -- Robie Basak   Thu, 01 Jun 2023 16:03:13
+
# cat > debian/control
Source: test
Build-Depends: hello
# mk-build-deps -i -r
dpkg-buildpackage: info: source package test-build-deps
dpkg-buildpackage: info: source version 1.0
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Equivs Dummy Package Generator 

dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
 debian/rules clean
dh clean
   dh_clean
 debian/rules binary
dh binary
   dh_update_autotools_config 
   dh_autoreconf
   create-stamp debian/debhelper-build-stamp
   dh_prep
   dh_auto_install --destdir=debian/test-build-deps/
   dh_install
   dh_installdocs   
   dh_installchangelogs
   dh_perl
   dh_link
   dh_strip_nondeterminism
   dh_compress
   dh_fixperms
   dh_missing
   dh_installdeb
   dh_gencontrol
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'test-build-deps' in 
'../test-build-deps_1.0_all.deb'.
 dpkg-genbuildinfo --build=binary -O../test-build-deps_1.0_amd64.buildinfo
 dpkg-genchanges --build=binary -O../test-build-deps_1.0_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build .
dpkg-buildpackage: info: binary-only upload (no source included)

The package has been created.
Attention, the package has been created in the current directory,
not in ".." as indicated by the message above!
dpkg: error: cannot access archive 'test-build-deps_0_all.deb': No such file or 
directory
mk-build-deps: dpkg --unpack failed

Bug#1037004: msmtp-mta doesn't respect DEBIAN_FRONTEND=noninteractive

[Tao Effect]

Wow, that worked! Sorry for not understanding that that had to be prepended to 
both commands.

Lesson learned! Thank you and please feel free to close this bug report now (I 
have no idea how to do that).

- Greg

> On May 31, 2023, at 10:31 PM, Emmanuel Bouthenot  wrote:
> 
> Hello (again),
> 
> On Wed, May 31, 2023 at 03:26:23PM -0700, Greg wrote:
> [...]
> 
>> RUN DEBIAN_FRONTEND=noninteractive apt-get -y update && \
>>  apt-get install -yq --no-install-recommends msmtp-mta s-nail htop dialog 
>> less paxctl sudo
> 
> I didn't noticed it in the first place but you also have to set the
> noninteractive frontend when installing/updating the package not only
> when updating the packages index.
> 
> Try:
> RUN DEBIAN_FRONTEND=noninteractive apt-get -y update && 
> DEBIAN_FRONTEND=noninteractive apt-get install -yq --no-install-recommends 
> msmtp-mta s-nail htop dialog less paxctl sudo
> 
> If it works as expected it's far better than preseeding (suggested in my
> previous reply).
> 
> Have a nice day.
> 
> Regards,
> 
> -- 
> Emmanuel Bouthenot
>  kolter@{openics,debian}.org   kolter@{libera,oftc}
>  0x929D42C3/4096R

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Brian Vaughan]

I have good news and bad news.

The good news is that the issue seems to have been fixed as of today. I 
don't get the error popup, and Help > Dependencies shows pylsp_black 
installed and at version 1.21.


The bad news is I'm not sure what fixed it. I realized I made the 
mistake of following my daily routine of updating my system, which is 
not a good idea when troubleshooting. I checked the changelog dates on 
the dependencies for python3-spyder, and the most recently updated were 
python3-pygments on April 19, and python3-cookiecutter and 
python3-sphinx on March 29.


The only updates today were chromium, chromium-common, and 
chromium-sandbox, updated to 114.0.5735.90-2. Maybe those are indirect 
dependencies?

Bug#1036992: r8168-dkms: Adding more information

[Mohammed Anas]

i used the below command to purge:
*sudo apt purge r8168-dkms*


*find /lib/modules /usr/src /var/lib/dkms -name '*r8168*'*
output:
/lib/modules/5.10.0-23-amd64/kernel/drivers/net/ethernet/realtek/r8168.ko.bak


Please note that I have reinstalled my linux kernel in an attempt to make
the ethernet interface work again , which has installed the kernel built-in
driver and solved my problem .

Below are the files under
/lib/modules/5.10.0-23-amd64/kernel/drivers/net/ethernet/realtek before i
reinstalled my kernel and after purging the r8168-dkms driver:
8139cp.ko
8139too.ko
r8168.ko
r8169.bak

Then i had changed r8168.ko to r8168.ko.bak and r8169.bak to r8169.ko , and
reboot, in an attempt to reload the driver r8169, but didn't work. And
FInally did a kernel reinstall, which actually solved my issue.


On Thu, Jun 1, 2023 at 12:45 PM Andreas Beckmann  wrote:

> [please keep the bug in Cc:]
>
> On 01/06/2023 04.06, Mohammed Anas wrote:
> > Sorry to not mention it, But after purging the new driver , i did reboot
> > the system. But the old driver was still not loaded.
>
> Weird. How did you purge the new driver?
>
> Please send the output of the following command:
>
> find /lib/modules /usr/src /var/lib/dkms -name '*r8168*'
>
>
> Andreas
>
>
[image: Mailtrack]

Sender
notified by
Mailtrack

01/06/23,
21:27:26

Bug#1036256: golang-github-pin-tftp: FTBFS in testing

[Paul Gevers]

Hi all,

On Wed, 31 May 2023 08:31:25 -0300 Thiago Andrade  
wrote:
I've tested golang-github-pin-tftp locally and everything looks perfect. 


I looked at the results on the reproducible build infrastructure and the 
package seems to regularly fail. This may hint that the tests are flaky. 
Also autopkgtest is not without failure [2].


Paul

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-pin-tftp.html

[2] https://ci.debian.net/packages/g/golang-github-pin-tftp/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036946: webkit2gtk: Tries to build Bubblewrap support even if its disabled

[Alberto Garcia]

On Wed, May 31, 2023 at 10:57:32AM -0400, Jeremy Bícha wrote:
> Untested, but I think this would work:
> https://salsa.debian.org/webkit-team/webkit/-/merge_requests/17

I already had some of this changes already applied locally, I just
pushed them. Thanks!

Berto

Bug#1033479: closed by Thomas Goirand (Re: Bug#1033479: minissdpd: Service fails to start on boot with "Error parsing address/mask...")

[Facundo Gaich]

On Thu, Jun 1, 2023 at 11:54 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Hi,
>
> This is IMO a missconfiguration, not a bug. Closing accordingly.
>
> Cheers,
>
> Thomas Goirand (zigo)
>

 Hi Thomas,

Thanks, although, isn't it still a bug if it arrived at a misconfigured
state without user interaction?

Bug#999918: [Pkg-zsh-devel] Bug#999918: zsh: depends on obsolete pcre3 library

[Jeremy Bícha]

Control: tags -1 +patch

It looks like this was fixed upstream with
https://github.com/zsh-users/zsh/commit/b62e91134

Thank you,
Jeremy Bícha

Bug#1037015: MOZ_APP_REMOTINGNAME should contain lowercase firefox-esr to have correct window icons with MOZ_ENABLE_WAYLAND=1 on KDE Wayland

[Jan Andre Ikenmeyer]

Package: firefox-esr
Version: 102.11.0esr-1

Debian's MOZ_APP_REMOTINGNAME is Firefox-esr, it should be lowercase 
firefox-esr as it is in builds from 
https://download.mozilla.org/?product=firefox-esr-latest-ssl=linux64.


MOZ_APP_REMOTINGNAME must match
- MOZ_APP_REMOTINGNAME.desktop to avoid 
https://bugzilla.mozilla.org/show_bug.cgi?id=1826330 on KDE Wayland

- StartupWMClass=MOZ_APP_REMOTINGNAME

$ cat /usr/share/applications/firefox-esr.desktop | grep StartupWMClass
> StartupWMClass=Firefox-esr

Wayland:
$ WAYLAND_DEBUG=1 MOZ_ENABLE_WAYLAND=1 firefox-esr |& grep 
'xdg_toplevel@[0-9]\+\.set_app_id'

> [ 947103.838]  -> xdg_toplevel@43.set_app_id("Firefox-esr")

About/Downloads/bookmarks windows have a wrong window icon (the Wayland 
W icon).

With browser.tabs.inTitlebar=0, the main window has a wrong icon as well.

X11 / Xwayland:
When the cursor becomes a "+", click on Firefox' window:
$ firefox-esr & xprop WM_CLASS
> WM_CLASS(STRING) = "Navigator", "Firefox-esr"

Proposed fix:
https://salsa.debian.org/mozilla-team/firefox/-/blob/b2698cd93ded2aa17bb6a2756ee85f015b63dbe8/debian/rules#L76
> export MOZ_APP_REMOTINGNAME := $(call uc_first,$($(PRODUCT)))

I assume MOZ_APP_REMOTINGNAME needs to become PRODUCT, without uc_first.

MOZ_APP_REMOTINGNAME is used by Firefox
to call `g_set_prgname(gAppData->remotingName);` for correct window icon 
and grouping on Wayland (it can be overridden with --name argument)
to call `gdk_set_program_class(gAppData->remotingName);` for correct 
window grouping on X11 (it can be overriden with --class argument)


And
https://salsa.debian.org/mozilla-team/firefox/-/blob/b2698cd93ded2aa17bb6a2756ee85f015b63dbe8/debian/browser.desktop.in#L103
> StartupWMClass=@MOZ_APP_REMOTINGNAME@

can become
StartupWMClass=@browser@


Offtopic, but further fixes for the .desktop file:
You can use the longer MimeType string from Mozilla's Nightly debian 
package (https://bugzilla.mozilla.org/show_bug.cgi?id=1836205#c3) to fix 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031041.
"MimeType" doesn't change default apps and its order doesn't matter 
(https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#mime-types).
You could also adopt "Actions" (plus "Desktop Action"s) and translations 
from it.

Bug#1037014: AttributeError: module 'gettext' has no attribute 'bind_textdomain_codeset'

[Matt Culler]

Package: deluge-console
Version: 2.0.3-4
Severity: important
X-Debbugs-Cc: mrcul...@gmail.com

Hello,

Running any command in deluge-console on bookworm results in a python
exception being thrown:


Unable to initialize gettext/locale!
module 'gettext' has no attribute 'bind_textdomain_codeset'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/deluge/i18n/util.py", line 111, in 
setup_translation
gettext.bind_textdomain_codeset(I18N_DOMAIN, 'UTF-8')
^^^
AttributeError: module 'gettext' has no attribute 'bind_textdomain_codeset'
15:58:20 [ERROR   ][deluge.i18n.util  :146 
] Unable to initialize gettext/locale!
15:58:20 [ERROR   ][deluge.i18n.util  :147 
] module 'gettext' has no attribute 'bind_textdomain_codeset'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/deluge/i18n/util.py", line 111, in 
setup_translation
gettext.bind_textdomain_codeset(I18N_DOMAIN, 'UTF-8')
^^^
AttributeError: module 'gettext' has no attribute 'bind_textdomain_codeset'


I believe the solution is for package maintainers to bump the deluge version 
from 2.0.3 to 2.0.4.  If you check line 111 of deluge/i18n/util.py and compare 
between those two versions, this line changes, because the 
gettext.bind_textdomain_codeset function was removed starting with python 3.10, 
and bookworm uses 3.11.

Also I'd imagine there are probably other issues that may be run into by 
depending on a version of deluge that's out of sync with the system's python 
version.

(https://docs.python.org/3.8/library/gettext.html#gettext.bind_textdomain_codeset)


Dear Maintainer,

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

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

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


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 6.1.0-9-686-pae (SMP w/2 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 deluge-console depends on:
ii  deluge-common   2.0.3-4
ii  python3 3.11.2-1+b1
ii  python3-libtorrent  2.0.8-1+b1

deluge-console recommends no packages.

deluge-console suggests no packages.

-- no debconf information

Bug#1037013: libexiv2-27 0.27.3-3+deb11u2 makes gthumb crash

[Martin Tharby Jones]

Package: libexiv2-27
Version: 0.27.3-3+deb11u2
Severity: important
X-Debbugs-Cc: mar...@brasskipper.org.uk, t...@security.debian.org

Dear Maintainer,

The latest update causes gthumb crash it worked with Version: 0.27.3-3+deb11u1

martin@ant:~$ gthumb

(gthumb:8908): Gtk-WARNING **: 15:10:24.901: Failed to register client:
GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register
client
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::at: __n (which is 19) >= this->size() (which is 19)
Aborted
martin@ant:~$

This looks like a known bug see
https://bugs.launchpad.net/ubuntu/+source/exiv2/+bug/1942799

martin@ant:~$ gdb -q gthumb
Reading symbols from gthumb...
(gdb) start
Temporary breakpoint 1 at 0xf85b9: file ../gthumb/main.c, line 47.
Starting program: /usr/local/bin/gthumb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe138) at
../gthumb/main.c:47
47  program_argv0 = argv[0];
(gdb) c
Continuing.
[New Thread 0x755cb700 (LWP 9597)]
[New Thread 0x7fffee4e6700 (LWP 9598)]
[New Thread 0x7fffe1926700 (LWP 9599)]
[New Thread 0x7fffdbfff700 (LWP 9600)]
[New Thread 0x7fffe1125700 (LWP 9601)]
[New Thread 0x7fffe0924700 (LWP 9602)]

(gthumb:9593): Gtk-WARNING **: 15:28:39.706: Failed to register client:
GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register
client
[New Thread 0x7fffdb7fe700 (LWP 9604)]
[New Thread 0x7fffd9940700 (LWP 9605)]
[New Thread 0x7fffd913f700 (LWP 9606)]
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::at: __n (which is 19) >= this->size() (which is 19)

Thread 9 "pool-gthumb" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd9940700 (LWP 9605)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x76c30537 in __GI_abort () at abort.c:79
#2  0x744fe7ec in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x74509966 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x745099d1 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x74509c65 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x74501113 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x7fffdac3db16 in  () at /lib/x86_64-linux-gnu/libexiv2.so.27
#8  0x7fffdabcbcdd in Exiv2::Xmpdatum::write(std::ostream&, Exiv2::ExifData
const*) const ()
at /lib/x86_64-linux-gnu/libexiv2.so.27
#9  0x7fffdab961c1 in Exiv2::Metadatum::print[abi:cxx11](Exiv2::ExifData
const*) const ()
at /lib/x86_64-linux-gnu/libexiv2.so.27
#10 0x7fffdadf02c2 in exiv2_read_metadata(Exiv2::Image::AutoPtr,
GFileInfo*, gboolean)
(image=..., info=0x56134b30, update_general_attributes=1)
at ../extensions/exiv2_tools/exiv2-utils.cpp:830
#11 0x7fffdadf08ad in exiv2_read_metadata_from_file(GFile*, GFileInfo*,
gboolean, GCancellable*, GError**)
(file=0x55908d40, info=0x56134b30, update_general_attributes=1,
cancellable=0x56111520, error=0x0) at
../extensions/exiv2_tools/exiv2-utils.cpp:888
#12 0x7fffdadf69c2 in gth_metadata_provider_exiv2_read
(base=0x7fffc808f650, file_data=0x561966f0, attributes=0x562053d0
"standard::type,standard::is-hidden,standard::is-
backup,standard::name,standard::display-name,standard::edit-
name,standard::icon,standard::symbolic-
icon,standard::size,thumbnail::pathtime::created,time"...,
cancellable=0x56111520)
at ../extensions/exiv2_tools/gth-metadata-provider-exiv2.c:124
#13 0x55620807 in gth_metadata_provider_read
(self=0x7fffc808f650, file_data=0x561966f0, attributes=0x562053d0
"standard::type,standard::is-hidden,standard::is-
backup,standard::name,standard::display-name,standard::edit-
name,standard::icon,standard::symbolic-
icon,standard::size,thumbnail::pathtime::created,time"...,
cancellable=0x56111520)
at ../gthumb/gth-metadata-provider.c:117
#14 0x55620a16 in _g_query_metadata_async_thread
(task=0x561a6330, source_object=0x0, task_data=0x5610bbf0,
cancellable=0x56111520)
at ../gthumb/gth-metadata-provider.c:215
#15 0x77c0204e in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#16 0x77daf9a4 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x77daf0bd in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x76debea7 in start_thread (arg=) at
pthread_create.c:477
#19 0x76d09a2f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) c
Continuing.
[Thread 0x7fffd913f700 (LWP 9606) exited]
[Thread 0x7fffd9940700 (LWP 9605) exited]
[Thread 0x7fffdb7fe700 (LWP 9604) exited]
[Thread 0x7fffe1125700 (LWP 9601) exited]
[Thread 0x7fffdbfff700 (LWP 9600) exited]
[Thread 

Bug#1032994: unblock: node-webpack/5.76.1+dfsg1+~cs17.16.16-1

[Yadd]

On 6/1/23 13:44, Paul Gevers wrote:

control: tags -1 moreinfo

Hi Yadd,

On 29-05-2023 05:58, Yadd wrote:

On 5/28/23 10:29, Graham Inggs wrote:

On Wed, 3 May 2023 at 04:51, Yadd  wrote:

How about reverting and providing a fix only for that CVE please?


instead of reverting and have a too long version 
(5.76.1+dfsg1+~cs17.16.16+really-5.75.0+dfsg+~cs17.16.14-1), if upload 
to bookworm is allowed, I'm able to push this debdiff.


Please upload this debdiff to unstable ASAP. I'm not aware of 
limitations for the version number that you would trigger with that. tpu 
is not meant for this purpose (it doesn't have any QA). Mind you, the 
closing window for uploads was last weekend, so we're extremely late. 
Otherwise we'll have to do this via the security archive or a point 
release update.


Paul


Hi,

I can't upload this debdiff to unstable because version in unstable is 
5.76.1+dfsg1+~cs17.16.16-1. If we can't upload to bookworm without using 
unstable, let's wait for Debian/12.1.

Else, version would be:
 - 5.76.1+dfsg1+~cs17.16.16+really-5.75.0+dfsg+~cs17.16.14-1
and then later fixes will look like
 - 5.76.1+dfsg1+~cs17.16.16+really-5.75.0+dfsg+~cs17.16.14-1+deb12u1

I don't want to be the author of such version.

Bug#1033479: minissdpd: Service fails to start on boot with "Error parsing address/mask..."

[Thomas Goirand]

On 6/1/23 10:07, Jonathan Dowland wrote:

But I suggest to the maintainer (Hi Thomas!): If you're confident that
you can guess the right interface at install time, why not do that at
service start up time instead? That way it will adjust to changing
environments.


I don't think it'd be such a great idea. I prefer let the user do what 
they feel is correct.


FYI, it's also possible for interfaces being renamed from one udev 
version to the next. IMO, that's a case for filling a bug against udev, 
not minissdpd.


Cheers,

Thomas Goirand (zigo)

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[Theodore Ts'o]

In addition to Bookworm being hard frozen, I question the importance
of this patch, the bug priority, and whether the title is correct.
After all, at least with respect to e2fsprogs systemd unit *will*
still be enabled.  It will just be enabled using
../multi-user.target/wanted instead of ../default.target/wanted.

Ok, piuparts whines about it, and I agree that it's ideal if things
are the stame regardless of whether the distro is freshly installed or
uprgaded --- but e2scrub-repeat.service will *still* be enabled,
right?  And so the bug title is misleaing, right?

So it's not a big deal; is that correct so this patch is not worth
trying to shoehorn in beform Bookworm ships, and this particular patch
can be safely downgraded from importanted, right?

Or else, what am I missing?

Thanks,

- Ted

P.S.  And repeat after me, "systemd is *so* much more simpler than
init.d scripts because it's declarative"

Bug#1035852: Updated patch series for version jhove version 1.28.0

[Elias Oltmanns]

Hi there,

meanwhile, version 1.28.0 has been released upstream. Please find the
updated patch series below.

Also, I have realised that I am probably not asking for a NMU because I
am not a Debian developer myself. Can anyone review the patches and help
to get a new version uploaded?

Thank you in advance,

Elias
>From ea1161185c01a2510ba6c7d07b0d98009b78d5b4 Mon Sep 17 00:00:00 2001
From: Elias Oltmanns 
Date: Wed, 19 Apr 2023 10:00:55 +0200
Subject: [PATCH 01/18] Tighten version pattern in watch file and fix orig
 package name

Make sure that the minor version number is even since this is what
upstream considers a production release.
---
 debian/watch | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/debian/watch b/debian/watch
index d69f157..d9757eb 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,4 @@
-version=3
-https://github.com/openpreserve/jhove/tags .*/(?:.*?)([\d\.]+)\.tar\.gz
+version=4
+opts="filenamemangle=s%.*/v(@ANY_VERSION@@ARCHIVE_EXT@)$%@PACKAGE@-$1%" \
+https://github.com/openpreserve/jhove/tags \
+.*/v(\d+\.\d*[02468](?:\.\d+)*)@ARCHIVE_EXT@
-- 
2.25.1

>From 90760ff3afac0c1ea82f51c0d79bb42ac8fe5439 Mon Sep 17 00:00:00 2001
From: Elias Oltmanns 
Date: Thu, 20 Apr 2023 19:01:30 +0200
Subject: [PATCH 02/18] Remove ICC profiles and jar files from source for DFSG
 compliance

Remove DFSG violating files from the source tarball and move this
application back to the main archive area of the distribution.

Note that the deleted ICC profiles are shipped with Debian in the
icc-profiles package (non-free). They are used by the test suite only,
hence neither required at build nor at run time. The removed JAR files
provide dependencies for code in the jhove-ext-modules directory that
are sadly missing from the Debian archive. Since previous versions of
this Debian package did not build the jhove-ext-modules either,
removing those JAR files should not introduce any regression in
Debian.

Bug-Debian: https://bugs.debian.org/1008969
---
 debian/README.source | 9 +
 debian/control   | 2 +-
 debian/copyright | 4 
 debian/watch | 2 +-
 4 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/debian/README.source b/debian/README.source
index a2eef8e..c12bdd6 100644
--- a/debian/README.source
+++ b/debian/README.source
@@ -7,3 +7,12 @@ from the maven-debian-helper package.
 The build system uses Maven but prevents it from downloading
 anything from the Internet, making the build compliant with
 the Debian policy.
+
+Due to DFSG issues, upstream source has been repackaged without
+various JAR files as well as two ICC profiles. This does not impose
+any restrictions on building and using the application including its
+internal modules. The test suite and code from the jhove-ext-modules
+directory cannot be built, however, because some dependencies have not
+been packaged for Debian yet. Note that the deleted ICC profiles (used
+as resources in the test suite) are shipped with Debian in the
+non-free icc-profiles package.
diff --git a/debian/control b/debian/control
index 29a1bb3..9b4f96e 100644
--- a/debian/control
+++ b/debian/control
@@ -1,5 +1,5 @@
 Source: jhove
-Section: non-free/utils
+Section: utils
 Priority: optional
 Maintainer: Debian Java Maintainers 
 Uploaders: Jeff Breidenbach 
diff --git a/debian/copyright b/debian/copyright
index eef25a8..5196e63 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,6 +2,10 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: JHOVE - JSTOR/Harvard Object Validation Environment
 Upstream-Contact: http://jenkins.opf-labs.org
 Source: https://github.com/openpreserve/jhove/
+Files-Excluded:
+ */*.jar
+ lib
+ jhove-core/src/test/resources/edu/harvard/hul/ois/jhove/*.icc
 
 Files: *
 Copyright: 2008-2018, The Open Preservation Foundation
diff --git a/debian/watch b/debian/watch
index d9757eb..b579ba8 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
 version=4
-opts="filenamemangle=s%.*/v(@ANY_VERSION@@ARCHIVE_EXT@)$%@PACKAGE@-$1%" \
+opts="filenamemangle=s%.*/v(@ANY_VERSION@@ARCHIVE_EXT@)$%@PACKAGE@-$1%,dversionmangle=auto,repacksuffix=+dfsg1" \
 https://github.com/openpreserve/jhove/tags \
 .*/v(\d+\.\d*[02468](?:\.\d+)*)@ARCHIVE_EXT@
-- 
2.25.1

>From 77c40ead666f659852f634424a73c8e5471f2ad9 Mon Sep 17 00:00:00 2001
From: Elias Oltmanns 
Date: Fri, 21 Apr 2023 16:46:25 +0200
Subject: [PATCH 03/18] Fetch source via mode=git and verify signed tag

---
 debian/upstream/signing-key.asc | 41 +
 debian/watch|  6 ++---
 2 files changed, 44 insertions(+), 3 deletions(-)
 create mode 100644 debian/upstream/signing-key.asc

diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
new file mode 100644
index 000..82024b0
--- /dev/null
+++ b/debian/upstream/signing-key.asc
@@ -0,0 +1,41 @@
+-BEGIN PGP PUBLIC KEY BLOCK-
+

Bug#1037012: gconf: Intent to remove from Debian

[Jeremy Bícha]

Source: gconf
Version: 3.2.6-8
Severity: serious
Tags: unstable trixie

I intend to file a bug requesting that ftpmasters remove gconf from
Debian Unstable soon after the Debian 12 release.

gconf is only included in Debian 12 to provide the migration utility
away from gconf for alarm-clock-applet and mssh. Since that migration
will be complete in Debian 12, there is no need for future Debian
releases to include gconf.

On behalf of the Debian GNOME team,
Jeremy Bícha

Bug#1035979: redmine-plugin-pretend: fails to install: rake aborted! LoadError: cannot load such file -- redmine_pretend

[Andreas Beckmann]

On 01/06/2023 14.16, Paul Gevers wrote:
On Fri, 12 May 2023 09:16:32 +0200 Andreas Beckmann  
wrote:

Package: redmine-plugin-pretend



during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.


If I look at the log, it's redmine itself that fails during 
installation. @anbe: why did you decide to file against the plugin? I'm 
guessing here, but if redmine is installed and configured before 
installing the plugin, everything's fine?


redmine alone works fine, but there are two plugins that make redmine "blow up" 
if they are installed.

If redmine is installed first (without errors), the plugin installation still 
blows redmine up:

0m56.6s DEBUG: Starting command: ['nsenter', 
'--net=/run/netns/piuparts-netns-13', 
'--uts=/srv/piuparts/tmp/tmp53VbkN/ns-uts', 'chroot', 
'/srv/piuparts/tmp/tmp53VbkN/chroot', 'apt-get', '-y', 'install', 
'redmine-plugin-pretend=0.0.2+git20130821-5']
1m2.6s DUMP:
  Reading package lists...
  Building dependency tree...
  Reading state information...
  The following NEW packages will be installed:
redmine-plugin-pretend
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 6132 B of archives.
  After this operation, 38.9 kB of additional disk space will be used.
  Get:1 http://ftp.de.debian.org/debian bookworm/main amd64 
redmine-plugin-pretend all 0.0.2+git20130821-5 [6132 B]
  debconf: delaying package configuration, since apt-utils is not installed
  Fetched 6132 B in 0s (207 kB/s)
  Selecting previously unselected package redmine-plugin-pretend.
(Reading database ... 19234 files and directories currently installed.)
  Preparing to unpack .../redmine-plugin-pretend_0.0.2+git20130821-5_all.deb ...
  Unpacking redmine-plugin-pretend (0.0.2+git20130821-5) ...
  Setting up redmine-plugin-pretend (0.0.2+git20130821-5) ...
  Processing triggers for redmine (5.0.4-5) ...
  Don't run Bundler as root. Bundler can ask for sudo if it is needed, and
  installing your bundle as root will break this application for all non-root
  users on this machine.
  dbconfig-common: flushing administrative password
  rake aborted!
  LoadError: cannot load such file -- redmine_pretend
  
/usr/share/rubygems-integration/all/gems/zeitwerk-2.6.1/lib/zeitwerk/kernel.rb:35:in
 `require'
  
/usr/share/rubygems-integration/all/gems/zeitwerk-2.6.1/lib/zeitwerk/kernel.rb:35:in
 `require'
  /usr/share/redmine/plugins/redmine_pretend/init.rb:1:in `'
  /usr/share/redmine/lib/redmine/plugin_loader.rb:31:in `load'
  /usr/share/redmine/lib/redmine/plugin_loader.rb:31:in `run_initializer'
  /usr/share/redmine/lib/redmine/plugin_loader.rb:108:in `each'
  /usr/share/redmine/lib/redmine/plugin_loader.rb:108:in `block in load'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:427:in
 `instance_exec'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:427:in
 `block in make_lambda'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:198:in
 `block (2 levels) in halting'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:604:in
 `block (2 levels) in default_terminator'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:603:in
 `catch'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:603:in
 `block in default_terminator'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:199:in
 `block in halting'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:512:in
 `block in invoke_before'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:512:in
 `each'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:512:in
 `invoke_before'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/callbacks.rb:105:in
 `run_callbacks'
  
/usr/share/rubygems-integration/all/gems/activesupport-6.1.7.3/lib/active_support/reloader.rb:88:in
 `prepare!'
  
/usr/share/rubygems-integration/all/gems/railties-6.1.7.3/lib/rails/application/finisher.rb:124:in
 `block in '
  
/usr/share/rubygems-integration/all/gems/railties-6.1.7.3/lib/rails/initializable.rb:32:in
 `instance_exec'
  
/usr/share/rubygems-integration/all/gems/railties-6.1.7.3/lib/rails/initializable.rb:32:in
 `run'
  
/usr/share/rubygems-integration/all/gems/railties-6.1.7.3/lib/rails/initializable.rb:61:in
 `block in run_initializers'
  
/usr/share/rubygems-integration/all/gems/railties-6.1.7.3/lib/rails/initializable.rb:60:in
 `run_initializers'
  
/usr/share/rubygems-integration/all/gems/railties-6.1.7.3/lib/rails/application.rb:391:in
 `initialize!'
  

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Emanuele Rocca]

Hi again,

On 2023-05-31 05:46, Samuel Thibault wrote:
> The problem is that both are frown-prone. I guess there is a reason why
> on arm the default console is set to the serial port, e.g. for simpler
> debugging or something like that.

Also worth mentioning: there is no bug on real hardware (eg: RPi 3B+).

So far I think we've only heard about people getting this issue with
qemu.

ciao,
  ema

Bug#1036081: unblock: mariadb/1:10.11.3-1

[Paul Gevers]

Dear Otto,

While you may not agree with how the Release Team is managing the 
release process and with the guidelines that we have created to make 
that process manageable, we are delegated by the Debian Project Leader 
to do exactly that. I'm very disappointed to see that you keep on 
insisting to do it your way. I recognize you are busy. But managing the 
release is also a lot of work and the way of working has been 
established over the course of many years. It would be great if you 
could try a bit more to work together.


Anyways, in the interest of our users, _we_ have decided that it's best 
to let mariadb migrate, despite it not being in line with what we asked.


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Emanuele Rocca]

Hi,

On 2023-05-31 05:46, Samuel Thibault wrote:
> I'd rather see a patch like
> 
> if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then
>   # Busybox's init uses a global TERM across all consoles.
> # If the serial console is the default such as on arm64, that
> # will force vt102 on the Linux VT. Fix this back so we get
>   # colors, utf-8, etc.
>   TERM=linux
> fi
> 
> (to be tested etc.)

The following patch works. I've built a netboot image with patched rootskel,
see attached screenshots for before and after the cure.

diff -Nur rootskel-1.135/src/lib/debian-installer.d/S40term-linux 
/home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux
--- rootskel-1.135/src/lib/debian-installer.d/S40term-linux 2011-01-20 
01:05:16.0 +0100
+++ 
/home/ema/debian/rootskel-1.135+nmu1/src/lib/debian-installer.d/S40term-linux   
2023-06-01 15:05:32.514361854 +0200
@@ -1,5 +1,13 @@
 export LANG=C

+if [ "$TERM" = vt102 -a `tty` = /dev/tty1 ] ; then
+   # Busybox's init uses a global TERM across all consoles.
+# If the serial console is the default such as on arm64, that
+# will force vt102 on the Linux VT. Fix this back so we get
+   # colors, utf-8, etc.
+   TERM=linux
+fi
+
 if [ "$TERM" = linux ] ; then
if [ "$TERM_TYPE" = virtual ]; then
echo -ne "\033[9;0]" # Turn off console blanking.

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[James Addison]

Package: e2fsprogs
Followup-For: Bug #1035543
X-Debbugs-Cc: jspri...@debian.org

On Thu, 1 Jun 2023 13:53:18 +0200, Jochen wrote:
> * James Addison  [2023-06-01 12:44]:
> >Would reverting the Install.WantedBy modification[1][2], restoring 
> >e2scrub_reap
> >enablement using 'default.target' on relevant systems, be a sensible approach
> >for bookworm until we can figure out the debhelper-system behaviour when that
> >setting changes?
>
> No, bookworm is frozen and done:
>
> "In the last week prior to the freeze, testing will be completely
> frozen and only emergency bug fixes will be considered in this period."
>
> https://lists.debian.org/debian-devel-announce/2023/04/msg7.html

Drats - but also, thank you for confirming that.  I'd read the announcement, 
and it is
clear, but then somehow afterwards forgot, and thought that the relevant
closing date was one week before the release itself.  I'll return to this after
bookworm is out and until then will try to relax and perhaps may even be able to
de-serious myself temporarily to allow 'celebration'.  Anyway, a revert patch is
attached, although naturally it'd be better to determine the cause.

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[James Addison]

Package: e2fsprogs
Followup-For: Bug #1035543
Control: tags -1 patch
>From 9ad481148456520f15f92973cdd0cf6caa16a088 Mon Sep 17 00:00:00 2001
From: James Addison 
Date: Thu, 1 Jun 2023 13:20:29 +0100
Subject: [PATCH] Revert "e2scrub: use WantedBy=multi-user.target in
 e2scrub_reap.service"

This reverts commit b42c9788c75de10ee3b6d1a7f9fbc2f529b64889.

Signed-off-by: James Addison 
---
 scrub/e2scrub_reap.service.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scrub/e2scrub_reap.service.in b/scrub/e2scrub_reap.service.in
index 58a45656..10d25f06 100644
--- a/scrub/e2scrub_reap.service.in
+++ b/scrub/e2scrub_reap.service.in
@@ -22,4 +22,4 @@ SyslogIdentifier=%N
 RemainAfterExit=no
 
 [Install]
-WantedBy=multi-user.target
+WantedBy=default.target
-- 
2.39.2

Bug#1035979: redmine-plugin-pretend: fails to install: rake aborted! LoadError: cannot load such file -- redmine_pretend

[Paul Gevers]

Hi,

[Release Team member here.]

On Fri, 12 May 2023 09:16:32 +0200 Andreas Beckmann  wrote:

Package: redmine-plugin-pretend



during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.


If I look at the log, it's redmine itself that fails during 
installation. @anbe: why did you decide to file against the plugin? I'm 
guessing here, but if redmine is installed and configured before 
installing the plugin, everything's fine?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Hi Nicholas,
I've uploaded again to mentors, the (now gone) lintian warning complained about 
missing the SystemD service for the package. I've added one from scratch and 
upon initial testing it performs OK.
I modified debian/rules to take the service into consideration though this 
raises some concerns for non-systemd Debian installations. I assume further 
modifications are required to intelligently enable or ignore the service (use 
old init.d mechanism).
mini-httpd already depends on init-system-helpers so that might not be an 
issue, I'll have to test on a non systemd system.
As for the old bugs, at least #491078 and #1018900 are stil present, I shall 
test a user submitted patch for the first one. I'll also create a salsa account 
soon.
I hope this mail finds you well !

Kind regards,
Alexandru Mihail

On Wed, May 31, 2023 at 00:53, Alexandru Mihail 
<[alexandru_mih...@protonmail.ch](mailto:On Wed, May 31, 2023 at 00:53, 
Alexandru Mihail < wrote:

> Hello again, Nicholas
>
> ProtonMail wins this time, I shall send directly to the bug as of now.
>
>> Since you're comfortable with git, please consider creating a Salsa
>> account and continuing to maintain the package in the Debian (previously
>> collab-maint) group. Here's more info on what that means:
>
> Sure, I'm absolutely fine with that
>
>> That's ok, and totally understandable. What I meant is that 1.30 isn't
>> that old compared to Bug #437932 (14 Aug 2007), #516307 from 2009.
>> Those look like they may have already been fixed upstream. Then there
>> are ones like #491078 that may have been fixed in Debian and/or
>> upstream, or could be fixed in the next upload to Debian.
>
> I'll check if those are resolved, of course; I'll add a suitable systemd 
> service to resolve "missing-systemd-service-for-init.d-script".
>
>>
>> Thank you, I hope yours was as good as mine!
>>
> Sure was, thank you too and have a great day/night !
>
> Best,
> Alexandru
>
> --- Original Message ---
> On Wednesday, May 31st, 2023 at 00:06, Nicholas D Steeves  
> wrote:
>
>> Hello Alexandrus,
>>
>> It appears that your mail user agent (possibly webmail) is encrypting
>> emails to me when you "reply all" to the bug; the effect is non-public.
>> It may be that the only way to fix that effect is to either 1. not CC me
>> (just send to the bug) 2. Make that interface forget my key, because it
>> always encrypts when a key is available. 3. Maybe there's a config
>> toggle that disables unconditional encryption, for use with mailing
>> lists?
>>
>> Alexandru Mihail alexandru_mih...@protonmail.ch writes:
>>
>> > Hello Nicholas,
>> > Of course, please quote the first email at the bug. My apologies for 
>> > omitting to reply all :)
>>
>>
>> -- Re PM follows:
>>
>> > Thank you a lot for taking the time to sponsor my work, it is a great 
>> > pleasure and honor for me to finally contribute to Debian packages, after 
>> > 11 years of daily usage :) . Sorry for the later reply, it's morning here.
>>
>>
>> You're welcome! :) No worries with taking time to reply, and feel free
>> to ping me if I take to long to reply.
>>
>> > > "Do you intend to continue to maintain mini-httpd at this location (Vcs 
>> > > location), or do you have a new one in mind?"
>> >
>> > Do you have any preferences/suggestions regarding this question?
>> > I am comfortable with git so forking on git wouldn't be a problem. I have 
>> > no remote to share so far.
>>
>>
>> Since you're comfortable with git, please consider creating a Salsa
>> account and continuing to maintain the package in the Debian (previously
>> collab-maint) group. Here's more info on what that means:
>>
>> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
>>
>> It's ok if you don't want to; however, in this case we'll need to update
>> the Vcs links in the package.
>>
>> > > "On the topic of work, has upstream resolved any of these old bugs"
>> >
>> > The latest upstream release is still mini_httpd-1.30.tar.gz. ACME
>> > produces quality releases in general, but their release cycle is
>> > pretty lethargic as they are a small team working on many tools.
>>
>>
>> That's ok, and totally understandable. What I meant is that 1.30 isn't
>> that old compared to Bug #437932 (14 Aug 2007), #516307 from 2009.
>> Those look like they may have already been fixed upstream. Then there
>> are ones like #491078 that may have been fixed in Debian and/or
>> upstream, or could be fixed in the next upload to Debian.
>>
>> > As context, I've worked professionally on patches for mini-httpd for about 
>> > 9 months, adding PAM support and AAA authentication. Sadly, the license of 
>> > my work is evidently proprietary. If I have the time I can try to tackle 
>> > all the bugs alone, as I know everything that's happening in mini_httpd.c. 
>> > I'll try mailing Jef (from ACME) to see if any fixes are in the pipeline.
>>
>>
>> Nice, it sounds like you're the ideal maintainer for Debian's
>> mini-httpd! It also sounds like 

Bug#1001894: license questions

[matthias . geiger1024]

Relevant debian-legal thread:

https://lists.debian.org/debian-legal/2023/01/msg0.html

This means (from what I understand) that Microsoft would need to release the 
source code under a free (permissive) license.---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1035757: unblock: org-mode/9.5.2+dfsh-5

[Paul Gevers]

Hi,

On 01-06-2023 13:50, David Bremner wrote:

Uploaded and built:


And unblocked.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[Jochen Sprickerhof]

* James Addison  [2023-06-01 12:44]:

Would reverting the Install.WantedBy modification[1][2], restoring e2scrub_reap
enablement using 'default.target' on relevant systems, be a sensible approach
for bookworm until we can figure out the debhelper-system behaviour when that
setting changes?


No, bookworm is frozen and done:

"In the last week prior to the freeze, testing will be completely
frozen and only emergency bug fixes will be considered in this period."

https://lists.debian.org/debian-devel-announce/2023/04/msg7.html

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1035757: unblock: org-mode/9.5.2+dfsh-5

[David Bremner]

Paul Gevers  writes:

>
> The debdiff in message #36 looks OK. If the upload happens very soon, as 
> in today, than we'll see if we can have it migrate in time.
>
> Paul

Uploaded and built:

https://buildd.debian.org/status/fetch.php?pkg=org-mode=9.5.2%2Bdfsh-5=all=1685619895

d

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[James Addison]

Followup-For: Bug #1035543
X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de, 
jspri...@debian.org, ans...@debian.org, a...@debian.org, 
debian.bugrep...@wodny.org, debian-rele...@lists.debian.org

[ re-introducing the larger cc list audience, plus debian-release ]

Would reverting the Install.WantedBy modification[1][2], restoring e2scrub_reap
enablement using 'default.target' on relevant systems, be a sensible approach
for bookworm until we can figure out the debhelper-system behaviour when that
setting changes?

[1] - 
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=b42c9788c75de10ee3b6d1a7f9fbc2f529b64889

[2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991349

Bug#1036818: [pkg-lxc-devel] Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat

[Mathias Gibbens]

On Mon, 2023-05-29 at 20:03 +0200, Paul Gevers wrote:
> We have three layers here. The bare metal is arm64. It hosts several 
> arm* QEMU VM. Inside the VM we run the lxc. I put the output of all 
> three at the bottom. *Maybe* it's relevant that the bare metal still 
> runs bullseye while the VM's run bookworm. I'll also share the
> content for an arm64 host (which is a VM where I don't have access to
> the bare metal.)

[snip]

> # generating the container and showing inside
> debian@ci-worker-armhf-01:~$ sudo lxc-copy -N elbrus 
> autopkgtest-unstable-armhf && sudo lxc-start elbrus && sudo lxc-
> attach elbrus
> root@elbrus:/# cat /proc/cpuinfo
> root@elbrus:/# ls -al /proc/cpuinfo
> -r--r--r-- 1 root root 3878 May 29 17:48 /proc/cpuinfo

  Yeah, that's definitely not right! I don't currently have an
armel/armhf system to test on, but did try using the abel.d.o
porterbox. lxcfs requires elevated permissions to start, which I don't
have on that box.

  Some other things we can look at -- are there any errors/warnings in
the lxcfs service journal and/or the system's dmesg that is running
lxcfs? It might also be useful to start lxcfs with debugging (`-d`) if
there's nothing being logged about populating /proc/cpuinfo.

  I should have time this weekend when I can spin up a qemu vm to test
in, if we're not able to get a root cause identified before then.

Mathias


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

Bug#694154: debian-installer: Preseeding isn't possible for partman-crypto (encrypted LVM)

[James Addison]

Source: partman-crypto
Followup-For: Bug #694154
Control: fixed -1 partman-crypto/77

It looks like this was resolved[1] in partman-crypto version 77 (Debian bug
#656710 / Ubuntu launchpad issue #546405 for the same) - can we close this
bugreport?

[1] - 
https://salsa.debian.org/installer-team/partman-crypto/-/commit/be0a3afab31ba7a174047289c3aa5df179c6a794

Bug#1035949: mariadb: upgrade issue: mariadb-server-10.5 fails to stop after all other -10.5 packages were removed

[Andreas Beckmann]

On 26/05/2023 19.16, Otto Kekäläinen wrote:

I filed now 
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/47
as an exploration to fix this issue.


That worked for me for zoph, but a new failure occurred in tt-rss.
I'm now trying a transitional mariadb-server-10.5 package which seems to 
work for both these cases. Will do a complete set of piuparts upgrade 
tests for all upgrade paths involving mariadb-server-10.5



If we don't fix this in 10.11 the alternative would be to patch 10.5
and 10.3 to simply never fail on missing mariadb-client-10.3/5
package. I already did
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/14
to make the problem have a proper error message users.


Proper error message is good. ;-)
Ignoring the failure not. :-(

While creating the transitional package I came across some 
inconsistencies between Conflicts/Breaks/Replaces. I'm not sure whether 
they are intentional, but I'm doing my tests with the three attached 
patches applied. They didn't make a difference on their own.




AndreasFrom 9c7c48a0d6428535596665590c2e87b4a477abd4 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Thu, 1 Jun 2023 09:53:25 +0200
Subject: [PATCH 1/3] drop redundant Breaks+Conflicts

---
 debian/control | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index d8b99443551..6f3aff563e3 100644
--- a/debian/control
+++ b/debian/control
@@ -88,10 +88,7 @@ Conflicts: libmariadb-client-lgpl-dev-compat,
libmysqlclient-dev
 Provides: libmariadb-client-lgpl-dev-compat,
   libmariadbclient-dev-compat
-Breaks: libmariadb-client-lgpl-dev-compat,
-libmariadbclient-dev (<< 1:10.3),
-libmariadbclient-dev-compat,
-libmysqlclient-dev
+Breaks: libmariadbclient-dev (<< 1:10.3)
 Replaces: libmariadb-client-lgpl-dev-compat,
   libmariadbclient-dev (<< 1:10.3),
   libmariadbclient-dev-compat,
-- 
2.20.1

From c8fd52f3bbe17d888981652823a3e0ac19c9a657 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann 
Date: Thu, 1 Jun 2023 09:54:46 +0200
Subject: [PATCH 2/3] tighten server plugin dependencies

---
 debian/control | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/debian/control b/debian/control
index 6f3aff563e3..ade3b98e256 100644
--- a/debian/control
+++ b/debian/control
@@ -652,7 +652,7 @@ Description: Spider storage engine for MariaDB
 Package: mariadb-plugin-gssapi-server
 Architecture: any
 Depends: libgssapi-krb5-2,
- mariadb-server,
+ mariadb-server (= ${server:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Breaks: mariadb-gssapi-server-10.1,
@@ -696,7 +696,7 @@ Description: CrackLib Password Validation Plugin for MariaDB
 Package: mariadb-plugin-hashicorp-key-management
 Architecture: any
 Depends: libcurl4,
- mariadb-server,
+ mariadb-server (= ${server:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: Hashicorp Key Management plugin for MariaDB
@@ -705,7 +705,7 @@ Description: Hashicorp Key Management plugin for MariaDB
 
 Package: mariadb-plugin-provider-bzip2
 Architecture: any
-Depends: mariadb-server (>= 1:10.11.1-1),
+Depends: mariadb-server (= ${server:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: BZip2 compression support in the server and storage engines
@@ -719,7 +719,7 @@ Description: BZip2 compression support in the server and storage engines
 
 Package: mariadb-plugin-provider-lz4
 Architecture: any
-Depends: mariadb-server (>= 1:10.11.1-1),
+Depends: mariadb-server (= ${server:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: LZ4 compression support in the server and storage engines
@@ -733,7 +733,7 @@ Description: LZ4 compression support in the server and storage engines
 
 Package: mariadb-plugin-provider-lzma
 Architecture: any
-Depends: mariadb-server (>= 1:10.11.1-1),
+Depends: mariadb-server (= ${server:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: LZMA compression support in the server and storage engines
@@ -747,7 +747,7 @@ Description: LZMA compression support in the server and storage engines
 
 Package: mariadb-plugin-provider-lzo
 Architecture: any
-Depends: mariadb-server (>= 1:10.11.1-1),
+Depends: mariadb-server (= ${server:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: LZO compression support in the server and storage engines
@@ -761,7 +761,7 @@ Description: LZO compression support in the server and storage engines
 
 Package: mariadb-plugin-provider-snappy
 Architecture: any
-Depends: mariadb-server (>= 1:10.11.1-1),
+Depends: mariadb-server (= ${server:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Description: Snappy compression support in the server and storage engines
-- 
2.20.1

From 07f654ffce74f75380065d447f76766d36cd06ea Mon Sep 17 00:00:00 2001
From: Andreas 

Bug#1035871: flare-engine: broken symlink: /usr/share/games/flare/mods/default/fonts/unifont-10.0.06.ttf -> ../../../../../fonts/truetype/unifont/unifont.ttf

[Paul Gevers]

Dear maintainers,

[Release Team member here.]

On Wed, 10 May 2023 13:54:11 +0200 Andreas Beckmann  wrote:

fonts-unifont does no longer ship unifont.ttf or other *.ttf.
There are only the *.otf variants left in most cases.


How bad is this in practice? Does flare-engine break completely or is 
this mostly an annoyance? (I can imagine either or anything in between)


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036970: 0ad: third party library (mbedtls) needs to be updated

[Fabio Pedretti]

forwarded 1036970 https://trac.wildfiregames.com/ticket/6816
thanks

Bug#1032994: unblock: node-webpack/5.76.1+dfsg1+~cs17.16.16-1

[Paul Gevers]

control: tags -1 moreinfo

Hi Yadd,

On 29-05-2023 05:58, Yadd wrote:

On 5/28/23 10:29, Graham Inggs wrote:

On Wed, 3 May 2023 at 04:51, Yadd  wrote:

How about reverting and providing a fix only for that CVE please?


instead of reverting and have a too long version 
(5.76.1+dfsg1+~cs17.16.16+really-5.75.0+dfsg+~cs17.16.14-1), if upload 
to bookworm is allowed, I'm able to push this debdiff.


Please upload this debdiff to unstable ASAP. I'm not aware of 
limitations for the version number that you would trigger with that. tpu 
is not meant for this purpose (it doesn't have any QA). Mind you, the 
closing window for uploads was last weekend, so we're extremely late. 
Otherwise we'll have to do this via the security archive or a point 
release update.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036993: [Pkg-sssd-devel] Bug#1036993: /lib/x86_64-linux-gnu/security/pam_sss.so: pam_sss passes KRB5CCNAME with sudo -i (see redhat bug/fix 1324486)

[Timo Aaltonen]

J. Pfennig kirjoitti 31.5.2023 klo 21.34:

Package: libpam-sss
Version: 2.8.2-4
Severity: normal
File: /lib/x86_64-linux-gnu/security/pam_sss.so

Dear Maintainer,

* What led up to the situation?

 using kerberos, AD/DC, sssd and its pam module

* What exactly did you do (or not do) that was effective (or
  ineffective)?

 kinit ...   # to get a kerberos ticket
 echo $KRB5CCNAME# path to creditial cache

 sudo -i user2
 echo $KRB5CCNAME# ORIGINAL path to creditial cache

* What was the outcome of this action?

 kinit, klist et al fail, wrong credential cache
 echo $KRB5CCNAME# path from original user

* What outcome did you expect instead?

 KRB5CCNAME must not be passed

 the case is described better than I can do at:

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

 Bug fixed there in 2017. Could Debian fix it too?



The default value for pam_response_filter should already be
'ENV:KRB5CCNAME:sudo, ENV:KRB5CCNAME:sudo-i', so this issue should not 
happen since 2.5.1.



--
t

Bug#1030779: pip check

[Cesar Enrique Garcia Dabo]

Just as additional information, running pip check already complains 
about this:


$ pip check

fastapi 0.92.0 has requirement starlette<0.26.0,>=0.25.0, but you have 
starlette 0.26.1.

Bug#1035757: unblock: org-mode/9.5.2+dfsh-5

[Paul Gevers]

Dear David,

On 20-05-2023 15:34, David Bremner wrote:

I dove down this rabbit-hole a bit, not enough to figure the ultimate
cause, but enough to notice these files are also because of
"apt install systemd". So no related to org-mode. FWIW, systemd is
pulled in by emacs-gtk.


Earlier this week you asked about this unblock request on IRC, but the 
bug is not actionable for us.


elbrus@respighi:~$ rmadison org-mode -sunstable,testing
org-mode   | 9.5.2+dfsh-4  | testing| source, all
org-mode   | 9.5.2+dfsh-4  | unstable   | source, all

Aha, wait, I think you were still waiting for the ACK on the debdiff. 
Sorry, I got confused by your last reply and I lost track of that.


The debdiff in message #36 looks OK. If the upload happens very soon, as 
in today, than we'll see if we can have it migrate in time.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037010: python3-levenshtein: pip does not recognize that apt package python3-levenshtein is installed

[Enrique Garcia]

Package: python3-levenshtein
Version: 0.12.2-2+b4
Severity: minor
X-Debbugs-Cc: cqu...@arcor.de

I am trying to install with pip a package that depends on Levenshtein. I
usually do that in a venv with the --system-site-packages option so that the
packages installed with apt can be seen. However it looks as if the
python3-levenshtein package is not recognized by pip:

$ pip install sublime_music-0.12.0-py3-none-any.whl
Requirement already satisfied: bleach in /usr/lib/python3/dist-packages (from
sublime-music==0.12.0) (5.0.1)
Requirement already satisfied: dataclasses-json in /usr/lib/python3/dist-
packages (from sublime-music==0.12.0) (0.5.7)
Requirement already satisfied: deepdiff in /usr/lib/python3/dist-packages (from
sublime-music==0.12.0) (6.2.2)
Requirement already satisfied: thefuzz in /usr/lib/python3/dist-packages (from
sublime-music==0.12.0) (0.19.0)
Requirement already satisfied: peewee in /usr/lib/python3/dist-packages (from
sublime-music==0.12.0) (3.14.10)
Requirement already satisfied: PyGObject in /usr/lib/python3/dist-packages
(from sublime-music==0.12.0) (3.42.2)
Requirement already satisfied: python-dateutil in /usr/lib/python3/dist-
packages (from sublime-music==0.12.0) (2.8.2)
Collecting Levenshtein
  Using cached
Levenshtein-0.21.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
(173 kB)
Requirement already satisfied: python-mpv in /usr/lib/python3/dist-packages
(from sublime-music==0.12.0) (1.0.1)
Requirement already satisfied: requests in /usr/lib/python3/dist-packages (from
sublime-music==0.12.0) (2.28.1)
Requirement already satisfied: semver in /usr/lib/python3/dist-packages (from
sublime-music==0.12.0) (2.10.2)
Requirement already satisfied: rapidfuzz<4.0.0,>=2.3.0 in
/home/user/.local/lib/python3.11/site-packages (from Levenshtein->sublime-
music==0.12.0) (3.0.0)
Requirement already satisfied: pycairo>=1.16.0 in /usr/lib/python3/dist-
packages (from PyGObject->sublime-music==0.12.0) (1.20.1)
Installing collected packages: Levenshtein, sublime-music
Successfully installed Levenshtein-0.21.0 sublime-music-0.12.0


As can be seen, all dependencies are found in the system,  but not Levenshtein,
despite being installed in the system:
dpkg -l | grep python3-levenshtein
ii  python3-levenshtein  0.12.2-2+b4

I think it has to do with the name in PKG-INFO:
$ grep Name /usr/lib/python3/dist-packages/python_Levenshtein-0.12.2.egg-
info/PKG-INFO
Name: python-Levenshtein

(rather than simply Name: Levenshtein). But I am not sure whether that's
enough.


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

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

Versions of packages python3-levenshtein depends on:
ii  libc6  2.36-9
ii  python33.11.2-1+b1
ii  python3-pkg-resources  66.1.1-1

python3-levenshtein recommends no packages.

python3-levenshtein suggests no packages.

-- no debconf information

Bug#1033502: It is still broken

[Julian Andres Klode]

Control: forcemerge 1029766 -1

On Thu, Jun 01, 2023 at 11:36:38AM +0300, Norbert wrote:
> root@debian:~# add-apt-repository -y "deb
> http://ppa.launchpad.net/nrbrtx/vte/ubuntu jammy main"
> Traceback (most recent call last):
>   File "/usr/bin/add-apt-repository", line 362, in 
> sys.exit(0 if addaptrepo.main() else 1)
>   ^
>   File "/usr/bin/add-apt-repository", line 345, in main
> shortcut = handler(source, **shortcut_params)
>^^
>   File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py",
> line 40, in shortcut_handler
> return handler(shortcut, **kwargs)
>^^^
>   File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 78,
> in __init__
> self.lpppa
>   File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line
> 126, in lpppa
> self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
>   ^^^
>   File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line
> 113, in lpteam
> self._lpteam = self.lp.people(self.teamname)
>^^
> AttributeError: 'NoneType' object has no attribute 'people'
> root@debian:~# apt-cache policy $(dpkg -S $(which add-apt-repository))
> software-properties-common:
>   Installed: 0.99.30-4
>   Candidate: 0.99.30-4
>   Version table:
>  *** 0.99.30-4 500
> 500 http://deb.debian.org/debian bookworm/main amd64 Packages
> 100 /var/lib/dpkg/status
> N: Unable to locate package /usr/bin/add-apt-repository
> root@debian:~# lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description: Debian GNU/Linux 12 (bookworm)
> Release: 12
> Codename: bookworm
> root@debian:~#
> 
> root@debian:~# add-apt-repository ppa:nrbrtx/xorg-hotkeys
> Traceback (most recent call last):
>   File "/usr/bin/add-apt-repository", line 362, in 
> sys.exit(0 if addaptrepo.main() else 1)
>   ^
>   File "/usr/bin/add-apt-repository", line 345, in main
> shortcut = handler(source, **shortcut_params)
>^^
>   File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py",
> line 40, in shortcut_handler
> return handler(shortcut, **kwargs)
>^^^
>   File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 86,
> in __init__
> if self.lpppa.publish_debug_symbols:
>^^
>   File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line
> 126, in lpppa
> self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
>   ^^^
>   File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line
> 113, in lpteam
> self._lpteam = self.lp.people(self.teamname)
>^^
> AttributeError: 'NoneType' object has no attribute 'people'
> root@debian:~#
> 
> 
> 
> Do you plan to fix this bug before Debian 12 final release?

No, this is a minor cosmetic issue for unsupported hacks,
it does not affect functionality.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1033502: It is still broken

[Norbert]

Do you plan to fix this bug before Debian 12 final release?

Bug#1033502: It is still broken

[Norbert]

root@debian:~# add-apt-repository -y "deb
http://ppa.launchpad.net/nrbrtx/vte/ubuntu jammy main"
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 362, in 
sys.exit(0 if addaptrepo.main() else 1)
  ^
  File "/usr/bin/add-apt-repository", line 345, in main
shortcut = handler(source, **shortcut_params)
   ^^
  File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py",
line 40, in shortcut_handler
return handler(shortcut, **kwargs)
   ^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 78,
in __init__
self.lpppa
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line
126, in lpppa
self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
  ^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line
113, in lpteam
self._lpteam = self.lp.people(self.teamname)
   ^^
AttributeError: 'NoneType' object has no attribute 'people'
root@debian:~# apt-cache policy $(dpkg -S $(which add-apt-repository))
software-properties-common:
  Installed: 0.99.30-4
  Candidate: 0.99.30-4
  Version table:
 *** 0.99.30-4 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status
N: Unable to locate package /usr/bin/add-apt-repository
root@debian:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm
root@debian:~#

root@debian:~# add-apt-repository ppa:nrbrtx/xorg-hotkeys
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 362, in 
sys.exit(0 if addaptrepo.main() else 1)
  ^
  File "/usr/bin/add-apt-repository", line 345, in main
shortcut = handler(source, **shortcut_params)
   ^^
  File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py",
line 40, in shortcut_handler
return handler(shortcut, **kwargs)
   ^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 86,
in __init__
if self.lpppa.publish_debug_symbols:
   ^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line
126, in lpppa
self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
  ^^^
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line
113, in lpteam
self._lpteam = self.lp.people(self.teamname)
   ^^
AttributeError: 'NoneType' object has no attribute 'people'
root@debian:~#



Do you plan to fix this bug before Debian 12 final release?

Bug#1036918: debvm: manual mounting of root image

[Wouter Verhelst]

Hi Helmut,

On Thu, Jun 01, 2023 at 07:53:00AM +0200, Helmut Grohne wrote:
> Hi Wouter,
> 
> On Wed, May 31, 2023 at 12:18:00PM +0200, Wouter Verhelst wrote:
> > I don't think it is. All packages that do things at early boot have
> > complicatd requirements; nbd isn't the only one. It's just the first one
> > you hear about.
> 
> Thank you for not giving up here.
> 
> > > and that debvm may not be the right hammer for your job? While debvm
> > > gives you a complete rootfs, you seem to be satisfied with a kernel an
> > > an initrd.
> > 
> > No, that is not accurate; I do need a root filesystem too.
> 
> Now that - to me - is a compelling argument. Arguably, that should have
> been obvious. Thanks for spelling it out.
> 
> > Yes, I could run debvm-create and then do the extraction of the kernel
> > and initrd myself, but that shouldn't be necessary -- debvm-run would be
> > a perfectly good abstraction, if only it allowed me to tell it not to
> > try to mount the hard drive automatically and/or let me override the
> > root= parameter.
> 
> I believe I now understand your use case and I follow your reasoning
> that debvm could reasonably do better at supporting it.
> 
> Both mmdebstrap and debvm-create have a --skip mechanism. Doing
> something similar to debvm-run seems sensible initially. The precise way
> of doing it less so. Would you be interested in helping sort the
> details?
> 
> For one thing, I think your use of -append does not work well with
> debvm-run. While it sounds like it was appending, it actually is
> replacing the kernel cmdline. debvm-run has its own ideas and passes the
> rootfs, console and terminal emulation type there. By overriding
> -append, you miss all of that. I suspect, we need a more clever
> management of cmdline here and am unsure what that should be exactly.

Ah, yes. I did indeed assume it was keeping the arguments, but it not
doing so seems consistent with what I saw. I assumed that things went
wrong because there were multiple versions of hte same filesystem; but
come to think of it, I would then still have had some output, at least,
which I did not. Losing the whole command line would lose the console,
which would mean there was no output.

I do think debvm-run needs to have a way to actually add to the kernel
command line. Some use cases would need this without having to basically
reimplement what it is already doing. Combined with a skip mechanism, I
think that would cover a lot of use cases.

Since ordering of the kernel command line rarely matters, adding a
simple option for additional command line bits (which then get added at
the end of the command line) should be sufficient, I would think.

> For passing the actual rootfs, I guess a --skip=rootdev would address
> your need. I imagine it as skipping both the root= cmdline argument and
> passing of the blockdev.

I think it may make more sense to treat the two as separate. You mount
the root filesystem by label, currently; so it does not matter how the
block device is set up, as long as it is there. I think some use cases
would benefit from being able to fine-tune the way the block device is
set up without having to add the root filesystem again.

On the other hand, adding a root= parameter to the command line after it
has been removed should be fairly trivial, provided there is a way to
add to the kernel command line without having to redo it. So I don't
think this is really crucial.

> Other things that users might want to skip include the network setup
> (not in your case ;) and the random device setup.
> 
> So at this point, the addition of a --skip option seems fairly likely to
> me, but I'd like to consult with other users some more and won't upload
> debvm before bookworm has been released anyway. Still your (and other's)
> input on what kind of features should be skippable and how we could
> better deal with the cmdline is welcome.
> 
> Thanks for insisting.
> 
> Helmut
> 
> 

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1037009: ITP: python-drf-spectacular-sidecar-nonfree -- Serve builds of Swagger UI and Redoc for Django REST framework

[Carsten Schoenert]

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

* Package name: python-drf-spectacular-sidecar-nonfree
  Version : 2023.5.1
  Upstream Contact: T. Franzel 
* URL : https://github.com/tfranzel/drf-spectacular-sidecar
* License : Apache-2.0, BSD-3, MIT/X
  Programming Lang: Python, JS, CSS
  Description : Serve builds of Swagger UI and Redoc for Django REST 
framework

Serve self-contained distribution builds of Swagger UI and Redoc with
Django either via runserver or collectstatic.

This Django app is an optional addition to drf-spectacular, but does not
depend on it. It may also be used independently.
It uses parts of 
Swagger UI version 4.18.3
Redoc version 2.0.0

The pulled in files for Swager-UI und Redoc are fetched from jsdelivr
and are unfortunately only the minimized parts that probbaly make the
package non-free as I'm unable to rebuild them.
.
The source for Redoc is available from
https://github.com/Redocly/redoc
but isn't packaged or available in some form in Debian.

The same is true for Swagger UI, the source is also avaialbe on GitHub
https://github.com/swagger-api/swagger-ui

So far also no Debian packages are created yet for Swagger-UI which
could be used to rebuild or reference the used minimized files in
drf-spectacular-sidecar.

This package is new dependency for NetBox (see ITP
https://bugs.debian.org/1017079) as since version 3.5.0 NetBox Upstream
has moved over to support using the OpenAPI 3.0 spec to generate the
REST API schema.

I plan to maintain the package within the an Debian Python Team.
As like for NetBox I appreciate any help around how the minimized files
could be rebuild so the package wouldn't needed to be placed in
non-free.

Regards
Carsten

Bug#1033479: minissdpd: Service fails to start on boot with "Error parsing address/mask..."

[Jonathan Dowland]

I've hit something similar. In my case the error in the logs is

Mar 07 17:59:33 phobos minissdpd-systemd-wrapper[1302]: Error parsing 
address/mask (or interface name) : enp3s0
Mar 07 17:59:33 phobos minissdpd-systemd-wrapper[1302]: can't parse 
"enp3s0" as a valid address or interface name

and my /etc/default/minissdpd contained

MiniSSDPd_INTERFACE_ADDRESS="enp3s0"

Likewise, I have not edited that file myself. I guess it was populated
by the debconf template[1]

It was probably correct at the time I installed minissdpd (which I did
transitively: and as such I'm not very familiar with what it does or how
it works, since it's a dependency package of something else) and has
become incorrect later on, as I've moved enp3s0 onto a bridge interface.

My fix (the inverse of yours I guess) is to substitute 


MiniSSDPd_INTERFACE_ADDRESS="br0"

In the config file.

But I suggest to the maintainer (Hi Thomas!): If you're confident that
you can guess the right interface at install time, why not do that at
service start up time instead? That way it will adjust to changing
environments.


[1] 
https://salsa.debian.org/miniupnp-team/minissdpd/-/blob/debian-sid/debian/minissdpd.config#L45

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1034546: RFS: luametatex/2.10.07-1 [ITP] -- Next generation ConTeXt processing engine

[Preuße]

On 17.04.2023 23:44, Hilmar Preusse wrote:

Dear mentors,


I am looking for a sponsor for my package "luametatex":

  * Package name : luametatex
Version  : 2.10.07-1
Upstream contact : Hans Hagen 
  * URL  : https://github.com/contextgarden/luametatex
  * License  : MIT, GPL-2+, ICU, PD
  * Vcs  : https://github.com/debian-tex/luametatex
Section  : tex

The source builds the following binary packages:

   luametatex - Next generation ConTeXt processing engine



Ping! Would anybody so kind to upload to experimental? That package is 
prereq for the next version of ConTeXt.


Thanks!

Hilmar
--
sigfault



OpenPGP_0x0C871C4C653C1F59.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature