Bug#1033307: RFS: 86box/3.7.1-1 [ITP] -- An emulator for classic IBM PC clones

[sun min]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "86box":

 * Package name : 86box
   Version  : 3.11+ds-1
   Upstream contact : OBattler 
 * URL  : https://86box.net/
 * License  : GPL-2
 * Vcs  : https://salsa.debian.org/sunmin/86box
   Section  : otherosfs

The source builds the following binary packages:

  86box - classic IBM PC emulator

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

  https://mentors.debian.net/package/86box/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/8/86box/86box_3.11+ds-1.dsc

Changes for the initial release:

 86box (3.11+ds-1) UNRELEASED; urgency=low
 .
   * Initial release. (Closes: #996637)



 86Box is a low level x86 emulator that runs older operating systems
 and software designed for IBM PC systems and compatibles from 1981
 through fairly recent system designs based on the PCI bus.


Regards,
--
  sun min

Bug#1003352:

[Cyrus Lien]

Dear maintainer,

This bug still needs a boot script mounting efivarfs in initrd for systems
whose rootfs are on RAID volume.
Either as Jörn Heissler's suggestion to put boot script in /init-premount,
or in /init-top, something like this
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/66/diffs
.

Kind regards,
Cyrus

Bug#1033306: tor: Tor relays running 0.4.5.16 will soon be cut off from the network

[Francois Marier]

Package: tor
Version: 0.4.5.16-1
Severity: grave
Justification: renders package unusable

I received the following email from the Tor Project:

Hi,

You are running a bunch of Tor relays, which is great:

However, those relays' Tor version is obsolete, and because of old bugs,
we will soon cut relays and bridges running that version out of the
network. Please consider upgrading!

You can find Tor packages and instructions for your distro / OS here:
https://community.torproject.org/relay/setup/guard/

If you need help upgrading your relays, please use the Tor Forum:
https://forum.torproject.net/c/support/relay-operator/17

Let us know if we can do anything to make the process easier.

Thanks!
Georg

They are currently aiming for a cut-off date 4-6 weeks from now.

This means that the version of tor that's in bullseye will essentially stop
working for most uses.

There is already a version in backports that will work fine, but perhaps
it's worth also uploading it to stable for the next point release?

Francois

-- 
https://fmarier.org/

Bug#980316: Update on packaging corepack

[Pirate Praveen]

On Tue, Mar 21 2023 at 09:06:41 PM +01:00:00 +01:00:00, Paul Gevers 
 wrote:

Hi Pirate,

Thanks for reaching out.

On 20-03-2023 16:44, Pirate Praveen wrote:

I request bookworm-ignore tags for these bugs (as such there is
no immediate breakage, just unmaintained upstreams for these 
packages).


> yarnpkg: 980316,958686, 1002902, 980316
> node-har-validator: 1024575
> node-request: 956423
> node-request-capture-har: 1002901

As the packages in question are key packages, we can't easily remove
them. Hence adding a bookworm-ignore tag doesn't really change the
situation in bookworm in any way. Hence, the question is whether 
fixing

it now and adding an exception is better or worse than letting the bug
ship in bookworm. If I understand correctly, than the required change
would mean a new complex package (corepack) which (again, if I
understand correctly) is considered also by you as inappropriate at 
this

time. If you confirm my understanding, I agree that those bugs can be
marked bookworm-ignore (I already marked them as bookworm-can-defer,
which is less strong and less official).


We won't be able to complete corepack in a few weeks or months. So we 
have to ship bookworm with these bugs and get this fixed in time for 
trixie.




Paul

Bug#1033278: wine: Battle.Net: The application failed to start because no Qt platform plugin could be initialized

[Joe Nahmias]

On Mon, Mar 20, 2023 at 11:38:23PM -0400, Joseph Nahmias wrote:
> I just upgraded from bullseye to bookworm and now Battle.Net / Hearthstone
> refuses to start. Instead it shows this error message:
> 
> The application failed to start because no Qt
> platform plugin could be initialized. Reinstalling
> the application may fix this problem.
> 
> Was there some change in the wine packaging that would cause this error?
> Would additional logs/debug info be useful to troubleshoot?

False alarm. Seems to be related to an update of the Battle.Net client -- not
wine itself. See https://bugs.winehq.org/show_bug.cgi?id=53826 and
https://gitlab.winehq.org/wine/wine/-/merge_requests/1148 for details.

Thanks,
--Joe

Bug#1033288: Build Problems with nvidia-fs-dkms on kernel version 6.1.20

[Andreas Beckmann]

On 21/03/2023 16.38, Jannick Loch wrote:
Durimng my update routine, i notice that i have problems with building 
the nvidia-fs module on the newest linux kernel package
6.1.20. Dkms said that there was an BUILD_EXCLUSIVE directive which does 
not match this kernel/arch/config. If i remove this directive by comment 


I'm currently working on fixing the module to build for current kernels.


Andreas

Bug#1033304: request-tracker5: debianisation of version interferes with doc linking

[AP]

Package: request-tracker5
Version: 5.0.3
Severity: normal

Dear Maintainer,

RT5 (and possibly RT4) uses the version number to generate a URL for its 
documentation.
This URL is in use when configuring the system via the web interface (click on 
a config
name and it takes you to the help for it).

As a result the help results in a 404 until you manually remove the debian 
component of
the version.

This error is the result of the debianize_version.diff patch which changes the 
version
globally.

Bug#1033303: mergerfs: Upgrade to v2.34.1 for bookworm

[MK]

Package: mergerfs
Version: 2.33.5~debian-bullseye
Severity: wishlist


Dear Maintainer,


Would love to see the latest version of mergerfs in the upcoming bookworm 
release.
Changes are minor and this package doesn't impact other packages.


What's Changed
Rework support section in readme by @trapexit in #1032
Add details about usage of FUSE to docs by @trapexit in #1039
Fix typos by @Gelma in #1045
Error when given invalid policy names by @trapexit in #1057
Support doc update by @trapexit in #1058
Fix setting of stat vars for symlinkify by @trapexit in #1085
Update fuse_kernel.h by @trapexit in #1087
Tweaks for 32bit systems by @trapexit in #1089
Remove unnecessary libfuse abstractions by @trapexit in #1091
Remove write_buf, simplify FUSE msg dispatching by @trapexit in #1092
Add CodeQL workflow for GitHub code scanning by @lgtm-com in #1093
Remove libfuse abstraction in prep for adding request data by @trapexit in #1104
Misc cleanup by @trapexit in #1105
Fix reading of setxattr name by @trapexit in #1106
Fix regression testing for implemented functions


** Note- system below is not running bookworm




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


Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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 mergerfs depends on:
ii  fuse        2.9.9-5
ii  libc6       2.31-13+deb11u5
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6


mergerfs recommends no packages.


mergerfs suggests no packages.


-- no debconf information

Bug#1033044: daily cron job broken?

[tommy reid]

That have happened and. I just want. An answer too maybe. I mean, I can't.
Seemed to get away from it.HELP



On Tue, Mar 21, 2023 at 12:30 AM tommy reid 
wrote:

> Never broken
>
> On Thu, Mar 16, 2023, 5:45 AM Marc Haber 
> wrote:
>
>> Package: aide-common
>> Version: 0.18.1-1
>> Severity: grave
>> Tags: confirmed
>>
>> Justification: Maintainer discretion, cron job broken
>>
>> diff --git a/debian/bin/dailyaidecheck b/debian/bin/dailyaidecheck
>> index aa4b59c..fbd0a57 100755
>> --- a/debian/bin/dailyaidecheck
>> +++ b/debian/bin/dailyaidecheck
>> @@ -161,7 +161,7 @@ FILTERUPDATES="${FILTERUPDATES:-no}"
>>  FILTERINSTALLATIONS="${FILTERINSTALLATIONS:-no}"
>>  CRONEXITHOOK="${CRONEXITHOOK:-}"
>>  ONEXIT=""
>> -AIDEUSER="${AIDEUSER:-root}"
>> +AIDEUSER="${AIDEUSER:-$(id --user --name)}"
>>  AIDEUSERUID="$(id --user "${AIDEUSER}")"
>>
>>  # silent implies quiet
>>
>> And upload will follow shortly.
>>
>> Greetings
>> Marc, Maintainer
>>
>>

Bug#1000130: [htcondor-debian] Bug#1000130: condor: depends on obsolete pcre3 library

[Tim Theisen]

Hello,

I am trying to get HTCondor 10.3.0 into shape. Then this bug will be 
resolved.


...Tim

On 2/23/23 06:09, Kentaro Hayashi wrote:

FYI:

It seems that this issue was fixed in version 9.10.0

https://htcondor.readthedocs.io/en/latest/version-history/development-release-series-91.html#version-9-10-0
___
htcondor-debian mailing list
htcondor-deb...@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian


--
Tim Theisen (he, him, his)
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736

Bug#1033298: webkit2gtk: please cherry-pick upstream riscv64 build fixes [PATCH]

[Alberto Garcia]

On Tue, Mar 21, 2023 at 09:35:20PM +0100, Gianfranco Costamagna wrote:

> Please if possible consider cherry-picking them in Debian, if not
> (since riscv64 is not release architecture), I'm pretty sure on next
> upstream release they won't be needed anymore anyway :)

I'm a bit hesitant to do it now while we're in the middle of an
unblock request and, as you say, riscv64 is not a release architecture
and the next upstream release (which will happen soon I think) will
include these patches.

Berto

Bug#861796: chromium: Chromium doesn't start

[Andres Salomon]

On Fri, 28 Jan 2022 16:29:18 + Amr Ibrahim 
 wrote:

> Am Donnerstag, dem 27.01.2022 um 18:55 -0500 schrieb Andres Salomon:
> > you can also run "chromium --ozone-platform=wayland" to get native
> > wayland.
>
> Thanks for the tip, I never tried that. I do the chrome://flags way
> because it's persistent and doesn't require running chromium from the
> command-line.
>
> And "Preferred Ozone platform = Auto" is fail-safe in case the system
> does not support Wayland.
>
> Best,
> Amr
>


This will be documented in README.Debian, as well.

I realize that this bug never got an explanation why Wayland was turned 
off - https://bugs.debian.org/1003689 has the details.


We'll try again post-bookworm.

Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Aurelien Jarno]

Source: linux
Version: 6.1.15-1
Severity: important
Tags: upstream
X-Debbugs-Cc: vagr...@debian.org
Control: affects -1 + u-boot-rpi

Hi,

Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
to boot with:

| 40175552 bytes read in 1695 ms (23 MiB/s)
| 43794863 bytes read in 1817 ms (23 MiB/s)
| Moving Image from 0x8 to 0x20, end=299
| ERROR: RD image overlaps OS image (OS=0x20..0x299)

I tracked the issue to a significant increase of the kernel size between
version 6.1.12-1 and 6.15-1:

| 31492   /boot/vmlinuz-6.1.0-5-arm64
| 39236   /boot/vmlinuz-6.1.0-6-arm64

This is more than the 36MB that is allowed by u-boot with the default
load addresses. A workaround is to shift the load addresses at the
u-boot level as in the attached patch.

I have tracked issue on the upstream kernel side to the following commit
on the stable tree:

| commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
| Author: Masahiro Yamada 
| Date:   Thu Oct 13 08:35:00 2022 +0900
| 
| arm64: remove special treatment for the link order of head.o
| 
| commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
| 
| In the previous discussion (see the Link tag), Ard pointed out that
| arm/arm64/kernel/head.o does not need any special treatment - the only
| piece that must appear right at the start of the binary image is the
| image header which is emitted into .head.text.
| 
| The linker script does the right thing to do. The build system does
| not need to manipulate the link order of head.o.
| 
| Link: 
https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
| Suggested-by: Ard Biesheuvel 
| Signed-off-by: Masahiro Yamada 
| Reviewed-by: Nicolas Schier 
| Link: 
https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
| Signed-off-by: Will Deacon 
| Signed-off-by: Tom Saeger 
| Signed-off-by: Greg Kroah-Hartman 

The problem is still reproducible on Linus' master.

I am reporting the bug to the linux package as I believed there is no
real reason for such an increase in the kernel size. In case I missed
something and this is actually wanted, the bug can be reassigned to the
u-boot package.

Regards
Aurelien
--- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
+++ u-boot-2023.01+dfsg/include/configs/rpi.h
@@ -95,32 +95,32 @@
  *   text_offset bytes (specified in the header of the Image) into a 2MB
  *   boundary. The 'booti' command relocates the image if necessary. Linux uses
  *   a default text_offset of 0x8.  In summary, loading at 0x8
- *   satisfies all these constraints and reserving memory up to 0x0240
- *   permits fairly large (roughly 36M) kernels.
+ *   satisfies all these constraints and reserving memory up to 0x02a0
+ *   permits fairly large (roughly 42M) kernels.
  *
  * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
  * conflict with something else. Reserving 1M for each of them at
- * 0x0240-0x0250 and 0x0250-0x0260 should be plenty.
+ * 0x02a0-0x02b0 and 0x02c0-0x02d0 should be plenty.
  *
  * On ARM, both the DTB and any possible initrd must be loaded such that they
  * fit inside the lowmem mapping in Linux. In practice, this usually means not
  * more than ~700M away from the start of the kernel image but this number can
  * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
  * parameter given to the kernel. So reserving memory from low to high
- * satisfies this constraint again. Reserving 1M at 0x0260-0x0270 for
- * the DTB leaves rest of the free RAM to the initrd starting at 0x0270.
+ * satisfies this constraint again. Reserving 1M at 0x02c0-0x02d0 for
+ * the DTB leaves rest of the free RAM to the initrd starting at 0x02d0.
  * Even with the smallest possible CPU-GPU memory split of the CPU getting
- * only 64M, the remaining 25M starting at 0x0270 should allow quite
+ * only 64M, the remaining 19M starting at 0x02d0 should allow quite
  * large initrds before they start colliding with U-Boot.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
"fdt_high=" FDT_HIGH "\0" \
"initrd_high=" INITRD_HIGH "\0" \
"kernel_addr_r=0x0008\0" \
-   "scriptaddr=0x0240\0" \
-   "pxefile_addr_r=0x0250\0" \
-   "fdt_addr_r=0x0260\0" \
-   "ramdisk_addr_r=0x0270\0"
+   "scriptaddr=0x02a0\0" \
+   "pxefile_addr_r=0x02b0\0" \
+   "fdt_addr_r=0x02c0\0" \
+   "ramdisk_addr_r=0x02d0\0"
 
 #if CONFIG_IS_ENABLED(CMD_MMC)
#define BOOT_TARGET_MMC(func) \

Bug#1033184: AnyMeal: The desktop file is missing an additional category 'Viewer'

[Jan Wedekind]

On Sun, 19 Mar 2023, Joerg Schiermeier, Bielefeld/Germany wrote:


Hello!

The desktop file for Linux/Debian 
(/usr/share/applications/de.wedesoft.anymeal.desktop) is missing the additional 
category: 'Viewer'.

For further information please see the documentation about desktop files here:


As a viwer for recipes this additional category should be added.

- --
Yours sincerely
Joerg Schiermeier


Hi,
Thanks for reporting the bug. I have fixed it upstream. I guess I need to 
wait for the end of the freeze before getting it uploaded to unstable.


Kind regards
Jan

Bug#1032794: [pre-approval] qtwebengine-opensource-src 5.15.13 for bookworm?

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-03-11 21:04:14 +0300, Dmitry Shachnev wrote:
> Package: release.debian.org
> Severity: wishlist
> 
> Dear Release Team,
> 
> Qt WebEngine 5.15 LTS branch has a new patch release, 5.15.13.
> 
> It mostly contains backports for security fixes from upstream Chromium,
> and some other minor fixes.
> 
> This particular release does not have any ABI changes, but per our
> team practice we bump the name of provided virtual ABI package from
> qtwebengine-abi-5-15-12 to qtwebengine-abi-5-15-13. This will require a
> no-change rebuild of two reverse dependencies (qtwebview-opensource-src
> and angelfish). Is that acceptable for bookworm?

Do both reverse dependencies build fine with the new version of
qtwebengine-opensource-src?

> I am attaching a git diff of my packaging and an upstream git diff.
> Upstream diff is large, but it's mostly security/CVE fixes, as can be
> seen in the commit messages (the relevant commits are starting from
> 2022-12-22):
> 
> https://code.qt.io/cgit/qt/qtwebengine-chromium.git/log/?h=87-based
> 
> I have also included a patch from bug #1005824 to build with pipewire
> support. If a new release is acceptable but that patch is not, I can
> remove it.

We are past the point of adding new features. Please postpone this
change to trixie.

Cheers

> 
> --
> Dmitry Shachnev

> diff --git a/debian/changelog b/debian/changelog
> index 9f4762d..afa565a 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,19 @@
> +qtwebengine-opensource-src (5.15.13+dfsg-1) UNRELEASED; urgency=medium
> +
> +  [ Dmitry Shachnev ]
> +  * New upstream release.
> +  * Update SUBMODULE_COMMIT for the new release.
> +  * Remove copyright section for debian/missing-sources/jszip-2.4.0.
> +  * Build with pipewire support (closes: #1005824).
> +- Backport upstream patch to improve screen sharing with PipeWire
> +  on Wayland and to add support for PipeWire 0.3.
> +- Thanks Pirate Praveen and C�dric Hannotier!
> +  * Bump ABI version to qtwebengine-abi-5-15-13.
> +  * Drop gcc-12.patch, included in the new release.
> +  * Refresh debian/patches/python3.patch.
> +
> + -- Debian Qt/KDE Maintainers   Sat, 11 Feb 
> 2023 13:19:26 +0400
> +
>  qtwebengine-opensource-src (5.15.12+dfsg-3) unstable; urgency=medium
>  
>* Add debian/90qtwebengine-dictionaries-path.conf.
> diff --git a/debian/control b/debian/control
> index 827e12c..72d1c65 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -39,6 +39,7 @@ Build-Depends: binutils (>= 2.32-8~),
> libopenjp2-7-dev,
> libopus-dev (>= 1.3.1),
> libpci-dev,
> +   libpipewire-0.3-dev,
> libpng-dev,
> libprotobuf-dev,
> libpulse-dev,
> @@ -158,7 +159,7 @@ Description: Web content engine library for Qt
>  Package: libqt5webenginecore5
>  Architecture: amd64 arm64 armhf i386 mips64el mipsel
>  Multi-Arch: same
> -Provides: qtwebengine-abi-5-15-12
> +Provides: qtwebengine-abi-5-15-13
>  Depends: libqt5webengine-data (= ${source:Version}),
>   sse2-support [i386],
>   ${misc:Depends},
> diff --git a/debian/copyright b/debian/copyright
> index 01fc92e..f8e99e9 100644
> --- a/debian/copyright
> +++ b/debian/copyright
> @@ -120,10 +120,6 @@ Files: src/3rdparty/ninja/*
>  Copyright: 2011-2018 Google Inc.
>  License: Apache-2.0
>  
> -Files: debian/missing-sources/jszip-2.4.0/*
> -Copyright: 2009-2014 Stuart Knightley, David Duponchel, Franz Buchinger, 
> Ant�nio Afonso
> -License: MIT or GPL-3
> -
>  ## BEGIN AUTO GENERATED BLOCK
>  
>  Files: examples/webengine/quicknanobrowser/icons/3rdparty/*
> diff --git a/debian/libqt5webengine5.symbols b/debian/libqt5webengine5.symbols
> index 2dcf53f..a555804 100644
> --- a/debian/libqt5webengine5.symbols
> +++ b/debian/libqt5webengine5.symbols
> @@ -1,6 +1,6 @@
>  # SymbolsHelper-Confirmed: 5.15.5 amd64
>  libQt5WebEngine.so.5 libqt5webengine5 #MINVER#
> -| libqt5webengine5 #MINVER#, qtwebengine-abi-5-15-12
> +| libqt5webengine5 #MINVER#, qtwebengine-abi-5-15-13
>  * Build-Depends-Package: qtwebengine5-dev
>   Qt_5.0@Qt_5.0 5.7.1
>   Qt_5.10@Qt_5.10 5.10.1
> diff --git a/debian/libqt5webenginecore5.symbols 
> b/debian/libqt5webenginecore5.symbols
> index 286c991..58e1462 100644
> --- a/debian/libqt5webenginecore5.symbols
> +++ b/debian/libqt5webenginecore5.symbols
> @@ -1,6 +1,6 @@
>  # SymbolsHelper-Confirmed: 5.15.10 amd64 arm64 armhf i386 mips64el mipsel
>  libQt5WebEngineCore.so.5 libqt5webenginecore5 #MINVER#
> -| libqt5webenginecore5 #MINVER#, qtwebengine-abi-5-15-12
> +| libqt5webenginecore5 #MINVER#, qtwebengine-abi-5-15-13
>  * Build-Depends-Package: qtwebengine5-dev
>   (optional=gold)Qt_5.0@Qt_5.0 5.7.1
>   (optional=gold)Qt_5.10@Qt_5.10 5.10.1
> diff --git a/debian/libqt5webenginewidgets5.symbols 
> b/debian/libqt5webenginewidgets5.symbols
> index ec9760b..4773255 100644
> --- a/debian/libqt5webenginewidgets5.symbols
> +++ 

Bug#1032986: unblock fdroidserver/2.2.1-1

[Hans-Christoph Steiner]

Paul Gevers:

Hi,

On 20-03-2023 17:16, Hans-Christoph Steiner wrote:
I haven't really ever been able to troubleshoot it.  I don't have access to a 
s390x box.  And:


  ~ $ ssh zelenka.debian.org
ssh: connect to host zelenka.debian.org port 22: Connection timed out
  ~ $

That's the only porterbox I could find.


It works for me (now). Can you try again?


I got in.

Also, you don't strictly need to troubleshoot it. Obviously it depends on how 
sure you are it's in your dependency, but you said it quite convinced.


I'm 100% sure its the dependency, and I just confirmed it on the porterbox and 
filed a bug upstream:

https://github.com/androguard/androguard/issues/928

Normally we expect a debdiff attached to an unblock. This is mostly to 
trigger the submitter to look at it and make sure that all changes are 
explained. Can you please elaborate on the changes in ./debian/?

   ^


* zipalign is no longer used by fdroidserver

* these patches were upstreamed:
  debian/patches/0005-handle-str-and-pathlib.Path-in-getvcs.patch was upstreamed
  debian/patches/0006-Fix-openjdk-detection-on-different-architectures.patch
  debian/patches/fix-java-paths-for-non-amd64.patch


The debdiff is large because we were working upstream on 2.2.x as the release 
that is tied to Debian/bookworm (attached).


Sure, I already used some tooling on our side to inspect it. It would help if 
you took a look and see if you spot things worth mentioning (e.g. some patches 
being dropped, I don't want to assume things). To reduce the diff you could 
ignore the tests and translations.


There were changes related to have I mentioned above, like purging dead code 
related to zipalign, buildozer, and bug fixes related to a recent port to use 
pathlib.


Also, there were methods added to support verifying JARs and APKs signed by 
SHA1, which are still considered valid by the Android apksigner tool, though 
Java has dropped support for verifying SHA1 signatures.


The download_repo_index_v2() function was to finalize the whole "index-v2" work 
that was completed in fdroidserver 2.2.x.  That was the one last key missing bit.

Bug#1033267: Upload ccache bookworm fix via testing-proposed-updates?

[Paul Gevers]

Hi,

On 21-03-2023 22:11, Joel Rosdahl wrote:

I think that what made things unclear to me was the "revert" part which just
didn't fit my mental model of how things work. But under "Applying for an
unblock" I now read "[...] revert [...] e.g. by using a
new-version+reallyold-version versioning scheme". I've never seen that
workaround before. So IIUC this suggests using a version like
4.8-2+really4.7.5? Are there other ways since it says "e.g."?


You can use any version you like that's bigger than what's currently in 
the archive. But to prevent epochs you want a version that's lower than 
the next upstream version. The +really scheme is quite common for this 
purpose.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033267: Upload ccache bookworm fix via testing-proposed-updates?

[Joel Rosdahl]

On Tue, Mar 21, 2023, at 20:55, Paul Gevers wrote:
> I'm wondering where you are reading that. The text says: If there are 
> unrelated changes in unstable, we ask you to revert these changes 
> instead of making an upload to testing-proposed-updates.
>
> What's unclear in that phrase?

I think that what made things unclear to me was the "revert" part which just
didn't fit my mental model of how things work. But under "Applying for an
unblock" I now read "[...] revert [...] e.g. by using a
new-version+reallyold-version versioning scheme". I've never seen that
workaround before. So IIUC this suggests using a version like
4.8-2+really4.7.5? Are there other ways since it says "e.g."?

-- Joel

Bug#1033300: xmppc: Error loading keyfile

[Martin Dosch]

Package: xmppc
Version: 0.1.0-2
Severity: normal

Dear Maintainer,

when trying to send a message xmppc is not sending the message but shows 
an error:

>xmppc --jid sen...@example.org --pwd password --mode message 
>recipi...@example.org "Hallo"
>
>Error loading key file: No such file or directory% 

Best regards,
Martin

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

Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 xmppc depends on:
ii  libc6 2.36-8
ii  libglib2.0-0  2.74.6-1
ii  libgpgme111.18.0-3+b1
ii  libstrophe0   0.12.2-1

xmppc recommends no packages.

xmppc suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#980249: wiki.debian.org: 408 Request Timeout editing U-boot/Status

[Thorsten Glaser]

Package: wiki.debian.org
Followup-For: Bug #980249
X-Debbugs-Cc: t...@mirbsd.de

Same for me and any submissions to
https://wiki.debian.org/DebianEvents/de/2023/DebianReunionHamburg#preview
(both Save Changes and Cancel) just time out. Just, for me, it’s more of
a 0-out-of-10-times thing.

This is lynx on bullseye.

I did try nullrouting IPv6 to see if it’s a network thing, but no;
besides reading requests work, albeit slowly.

Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions

[Paul Gevers]

Hi,

On Sun, 08 Jan 2023 00:26:39 +0100 Andreas Beckmann  wrote:

This happens with g++-12 but not with g++-11.
It is fixed in the boost version in experimental.


Any chance for a *targeted* fix in bookworm?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032647: fixed in nvidia-graphics-drivers 530.30.02-1

[Paul Gevers]

Hi Andreas,

On Mon, 13 Mar 2023 23:04:41 + Debian FTP Masters 
 wrote:

Changes:
 nvidia-graphics-drivers (530.30.02-1) experimental; urgency=medium
 .
   * New upstream beta 530.30.02 (2023-02-28).  (Closes: #1032647)


I'm not expecting a targeted fix is reasonably possible for this issue, 
right? Did you intend to ignore it in bookworm from your side?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033299: RM: ltrace [mipsel] -- RoQA; not built anymore as it's useless on mipsel

[Paul Gevers]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ltr...@packages.debian.org
Control: affects -1 + src:ltrace

Dear ftp-masters,

A NMU of ltrace was done to stop building on mipsel because it turned
out to no longer there. The only reverse build dependency of ltrace
has dropped its use on mipsel.

Paul

Bug#1033298: webkit2gtk: please cherry-pick upstream riscv64 build fixes [PATCH]

[Gianfranco Costamagna]

Source: webkit2gtk
Version: 2.40.0-3
tags: patch

Hello, I tried cherry-picking (and rebasing/commenting some parts) of the 
following upstream commits
+ab3a72163b82dabbc3028b877d3e95cdca29739f.patch
+672628fb19da7b1b93ab08eaa288fdb3ef5897d9.patch
+2a0f7a05e87b25c828813ba6945978c51a2610aa.patch
+adae6f1191279924b2af177e3e8ba94ce7516212.patch
+5725527e969ef5d52759e35d253f6ca9b05741d4.patch
+c07cdb6ae80b0847da58a6acb1022b8b3e170073.patch

and I can see that the riscv64 build is now again fine.

You can see the diff here, and the build in Ubuntu
http://launchpadlibrarian.net/656956834/webkit2gtk_2.40.0-2_2.40.0-2ubuntu1.diff.gz

Please if possible consider cherry-picking them in Debian, if not (since 
riscv64 is not release architecture),
I'm pretty sure on next upstream release they won't be needed anymore anyway :)

thanks!

Gianfranco


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033297: xen: CVE-2022-42331 CVE-2022-42332 CVE-2022-42333 CVE-2022-42334

[Salvatore Bonaccorso]

Source: xen
Version: 4.17.0+46-gaaf74a532c-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for xen.

CVE-2022-42331[0]:
| x86: speculative vulnerability in 32bit SYSCALL path Due to an
| oversight in the very original Spectre/Meltdown security work
| (XSA-254), one entrypath performs its speculation-safety actions too
| late. In some configurations, there is an unprotected RET instruction
| which can be attacked with a variety of speculative attacks.


CVE-2022-42332[1]:
| x86 shadow plus log-dirty mode use-after-free In environments where
| host assisted address translation is necessary but Hardware Assisted
| Paging (HAP) is unavailable, Xen will run guests in so called shadow
| mode. Shadow mode maintains a pool of memory used for both shadow page
| tables as well as auxiliary data structures. To migrate or snapshot
| guests, Xen additionally runs them in so called log-dirty mode. The
| data structures needed by the log-dirty tracking are part of
| aformentioned auxiliary data. In order to keep error handling efforts
| within reasonable bounds, for operations which may require memory
| allocations shadow mode logic ensures up front that enough memory is
| available for the worst case requirements. Unfortunately, while page
| table memory is properly accounted for on the code path requiring the
| potential establishing of new shadows, demands by the log-dirty
| infrastructure were not taken into consideration. As a result, just
| established shadow page tables could be freed again immediately, while
| other code is still accessing them on the assumption that they would
| remain allocated.


CVE-2022-42333[2]:
| x86/HVM pinned cache attributes mis-handling T[his CNA information
| record relates to multiple CVEs; the text explains which
| aspects/vulnerabilities correspond to which CVE.] To allow cachability
| control for HVM guests with passed through devices, an interface
| exists to explicitly override defaults which would otherwise be put in
| place. While not exposed to the affected guests themselves, the
| interface specifically exists for domains controlling such guests.
| This interface may therefore be used by not fully privileged entities,
| e.g. qemu running deprivileged in Dom0 or qemu running in a so called
| stub-domain. With this exposure it is an issue that - the number of
| the such controlled regions was unbounded (CVE-2022-42333), -
| installation and removal of such regions was not properly serialized
| (CVE-2022-42334).


CVE-2022-42334[3]:
| x86/HVM pinned cache attributes mis-handling T[his CNA information
| record relates to multiple CVEs; the text explains which
| aspects/vulnerabilities correspond to which CVE.] To allow cachability
| control for HVM guests with passed through devices, an interface
| exists to explicitly override defaults which would otherwise be put in
| place. While not exposed to the affected guests themselves, the
| interface specifically exists for domains controlling such guests.
| This interface may therefore be used by not fully privileged entities,
| e.g. qemu running deprivileged in Dom0 or qemu running in a so called
| stub-domain. With this exposure it is an issue that - the number of
| the such controlled regions was unbounded (CVE-2022-42333), -
| installation and removal of such regions was not properly serialized
| (CVE-2022-42334).


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-42331
https://www.cve.org/CVERecord?id=CVE-2022-42331
[1] https://security-tracker.debian.org/tracker/CVE-2022-42332
https://www.cve.org/CVERecord?id=CVE-2022-42332
[2] https://security-tracker.debian.org/tracker/CVE-2022-42333
https://www.cve.org/CVERecord?id=CVE-2022-42333
[3] https://security-tracker.debian.org/tracker/CVE-2022-42334
https://www.cve.org/CVERecord?id=CVE-2022-42334

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033190: libvisual-plugins: [INTL:de] Updated German Translation

[Eriberto Mota]

> please find attached the newest German translation.

Hi Chris,

Your translation, sent in 2023-03-19 is for 0.4.0+dfsg1-17 revision.

I uploaded a new upstream version (0.4.1) to experimental in
2023-03-12 and the version 0.4.2, also to experimental, today (some
minutes ago). Could you check the last version? You may use tracker[1]
or Salsa[2].

[1] https://tracker.debian.org/pkg/libvisual
[2] https://salsa.debian.org/debian/libvisual

Thanks in advance.

Regards,

Eriberto

Bug#1032989: Liferea 1.14.1-1 segfaults on startup when trying to read gsettings

[Paul Gevers]

Control: forward -1 https://github.com/lwindolf/liferea/issues/1214

Hi Grzegorz,

Thanks for your feedback, much appreciated.

On 21-03-2023 17:48, Grzegorz Szymaszek wrote:

I think
we can set "forwarded" to issue 1214[3] which seems to more clearly
describe this specific crash.


Doing so now.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#980316: Update on packaging corepack

[Paul Gevers]

Hi Pirate,

Thanks for reaching out.

On 20-03-2023 16:44, Pirate Praveen wrote:
I request bookworm-ignore tags for these bugs (as such there is 
no immediate breakage, just unmaintained upstreams for these packages). 


> yarnpkg: 980316,958686, 1002902, 980316
> node-har-validator: 1024575
> node-request: 956423
> node-request-capture-har: 1002901

As the packages in question are key packages, we can't easily remove 
them. Hence adding a bookworm-ignore tag doesn't really change the 
situation in bookworm in any way. Hence, the question is whether fixing 
it now and adding an exception is better or worse than letting the bug 
ship in bookworm. If I understand correctly, than the required change 
would mean a new complex package (corepack) which (again, if I 
understand correctly) is considered also by you as inappropriate at this 
time. If you confirm my understanding, I agree that those bugs can be 
marked bookworm-ignore (I already marked them as bookworm-can-defer, 
which is less strong and less official).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033267: Upload ccache bookworm fix via testing-proposed-updates?

[Paul Gevers]

Control: tag -1 moreinfo

On 20-03-2023 22:15, Joel Rosdahl wrote:

Would it be
appropriate to use testing-proposed-updates for this, as suggested on the freeze
policy page?


I'm wondering where you are reading that. The text says: If there are 
unrelated changes in unstable, we ask you to revert these changes 
instead of making an upload to testing-proposed-updates.


What's unclear in that phrase?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033296: RFP: yabsm -- a btrfs snapshot manager and backup system

[Nicholas Hubbard]

Package: wnpp
Severity: wishlist

* Package name: yabsm
  Version : 3.15.0
  Upstream Author : Nicholas Hubbard (me)
* URL : https://metacpan.org/dist/App-Yabsm
* License : GPL3
  Programming Lang: Perl
  Description : a btrfs snapshot manager and backup system

yabsm is a btrfs snapshot manager and backup system.

yabsm is written in Perl and is available on CPAN as App::Yabsm.

It runs as a daemon that is meant to be started at boot time. An example
systemd service is located in its /examples/yabsmd.service file.

yabsm uses the common ExtUtils::Makemaker, so can be built, tested, installed,
etc, with the usual "perl Makefile.PL; make; make install DESTDIR=/foo"
commands.

Due to the nature of its configuration, it would be useful to users to
install the example configuration file /examples/yabsm.conf.example to
/etc/yabsm.conf.example.

yabsm depends on btrfs-progs, sudo, OpenSSH, and Perl >= 5.34.0.

yabsm packs itself, along with its Perl dependencies, into a single
script. This means that for all packaging intents and purposes yabsm
has zero Perl dependencies. However, the test-suite depends on
Test::Exception, so this module needs to be installed in order to run
its tests.
-- 

Bug#971783: marked as pending in mate-media

[Maxime G.]

Crash again today, here the full backtrace:

(mate-volume-control-status-icon:59859): Gdk-CRITICAL **: 17:44:19.067: 
gdk_window_thaw_toplevel_updates: assertion 
'window->update_and_descendants_freeze_count > 0' failed

(mate-volume-control-status-icon:59859): Gtk-WARNING **: 19:58:21.546: Calling 
gtk_widget_realize() on a widget that isn't inside a toplevel window is not 
going to work very well. Widgets must be inside a toplevel container before 
realizing them.

(mate-volume-control-status-icon:59859): GLib-GObject-CRITICAL **: 
19:58:21.546: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

(mate-volume-control-status-icon:59859): Gdk-CRITICAL **: 19:58:21.546: 
gdk_window_get_scale_factor: assertion 'GDK_IS_WINDOW (window)' failed
**
Gtk:ERROR:../../../gtk/gtkwidget.c:5875:gtk_widget_get_frame_clock: assertion 
failed: (window != NULL)
Bail out! Gtk:ERROR:../../../gtk/gtkwidget.c:5875:gtk_widget_get_frame_clock: 
assertion failed: (window != NULL)

Thread 1 "mate-volume-con" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: Aucun fichier ou dossier de ce type.
(gdb) bt full
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
tid = 
ret = 0
pd = 
old_mask = {__val = {140737340208256}}
ret = 
#1  0x7702ad2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x76fdbef2 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
ret = 
#3  0x76fc6472 in __GI_abort () at ./stdlib/abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, 
sa_mask = {__val = {93824994969568, 140737488343016, 140737339441927, 
93823560581168, 140733193388032, 93824994584288, 0, 93824997363264, 
5024613291978080768, 140737339702443, 18446744073709551488, 11, 
140737340210816, 140737348604049, 140737488343120, 140737340300128}}, sa_flags 
= -150762193, sa_restorer = 0x77a3f133}
#4  0x7719eec8 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x771fee1a in g_assertion_message_expr () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x77969d56 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#7  0x77978a6f in gtk_widget_realize () at 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#8  0x77978c68 in gtk_widget_map () at 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x776ccf80 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7771ee5f in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#11 0x772cf4e0 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x772e8bbf in g_signal_emit_valist () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x772e8dbf in g_signal_emit () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x77978c12 in gtk_widget_map () at 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#15 0x77991d10 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#16 0x772cf5a9 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x772e8bbf in g_signal_emit_valist () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x772e8dbf in g_signal_emit () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x77978c12 in gtk_widget_map () at 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#20 0x7798786b in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#21 0x772cf3b0 in g_closure_invoke () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x772e1d2d in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x772e8bf5 in g_signal_emit_valist () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x772e8dbf in g_signal_emit () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x77972986 in gtk_widget_show () at 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#26 0x77924615 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#27 0x77924811 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#28 0x775277e7 in  () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#29 0x771d619a in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#30 0x771d567f in g_main_context_dispatch () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#31 0x771d5a38 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#32 0x771d5cef in g_main_loop_run () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#33 0x778073e5 in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#34 0x9f33 in main ()
(gdb) c
Continuing.
Couldn't get registers: Aucun processus de ce type.
(gdb) [Thread 0x7fffe6c0 (LWP 67173) exited]
[Thread 0x7517e6c0 (LWP 59863) exited]
[Thread 0x7597f6c0 (LWP 59862) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

The program is not being run.


19 mars 2023 20:24 "Maxime G."  a écrit:

> Hi.
> 
> Issue 

Bug#1033295: cairosvg: CVE-2023-27586: SSRF & DOS vulnerability

[Salvatore Bonaccorso]

Source: cairosvg
Version: 2.5.2-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cairosvg.

CVE-2023-27586[0]:
| CairoSVG is an SVG converter based on Cairo, a 2D graphics library.
| Prior to version 2.7.0, Cairo can send requests to external hosts when
| processing SVG files. A malicious actor could send a specially crafted
| SVG file that allows them to perform a server-side request forgery or
| denial of service. Version 2.7.0 disables CairoSVG's ability to access
| other files online by default.

I am planning to look in the current bullseye version for a security
upload, and can have a look as well for doing a NMU reaching bookworm.

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-27586
https://www.cve.org/CVERecord?id=CVE-2023-27586
[1] https://github.com/Kozea/CairoSVG/security/advisories/GHSA-rwmf-w63j-p7gv
[2] 
https://github.com/Kozea/CairoSVG/commit/12d31c653c0254fa9d9853f66b04ea46e7397255
 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1032554: h2o: FTBFS in testing: [h2o_mruby] in request:/:mruby raised: /tmp/UpqKGDqVnc:19: yeah! (RuntimeError)

[Santiago Vila]

El 21/3/23 a las 19:57, Chris Hofstaedtler escribió:

it seems like its not 100% reproducible (in my builds at least).


Hello. I can reproduce the FTBFS failure in a consistent way
(i.e. not randomly but always) on three different kind of
machines: Self-hosted VMs using kvm, VMs from GCP, and VMs from Hetzner.

If you (or anybody else interested) want to debug this and it only
fails randomly for you, please contact me privately and I can provide
ssh access to a test machine where it happens always.

This is my build history with all the machines combined:

Status: successful  h2o_2.2.5+dfsg2-6.2_amd64-20220430T092608.165Z
Status: successful  h2o_2.2.5+dfsg2-6.2_amd64-20220503T213948.786Z
Status: successful  h2o_2.2.5+dfsg2-6.2_amd64-20220509T175008.611Z
Status: successful  h2o_2.2.5+dfsg2-6.2_amd64-20220509T181241.653Z
Status: successful  h2o_2.2.5+dfsg2-6.2_amd64-20221210T052645.088Z
Status: successful  h2o_2.2.5+dfsg2-6.2_amd64-20221211T062519.570Z
Status: successful  h2o_2.2.5+dfsg2-6.2_amd64-20221212T002906.924Z
Status: successful  h2o_2.2.5+dfsg2-6.2_amd64-20221212T004404.360Z
Status: failed  h2o_2.2.5+dfsg2-6.2_amd64-20230310T080600.446Z
Status: failed  h2o_2.2.5+dfsg2-6.2_amd64-20230310T081557.903Z
Status: failed  h2o_2.2.5+dfsg2-6.2_amd64-20230311T113541.485Z
Status: failed  h2o_2.2.5+dfsg2-6.2_amd64-20230311T215111.404Z
Status: failed  h2o_2.2.5+dfsg2-6.2_amd64-20230314T160532.877Z
Status: failed  h2o_2.2.5+dfsg2-6.2_amd64-20230314T160534.994Z
Status: failed  h2o_2.2.5+dfsg2-6.2_amd64-20230314T160639.774Z
Status: failed  h2o_2.2.5+dfsg2-6.2_amd64-20230314T160726.134Z

One of the things which happened between 20221212 and 20230310 is
that I started to use bookworm as the host OS for my VMs, so it could
be the kernel.

Thanks.

Bug#1033291: autopkgtest-virt-qemu: support booting images created using debvm-create

[Paul Gevers]

Hi Helmut,

On 21-03-2023 19:58, Helmut Grohne wrote:

you may have heared about this shiny new thing called debvm. At least
Paul knows it as he helped me get its autopkgtests pass. Thank you. 


You're welcome. But for the rest of your bug, I'm too busy with Release 
Team work to think about it. If Antonio (or Simon) doesn't handle it, 
please ping this bug after the bookworm release. I'm trying hard to have 
a short freeze.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032554: h2o: FTBFS in testing: [h2o_mruby] in request:/:mruby raised: /tmp/UpqKGDqVnc:19: yeah! (RuntimeError)

[Anton Gladky]

Hi Chris,

thanks for your work! Please go ahead and upload without
a delay. Please push your changes to git and tag it.

Thanks and regards

Anton


Am Di., 21. März 2023 um 19:57 Uhr schrieb Chris Hofstaedtler <
z...@debian.org>:

> Hi,
>
> I will upload a change disabling the failing test to DELAYED/7.
> Please let me know if I should cancel it. Debdiff attached.
>
> The failing mruby test might or might not point to a real problem,
> it seems like its not 100% reproducible (in my builds at least).
> I want src:h2o / libh2o to stay in bookworm so it can be used by
> dnsdist; after bookworm I expect dnsdist upstream to switch away
> from h2o, which itself seems upstream-dead.
>
> Thanks,
> Chris
>
>

Bug#1025453: Is there any update

[graeme vetterlein]

Added to "pipewire"


https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3110


On 20/03/2023 11:07, Dylan Aïssi wrote:

Le sam. 18 mars 2023 à 14:51, graeme vetterlein
  a écrit :

I, for one, have had no sound for the past 4 months. Not personally critical as 
it's an unstable dev system, not main dev machine.


Do you have no sound at all or choppy sound like you said in [1].
Have you tried using speakers not connected via HDMI? I guess it is related
to HDMI connection, can you fill a bug on the upstream bug tracker [2]?

[1]https://bugs.debian.org/1025453#40
[2]https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Bug#1033294: lintian: detect and warn about Python 2 related paths within packages

[Patrice Duroux]

Package: lintian
Version: 2.116.3
Severity: wishlist

Dear Maintainer,

This request is related to the content of the chiark-scripts package:
https://packages.debian.org/sid/all/chiark-scripts/filelist
and there is no lintian notification on this regarding its DPT page:
https://tracker.debian.org/pkg/chiark-utils

Regards,
Patrice

ps: this follows the answer of Paul Wise to my email
https://lists.debian.org/debian-qa/2023/03/msg00029.html




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

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

Versions of packages lintian depends on:
ii  binutils2.40-2
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.21
ii  dpkg-dev1.21.21
ii  file1:5.44-3
ii  gettext 0.21-12
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.13.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.35-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.21
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.003+ds-1
ii  libsereal-encoder-perl  5.003+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.16-1
ii  libwww-perl 6.68-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-5
ii  lzop1.04-2
ii  man-db  2.11.2-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-7
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.1-0.2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1033293: 100% cpu usage for ibus with ardour 1:7.3.0+ds0-1

[Gunnar Hjalmarsson]

Package: ardour
Version: 1:7.3.0+ds0-1
X-Debbugs-CC: enorrm...@gmail.com

Dear maintainer,

This is a forward of the Ubuntu bug 
. After the bug reporter had 
upgraded from Ubuntu 22.10 to 23.04, ibus started to consume a lot of 
cpu when using ardour. The ardour version available in Ubuntu 22.10 is 
1:6.9.0+ds0-2.


It's worth mentioning that the issue is not present with the Ardour 
7.3.0 binary from upstream. That made me wonder if there may be 
something with the packaging — hence this bug report.


--
Rgds,
Gunnar Hjalmarsson

Bug#1033292: unblock: amanda/1:3.5.1-11

[Jose M Calhariz]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ama...@packages.debian.org, jose.calha...@tecnico.ulisboa.pt, 
calha...@debian.org, ns-l...@dsi.ist.utl.pt
Control: affects -1 + src:amanda

Please unblock package amanda


[ Reason ]

The previous version on the fix for CVE-CVE-2022-37705 introduced a
regression that is fixed by this version.  


[ Impact ]

Breaks the use of tar, for backups in some setups, on the affected
clients, i.e., the use of package amanda-client.  The server can not
backup itself, but can backups clients with good amanda client
software,



[ Tests ]

I manually tested the affected version and the fixed version, using a
VM running testing (bookworm) with a amanda compiled for sid.  The
test is to do backup of the server.  The detail that breaks or not is
two options in a dumptype that specifies what program to use for
backup.  When using traditional and old interface for gnutar it
breaks.  When using the new interface it is not affected.

I do not have experience in C language to do a proper review of the
patch that is very simple, but broken in 3.5.1-10.


[ Risks ]

The fix in 3.5.1-10 for the three CVEs are a low risks ones because
user backup is a restricted user.  Only people with previliges already
can login as user backup and try to run the setgid binaries.  For the
people affected by regression 3.5.1-10 can workaround using an older
version on the affected clients.  This bugs does not affect other
packages as amanda-client is a leaf package.



[ 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

[ Other info ]

for name in amanda-client amanda-common amanda-server ; do debdiff 
"/var/cache/apt/archives/${name}_1%3a3.5.1-10_amd64.deb" 
"/root/${name}_3.5.1-11_amd64.deb" ; done

File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: amanda-common (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} libxml-simple-perl, 
perl:any, libc6 (>= 2.34), libglib2.0-0 (>= 2.31.8), libreadline8 (>= 6.0)
Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Suggests: amanda-server (= [-1:3.5.1-10)-] {+1:3.5.1-11)+} | amanda-client (= 
[-1:3.5.1-10)-] {+1:3.5.1-11)+}
Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: amanda-common (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} bsd-mailx | mailx, 
libjson-perl, perl:any, libc6 (>= 2.34), libcurl4 (>= 7.16.2), libglib2.0-0 (>= 
2.31.8)
Installed-Size: [-1076-] {+1077+}
Suggests: amanda-client (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} cpio | mt-st, 
gnuplot
Version: [-1:3.5.1-10-] {+1:3.5.1-11+}




unblock amanda/1:3.5.1-11

Bug#1032937: breaks building cloud images

[Helmut Grohne]

Hi Bastian,

On Sun, Mar 19, 2023 at 12:21:48PM +0100, Bastian Blank wrote:
> This modification of global configuration breaks the building of cloud
> images.  We need a way to install the package, but no services will run
> in the environment, nor is there a systemd-resolved in the same network
> namespace.

That sounds fine to me.

> The build does not exhibit that failure right now, because by chance
> systemd-resolved is the last thing that needs a working resolver before
> the build is finished.  But this is not guaranteed.

On irc, you explained the concrete expectation an I'm giving it here for
reference. 

You expect that you can install systemd-resolved without running any
services or init processes (in a chroot or service-less container) and
then continue using DNS resolution inside that environment.

I content that such an environment is very unusual since you would not
want to install systemd-resolved in a setting where you do not run
services and if you are in bootstrap setting, you can use an external
apt (with access to an external resolv.conf) to download packages.

Even then when assuming that your expectation is well-founded (which I
do not fully agree with), it remains unclear why Michael's proposal
would not solve your problem.

Given the lack of answers on these questions, I think that rc-severity
is not reasonable though I do not have authority on this question.

Helmut

Bug#1033291: autopkgtest-virt-qemu: support booting images created using debvm-create

[Helmut Grohne]

Package: autopkgtest
Version: 5.28
Severity: wishlist
Control: affects -1 + debvm
X-Debbugs-Cc: jo...@debian.org, jspri...@debian.org

Hi Antonio and Paul,

you may have heared about this shiny new thing called debvm. At least
Paul knows it as he helped me get its autopkgtests pass. Thank you. This
is a tool for creating and running ephemeral virtual machines. And
autopkgtest-virt-qemu is a tool for running virtual machine images.
Sounds like these two should somehow fit together. This is exactly what
this bug is about.

debvm has a quite special idea how a virtual machine image looks like:
 * A virtual machine image is a (sparse) raw image.
 * It contains an ext2 (or later) filesystem.
 * The filesystem has a non-empty filesystem label.
 * The filesystem contains Linux kernel and initrd, but not a
   bootloader.

This makes some things very easy:
 * Since qemu becomes the actual bootloader, this removes a lot of
   architecture-specific issues and one can boot all architectures
   in a uniform way.
 * A raw image can easily be resized later
 * Generating such an image can be done entirely without root and this
   implies that running autopkgtests in qemu can be done entirely
   without root privileges.

There also are downsides:
 * You cannot test bootloaders with this (obviously).
 * You cannot test stuff that requires rebooting into an updated initrd
   or Linux kernel.
 * You cannot use a non-ext filesystem.

So this is not what everyone wants, but probably what some people want.

It also isn't like every image created by debvm-create just works. You
do need some options:

debvm-create -o autopkgtest.ext4 -z 10G -- \
--include python3,linux-image-generic \
--customize-hook='systemctl --root="$1" enable serial-getty@ttyS1 
serial-getty@hvc1' \
--customize-hook='sed "s/^deb /deb-src /" "$1/etc/apt/sources.list" > 
"$1/etc/apt/sources.list.d/src.list"' \
--customize-hook='APT_CONFIG=$MMDEBSTRAP_APT_CONFIG apt-get update'

We include python3 here, because autopkgtest-virt-qemu says so. We also
include a generic kernel image, because debvm prefers a cloud image,
which lacks support for the 9p filesystem used by autopkgtest-virt-qemu
(see #1027174). Then we must enable the additional serial gettys. While
systemd has a getty generator, this generator cannot enable the consoles
that autopkgtest-virt-qemu needs. autopkgtest-virt-qemu really wants
boot messages one ttyS0 (or hvc0), so this is what we must pass as
console= boot parameter. At the same time it wants a root shell on hvc1,
which is not considered by the generator even when passing
systemd.getty_auto, so we have to enable these at image construction
time. By default debvm will perform a root autologin on serial gettys,
so as soon as we enable them, they'll do the right thing for
autopkgtest-virt-qemu. And finally, we need to add deb-src lines as
debvm doesn't add them by default.

Once we have this image, we need to teach autopkgtest this strange boot
protocol of debvm and this is what this particular bug report is about.
I'm attaching a patch to autopkgtest that adds the --boot=vmlinux value
to implement this boot protocol as well as adding support for
--boot=auto. And with this patch, you can say

autopkgtest hello -- qemu autopkgtest.ext4

and have things just work.

What do you think? Do you like the feature idea? Do you like the patch?
This is a first iteration and probably not the last, but it definitely
should be good to start the conversation.

Helmut
diff -Nru autopkgtest-5.28/debian/changelog 
autopkgtest-5.28+nmu1/debian/changelog
--- autopkgtest-5.28/debian/changelog   2023-01-30 19:29:59.0 +0100
+++ autopkgtest-5.28+nmu1/debian/changelog  2023-03-21 13:52:17.0 
+0100
@@ -1,3 +1,10 @@
+autopkgtest (5.28+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * virt-qemu: Support images created by debvm-create. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 21 Mar 2023 13:52:17 +0100
+
 autopkgtest (5.28) unstable; urgency=medium
 
   [ Jochen Sprickerhof ]
diff -Nru autopkgtest-5.28/lib/autopkgtest_qemu.py 
autopkgtest-5.28+nmu1/lib/autopkgtest_qemu.py
--- autopkgtest-5.28/lib/autopkgtest_qemu.py2023-01-30 19:29:59.0 
+0100
+++ autopkgtest-5.28+nmu1/lib/autopkgtest_qemu.py   2023-03-21 
13:52:17.0 +0100
@@ -36,6 +36,7 @@
 
 import errno
 import fcntl
+import itertools
 import json
 import os
 import re
@@ -46,6 +47,7 @@
 import tempfile
 import time
 from typing import (
+BinaryIO,
 List,
 Optional,
 Sequence,
@@ -124,6 +126,52 @@
 return []
 
 
+def call_debugfs(
+image: str, command: str, stdout: Optional[BinaryIO] = None
+) -> subprocess.CompletedProcess:
+result = subprocess.run(
+["/sbin/debugfs", "-R", command, image],
+stdout=stdout or subprocess.PIPE,
+stderr=subprocess.PIPE,
+)
+if result.returncode:
+raise ValueError(
+"command %r exited %d and stderr %r" 

Bug#1032554: h2o: FTBFS in testing: [h2o_mruby] in request:/:mruby raised: /tmp/UpqKGDqVnc:19: yeah! (RuntimeError)

[Chris Hofstaedtler]

Hi,

I will upload a change disabling the failing test to DELAYED/7.
Please let me know if I should cancel it. Debdiff attached.

The failing mruby test might or might not point to a real problem,
it seems like its not 100% reproducible (in my builds at least).
I want src:h2o / libh2o to stay in bookworm so it can be used by
dnsdist; after bookworm I expect dnsdist upstream to switch away
from h2o, which itself seems upstream-dead.

Thanks,
Chris

diff -Nru h2o-2.2.5+dfsg2/debian/changelog h2o-2.2.5+dfsg2/debian/changelog
--- h2o-2.2.5+dfsg2/debian/changelog2022-04-13 20:41:51.0 +
+++ h2o-2.2.5+dfsg2/debian/changelog2023-03-21 12:40:38.0 +
@@ -1,3 +1,11 @@
+h2o (2.2.5+dfsg2-7) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove VCS tags from picohttpparser source files
+  * Disable failing mruby test (Closes: #1032554)
+
+ -- Chris Hofstaedtler   Tue, 21 Mar 2023 12:40:38 +
+
 h2o (2.2.5+dfsg2-6.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru h2o-2.2.5+dfsg2/debian/patches/picohttpparser-vcstags.patch 
h2o-2.2.5+dfsg2/debian/patches/picohttpparser-vcstags.patch
--- h2o-2.2.5+dfsg2/debian/patches/picohttpparser-vcstags.patch 1970-01-01 
00:00:00.0 +
+++ h2o-2.2.5+dfsg2/debian/patches/picohttpparser-vcstags.patch 2023-03-21 
12:40:38.0 +
@@ -0,0 +1,25 @@
+Remove expanded $Id$ strings, which seem to break building
+using h2o_2.2.5+dfsg2.orig.tar.xz from the archive.
+
+--- h2o-2.2.5+dfsg2.orig/deps/picohttpparser/picohttpparser.c
 h2o-2.2.5+dfsg2/deps/picohttpparser/picohttpparser.c
+@@ -36,7 +36,7 @@
+ #endif
+ #include "picohttpparser.h"
+ 
+-/* $Id: a707070d11d499609f99d09f97535642cec910a8 $ */
++/* $Id$ */
+ 
+ #if __GNUC__ >= 3
+ #define likely(x) __builtin_expect(!!(x), 1)
+--- h2o-2.2.5+dfsg2.orig/deps/picohttpparser/picohttpparser.h
 h2o-2.2.5+dfsg2/deps/picohttpparser/picohttpparser.h
+@@ -33,7 +33,7 @@
+ #define ssize_t intptr_t
+ #endif
+ 
+-/* $Id: 67fd3ee74103ada60258d8a16e868f483abcca87 $ */
++/* $Id$ */
+ 
+ #ifdef __cplusplus
+ extern "C" {
diff -Nru h2o-2.2.5+dfsg2/debian/patches/series 
h2o-2.2.5+dfsg2/debian/patches/series
--- h2o-2.2.5+dfsg2/debian/patches/series   2022-04-13 20:41:51.0 
+
+++ h2o-2.2.5+dfsg2/debian/patches/series   2023-03-21 12:40:38.0 
+
@@ -5,3 +5,4 @@
 link-libh2o-with-wslay.patch
 fix_CVE-2019_1.patch
 mruby_fileutils_no_verbose.patch
+picohttpparser-vcstags.patch
diff -Nru h2o-2.2.5+dfsg2/debian/rules h2o-2.2.5+dfsg2/debian/rules
--- h2o-2.2.5+dfsg2/debian/rules2022-04-13 20:41:51.0 +
+++ h2o-2.2.5+dfsg2/debian/rules2023-03-21 12:40:38.0 +
@@ -7,7 +7,7 @@
 # Disable the following tests as they require network access
 BAD_TESTS=10http1client 50access-log 50reverse-proxy-added-headers 
50reverse-proxy-drop-headers 50reverse-proxy-https 
50reverse-proxy-session-resumption 80invalid-h2-chars-in-headers 40server-push 
50mruby-acl 80issues595 40max-connections 40session-ticket
 # Disable test which fails with newer mruby
-BAD_TESTS += 50mruby-htpasswd
+BAD_TESTS += 50mruby-htpasswd 50mruby-http-request
 
 %:
dh $@

Bug#1025453: Is there any update

[graeme vetterlein]

Indeed it was simply choppy. I (personally) have no sound because I had 
to turn it off, it was unlistenable.


I don't have other "speakers" but I plugged in a set of headphones, I 
assume that's equivalent?

Anyhow sound from the headphones was fine. (tested with mpv and Lxmusic)



On 20/03/2023 11:07, Dylan Aïssi wrote:

Le sam. 18 mars 2023 à 14:51, graeme vetterlein
 a écrit :

I, for one, have had no sound for the past 4 months. Not personally critical as 
it's an unstable dev system, not main dev machine.


Do you have no sound at all or choppy sound like you said in [1].
Have you tried using speakers not connected via HDMI? I guess it is related
to HDMI connection, can you fill a bug on the upstream bug tracker [2]?

[1] https://bugs.debian.org/1025453#40
[2] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Bug#1014544: Please update privacybadger to 2023.1.31 in Debian unstable

[Amr Ibrahim]

Hello,

Please update privacybadger to 2023.1.31 in Debian unstable.

https://github.com/EFForg/privacybadger/releases

Best,
Amr

Bug#1033289: fprintd: Configure Fingerprint Authentication > Kali Linux KDE - after inserting root password fingerprint chip disconnects

[Andrei Mungiu]

Package: fprintd
Version: 1.94.2-2
Severity: important
X-Debbugs-Cc: mungiuand...@gmail.com

Dear Maintainer,



   * What led up to the situation?
  I checked how to enable the fingerprint authentication functionality on 
linux, so that I may use it isntead of inserting a password when I loging and 
hopefully when the terminal asks for the password.

  My fingerprint chip is: Bus 003 Device 002: ID 04f3:0c4b Elan 
Microelectronics Corp. ELAN:Fingerprint
  My machine is: Lenovo ThinkPad E15 (Ryzen 7, AMD Radeon Graphics)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  1 - installed fprintd & libpam-fprintd (and enabled fingerprint in PAM 
configuration menu)
  2 - restarted laptop
  3 - opened "Users" menu
  4 - selected user
  5 - clicked on the now available (after fprintd installation) menu button 
called: "Configure Fingerprint Authentication..."
  6 - clicked "add"
  7 - selected right index finger
  8 - inserted root password
  9 - scanned the finger succesfully
  10- ERROR appears inside the fingerprint app screen: "the device has 
disconnected"
   * What was the outcome of this action?
  See the above step by step description.
   * What outcome did you expect instead?
  I expected the fingerprint to be registered and for Kali Linux to know 
accept my fingerprint.




-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2023.1
Codename:   kali-rolling
Architecture: x86_64

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

Versions of packages fprintd depends on:
ii  dbus   1.14.6-1
ii  libc6  2.36-8
ii  libfprint-2-2  1:1.94.5-1
ii  libglib2.0-0   2.74.6-1
ii  libpolkit-gobject-1-0  122-3+kali1
ii  policykit-1122-3+kali1

fprintd recommends no packages.

fprintd suggests no packages.

-- no debconf information

*** /tmp/reportbug-fprintd-20230321180415-927zgr6q
Subject: fprintd: Configure Fingerprint Authentication > Kali Linux KDE - after 
inserting root password fingerprint chip disconnects
Package: fprintd
X-Debbugs-Cc: mungiuand...@gmail.com
Version: 1.94.2-2
Severity: important

Dear Maintainer,



   * What led up to the situation?
  I checked how to enable the fingerprint authentication functionality on 
linux, so that I may use it isntead of inserting a password when I loging and 
hopefully when the terminal asks for the password.

  My fingerprint chip is: Bus 003 Device 002: ID 04f3:0c4b Elan 
Microelectronics Corp. ELAN:Fingerprint
  My machine is: Lenovo ThinkPad E15 (Ryzen 7, AMD Radeon Graphics)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  1 - installed fprintd & libpam-fprintd (and enabled fingerprint in PAM 
configuration menu)
  2 - restarted laptop
  3 - opened "Users" menu
  4 - selected user
  5 - clicked on the now available (after fprintd installation) menu button 
called: "Configure Fingerprint Authentication..."
  6 - clicked "add"
  7 - selected right index finger
  8 - inserted root password
  9 - scanned the finger succesfully
  10- ERROR appears inside the fingerprint app screen: "the device has 
disconnected"
   * What was the outcome of this action?
  See the above step by step description.
   * What outcome did you expect instead?
  I expected the fingerprint to be registered and for Kali Linux to know 
accept my fingerprint.




-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2023.1
Codename:   kali-rolling
Architecture: x86_64

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

Versions of packages fprintd depends on:
ii  dbus   1.14.6-1
ii  libc6  2.36-8
ii  libfprint-2-2  1:1.94.5-1
ii  libglib2.0-0   2.74.6-1
ii  libpolkit-gobject-1-0  122-3+kali1
ii  policykit-1122-3+kali1

fprintd recommends no packages.

fprintd suggests no packages.

-- no debconf information

Bug#1018061: pads: segfault at 3a ip

[Tim McConnell]

Hi Bernhard, 
I believe the patch has fixed the issue. I haven't seen any messages
about psad since installing the patch. 
Thanks so much for the fix & patience with me. 

-- 
Tim McConnell 


On Wed, 2023-03-15 at 12:10 +0100, Bernhard Übelacker wrote:
> Am 26.02.23 um 16:47 schrieb Tim McConnell:
> 
> > Hi Bernhard,
> > The delay is fine, I'm sure it takes a minute to figure it out ;-)
> > and
> > no I didn't have anything other than defaults for GDB set. I'm not
> > a
> > programmer so I don't know all the tricks to GDB or when is best  
> > to
> > use them. With that said, how would I go about installing /testing
> > the
> > patch you provide? I'm happy to test it out for you, I just need
> > the
> > knowledge of how to.
> > Thanks!
> > 
> 
> 
> Hello Tim,
> if you are fine with installing a bunch of build dependencies
> you could use following steps to rebuild the package with the patch.
> 
> As root:
> # apt build-dep pads
> 
> As user:
> $ mkdir -p source/pads
> 
> Put attached patch to the new directory and continue as user:
> $ cd   source/pads
> $ apt source pads
> $ cd pads-1.2/
> $ patch -p1 < ../pads_print_arp_asset_initialize.patch
> $ dpkg-buildpackage -b
> 
> As root (with the directory adjusted to your user):
> # dpkg -i /home/benutzer/source/pads/{pads_1.2-14_amd64.deb,pads-
> dbgsym_1.2-14_amd64.deb}
> 
> 
> And then see if it still works as expected and see
> if the crash happens again.
> 
> Kind regards,
> Bernhard

Bug#1032989: Liferea 1.14.1-1 segfaults on startup when trying to read gsettings

[Grzegorz Szymaszek]

Hi Paul,

On Fri, Mar 17, 2023 at 09:49:31PM +0100, Paul Gevers wrote:
> It seems upstream is on to something:
> https://github.com/lwindolf/liferea/issues/1212#issuecomment-1472904260

Upstream issue 1212 is now closed and version 1.14.2 is released. I've
built and tested two Liferea Debian packages:
 (1) the same as git tag debian/1.14.1-1,
 (2) the same as above, but with all upstream changes between 1.14.1 and
 1.14.2[1] applied (except commit
 f04dae4ee0f54ac7ec630f35548aed4f31e2c5dc[2] which would cause the
 build to fail) as package patches, so technically version 1.14.2.

Both segfault in the same place as I have originally reported. I think
we can set "forwarded" to issue 1214[3] which seems to more clearly
describe this specific crash.

[1]: https://github.com/lwindolf/liferea/compare/v1.14.1...v1.14.2
[2]: 
https://github.com/lwindolf/liferea/commit/f04dae4ee0f54ac7ec630f35548aed4f31e2c5dc
[3]: https://github.com/lwindolf/liferea/issues/1214

Thanks!

-- 
Grzegorz


signature.asc
Description: PGP signature

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Cyril Brulebois]

Frédéric Bonnard  (2023-03-17):
> > It would be helpful to confirm which exact kernel version is getting
> > used in both cases (last 6.1.0-4 working, and first 6.1.0-5 not
> > working), then look at the changes between both versions, in src:linux
> > (and resulting udebs).
> 
> From linux changelog (
> https://tracker.debian.org/media/packages/l/linux/changelog-6.1.15-1 )
> and http://snapshot.debian.org/package/linux/,
> I see :
> 6.1.11-1 -> Bump ABI to 4 
> http://snapshot.debian.org/archive/debian/20230211T151657Z/
> 6.1.12-1 -> Bump ABI to 5 
> http://snapshot.debian.org/archive/debian/20230217T033139Z/
> 
> and tested from those (rebuilding the same d-i source with the 2 kernels
> from snapshot.d.o . 6.1.12-1 clearly doesn't work.
> I had already have a look at the kernel changelog but missed that one :
> ---
> linux (6.1.12-1) unstable; urgency=medium
> ...
> - of: Make OF framebuffer device names unique
> ...
> ---
> 
> I recompiled the kernel deb source without that one (
> https://github.com/torvalds/linux/commit/241d2fb56a18473af5f2ff0d512992a996eb64dd.patch
> ) and the mini.iso actually made it to the menu... and given the
> behaviour, a framebuffer actually makes sense.
> 
> Now, that patch does not harm when the kernel is installed on disk.
> But it does in the installer...

Adding the kernel team to the loop: d-i regression on ppc64el.


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


signature.asc
Description: PGP signature

Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312

[Cyril Brulebois]

Cyril Brulebois  (2023-03-08):
> I should be able to share a small(-ish) ISO for you to test, so that
> you can check whether touchpad support becomes available. Same story
> as before: that'd be just about booting the installer, reaching the
> language selection screen, and letting us know whether the touchpad's
> working.

Test ISO (without any firmware, just a fresh minimal installer build) 
available here for you to check whether that helps the touchpad become
alive:
  https://people.debian.org/~kibi/bug-1032136/


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


signature.asc
Description: PGP signature

Bug#1032136: installation-reports: Touchpad does not work during a graphical installation

[Cyril Brulebois]

Cyril Brulebois  (2023-02-28):
> Caleb McKay  (2023-02-28):
> > Here ya go! If you need anything, just let me know.
> 
> OK, so the input device is definitely not seen in d-i.
> 
> Let me guess, `lsmod|grep lpss` returns stuff in your installed system?

[…]

Test ISO (without any firmware, just a fresh minimal installer build)
available here for you to check whether that helps the touchpad become
alive:
  https://people.debian.org/~kibi/bug-1032136/


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


signature.asc
Description: PGP signature

Bug#1033230: webkit2gtk: version 2.39.90-1 lost its libgles2 runtime dependency

[Alberto Garcia]

On Mon, Mar 20, 2023 at 01:29:51PM +0100, Gianfranco Costamagna wrote:

> Hello, for some reasons, now webkit2gtk is not linking anymore
> libGLESv2.so.2 causing surf to fail autopkgtests on arm64 and armhf

Hmmm... the reason is that this is now handled via libepoxy, which
opens libGLESv2.so.2 on runtime using dlopen().

I think that I'll add the dependencies manually for now, but I wonder
if libepoxy should depend on those libraries instead?

Berto

Bug#950174: Fwd: 950174 resolved!

[pipe...@yahoo.it]

HI
after much research and knowing that the problem does not arise on new
installations,
I searched for all the old configuration files
In the X11 folder /etc/X11/Xsession.d/ there were files from 2010 and
trying to associate each file with the package they were installed from..
 I found the file
/etc/X11/Xsession.d/20desktop-profiles_activateDesktopProfiles
belonging to the package
desktop-profiles

I fixed it by deleting the outdated package desktop-profiles and finally it
works without errors and without slowdowns!
I hope it's usefullly

thanks a lot !
Gianluca

Bug#896101: Please switch Suggests from libvte9 to libvte-2.91-0

[Thomas Uhle]

Package: geany
Followup-For: Bug #896101

Dear maintainers,

could you please consider to finally merge Laurent's patch?

Geany tries to load libvte-2.91.so.0 or libvte-2.91.so since version 1.29 
if it is built with GTK 3, so in Debian since version 1.32-2.  That is why 
this is not just a cosmetical issue and an annoying thing for everyone who 
does not already have installed libvte-2.91-0 because of gnome-terminal or 
another (terminal) application using VTE.


It would be good if debian/control would be fixed before the release of 
Debian bookworm.


Thank you in advance!

Best regards,

Thomas Uhle

Bug#1032563: nvidia-driver 525.89.02 fails to initialize with Quadro M2200M

[Matvey Soloviev]

I did not have nvidia-open-kernel-dkms installed when performing those
experiments (and never seem to have had it installed on my system, as there
is no rc record in dpkg). I believe that I also tested it with the 530
driver at the time, with the same results.

Do you expect different results with the tesla-470 driver? I'm fairly sure
that the 470 series of the standard driver worked for me, as 510.108.03-1,
which I am using right now, does (though I'm not sure if hibernation was
already broken in 470), but the lack of some features that were added
between then and 510 seems likely to cause compatibility issues at this
point.

Best wishes,
Matvey

On Tue, 21 Mar 2023 at 14:34, Andreas Beckmann  wrote:

> Control: tag -1 moreinfo upstream
>
> On 09/03/2023 00.20, Matvey Soloviev wrote:
> > Package: nvidia-driver
> > Version: 525.89.02-1
> >
> > Nvidia drivers newer than the 510 series fail to load on my system, which
> > is a Lenovo Thinkpad P51 with a Quadro M2200 GPU, with BIOS 1.60 and ECP
> > 1.10. I have encountered this bug with driver versions 515, 520 and now
> the
> > 525 that landed in testing, as well as with a version of 525 installed
> > using nvidia's official installer, and kernels including 6.0.7 and 6.2.2
> > from xanmod and 6.1.0-5-amd64 from Debian's official repository. My
> system
> > is a mixture of packages from stable and testing, with libc6=2.36-7.
> Driver
> > version 510.108.03-1 works (but is unstable in sleep and broken in
> > hibernation).
>
> Do you have by chance installed nvidia-open-kernel-dkms instead of
> nvidia-kernel-dkms? In that case, please switch to the proprietary
> module (nvidia-kernel-dkms).
>
> You could also try with the 530 driver from experimental.
>
> You could also try the tesla-470 driver.
>
>
> Andreas
>

Bug#1033288: Build Problems with nvidia-fs-dkms on kernel version 6.1.20

[Jannick Loch]

Package: nvidia-fs-dkms
Version: 2.13.5~11.8.0-2

Durimng my update routine, i notice that i have problems with building the 
nvidia-fs module on the newest linux kernel package
6.1.20. Dkms said that there was an BUILD_EXCLUSIVE directive which does not 
match this kernel/arch/config. If i remove this directive by comment it out,
i get following error log in make.log:
DKMS make.log for nvidia-fs-2.13 for kernel 6.1.0-7-amd64 (x86_64)
Di 21. Mär 16:37:07 CET 2023
./configure 6.1.0-7-amd64
Picking NVIDIA driver sources from 
NVIDIA_SRC_DIR=/usr/src/nvidia-current-525.89.02/nvidia-peermem. If that does 
not meet your expectation, you might have a stale driver still around and that 
might cause problems.
chmod +x ./create_nv.symvers.sh
./create_nv.symvers.sh 6.1.0-7-amd64
Getting symbol versions from 
/lib/modules/6.1.0-7-amd64/updates/dkms/nvidia-current.ko ...
Created: /var/lib/dkms/nvidia-fs/2.13/build/nv.symvers
cat nv.symvers >> Module.symvers
checking if uaccess.h access_ok has 3 parameters... no
checking if uaccess.h access_ok has 2 parameters... yes
Checking if blkdev.h has blk_rq_payload_bytes... yes
Checking if fs.h has call_read_iter and call_write_iter... yes
Checking if fs.h has filemap_range_has_page... no
Checking if kiocb structue has ki_complete field... yes
Checking if vm_fault_t exist in mm_types.h... yes
Checking if IOCB_HIPRI flag exists in fs.h... yes
Checking if enum PCIE_SPEED_32_0GT exists in pci.h... yes
Checking if atomic64_t counter is of type long... no
Checking if RQF_COPY_USER is present or not... no
Checking if dma_drain_size and dma_drain_needed are present in struct 
request_queue... no
Checking if struct proc_ops is present or not ... yes
Checking if split is present in vm_operations_struct or not ... no
Checking if mremap in vm_operations_struct has one parameter... yes
Checking if mremap in vm_operations_struct has two parameters... no
Checking if symbol module_mutex is present... no
Checking if blk-integrity.h is present... yes
KCPPFLAGS="-DCONFIG_NVFS_STATS=y -DGDS_VERSION=1.4.0.29 
-DNVFS_ENABLE_KERN_RDMA_SUPPORT -DNVFS_BATCH_SUPPORT=y" CONFIG_NVFS_BATCH_SUPPORT=y 
CONFIG_NVFS_STATS=y make -j4 -C /lib/modules/6.1.0-7-amd64/build  M=$PWD modules
make[1]: warning: -j4 forced in submake: resetting jobserver mode.
make[1]: Verzeichnis „/usr/src/linux-headers-6.1.0-7-amd64“ wird betreten
  CC [M]  /var/lib/dkms/nvidia-fs/2.13/build/nvfs-core.o
  CC [M]  /var/lib/dkms/nvidia-fs/2.13/build/nvfs-dma.o
  CC [M]  /var/lib/dkms/nvidia-fs/2.13/build/nvfs-mmap.o
  CC [M]  /var/lib/dkms/nvidia-fs/2.13/build/nvfs-pci.o
/var/lib/dkms/nvidia-fs/2.13/build/nvfs-core.c:853:5: error: conflicting types 
for ‘rw_verify_area’; have ‘int(int,  struct file *, char *, const loff_t *, 
size_t)’ {aka ‘int(int,  struct file *, char *, const long long int *, long 
unsigned int)’}
  853 | int rw_verify_area(int read_write, struct file *file,
  | ^~
In file included from 
/usr/src/linux-headers-6.1.0-7-common/include/linux/huge_mm.h:8,
 from 
/usr/src/linux-headers-6.1.0-7-common/include/linux/mm.h:743,
 from /var/lib/dkms/nvidia-fs/2.13/build/nvfs-core.c:34:
/usr/src/linux-headers-6.1.0-7-common/include/linux/fs.h:3200:5: note: previous 
declaration of ‘rw_verify_area’ with type ‘int(int,  struct file *, const 
loff_t *, size_t)’ {aka ‘int(int,  struct file *, const long long int *, long 
unsigned int)’}
 3200 | int rw_verify_area(int, struct file *, const loff_t *, size_t);
  | ^~
/var/lib/dkms/nvidia-fs/2.13/build/nvfs-core.c: In function ‘nvfs_direct_io’:
/var/lib/dkms/nvidia-fs/2.13/build/nvfs-core.c:932:44: error: assignment to 
‘void (*)(struct kiocb *, long int)’ from incompatible pointer type ‘void 
(*)(struct kiocb *, long int,  long int)’ [-Werror=incompatible-pointer-types]
  932 | nvfsio->common.ki_complete = nvfs_io_complete;
  |^
/var/lib/dkms/nvidia-fs/2.13/build/nvfs-mmap.c: In function 
‘nvfs_mgroup_mmap_internal’:
/var/lib/dkms/nvidia-fs/2.13/build/nvfs-mmap.c:618:67: error: implicit 
declaration of function ‘prandom_u32’; did you mean ‘prandom_u32_max’? 
[-Werror=implicit-function-declaration]
  618 | base_index = NVFS_MIN_BASE_INDEX + (unsigned 
long)prandom_u32();
  |   
^~~
  |   
prandom_u32_max
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-6.1.0-7-common/scripts/Makefile.build:255: 
/var/lib/dkms/nvidia-fs/2.13/build/nvfs-core.o] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet
cc1: some warnings being treated as errors
make[2]: *** [/usr/src/linux-headers-6.1.0-7-common/scripts/Makefile.build:255: 
/var/lib/dkms/nvidia-fs/2.13/build/nvfs-mmap.o] Fehler 1
make[1]: *** [/usr/src/linux-headers-6.1.0-7-common/Makefile:2037: 

Bug#1033287: Apache 2.4.56 Upgrade changes PHP $_SERVER['REQUEST_URI'] to include full URL

[Jon Cutting]

Package: php7.4-cgi
Version: 7.4.33-1+deb11u3

The $_SERVER['REQUEST_URI'] variable differs between Apache version 
2.4.56 and earlier versions of Apache. When viewed on Apache 2.4.56 the 
variable contains the full URL including protocol of the request target, 
e.g. https://www.example.com/path/to/resource. On earlier versions of 
Apache, the variable would contain /path/to/resource.


Steps to replicate:

Install apache2, php7.4-cgi and enable Apache proxy_fcgi
Add info.php to /var/www/html with the contents http://{server}/info.php

Expected behaviour

$_SERVER['REQUEST_URL'] contains /info.php

Actual behaviour

$_SERVER['REQUEST_URL'] contains http://{server}/info.php



CONFIDENTIALITY NOTICE: 
This Email is confidential and may also be privileged. If you are not the

intended recipient, please notify the sender IMMEDIATELY; you should not
copy the email, use it for any purpose nor disclose its contents to any
other person. 

GENERAL STATEMENT: 
Any statements made, or intentions expressed, within this communication may

not necessarily reflect the views of the Company. Be advised that no content
herein may be held binding upon the Company or any associated company unless
confirmed by the issuance of a formal contractual document or Purchase
Order. 

Registered Office: 
38 Anson Road 
Martlesham Heath 
Ipswich 
Suffolk 
IP5 3RG 

Company Registration: 4426731 
VAT: GB 834 5358 17

Bug#1033286: systemsettings crashes when trying to access the Flatpak permission module

[Patrick Franz]

Package: systemsettings
Version: 4:5.27.2-1
Severity: important
X-Debbugs-Cc: delta...@debian.org

Dear Maintainer,

systemsettings crashes when trying to access the Flatpak Permission module.
This is due to the flatpak package not being required by the Permission
module. Installing the flatpak package resolves the issue.


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

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

Versions of packages systemsettings depends on:
ii  kio 5.103.0-1
ii  kpackagetool5   5.103.0-1
ii  libc6   2.36-8
ii  libkf5activities5   5.103.0-1
ii  libkf5auth5 5.103.0-1
ii  libkf5authcore5 5.103.0-1
ii  libkf5completion5   5.103.0-1
ii  libkf5configcore5   5.103.0-1
ii  libkf5configgui55.103.0-1
ii  libkf5configwidgets55.103.0-1
ii  libkf5coreaddons5   5.103.0-1
ii  libkf5crash55.103.0-1
ii  libkf5dbusaddons5   5.103.0-1
ii  libkf5i18n5 5.103.0-1
ii  libkf5iconthemes5   5.103.0-1
ii  libkf5itemmodels5   5.103.0-1
ii  libkf5itemviews55.103.0-1
ii  libkf5kcmutils5 5.103.0-3
ii  libkf5kiocore5  5.103.0-1
ii  libkf5kiogui5   5.103.0-1
ii  libkf5kiowidgets5   5.103.0-1
ii  libkf5kirigami2-5   5.103.0-1
ii  libkf5notifications55.103.0-1
ii  libkf5package5  5.103.0-1
ii  libkf5runner5   5.103.0-1
ii  libkf5service-bin   5.103.0-1
ii  libkf5service5  5.103.0-1
ii  libkf5widgetsaddons55.103.0-1
ii  libkf5windowsystem5 5.103.0-1
ii  libkf5xmlgui5   5.103.0-1
ii  libkworkspace5-54:5.27.2-1
ii  libqt5core5a5.15.8+dfsg-3
ii  libqt5gui5  5.15.8+dfsg-3
ii  libqt5qml5  5.15.8+dfsg-3
ii  libqt5quick55.15.8+dfsg-3
ii  libqt5quickwidgets5 5.15.8+dfsg-3
ii  libqt5widgets5  5.15.8+dfsg-3
ii  libstdc++6  12.2.0-14
ii  qml-module-org-kde-kcm  5.103.0-1
ii  qml-module-org-kde-kcmutils 5.103.0-3
ii  qml-module-org-kde-kirigami25.103.0-1
ii  qml-module-org-kde-kitemmodels  5.103.0-1
ii  qml-module-org-kde-newstuff 5.103.0-1
ii  qml-module-qtquick-controls 5.15.8-2
ii  qml-module-qtquick-layouts  5.15.8+dfsg-3
ii  qml-module-qtquick-shapes   5.15.8+dfsg-3
ii  qml-module-qtquick2 5.15.8+dfsg-3

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information

Bug#1032547: facet-analyser: FTBFS in testing: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j8 test ARGS\+=--verbose ARGS\+=-j8 returned exit code 2

[Roland Mas]

Le 08/03/2023 à 21:28, Lucas Nussbaum a écrit :

Source: facet-analyser
Version: 0.0~git20221121142040.6be10b8+ds1-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230307 ftbfs-bookworm

Hi,

During a rebuild of all packages in testing (bookworm), your package failed
to build on amd64.


Hi,

I can't seem to reproduce this FTBFS with a bookworm cowbuilder. The 
relevant part of the log (where the error used to be):


2/4 Test #4: basicExampleTest01 ...   Passed    2.04 sec
2: Traceback (most recent call last):
2:   File 
"/build/facet-analyser-0.0~git20221121142040.6be10b8+ds1/scripts/pvsm2x3d.py", 
line 73, in 

2: main()
2:   File 
"/build/facet-analyser-0.0~git20221121142040.6be10b8+ds1/scripts/pvsm2x3d.py", 
line 57, in main

2: exporters= pvs.servermanager.createModule("exporters")
2:    ^^
2: AttributeError: module 'paraview.servermanager' has no attribute 
'createModule'. Did you mean: 'updateModules'?

1: Traceback (most recent call last):
1:   File 
"/build/facet-analyser-0.0~git20221121142040.6be10b8+ds1/scripts/pvsm2webgl.py", 
line 73, in 

1: main()
1:   File 
"/build/facet-analyser-0.0~git20221121142040.6be10b8+ds1/scripts/pvsm2webgl.py", 
line 57, in main

1: exporters= pvs.servermanager.createModule("exporters")
1:    ^^
1: AttributeError: module 'paraview.servermanager' has no attribute 
'createModule'. Did you mean: 'updateModules'?

3/4 Test #2: basicPluginTest02 ***Skipped   4.49 sec
4/4 Test #1: basicPluginTest01 ***Skipped   4.51 sec

100% tests passed, 0 tests failed out of 4

Attaching the full build log for reference. The difference may be in 
either the versions of packages installed as build-dependencies, or in 
the xvfb setup, since you get X server errors in your log.


If a rebuild on the testing buildds works, then I'd be grateful if you 
could close this bug before facet-analyser gets AUTORMed from bookworm; 
otherwise I'll be happy to help pinpoint (and fix) the root cause.


Roland.

Bug#1025703: bullseye-pu: package libexplain/1.4.D001-11+deb11u1

[Santiago Vila]

Hello. I'm providing the same information in "reportbug format", just
in case not having doing so in the initial report may have contributed
for this report not to be processed yet.

[ Reason ]
This upload fixes FTBFS Bug #997222 (failure to build with newer kernel).

[ Impact ]
Without this update the package would continue to FTBFS in bullseye.

[ Tests ]
I've checked that the package fixes the FTBFS problem.

[ Risks ]
The upload fixes actually two FTBFS problems, one of them happens already
with the kernel in bullseye, the other only happens when building the
package with the kernel in bookworm, but it's also desirable to be applied
(I asked the patch author about this).

So, the only risk I can think of is that somebody could still want
the obsolete kernel interface of the second fix to be still documented
in bullseye, but I believe the ability to build this package under bookworm
(or even with bullseye and a new kernel) outweighs whatever value
documenting an obsolete kernel interface might have.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
The upload is a backport of the fixes which were already applied in bookworm.

[ Other info ]
I've updated the upload date (since I'm waiting for approval),
so I'm including the debdiff again.


Thanks.diff -Nru libexplain-1.4.D001/debian/changelog 
libexplain-1.4.D001/debian/changelog
--- libexplain-1.4.D001/debian/changelog2021-06-09 22:23:28.0 
+0200
+++ libexplain-1.4.D001/debian/changelog2023-03-21 14:20:00.0 
+0100
@@ -1,3 +1,12 @@
+libexplain (1.4.D001-11+deb11u1) bullseye; urgency=medium
+
+  * QA upload.
+  * Apply two patches from bookworm to build with newer kernels:
+  - Patch: Linux 5.11 no longer has if_frad.h, from Ubuntu. Closes: #997222
+  - Patch: termiox removed since kernel 5.12, from ALT Linux.
+
+ -- Santiago Vila   Tue, 21 Mar 2023 14:20:00 +0100
+
 libexplain (1.4.D001-11) unstable; urgency=medium
 
   * QA upload.
diff -Nru libexplain-1.4.D001/debian/patches/linux5.11.patch 
libexplain-1.4.D001/debian/patches/linux5.11.patch
--- libexplain-1.4.D001/debian/patches/linux5.11.patch  1970-01-01 
01:00:00.0 +0100
+++ libexplain-1.4.D001/debian/patches/linux5.11.patch  2023-03-21 
14:13:09.0 +0100
@@ -0,0 +1,33 @@
+From: Graham Inggs 
+Date: Tue, 16 Nov 2021 20:09:45 +0100
+Subject: Linux 5.11 no longer has if_frad.h
+
+Bug-Debian: https://bugs.debian.org/997222
+Last-Update: 2021-06-20
+---
+ libexplain/iocontrol/siocadddlci.c | 2 +-
+ libexplain/iocontrol/siocdeldlci.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/libexplain/iocontrol/siocadddlci.c
 b/libexplain/iocontrol/siocadddlci.c
+@@ -25,7 +25,7 @@
+ #include 
+ 
+ 
+-#ifdef SIOCADDDLCI
++#if defined(SIOCADDDLCI) && defined(HAVE_LINUX_IF_FRAD_H)
+ 
+ static void
+ print_data(const explain_iocontrol_t *p, explain_string_buffer_t *sb,
+--- a/libexplain/iocontrol/siocdeldlci.c
 b/libexplain/iocontrol/siocdeldlci.c
+@@ -26,7 +26,7 @@
+ #include 
+ 
+ 
+-#ifdef SIOCDELDLCI
++#if defined(SIOCDELDLCI) && defined(HAVE_LINUX_IF_FRAD_H)
+ 
+ static void
+ print_data(const explain_iocontrol_t *p, explain_string_buffer_t *sb,
diff -Nru libexplain-1.4.D001/debian/patches/series 
libexplain-1.4.D001/debian/patches/series
--- libexplain-1.4.D001/debian/patches/series   2021-06-09 22:03:05.0 
+0200
+++ libexplain-1.4.D001/debian/patches/series   2023-03-21 14:13:09.0 
+0100
@@ -11,3 +11,5 @@
 sanitize-bison.patch
 gcc-10.patch
 typos.patch
+linux5.11.patch
+termiox-no-more-exists-since-kernel-5.12.patch
diff -Nru 
libexplain-1.4.D001/debian/patches/termiox-no-more-exists-since-kernel-5.12.patch
 
libexplain-1.4.D001/debian/patches/termiox-no-more-exists-since-kernel-5.12.patch
--- 
libexplain-1.4.D001/debian/patches/termiox-no-more-exists-since-kernel-5.12.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libexplain-1.4.D001/debian/patches/termiox-no-more-exists-since-kernel-5.12.patch
   2023-03-21 14:13:09.0 +0100
@@ -0,0 +1,26 @@
+From: Håvard Flaget Aasen 
+Date: Tue, 16 Nov 2021 20:12:31 +0100
+Subject: termiox no more exists since kernel 5.12
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.12=c762a2b846b619c0f92f23e2e8e16f70d20df800
+
+Origin: 
https://packages.altlinux.org/en/sisyphus/srpms/libexplain/patches/libexplain-1.4-remove-termiox.patch
+---
+ libexplain/buffer/termiox.h | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/libexplain/buffer/termiox.h
 b/libexplain/buffer/termiox.h
+@@ -21,7 +21,11 @@
+ 
+ #include 
+ 
+-struct termiox; /* forward */
++/* make termiox empty
++   no more defined in Linux kernel since 5.12:
++   

Bug#1025654: bullseye-pu: package x4d-icons/1.2-2+deb11u1

[Santiago Vila]

Hello. I'm providing the same information in "reportbug format", just
in case not having doing so in the initial report may have contributed
for this report not to be processed yet.

[ Reason ]
This upload fixes FTBFS Bug #991067 (an imagemagick update which was
done in bullseye late in the release cycle made several packages not
to build anymore from source).

[ Impact ]
Without this update the package would continue to FTBFS in bullseye.

[ Tests ]
I've checked that both the package builds again from source and also
I've carefully checked that the package contents is what it should be.

[ Risks ]
There is a small risk related with raising debhelper compat level.
I've decided to do that as the preferred technical solution because
it allows to reuse the same fix which was already done in bookworm,
and also because the package is simple enough that it was easy to check
that a debhelper bump does not have undesired effects.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
The change is just a backport of the fix already applied in bookworm
three months ago.

[ Other info ]
I've reworded the changelog a little bit and updated the upload date
(since I'm waiting for approval), so I'm including the debdiff again.

Thanks.diff -Nru x4d-icons-1.2/debian/changelog x4d-icons-1.2/debian/changelog
--- x4d-icons-1.2/debian/changelog  2019-03-12 05:38:09.0 +0100
+++ x4d-icons-1.2/debian/changelog  2023-03-21 13:50:00.0 +0100
@@ -1,3 +1,12 @@
+x4d-icons (1.2-2+deb11u1) bullseye; urgency=medium
+
+  * QA upload.
+  * Fix FTBFS problem with new imagemagick. The fix is the same which was
+already applied in bookworm. Closes: #991067.
+  * The above patch requires raising debhelper compatibility level to 13.
+
+ -- Santiago Vila   Tue, 21 Mar 2023 13:50:00 +0100
+
 x4d-icons (1.2-2) unstable; urgency=medium
 
   * QA upload.
diff -Nru x4d-icons-1.2/debian/compat x4d-icons-1.2/debian/compat
--- x4d-icons-1.2/debian/compat 2014-05-03 07:01:56.0 +0200
+++ x4d-icons-1.2/debian/compat 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru x4d-icons-1.2/debian/control x4d-icons-1.2/debian/control
--- x4d-icons-1.2/debian/control2019-03-12 05:37:54.0 +0100
+++ x4d-icons-1.2/debian/control2023-03-21 13:48:49.0 +0100
@@ -2,7 +2,7 @@
 Section: graphics
 Priority: optional
 Maintainer: Debian QA Group 
-Build-Depends: debhelper (>= 9), imagemagick, faketime, librsvg2-bin, 
fonts-dejavu-core
+Build-Depends: debhelper-compat (= 13), imagemagick, faketime, librsvg2-bin, 
fonts-dejavu-core
 Standards-Version: 3.9.5
 Homepage: http://x4d.surgut.co.uk
 Vcs-Git: https://github.com/xnox/x4d.git
diff -Nru x4d-icons-1.2/debian/patches/020_fix_policy.patch 
x4d-icons-1.2/debian/patches/020_fix_policy.patch
--- x4d-icons-1.2/debian/patches/020_fix_policy.patch   1970-01-01 
01:00:00.0 +0100
+++ x4d-icons-1.2/debian/patches/020_fix_policy.patch   2023-03-21 
13:48:49.0 +0100
@@ -0,0 +1,29 @@
+Description: Override overly strict ImageMagick coder policy (#987504)
+ This creates a more permissive version of
+ /etc/ImageMagick-6/policy.xml and ensures it gets loaded after the
+ one from /etc.
+ .
+ It is done by means of a patch to make use of the debhelper-provided
+ $HOME visible by dh_auto_*.
+ .
+ The relevant code is at:
+ 
https://sources.debian.org/src/imagemagick/8:6.9.11.60+dfsg-1.3/magick/configure.c/#L860
+Author: Dennis Filder 
+Last-Updated: 2022-12-06
+
+--- a/generate.sh
 b/generate.sh
+@@ -33,6 +33,13 @@
+ generate XML '1.0' xml10
+ generate XML '1.1' xml11
+ 
++# this relies on debhelper providing a $HOME directory for us to write to
++imversion=$(convert -version|sed -n '/^Version: /s@Version: ImageMagick 
\([[:digit:]]\+\)\..*@ImageMagick-\1@p')
++polfile="/etc/${imversion}/policy.xml"
++mkdir "$HOME"/.magick
++sed -e '//s@"none"@"read|write"@' "$polfile" \
++> "$HOME"/.magick/policy.xml
++
+ /bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -L1 -I{} convert -background 
none {}-v.svg {}.png
+ /bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -L1 -I{} convert -background 
none {}-v.svg {}.gif
+ /bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -L1 -I{} convert -background 
none {}-v.svg {}-v.eps
diff -Nru x4d-icons-1.2/debian/patches/series 
x4d-icons-1.2/debian/patches/series
--- x4d-icons-1.2/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ x4d-icons-1.2/debian/patches/series 2023-03-21 13:48:49.0 +0100
@@ -0,0 +1 @@
+020_fix_policy.patch

Bug#1031537: RFS: monitoring-plugins-check-oracle-health/3.3.2.1-1 [ITP] -- Nagios plugin check_oracle_health

[Preuße]

Control: tags -1 + moreinfo

On 17.02.2023 23:39, Hilmar Preusse wrote:

Hi,


I am looking for a sponsor for my package 
"monitoring-plugins-check-oracle-health":


Package is not finalized, I deleted it from mentors.d.o. For now I tag
the RFS bug moreinfo.

H.
--
sigfault

Bug#1032563: nvidia-driver 525.89.02 fails to initialize with Quadro M2200M

[Andreas Beckmann]

Control: tag -1 moreinfo upstream

On 09/03/2023 00.20, Matvey Soloviev wrote:

Package: nvidia-driver
Version: 525.89.02-1

Nvidia drivers newer than the 510 series fail to load on my system, which
is a Lenovo Thinkpad P51 with a Quadro M2200 GPU, with BIOS 1.60 and ECP
1.10. I have encountered this bug with driver versions 515, 520 and now the
525 that landed in testing, as well as with a version of 525 installed
using nvidia's official installer, and kernels including 6.0.7 and 6.2.2
from xanmod and 6.1.0-5-amd64 from Debian's official repository. My system
is a mixture of packages from stable and testing, with libc6=2.36-7. Driver
version 510.108.03-1 works (but is unstable in sleep and broken in
hibernation).


Do you have by chance installed nvidia-open-kernel-dkms instead of 
nvidia-kernel-dkms? In that case, please switch to the proprietary 
module (nvidia-kernel-dkms).


You could also try with the 530 driver from experimental.

You could also try the tesla-470 driver.


Andreas

Bug#1033200: apt, apt-get, aptitude and others have been failing for an extended period.

[David Kalnischkies]

Control: merge 1033200 1033208 1033209

Hi,

On Sun, Mar 19, 2023 at 11:19:23AM -0400, WILLIAM ORVILLE RICHMOND wrote:
> Package: apt-get
> Version: 2.2.4

> Subject: This info seems to have inadvertently been omitted from the
> Debian Bug report logs

The package is called "apt", a package named "apt-get" doesn't exist, so
the bugs were assigned to a catch-all package – from there it got
assigned now to where you probably intended to report it against in the
first place…

Just, please don't make every of your mails a new bugreport. You can
add a message by replying to 1033...@bugs.debian.org (or just reply-all
to this message here). Thanks.


>   When, for example, I do:
> 
> orville@flinta:~$ sudo apt-get install lynx
[…]
> Ign:1 http://deb.debian.org/debian bullseye/main amd64 lynx-common all
> 2.9.0dev.6-3~deb11u1
> Err:1 http://deb.debian.org/debian bullseye/main amd64 lynx-common all
> 2.9.0dev.6-3~deb11u1
>   Connection failed [IP: 199.232.34.132 80]
[…]
> E: Failed to fetch 
> http://security.debian.org/debian-security/pool/updates/main/l/lynx/lynx-common_2.9.0dev.6-3%7edeb11u1_all.deb
> Connection failed [IP: 199.232.34.132 80]

The IP belongs to Fastly, a big CDN, sponsoring Debian. Can you reach
the IP in a browser, e.g. with "http://199.232.34.132/;? (It is
normal if the page you see isn't very informative and just talks about
"Fastly error: unknown domain". Not normal would be an error message
from your browser about being unable to connect or some such.)


>   I have been considering that maybe some part of the update process, (curl
> ??), has been being intercepted ... perhaps by my ISP?? ... but I don't

curl is not part of the "update process". Sure, 'something' could
potentially interfere with your network, but while a real attack could
look the same, it is usually just some local misconfiguration and not
some sinister plot by your ISP or country (if you don't happen to live
in a sinister country of course).

Have you e.g. recently changed something in your router configuration?
Is your machine connected to the right wlan network? Sometimes, these
issues turn out to be just some new neighbor with an open wlan…
Or do you have a proxy configuration? Adblocker? A open hotspot near by
with a captive portal? …

You can change the apt sources.list to use 'https' instead of 'http' to
potentially avoid some problems with external interference (although,
some interference is considered good interference, so this isn't
a default in Debian for now). A VPN would indeed eliminate far more of
potential external interference, but for now that seems like overkill.


>   It has seemed to be to be unlikely that I am the only person with these
> problems, however I do apologize for waiting so long,

As the world isn't burning (well, it is given climate and wars, but
I digress) it is actually very likely that you are the only person with
these problems as we would have literal thousands of people reporting
such issues, especially if they were ongoing for months, while we are
even in the process of releasing a new major version of Debian and
so many people interact with our servers for upgrades.

In fact, between 16 and 17 March the mail reception of the BTS and
a couple other things went down for a few hours only, and the outcry was
huge [0]. Problems for "months" is nearly 100% proof that this problem is
local to your setup.


I somewhat suspect that the reason Fedora isn't effected is simple that
the configuration you accidentally broke network reaching tools on
Debian with hasn't reached your Fedora setup yet, so I would start with
figuring out what makes your Fedora machines different from the Debian
ones. Are they in a different (sub)net on your network for example?


All in all, I don't really see a way to help you as I don't really see
how it could be a problem originating from "apt". Especially if you have
similar network problems with other tools.


Best regards

David Kalnischkies

[0] 
https://lists.debian.org/debian-infrastructure-announce/2023/03/msg3.html


signature.asc
Description: PGP signature

Bug#1033275: RFS: zstd-jni-java/1.5.4-2+ds-1 [Team] -- JNI bindings for Zstd (Architecture-specific files)

[Adam Borowski]

On Tue, Mar 21, 2023 at 01:13:35AM +, sun min wrote:
> I am looking for a sponsor for my package "zstd-jni-java":

> Changes since the last upload:
> 
> zstd-jni-java (1.5.4-2+ds-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream release.
+  * Update debian/libzstd-jni1.symbols.
+
+ -- sun min   Wed, 08 Mar 2023 16:40:55 +0800

This doesn't look like an update that's fit for Bookworm during the hard
freeze.  There's no description of changes attached, thus I can't tell if
these are bugfixes only.  If so, please say so.

Otherwise, let's use experimental or just refrain from uploading until
Bookworm is released.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Q: Is it ok to combine wired, wifi, and/or bluetooth connections
⢿⡄⠘⠷⠚⠋⠀in wearable computing?
⠈⠳⣄ A: No, that would be mixed fabric, which Lev19:19 forbids.

Bug#1032466: Performance problems with nvidia-driver version 525.89.02-1

[Andreas Beckmann]

Control: tag -1 moreinfo

On 07/03/2023 15.49, Jannick Loch wrote:

Package: nvidia-driver
Version: 525.89.02-1

The first Problem is, when i enable Vsync at any game, the framerate 
wont sync to my monitor refreshrate, it stuck at 60hz.
And the other Problem is, when i install the Extension Dash to Dock, all 
games say that they has more than 60hz, but i can see with my eyes and 
with a tool, that my monitor shows only 60 hz.


Please try the 530 driver from experimental.


Andreas

Bug#1020303: Ping

[Alberto Gonzalez Iniesta]

Hi, all. We're looking forward to uploading the latest CRS package to
bullseye-backports, but this will require this pending update to
bullseye. Any news on this front?

Regards,

Alberto
-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#1033248: ITP: python-onetimepad -- python library for the onetimepad algorithm

[Jakub Wilk]

* Matthias Geiger , 2023-03-20 18:36:

https://github.com/jailuthra/onetimepad


Misleading package name. Should be: 
python-toy-xor-encryption-do-not-use.


No, really, don't upload this to Debian.


it's a dependency for banking (#1013317).


It seems banking uses this via an embedded copy of 
, which is also 
horrifying.


--
Jakub Wilk

Bug#1033284: apache2 2.4.56-1 redirects not normal working appeared %3f

[Martin Hentschel]

Dear Debian-Team,

We also had a problem with broken redirects after upgrading to 2.4.56-1. 
The cause seemed to be, that the REQUEST_URI contained the complete URL 
and not only the request path. Downgrading back to 2.4.54-1 fixed it.


Thanks - Martin

Bug#1013345: ITP: west -- Description: meta tool for Zephyr RTOS

[Jakob Haufe]

On Sun, 19 Mar 2023 16:07:24 +0100
"Zygmunt Krynicki"  wrote:

> I forgot about this entirely, having changed jobs.
> 
> Let me share what I made once I'm home.

That would be great. Do you still intend to work on this?

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgpYfuSegeiKc.pgp
Description: OpenPGP digital signature

Bug#1033285: unblock: libpaper/1.1.29

[Giuseppe Sacco]

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

Please unblock package libpaper. This new version only includes non-code
changes: a few typos corrections in manual pages and a new language
translation.

[ Reason ]
While this is not a necessary update, it would benefits users without
having any functional impact.

[ Impact ]
ditto

[ Tests ]
nothing

[ Risks ]
No code changes are present. There should not be any risks.

[ 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

[ Other info ]
nothing

Thank you very much,
Giuseppe

unblock libpaper/1.1.29

diff -Nru libpaper-1.1.28/debian/changelog libpaper-1.1.29/debian/changelog
--- libpaper-1.1.28/debian/changelog	2019-06-26 00:04:32.0 +0200
+++ libpaper-1.1.29/debian/changelog	2023-03-17 14:44:15.0 +0100
@@ -1,3 +1,14 @@
+libpaper (1.1.29) unstable; urgency=medium
+
+  * Fix for parallel build. See #857058
+  * Added romanian translation. See #1032333
+  * Updated standards-version to 4.6.0 (no changes)
+  * Update papersize manual page. See #959403
+  * Update paperconf manual page. See #959404
+  * Update paperconfig manual page. See #959405
+
+ -- Giuseppe Sacco   Fri, 17 Mar 2023 14:44:15 +0100
+
 libpaper (1.1.28) unstable; urgency=medium
 
   * Completely fixed #927226.
diff -Nru libpaper-1.1.28/debian/control libpaper-1.1.29/debian/control
--- libpaper-1.1.28/debian/control	2016-07-16 18:06:42.0 +0200
+++ libpaper-1.1.29/debian/control	2023-03-17 14:29:31.0 +0100
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Giuseppe Sacco 
-Standards-Version: 3.9.8
+Standards-Version: 4.6.0
 Build-Depends: autotools-dev, dpkg-dev (>= 1.16.1~), debhelper (>= 9), dh-autoreconf, dh-exec(>= 0.3), po-debconf, autoconf
 
 Package: libpaper1
diff -Nru libpaper-1.1.28/debian/po/ro.po libpaper-1.1.29/debian/po/ro.po
--- libpaper-1.1.28/debian/po/ro.po	1970-01-01 01:00:00.0 +0100
+++ libpaper-1.1.29/debian/po/ro.po	2023-03-17 14:22:38.0 +0100
@@ -0,0 +1,316 @@
+# Mesajele în limba română pentru pachetul libpaper.
+# Romanian translation of libpaper.
+# Copyright © 2023 THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the libpaper package.
+#
+# Remus-Gabriel Chelu , 2023.
+#
+# Cronologia traducerii fișierului „libpaper”:
+# Traducerea inițială, făcută de R-GC, pentru versiunea libpaper 1.1.28(2009-07-18).
+# Actualizare a traducerii pentru versiunea Y, făcută de X, Y(anul).
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: libpaper 1.1.28\n"
+"Report-Msgid-Bugs-To: eppes...@debian.org\n"
+"POT-Creation-Date: 2007-07-18 19:50+0200\n"
+"PO-Revision-Date: 2023-02-26 11:30+0100\n"
+"Last-Translator: Remus-Gabriel Chelu \n"
+"Language-Team: Romanian \n"
+"Language: ro\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n==0 || (n!=1 && n%100>=1 && "
+"n%100<=19) ? 1 : 2);\n"
+"X-Bugs: Report translation errors to the Language-Team address.\n"
+"X-Generator: Poedit 3.2.2\n"
+
+# R-GC, scrie:
+# cum multe dintre dimensiunile ce apar aici,
+# au nume englezești(a se citi, americane),
+# ce traduse, nu ne spun mare lucru și care
+# pe aici pe colo, induc în eroare, am extras
+# dimensiunile acestora (în milimetri), din
+# pagina de Wikipedia:
+# 
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "letter"
+msgstr "Letter(scrisoare) [216 x 279mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "a4"
+msgstr "A4 [210 x 297mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "note"
+msgstr "Note(notă) [220 x 280mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "legal"
+msgstr "Legal [216 x 356mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "executive"
+msgstr "Executive [184 x 267mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "halfletter"
+msgstr "Half Letter(½ scrisoare) [140 x 216mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "halfexecutive"
+msgstr "Half Executive(½ executiv) [130 x 184mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "11x17"
+msgstr "11x17 [279 x 432mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "statement"
+msgstr "Statement(declarație) [140 x 216mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "folio"
+msgstr "Folio [203 x 330mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "quarto"
+msgstr "Quarto [216 x 275mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001
+msgid "10x14"
+msgstr "10x14 [254 x 356mm]"
+
+#. Type: select
+#. Choices
+#: ../libpaper1.templates:2001

Bug#1033243: [Pkg-puppet-devel] Bug#1033243: puppet: apt install puppet and puppet modules clash with official upstream repo

[Thomas Goirand]

On 3/20/23 17:13, Renato Gallo wrote:

Package: puppet
Version: 7.23.0
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainers,

At work I must install foreman and puppet using the official upstream repos for
a testing environment which are
cat puppet7.list
# Puppet 7 bullseye Repository
deb http://apt.puppetlabs.com bullseye puppet7

cat foreman.list
deb http://deb.theforeman.org/ bullseye nightly
deb http://deb.theforeman.org/ plugins nightly

problem being that the puppet debian version is not 7.23.0 the upstream dep
package has been named puppet7-release (not just puppet) and after having
installed a module via apt I find myself in a broken condition where apt
absolutely wants to install the old version of puppet (even when I try to
uninstall it) which breaks the foreman nightly installation. Can you please I
pray you upgrade the debian repo so that it follows the upstream one ?

else can you tell me how can I set up my preferences so that only the upstream
repo is considered ?

I have tried setting priority 1001 but it doesn't seem to work for all the
packages

Thanks in advance


Hi Renato,

Thanks for your bug report. However...

What you're reporting here, is an issue due to using upstream 
repository. In no way, this is a valid bug report for Debian (ie: the 
Debian repository and packages are working perfectly well).


Therefore, I'm closing your bug. If you need help on how to setup and 
use upstream repositories, I strongly suggest you that you ask for such 
help upstream, or in another location than the bug tracker.


If you think there's ways to improve the Debian packaging so that it 
plays in a nicer way with upstream repositories, this IMO is a case for 
a wishlist bug, absolutely not severity: grave.


Cheers,

Thomas Goirand (zigo)

Bug#1033284: apache2 2.4.56-1 redirects not normal working appeared %3f

[alex]

Package: apache2
Version: 2.4.56-1


Hello.
I used to redirect
RewriteRule ^test\.php$https://www.test.com/? [R=301,L]

Result
test.com/test.php 301 >https://www.test.com/


After upgrading to the 2.4.56-1
Result
test.com/test.php 301 >https://www.test.com/%3f

What is the problem can you fix it?

Bug#1032914: phog: ships /etc/pam.d/greetd

[Arnaud Ferraris]

Control: tags -1 + patch

Hi,

On Tue, 14 Mar 2023 00:20:10 +0100 Andreas Beckmann  wrote:
>
> Hi,
>
> during a test with piuparts I noticed your package failed to install
> because it tries to overwrite other packages files.
>
> From the attached log (scroll to the bottom...):
>
> 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/phog/32130044/log.gz

>
> Preparing to unpack .../phog_0.1.3-1_amd64.deb ...
> Unpacking phog (0.1.3-1) ...
> dpkg: error processing archive 
/var/cache/apt/archives/phog_0.1.3-1_amd64.deb (--unpack):
> trying to overwrite '/etc/pam.d/greetd', which is also in package 
greetd 0.9.0-2

> Errors were encountered while processing:
> /var/cache/apt/archives/phog_0.1.3-1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
>
> greetd recently started to ship /etc/pam.d/greetd (with different
> content) itself.

Thanks for the heads-up!

I have a pending MR for fixing this bug on phog's side (see 
https://salsa.debian.org/DebianOnMobile-team/phog/-/merge_requests/5), 
however this would require small changes to greetd as well (+cc duck for 
that matter) to ensure users don't end up in a messed up situation.


I opened a MR on salsa's greetd 
(https://salsa.debian.org/debian/greetd/-/merge_requests/1), attaching 
the corresponding patches here as well for completeness.


@duck, any comment on the above?

Cheers,
Arnaud

>
>
> cheers,
>
> Andreas
>
>
From eca07bda4c0b272ded196008c3d4528c756f5bb6 Mon Sep 17 00:00:00 2001
From: Arnaud Ferraris 
Date: Wed, 15 Mar 2023 13:51:11 +0100
Subject: [PATCH 1/3] debian: update PAM config(s)

Except for the gnome-keyring bits, all items currently set in the
`greetd` PAM config are already part of the `login` config. Including
the latter makes the `greetd` config simpler.

This commit also calls the PAM modules needed for unlocking the KDE
wallet as well, and adds the `greetd-greeter` config (simply including
`login` as the greeter itself doesn't need to deal with keyrings).

Finally, switch to using debhelper for installing the configs instead of
handling those manually.
---
 debian/greetd.greetd-greeter.pam |  2 ++
 debian/greetd.greetd.pam |  8 
 debian/greetd.install|  1 -
 debian/pam.d/greetd  | 22 --
 debian/rules |  5 -
 5 files changed, 14 insertions(+), 24 deletions(-)
 create mode 100644 debian/greetd.greetd-greeter.pam
 create mode 100644 debian/greetd.greetd.pam
 delete mode 100644 debian/pam.d/greetd

diff --git a/debian/greetd.greetd-greeter.pam b/debian/greetd.greetd-greeter.pam
new file mode 100644
index 000..1ed7162
--- /dev/null
+++ b/debian/greetd.greetd-greeter.pam
@@ -0,0 +1,2 @@
+#%PAM-1.0
+@include login
diff --git a/debian/greetd.greetd.pam b/debian/greetd.greetd.pam
new file mode 100644
index 000..7f2a906
--- /dev/null
+++ b/debian/greetd.greetd.pam
@@ -0,0 +1,8 @@
+#%PAM-1.0
+@include login
+
+-authoptionalpam_gnome_keyring.so
+-authoptionalpam_kwallet5.so
+
+-session optionalpam_gnome_keyring.so auto_start
+-session optionalpam_kwallet5.so auto_start
diff --git a/debian/greetd.install b/debian/greetd.install
index 0a3fbfb..83f2dad 100644
--- a/debian/greetd.install
+++ b/debian/greetd.install
@@ -1,4 +1,3 @@
 greetd.service /lib/systemd/system/
 config.toml /etc/greetd/
 debian/needrestart/50_greetd.conf /etc/needrestart/conf.d/
-debian/pam.d/greetd /etc/pam.d/
diff --git a/debian/pam.d/greetd b/debian/pam.d/greetd
deleted file mode 100644
index 062217b..000
--- a/debian/pam.d/greetd
+++ /dev/null
@@ -1,22 +0,0 @@
-#%PAM-1.0
-
-# Block login if they are globally disabled
-auth  requisite pam_nologin.so
-
-# Load environment from /etc/environment and ~/.pam_environment
-session  required pam_env.so readenv=1
-session  required pam_env.so readenv=1 envfile=/etc/default/locale
-
-@include common-auth
-
--auth  optional pam_gnome_keyring.so
-
-@include common-account
-
-session  requiredpam_limits.so
-session  requiredpam_loginuid.so
-@include common-session
-
--session optionalpam_gnome_keyring.so auto_start
-
-@include common-password
diff --git a/debian/rules b/debian/rules
index 523b72b..1c1d9c5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -30,10 +30,13 @@ execute_after_dh_install:
 	# bad perms
 	chmod a-x debian/greetd/lib/systemd/system/greetd.service
 
+override_dh_installpam:
+	dh_installpam --name=greetd
+	dh_installpam --name=greetd-greeter
+
 override_dh_installsystemd:
 	dh_installsystemd --no-stop-on-upgrade --no-start
 
 execute_after_dh_auto_clean:
 	make -C man clean
 	rm -f debian/cargo-checksum.json
-
-- 
2.39.1

From be90d0cb662cf94de32bbb95f9070a6127b25bef Mon Sep 17 00:00:00 2001
From: Arnaud Ferraris 
Date: Wed, 15 Mar 2023 13:52:39 +0100
Subject: [PATCH 2/3] d/control: break/replace older `phog`

`phog` used to ship the `greetd` and `greetd-greeter` PAM configs,
leading to conflicts with the 

Bug#1033283: Please remove $http_proxy validation from postinst script

[Daniel Richard G.]

Package: ttf-mscorefonts-installer
Version: 3.8

The package postinst script contains this bit:

while ! echo "$http_proxy" | \
egrep -iq 'https?://[[:alnum:]][-.[:alnum:]]+(:\d+)?/?' &&  \
[ ! -z "$http_proxy" ] ; do
db_fset msttcorefonts/http_proxy seen false
db_input high msttcorefonts/http_proxy
db_go
db_get msttcorefonts/http_proxy
http_proxy=$RET
done

This appears intended to reject an environment setting of, for example,

http_proxy=socks5h://proxy.example.com/

as wget(1) (which is used to download the font archives) does not
support SOCKS proxies.

However, note that wget can also be configured to use a proxy via a
wgetrc file, which will override the environment variable. In my
deployment, I set http_proxy in the environment to a SOCKS server so
that APT will download packages via same, and set http_proxy in
~/.wgetrc to an alternate HTTP proxy so that wget will work. (The latter
proxy happens to be somewhat unreliable, so the SOCKS one is preferable
wherever it can be used.) This has worked fine with everything I've used
save for this package.

The postinst script's validation of $http_proxy is thus not helpful, and
prevents downloading the package and then the fonts in a single APT
invocation. Here is the error I saw in an automated install process:

Unpacking ttf-mscorefonts-installer (3.8) ...
Setting up libmspack0:i386 (0.10.1-2) ...
Setting up cabextract (1.9-3) ...
Setting up ttf-mscorefonts-installer (3.8) ...
dpkg: error processing package ttf-mscorefonts-installer (--configure):
 installed ttf-mscorefonts-installer package post-installation script 
subprocess returned error exit status 30
Processing triggers for libc-bin (2.31-13+deb11u5) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for fontconfig (2.13.1-4.2) ...
Errors were encountered while processing:
 ttf-mscorefonts-installer
E: Sub-process /usr/bin/dpkg returned an error code (1)

If I attempt to complete the installation by hand, I get a debconf
dialog that pops back up repeatedly unless I remove the SOCKS proxy
setting. Given that the dialog makes no mention of wget's limited proxy
support, and neglects to give any sort of error message, this behavior
is quite user-hostile.

Note that the Ubuntu version of this package not only gets rid of the
$http_proxy validation, it also eliminates the msttcorefonts/http_proxy
debconf setting, and the questionable behavior of storing the install-
time value of $http_proxy therein. In fact, the package scripts make no
mention of a proxy at all. That not only seems to me like the right
approach (in that it avoids making assumptions on how the user manages
their proxies), it appears to be the convention followed by other
packages that perform an embedded download, like libdvd-pkg.

Given that the Ubuntu package has diverged slightly from the Debian one,
this may be a good opportunity/excuse to merge them back together.


--Daniel


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

Bug#1033246: watchdog: The periodic fork test mentioned in the man page is not performed

[Peter Rosin]

2023-03-20 at 17:56, Peter Rosin wrote:
> Dear Maintainer,
> 
> After crashing the kernel with "echo c > /proc/sysrq-trigger" the
> watchdoggery sometimes failes to trigger a reboot. It's as if the
> watchdog daemon continues to successfully perform its checks and
> thus continues to service the hardware watchdog even if the
> kernel has paniced.
> 
> The watchdog configuration is trivial:
> 
> watchdog-device = /dev/watchdog
> interval = 10
> realtime = yes
> priority = 1
> pidfile = /run/foo.pid
> pidfile = /run/bar.pid
> 
> When reading the manual I noticed this passage:
> 
> "watchdog will try periodically to fork itself to
> see whether the process table is full."
> 
> Since I was a bit sceptic that a paniced kernel could
> successfully fork, I wondered a bit about what "periodically"
> meant. So I went digging to see exactly how often that fork
> test is performed and how long a should expect to wait for it,
> but it appears it is no longer done at all.
> 
> To verify, I added an empty script that simply returns 0 to
> /etc/watchdog.d and after that, the watchdog kicks in as expected.
> That's arguably heavier than a fork-exit-test, but still an
> indication.
> 
> I then went digging in the git history to check if it might be
> intentional, but it appears not. The way I read it, the check
> went missing along with 12-year-old commit
> 0fc6d009c78f ("This patch allows zero or more scripts/programs...")
> which was new for version 5.10.
> 
> Notice how the "if (tbinary == NULL)" test is moved to before the
> fork() call in the check_bin() function in that patch. But maybe
> I misread something?
> 
> Anyway, please repair the broken fork test (or adjust the manual
> to the new reality.)

Patch and upstream merge request created that restores the fork test:
https://sourceforge.net/p/watchdog/code/merge-requests/4/

Cheers,
Peter

Bug#1033282: missing dependencies on gnome-shell-common and polkitd

[Jochen Sprickerhof]

Package: phog
Version: 0.1.3-1
Severity: important

Hi,

the package is missing a dependency on gnome-shell-common and polkitd to
work as can be tested with:

debvm-create -z 3G -- --include=phog,linux-image-amd64
debvm-run -g -- -m 4G --vga qxl

(you can use debvm-create --release testing as long as #1032914 is not
fixed.)

Cheers Jochen


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1-sunxi64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 phog depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  fonts-lato   2.0-2.1
ii  greetd   0.9.0-1
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libgcr-ui-3-13.41.1-2
ii  libglib2.0-0 2.74.6-1
ii  libgnome-desktop-3-2043.2-2
ii  libgtk-3-0   3.24.37-2
ii  libhandy-1-0 1.8.1-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libnm0   1.42.4-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libsystemd0  252.6-1
ii  libupower-glib3  0.99.20-2
ii  libwayland-client0   1.21.0-1
ii  phoc 0.24.0-1
ii  squeekboard  1.21.0-1

phog recommends no packages.

phog suggests no packages.

-- no debconf information

Bug#1033236: unblock: apktool/2.7.0+dfsg-6

[Hans-Christoph Steiner]

Control: retitle  -1 unblock: apktool/2.7.0+dfsg-6

aapt building is not supported on all arches, upstream only supports amd64, 
arm64 and i386.  So I had to restrict the test of building to those arches.
diff --git a/debian/changelog b/debian/changelog
index d439603..8c68cfa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+apktool (2.7.0+dfsg-6) unstable; urgency=medium
+
+  * only test APK build on arches with aapt that can do it
+
+ -- Hans-Christoph Steiner   Tue, 21 Mar 2023 09:41:45 +0100
+
+apktool (2.7.0+dfsg-5) unstable; urgency=medium
+
+  * fix broken symlink to commons-text.jar (Closes: #1033226)
+
+ -- Hans-Christoph Steiner   Mon, 20 Mar 2023 14:00:20 +0100
+
 apktool (2.7.0+dfsg-4) unstable; urgency=medium
 
   * fix arch detection for Depends:
diff --git a/debian/links b/debian/links
index 2c167db..779d62e 100644
--- a/debian/links
+++ b/debian/links
@@ -2,7 +2,7 @@ usr/share/java/antlr3-runtime.jar 
usr/share/apktool/antlr3-runtime.jar
 usr/share/java/commons-cli.jar usr/share/apktool/commons-cli.jar
 usr/share/java/commons-io.jar usr/share/apktool/commons-io.jar
 usr/share/java/commons-lang3.jar usr/share/apktool/commons-lang3.jar
-usr/share/java/commons-text-1.9.jar usr/share/apktool/commons-text-1.9.jar
+usr/share/java/commons-text.jar usr/share/apktool/commons-text.jar
 usr/share/java/guava.jar usr/share/apktool/guava.jar
 usr/share/java/snakeyaml.jar usr/share/apktool/snakeyaml.jar
 usr/share/java/stringtemplate.jar usr/share/apktool/stringtemplate.jar
diff --git a/debian/tests/control b/debian/tests/control
index 298f6e5..6855f40 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,4 +1,11 @@
 # urzip.apk comes from https://github.com/eighthave/urzip via 
https://gitlab.com/fdroid/fdroidserver
+
 Test-Command: apktool d debian/tests/urzip.apk && test -e 
urzip/smali/info/guardianproject/urzip/UnZipper.smali
 Depends: apktool
 Restrictions: allow-stderr
+
+# Test building an APK on arches that have aapt that can do it
+Test-Command: apktool d debian/tests/urzip.apk && test -e 
urzip/smali/info/guardianproject/urzip/UnZipper.smali && apktool b urzip/ && 
test -e urzip/dist/urzip.apk
+Architecture: amd64 arm64 i386
+Depends: apktool
+Restrictions: allow-stderr

Bug#1033281: unblock: dictionaries-common/1.29.5

[Agustin Martin]

El mar, 21 mar 2023 a las 9:40, Agustin Martin () escribió:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: dictionaries-com...@packages.debian.org
> Control: affects -1 + src:dictionaries-common
>
> Please unblock package dictionaries-common
...
> While changes are not at all critical (things will keep working with
> old info, new location for bdic conversion tool is just a symlink tp
> old one) I would appreciate if last version reaches testing to avoid
> having different info in new_stable and sid (and to have my git
> history as clean as possible and avoid branches in case something
> really important deserves an upload).
>
> I am attaching a full debdiff with all changes from previous version
> and a "debdiff -w" file skipping whitespace changes.

debdiff -w output really attached. Sorry for the noise.
diff -Nru -w dictionaries-common-1.29.4/debian/changelog dictionaries-common-1.29.5/debian/changelog
--- dictionaries-common-1.29.4/debian/changelog	2023-01-25 23:07:33.0 +0100
+++ dictionaries-common-1.29.5/debian/changelog	2023-03-14 22:17:31.0 +0100
@@ -1,3 +1,15 @@
+dictionaries-common (1.29.5) unstable; urgency=medium
+
+  [ Soren Stoutner ]
+  * debian/copyright:  Update copyright dates to include 2023.
+  * policy/dsdt-policy.xml.in:  Update to reflect changes in the Qt
+packaging.
+
+  [ Agustin Martin Domingo ]
+  * installdeb-myspell: Add /usr/bin/convert-bdic as first option.
+
+ -- Agustin Martin Domingo   Tue, 14 Mar 2023 22:17:31 +0100
+
 dictionaries-common (1.29.4) unstable; urgency=medium
 
   * debian/po/ro.po: Romanian debconf templates translation-revision,
diff -Nru -w dictionaries-common-1.29.4/debian/copyright dictionaries-common-1.29.5/debian/copyright
--- dictionaries-common-1.29.4/debian/copyright	2022-12-06 22:57:10.0 +0100
+++ dictionaries-common-1.29.5/debian/copyright	2023-03-14 22:12:41.0 +0100
@@ -5,9 +5,9 @@
 
 Files: *
 Copyright: 1999-2008 Rafael Laboissiere 
-	   2001-2022 Agustín Martín Domingo 
+   2001-2023 Agustín Martín Domingo 
 	   2003-2016 René Engelhard 
-	   2022 Soren Stoutner 
+   2022-2023 Soren Stoutner 
 License: GPL-2+
 
 Files: support/emacsen/ispell.el
diff -Nru -w dictionaries-common-1.29.4/policy/dsdt-policy.xml.in dictionaries-common-1.29.5/policy/dsdt-policy.xml.in
--- dictionaries-common-1.29.4/policy/dsdt-policy.xml.in	2022-12-13 18:24:52.0 +0100
+++ dictionaries-common-1.29.5/policy/dsdt-policy.xml.in	2023-03-14 22:12:41.0 +0100
@@ -139,7 +139,7 @@
 
 
   
-	1999-2014,2022
+1999-2014,2022-2023
   
   
 	Rafael Laboissire, David Coe, Agustn
@@ -781,14 +781,10 @@
 	
 	
 	  
-	Hunspell dictionary packages should build-depend on
-	qt6-webengine-dev-tools or a superseding package
-	so that they can use qwebengine_convert_dict to
-	generate the binary .bdic dictionary files.
-	Although qwebengine_convert_dict is also
-	available in qtwebengine5-dev-tools (in a
-	different path) its use is discouraged as it will disappear
-	sooner.
+Hunspell dictionary packages should build-depend on the
+convert-bdic package so that they can use the
+convert-bdic command to generate the binary
+.bdic dictionary files.
 	For more information see .
 	  
 	
@@ -1374,24 +1370,30 @@
 	binary .bdic file.
 	Qt distributes a renamed version of this tool
 	called qwebengine_convert_dict that is
-	shipped in Debian as part of
+currently shipped in Debian as part of
 	the qt6-webengine-dev-tools package.
   
   
+Because the versions of Qt available in Debian change over time,
+the latest version of Qt that ships
+qwebengine_convert_dict will always provide a
+virtual package named convert-bdic which will
+install a symlink from /usr/bin/convert-bdic
+to the current versioned location of
+qwebengine_convert_dict.
+  
+  
 	Hunspell dictionaries should build-depend on
-	qt6-webengine-dev-tools or a newer package
-	that supersedes it.
-	During binary package creation they should compile the binary
-	dictionary by calling a command similar to the following
-	where xx_XX corresponds to the language of
-	the Hunspell dictionary.
-	The .dic needs to reside in the same
-	directory as the .aff during binary
-	compilation so that qwebengine_convert_dict
-	can locate it.
+convert-bdic. During binary package creation
+they should compile the binary dictionary by calling a command
+similar to the following where xx_XX
+corresponds to the language of the Hunspell dictionary.
+The .aff needs to reside in the same
+directory as the .dic during binary compilation so
+that convert-bdic can locate it.
   
   
-/usr/lib/qt6/libexec/qwebengine_convert_dict path/to/xx_XX.dic path/to/xx_XX.bdic
+convert-bdic 

Bug#1012218: firefox: Firefox 111 was available on Debian riscv64

[Bo YU]

Hi,


On Tue, Mar 21, 2023 at 1:03 PM Jessica Clarke  wrote:
>
> On 21 Mar 2023, at 04:49, Bo YU  wrote:
> >
> > Source: firefox
> > Followup-For: Bug #1012218
> >
> > Hi,
> >
> > Now the firefox 111 can be built with patch attached on qemu
> > But unfortunately, it is still not able to build real riscv64
> > hardware(Unmatched board) due to running out of resources at
> > ld pharse.
>
> Is it doing LTO or something? 16 GiB is a lot of memory for the linker
Oh, you hit me here. I checked the ld flags(runtime, hang of ld phrase) again:
```
-plugin /usr/lib/gcc/riscv64-linux-gnu/12/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/riscv64-linux-gnu/12/lto-wrapper
```
https://paste.debian.net/1274601/
(please note here the ld is bfd I try). So I think LTO is enabled?
I will do some tests with explicitly configuring it with
```
export DEB_BUILD_MAINT_OPTIONS=optimize=-lto
```
from [0].
> to exhaust, especially for a non-debug build, even accounting for GNU
> ld’s inefficiency compared with other linkers. Though presumably it
> should build just fine if you add a swap partition,
Yeah, I have added swap partition here.
>or reduce parallelism if the problem is linking multiple large binaries at the
> same time?
hmm, This is a possible direction to try also. Do we have flags to
enable it for Debian here？

Many thanks.

BR,
Bo
[0]: https://wiki.debian.org/ToolChain/LTO

Bug#1033281: unblock: dictionaries-common/1.29.5

[Agustin Martin]

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

Please unblock package dictionaries-common

Sorry I forgot about hard freeze starting 2023-03-12. Did not it
notice until 2023-03-16 message from the release team (Bits from the
Release Team: bookworm in hard freeze), but uploaded this version on
2023-03-14.

Changes are documentation changes in hunspell dictionaries policy to
adjust it to last changes in qt6-webengine-dev that reached testing on
2023-03-09 and a minor change in installdeb-myspell to look for bdic
conversion tool first in new location.

While changes are not at all critical (things will keep working with
old info, new location for bdic conversion tool is just a symlink tp
old one) I would appreciate if last version reaches testing to avoid
having different info in new_stable and sid (and to have my git
history as clean as possible and avoid branches in case something
really important deserves an upload).

I am attaching a full debdiff with all changes from previous version
and a "debdiff -w" file skipping whitespace changes.

Thanks for all and sorry for having missed this.

unblock dictionaries-common/1.29.5
diff -Nru dictionaries-common-1.29.4/debian/changelog dictionaries-common-1.29.5/debian/changelog
--- dictionaries-common-1.29.4/debian/changelog	2023-01-25 23:07:33.0 +0100
+++ dictionaries-common-1.29.5/debian/changelog	2023-03-14 22:17:31.0 +0100
@@ -1,3 +1,15 @@
+dictionaries-common (1.29.5) unstable; urgency=medium
+
+  [ Soren Stoutner ]
+  * debian/copyright:  Update copyright dates to include 2023.
+  * policy/dsdt-policy.xml.in:  Update to reflect changes in the Qt
+packaging.
+
+  [ Agustin Martin Domingo ]
+  * installdeb-myspell: Add /usr/bin/convert-bdic as first option.
+
+ -- Agustin Martin Domingo   Tue, 14 Mar 2023 22:17:31 +0100
+
 dictionaries-common (1.29.4) unstable; urgency=medium
 
   * debian/po/ro.po: Romanian debconf templates translation-revision,
diff -Nru dictionaries-common-1.29.4/debian/copyright dictionaries-common-1.29.5/debian/copyright
--- dictionaries-common-1.29.4/debian/copyright	2022-12-06 22:57:10.0 +0100
+++ dictionaries-common-1.29.5/debian/copyright	2023-03-14 22:12:41.0 +0100
@@ -5,9 +5,9 @@
 
 Files: *
 Copyright: 1999-2008 Rafael Laboissiere 
-	   2001-2022 Agustín Martín Domingo 
-	   2003-2016 René Engelhard 
-	   2022 Soren Stoutner 
+   2001-2023 Agustín Martín Domingo 
+   2003-2016 René Engelhard 
+   2022-2023 Soren Stoutner 
 License: GPL-2+
 
 Files: support/emacsen/ispell.el
diff -Nru dictionaries-common-1.29.4/policy/dsdt-policy.xml.in dictionaries-common-1.29.5/policy/dsdt-policy.xml.in
--- dictionaries-common-1.29.4/policy/dsdt-policy.xml.in	2022-12-13 18:24:52.0 +0100
+++ dictionaries-common-1.29.5/policy/dsdt-policy.xml.in	2023-03-14 22:12:41.0 +0100
@@ -139,7 +139,7 @@
 
 
   
-	1999-2014,2022
+1999-2014,2022-2023
   
   
 	Rafael Laboissire, David Coe, Agustn
@@ -779,19 +779,15 @@
 myspell dictionary package.
   
 	
-	
-	  
-	Hunspell dictionary packages should build-depend on
-	qt6-webengine-dev-tools or a superseding package
-	so that they can use qwebengine_convert_dict to
-	generate the binary .bdic dictionary files.
-	Although qwebengine_convert_dict is also
-	available in qtwebengine5-dev-tools (in a
-	different path) its use is discouraged as it will disappear
-	sooner.
-	For more information see .
-	  
-	
+
+  
+Hunspell dictionary packages should build-depend on the
+convert-bdic package so that they can use the
+convert-bdic command to generate the binary
+.bdic dictionary files.
+For more information see .
+  
+
   
 
 
@@ -1357,106 +1353,105 @@
   Hunspell Binary Dictionaries
   
   
-	Google's Chromium project developed a binary Hunspell file
-	format used for spell checking by their web engine.
-	The binary format combines the
-	text-based .dic
-	and .aff files into
-	one .bdic binary file.
-	Other web engines that are based on Chromium's code, like Qt
-	WebEngine included in KDE, can also use
-	these .bdic dictionaries.
-  
-  
-	Google created a tool called convert_dict
-	that takes the input from a pair of .dic
-	and .aff files and compiles them into a
-	binary .bdic file.
-	Qt distributes a renamed version of this tool
-	called qwebengine_convert_dict that is
-	shipped in Debian as part of
-	the qt6-webengine-dev-tools package.
-  
-  
-	Hunspell dictionaries should build-depend on
-	qt6-webengine-dev-tools or a newer package
-	that supersedes it.
-	During binary package creation they should compile the binary
-	dictionary by calling a command similar to the following
-	where xx_XX corresponds to 

Bug#1033154: aspell-en: should not have /var/lib files in the package

[Agustin Martin]

El sáb, 18 mar 2023 a las 15:09, Russell Coker
() escribió:
>
> Package: aspell-en
> Version: 2020.12.07-0-1
> Severity: minor
>
> The FHS describes /var/lib as "State information. Persistent data modified by
> programs as they run (e.g., databases, packaging system metadata, etc.)."
>
> The files that are included in a package are expected not to change in normal
> operation and therefore aren't "modified by programs".  So /var/lib isn't the
> right place for this.  Maybe /usr/lib would be the right place.
>
> One reason that this matters is for security systems that treat /usr and /var
> differently.

Hi, Russell,

The origin of this was a wrong choice from dictionaries-common many
years ago. That dir contains info supplied by packages containing
dicts that is used to help different programs requiring spellchecking
to have the relevant info. So, this is not aspell-en specific.

Regards,

-- 
Agustin

Bug#1033280: obs-worker: invalid syntax in systemd unit

[Andrej Shadura]

Package: obs-worker
Version: 2.9.4-5
Severity: grave
Justification: renders package unusable

While trying to use this package in production we found the systemd unit
to use (unsupported) shell commands instead of the syntax systemd
supports:

systemd[1]: /lib/systemd/system/obsworker@.service:13: Executable "(cd" not 
found in path "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
systemd[1]: obsworker@0.service: Unit configuration has fatal error, unit will 
not be started.

This prevents the package from being usable.

Bug#1033279: the clamav-freshclam package fails to upgrade on Debian 11

[Giancarlo Giesa]

package: clamav-freshclam
version: 0.103.8+dfsg-0+deb11u1

description: the clamav upgrade via apt-get failed
the reason seems to be that the file /var/log/clamav/freshclam.log is 
not detected but instead this exists


proceeding with the command dpkg --configure -a does not solve the problem.

some output:

root@nas:~# dpkg --configure -a
Setting up clamav-freshclam (0.103.8+dfsg-0+deb11u1) ...
touch: cannot touch '"/var/log/clamav/freshclam.log"': No such file or 
directory

dpkg: error processing package clamav-freshclam (--configure):
 installed clamav-freshclam package post-installation script subprocess 
returned error exit status 1

dpkg: dependency problems prevent configuration of clamav-daemon:
 clamav-daemon depends on clamav-freshclam (>= 0.103.8+dfsg) | 
clamav-data; however:

  Package clamav-freshclam is not configured yet.
  Package clamav-data is not installed.
  Package clamav-freshclam which provides clamav-data is not configured 
yet.


dpkg: error processing package clamav-daemon (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of areos-debian-11:
 areos-debian-11 depends on clamav-daemon; however:
  Package clamav-daemon is not configured yet.

dpkg: error processing package areos-debian-11 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of clamav:
 clamav depends on clamav-freshclam (>= 0.103.8+dfsg) | clamav-data; 
however:

  Package clamav-freshclam is not configured yet.
  Package clamav-data is not installed.
  Package clamav-freshclam which provides clamav-data is not configured 
yet.


dpkg: error processing package clamav (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 clamav-freshclam
 clamav-daemon
 areos-debian-11
 clamav




but the file "/var/log/clamav/freshclam.log" is readable:
root@nas:~# cat /var/log/clamav/freshclam.log
ClamAV update process started at Sun Mar 19 00:00:00 2023
Current working dir is /var/lib/clamav/
Querying current.cvd.clamav.net
TTL: 1797
fc_dns_query_update_info: Software version from DNS: 0.103.8
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.103.7 Recommended version: 0.103.8
DON'T PANIC! Read https://docs.clamav.net/manual/Installing.html
[.]

Bug#1032691: More rinse/fedora-37 URL problems

[Benjamin Burton]

Hi - I couldn't install fedora-37 on arm64 today either - the aarch64 location 
encoded in /etc/rinse/rinse.conf did not exist.

I expect what’s going on is that release.fedoraproject.org 
 redirects to one of many mirrors, and both 
Dima and I landed on a mirror that did not include the specific release/arch 
combination that we were after.

What I’ve done locally in my own /etc/rinse/rinse.conf is hard-code the mirror 
location:

[fedora-37]
...
mirror.arm64 = 
https://ap.edge.kernel.org/fedora/releases/37/Everything/aarch64/os/Packages/

- Ben.

--

Prof. Benjamin Burton
Computational Geometry & Topology Group
School of Mathematics and Physics
The University of Queensland, Australia

UQ ALLY   ::   Supporting and celebrating the diversity of sexuality, gender 
and sex at UQ.   Pronouns: He, him, his

Bug#1033044: daily cron job broken?

[tommy reid]

Never broken

On Thu, Mar 16, 2023, 5:45 AM Marc Haber 
wrote:

> Package: aide-common
> Version: 0.18.1-1
> Severity: grave
> Tags: confirmed
>
> Justification: Maintainer discretion, cron job broken
>
> diff --git a/debian/bin/dailyaidecheck b/debian/bin/dailyaidecheck
> index aa4b59c..fbd0a57 100755
> --- a/debian/bin/dailyaidecheck
> +++ b/debian/bin/dailyaidecheck
> @@ -161,7 +161,7 @@ FILTERUPDATES="${FILTERUPDATES:-no}"
>  FILTERINSTALLATIONS="${FILTERINSTALLATIONS:-no}"
>  CRONEXITHOOK="${CRONEXITHOOK:-}"
>  ONEXIT=""
> -AIDEUSER="${AIDEUSER:-root}"
> +AIDEUSER="${AIDEUSER:-$(id --user --name)}"
>  AIDEUSERUID="$(id --user "${AIDEUSER}")"
>
>  # silent implies quiet
>
> And upload will follow shortly.
>
> Greetings
> Marc, Maintainer
>
>

Bug#925424: linux-image-amd64: Build the Silead touchscreen controller kernel driver

[Gregor Riepl]

Hi Debian kernel team,

It's been 4 years, and the Debian kernel is still lacking out-of-the-box 
support for Silead touchscreen controllers and corresponding DMI quirks.


Can you please enable these options?


CONFIG_TOUCHSCREEN_SILEAD=m
CONFIG_TOUCHSCREEN_DMI=y


Thank you very much.

Bug#1033243: puppet: apt install puppet and puppet modules clash with official upstream repo

[Renato Gallo]

Just to see what am I failing,
Can you please tell me what would you put into apt preferences and even
elsewhere to be positively sure I am NOT using the puppet/foreman debian
packages ?

Thank you in advance

On Mon, 20 Mar 2023 13:39:33 -0400
=?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?=  wrote:
> tags 1033243 wontfix
> thanks
>
> Hello,
>
> Generally, the Puppet ecosystem as packaged in the Debian archive isn't
> compatible with the upstream repositories and we currently don't plan to
> fix this.
>
> Files are not installed in the same directories, versions won't be the
> same and you'll experience weird breakage, like the one you seem to have.
>
> If you absolutely need to use upstream's repositories, I would thus
> recommend you don't use any of the Debian packages.
>
> If you want to keep using the Debian packages and you need Puppet
> modules that aren't packaged in the Debian, a more common workflow would
> be to use the Debian packages, but download Puppet modules either
> "manually" via git or from the Puppet forge.
>
> --
>⢀⣴⠾⠻⢶⣦⠀
>⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
>⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
>⠈⠳⣄

Bug#1033250: [Pkg-javascript-devel] Bug#1033250: Bug#1033250: node-request: CVE-2023-28155

[Pirate Praveen]

Control: block -1 by 956423

On Tue, Mar 21 2023 at 12:05:15 PM +05:30:00 +05:30:00, Pirate Praveen 
 wrote:

$ reverse-depends node-request

Reverse-Depends
===
* node-jsonld
* node-matrix-js-sdk
* yarnpkg

For yarnpkg, we are trying to remove the dependency to node-request, 
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980316#43 
(hopefully we will be able to remove it for trixie).


Asking yarn upstream as well, if we can remove dependency on request
https://github.com/yarnpkg/yarn/issues/8935

Bug#878599: [PATCH] Ship git-libsecret

[M Hickford]

The difficulty of installing git-credential-libsecret on Debian and
Ubuntu was recently discussed on the Git mailing list
https://lore.kernel.org/git/y2rdw7rd8mgtf...@tapette.crustytoothpaste.net/

Any chance to take another look at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878599#39 ?

Other distros name the package git-credential-libsecret matching the binary name
https://pkgs.org/search/?q=git-credential-libsecret . This is easiest
for users. If Debian chooses a different package name, it would be
helpful to specify `Provides: git-credential-libsecret`
https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides

Bug#1033250: [Pkg-javascript-devel] Bug#1033250: node-request: CVE-2023-28155

[Pirate Praveen]

On Mon, Mar 20 2023 at 07:34:33 PM +01:00:00 +01:00:00, Moritz 
Mühlenhoff  wrote:

Source: node-request
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for node-request.

CVE-2023-28155[0]:
| ** UNSUPPORTED WHEN ASSIGNED ** The Request package through 2.88.1 
for
| Node.js allows a bypass of SSRF mitigations via an 
attacker-controller
| server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS 
to

| HTTP). NOTE: This vulnerability only affects products that are no
| longer supported by the maintainer.

https://github.com/request/request/issues/3442 was reported, but seems
the module is EOLed, so maybe we should be looking into retiring it
for trixie?


$ reverse-depends node-request
Reverse-Depends
===
* node-jsonld
* node-matrix-js-sdk
* yarnpkg

For yarnpkg, we are trying to remove the dependency to node-request, 
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980316#43 
(hopefully we will be able to remove it for trixie).



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-28155
https://www.cve.org/CVERecord?id=CVE-2023-28155

Please adjust the affected versions in the BTS as needed.

--
Pkg-javascript-devel mailing list
pkg-javascript-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#1032787: vfu: cat not open file with special characters in it's name

[Anonymous 648]

Hi Vladi.

I use zsh (5.8-6+deb11u1)

On Mon, Mar 20, 2023 at 11:37:59PM +0200, Vladi Belperchinov-Shabanski wrote:


hi!

fixed in vslib for "|".
still not sure if there is ever need for "%" but added for now:
(btw, what shell do you use?)

vslib
commit ecdba011eef270083320fadd5e1a0407294fb3b2 (HEAD -> master)
Date:   Mon Mar 20 23:35:15 2023 +0200

thanks!

P! Vladi.

--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu