Bug#976077: nvidia-cuda-toolkit: Package depends on inexistent version of g++ (gg+-10)

[Andrea Pappacoda]

Package: nvidia-cuda-toolkit
Version: 11.1.1-2
Severity: normal

This package depends on "gg+-10", a package that does not exist.
I think this is a typo, so I'm reporting the issue.
This makes impossible to satisfy dependencies just with gcc-10.



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

Kernel: Linux 5.8.18 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 nvidia-cuda-toolkit depends on:
ii  g++-88.4.0-4
ii  gcc-10   10.2.0-16
ii  gcc-88.4.0-4
ii  gcc-99.3.0-18
ii  libc62.31-4
ii  libgcc-s110.2.0-16
ii  libstdc++6   10.2.0-16
ii  nvidia-cuda-dev  11.1.1-2
ii  nvidia-opencl-dev11.1.1-2
ii  nvidia-profiler  11.1.1-2
ii  ocl-icd-opencl-dev [opencl-dev]  2.2.13-1

Versions of packages nvidia-cuda-toolkit recommends:
ii  nsight-compute   11.1.1-2
ii  nsight-systems   11.1.1-2
ii  nvidia-cuda-gdb  11.1.1-2
ii  nvidia-cuda-toolkit-doc  11.1.1-2
ii  nvidia-visual-profiler   11.1.1-2

Versions of packages nvidia-cuda-toolkit suggests:
ii  nvidia-driver  450.80.02-1

-- no debconf information

Bug#976960: systemd: Please package systemd-userdb and systemd-homed

[Andrea Pappacoda]

Followup-For: Bug #976960
Package: systemd
Version: 247.2-5

I think that systemd-homed should be packaged from Debian
just for the simple reason of giving users choice.

> I still fail to see the use-case for homed, tbh and the current
> implementation still requires quite a few hacks (see the fosdem 2020
> talk of Lennart and the problems e.g. with SSH keys).

For example I have a persistent live system installed on a USB stick
that I share with some friends. Full disk encryption would be hard to implement
and not that useful, and it would be better to encrypt on a per-user basis. 
SSH is not an issue in this case, since a USB stick does not need to be 
accessed remotely.

I know that this is not the most common use case, but giving the user choice 
and not imposing anything controversial by default is a better approach, in my 
opinion.

Bug#980609: missing i386-cpuinfo.h

[Andrea Pappacoda]

Followup-For: Bug #980609
source: gcc-10

Is this fix going to be backported to bullseye/sid? I'm too facing this issue 
with gcc-10 10.2.1-6.

Bug#989885: nvidia-driver: package should recommend libnvidia-encode1

[Andrea Pappacoda]

Package: nvidia-driver
Version: 460.73.01-1
Severity: wishlist

libnvidia-encode1 contains the library needed to use NVENC, used to encode
videos on the GPU, and depends on libnvcuvid1, needed for NVDEC, the video
decoder.
They are part of the Nvidia driver, and some users, especially inexperienced
ones, would expect to have support for them after installing the nvidia-driver
package.
Another solution would be to just mark it as suggested by nvidia-driver, so
that it is easier to find.

-- Package-specific info:
uname -a:
Linux tachi-debian-1070 5.10.31 #1 SMP PREEMPT Thu Apr 22 19:21:16 CEST 2021 
x86_64 GNU/Linux

/proc/version:
Linux version 5.10.31 (tachi@tachi-debian-1070) (gcc (Debian 10.2.1-6) 10.2.1 
20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PREEMPT Thu Apr 22 
19:21:16 CEST 2021

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module 460.73.01 Thu Apr 1 21:40:36 UTC 
2021
GCC version: gcc version 10.2.1 20210110 (Debian 10.2.1-6)

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 
1070] [10de:1b81] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd GP104 [GeForce GTX 1070] [1458:3701]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video 226, 0 Jun 15 09:05 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Jun 15 09:05 /dev/dri/renderD128
crw-rw-rw- 1 root root 195, 254 Jun 15 09:05 /dev/nvidia-modeset
crw-rw-rw- 1 root root 195, 0 Jun 15 09:05 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Jun 15 09:05 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Jun 15 09:05 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Jun 15 09:05 pci-:01:00.0-render -> ../renderD128
video:x:44:tachi

OpenGL and NVIDIA library files installed:
-rw-r--r-- 1 root root 1188 Feb 15 2020 /etc/X11/xorg.conf
lrwxrwxrwx 1 root root 15 May 5 2020 /etc/alternatives/glx -> /usr/lib/nvidia
lrwxrwxrwx 1 root root 49 May 3 18:22 
/etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so
lrwxrwxrwx 1 root root 49 May 5 2020 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 51 May 5 2020 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root 48 May 3 18:22 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 May 3 18:22 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 May 5 2020 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 48 May 5 2020 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 50 May 5 2020 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 50 May 5 2020 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root 55 May 5 2020 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 55 May 5 2020 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 57 May 5 2020 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 57 May 5 2020 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 52 May 5 2020 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 52 May 5 2020 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 54 May 5 2020 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 54 May 5 2020 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root 42 May 5 2020 
/etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root root 42 May 5 2020 
/etc/alternatives/glx--libGLX_indirect.so.0-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
lrwxrwxrwx 1 root 

Bug#988219: meson: Move package into unstable

[Andrea Pappacoda]

Ok, I didn't knew that, thank you! Il 9 mag 2021 04:28 Jussi Pakkanen 
 ha scritto:
>
> On Sun, 9 May 2021 at 02:17, Andrea Pappacoda  wrote: 
>
> > I may be wrong, but I thought that only testing (bullseye) was under a 
> > freeze, while unstable (sid) is free to receive updates. For example, 
> > looking at the chromium package tracker (tracker.debian.org/pkg/chromium) 
> > the package has been updated to version 90 in unstable a few days ago, 
> > while freezed at version 89 in testing. 
>
> Build systems have a separate, stricter freeze. 

Bug#988219: meson: Move package into unstable

[Andrea Pappacoda]

Package: meson
Version: 0.58.0-1
Severity: wishlist

Since Meson 0.57.1 Meson has been only packaged for experimental, even if it 
seems that there isn't a good reason for it. Could it please be moved to 
unstable? This also makes updated version unavailable for Ubuntu. 
Thanks :) 


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

Kernel: Linux 5.10.31 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 meson depends on:
ii  ninja-build1.10.1-1
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-3

Versions of packages meson recommends:
ii  dpkg-dev  1.20.9

meson suggests no packages.

Bug#990415: autopkgtest: autopkgtest-build-qemu installs grub-pc on non-x86 architectures

[Andrea Pappacoda]

> The version of autopkgtest-build-qemu included in autopkgtest 5.16
> (which was current at freeze time) has never supported anything other
> than BIOS boot, and therefore can't work on anything except x86.
>
> Newer development versions, which have not yet been released, support
> a --boot={auto,bios,efi,ieee1275,none} option and default to --boot=efi
> on ARM architectures.

Thank you very much for the response, I thought I was doing something wrong...

So for the time being we can't use autopkgtest to build non-x86 images, right? 
Are there any workarounds? If not, I'll patiently wait for a new release :)

Bug#990415: autopkgtest: autopkgtest-build-qemu installs grub-pc on non-x86 architectures

[Andrea Pappacoda]

> I do not know of any workarounds other than using autopkgtest-build-qemu
> from git. The qemu code in autopkgtest 5.16 was written with x86 and
> BIOS-boot assumptions, and the necessary generalizations and
> architecture-specific quirks to deal with EFI and other architectures
> simply weren't there.

Ok, I'll use the tool from source, luckily it is implemented in python and I 
don't have to build it or anything.

> I'll try to get a new autopkgtest uploaded to experimental at some point,
> which will close this bug.


An upload to experimental would be highly appreciated :)


Thanks again

Bug#990415: autopkgtest: autopkgtest-build-qemu installs grub-pc on non-x86 architectures

[Andrea Pappacoda]

Package: autopkgtest
Version: 5.16
Severity: important

When running `autopkgtest-build-qemu --architecture arm64 testing image.img` 
the image builder tries to install grub-pc, resulting in a failure. 

You can take a look at this log: 
https://github.com/Tachi107/pistache/runs/2931528898

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

Kernel: Linux 5.10.46 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 autopkgtest depends on:
ii  apt-utils   2.2.4
ii  libdpkg-perl1.20.9
ii  procps  2:3.3.17-5
ii  python3 3.9.2-3
ii  python3-debian  0.1.39

Versions of packages autopkgtest recommends:
ii  autodep8  0.24

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  2020.11-2
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:5.2+dfsg-10+b2
pn  schroot   
ii  vmdb2 0.22-1

Bug#983505: doas: persist option does not work

[Andrea Pappacoda]

Package: doas
Version: 6.8.1-2
Severity: important

The manpage of doas.conf(5) says that the persist option can be user to make 
doas not ask for the user's password every time the command is ran.
Unfortunately, this option seems to be broken, as it doesn't do anything.

Thanks for packaging this openbsd port! 

Bug#983505: doas: persist option does not work

[Andrea Pappacoda]

"Scupake" scup...@riseup.net – 25 febbraio 2021 23:16
> Oh, right, almost forgot about that. That feature has to be enabled
> using the --with-timestamp configue flag. I'll add that flag in -3.
> Thank you for reminding me!


I'll wait for the update, thanks again :)

Bug#993508: RFS: howardhinnant-date/3.0.1-1 [ITP] -- date and time library based on the C++ header

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: martin.quin...@ens-rennes.fr

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

I am looking for a sponsor for my package "howardhinnant-date":

 * Package name: howardhinnant-date
   Version : 3.0.1-1
   Upstream Author : Howard Hinnant 
 * URL : https://github.com/HowardHinnant/date
 * License : Expat
 * Vcs : https://github.com/HowardHinnant/date.git
   Section : libs

It builds those binary packages:

  libhowardhinnant-date-tz3 - date and time library based on the C++ 
header
  libhowardhinnant-date-dev - date and time library based on the C++ 
header - development files

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

  https://mentors.debian.net/package/howardhinnant-date/

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

  dget -x https://mentors.debian.net/debian/pool/main/h/howardhinnant-
date/howardhinnant-date_3.0.1-1.dsc

Changes since the last upload:

 howardhinnant-date (3.0.1-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #895222

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYTCm0xQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRD/yQfijUdG7SCyAP9B+9t+Lhpaeqa+UjyuzcyWFZ13jdbK
k4YK0FoUH2EfagEAmNYX6tua6Rd6ndq9xySvoqOdX74/USSAPZIJ2NbzPgc=
=cGa3
-END PGP SIGNATURE-

Bug#983505: Help progress for doas persistence

[Andrea Pappacoda]

> The bug is lingering for 7 months and I want to help this to 
progress if I can..


This was fixed 6 months ago in the packaging Git repository (see 
https://salsa.debian.org/debian/doas/-/commit/4686a00819d963b88b5982fe57cf6cf717765997), 
but the maintainer never pushed the update to the Debian archive (maybe 
Scupake thought that he already did that?).


You could try building the package from the repository if you really 
want to use the persist feature.

Bug#963901: O: glm -- C++ library for OpenGL GLSL type-based mathematics

[Andrea Pappacoda]

> I intend to orphan the glm package.

Hi, I would like to maintain the glm package. I'm not a Debian 
maintainer, but I'm trying to become one (see 
https://mentors.debian.net/packages/uploader/and...@pappacoda.it/ ).


I've used glm in the past and upstream doesn't release often... A 
perfect place to start, right? :)


How can I start maintaining the package?

Thanks

Bug#994681: mbedtls: Enable CMAC support

[Andrea Pappacoda]

Package: mbedtls
Version: 2.16.9-0.1
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi James, I'm looking into packaging yuzu ( https://bugs.debian.org/947399 ),
and MbedTLS is one its dependencies. They require an LTS version of the library
with CMAC support enabled, so I'm asking if you could enabled it in d/rules.
The feature is also enabled by default in MbedTLS 3.0.0, and is considered safe
to use.

Speaking of 3.0.0 features, I noticed that you enabled MD2, MD4 and the HAVEGE
module; they have been all removed in the new version, and, considering the
fact that they are considered insecure and their use is discouraged by upstream
you could consider disabling them if possible.

Lastly, upstream provides a handy script (scripts/config.py) that can be used
to easily update include/mbedtls/config.h, so that you don't have to maintain
your own version of it in d/rules :)

If you would like some help to maintain the package I'd be happy to lend a
hand.

Thanks.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYUcaoRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSfiiAQDE+EyQY93kucJT+FHGrRWbuX62GsbF
c9WzpYymqSXvrgEAjBEEgcb7C8dT3Hg5A5aHYSF1cYw30l0wE5JveRRtgAU=
=Xm0C
-END PGP SIGNATURE-
>From 68aec014e876273af8ecac359a4c0f084dc21eab Mon Sep 17 00:00:00 2001
From: Andrea Pappacoda 
Date: Sun, 19 Sep 2021 13:06:29 +0200
Subject: [PATCH] d/rules: enable MBEDTLS_CMAC_C

---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index afb96904..39f1492a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,6 +31,7 @@ override_dh_auto_configure:
$(call CONFIG_ENABLE,MBEDTLS_MD4_C)
$(call CONFIG_ENABLE,MBEDTLS_THREADING_C)
$(call CONFIG_ENABLE,MBEDTLS_THREADING_PTHREAD)
+   $(call CONFIG_ENABLE,MBEDTLS_CMAC_C)
dh_auto_configure -- \
 -DLIB_INSTALL_DIR=lib/$(DEB_HOST_MULTIARCH) \
 -DUSE_STATIC_MBEDTLS_LIBRARY=ON \
-- 
2.33.0

Bug#994483: meson: import('python').find_installation() requires python3-distutils

[Andrea Pappacoda]

Package: meson
Version: 0.59.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

import('python').find_installation() requires the distutils.core Python module,
found in the python3-distutils package.

Meson should depend on that package as well.

See upstream bug
https://github.com/mesonbuild/meson/issues/4267#issuecomment-920919273


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

Kernel: Linux 5.10.46 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 meson depends on:
ii  ninja-build1.10.1-1
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-4

Versions of packages meson recommends:
ii  dpkg-dev  1.20.9

meson suggests no packages.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYUNM1hQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRD/yQfijUdG7feVAP0QKfO72AAh8fobXGE1ei32RlP6dYRl
qUI2iO+t8015ugEAsXLBJ73u9Z5xQBrdZF1DQNAA6vexhb/TT0R90lN1tQk=
=bp3q
-END PGP SIGNATURE-

Bug#994547: ITP: cpp-httplib -- C++ HTTP/HTTPS server and client library

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: cpp-httplib
  Version : 0.9.3+ds-1
  Upstream Author : Yuji Hirose 
* URL : https://github.com/yhirose/cpp-httplib
* License : Expat
  Programming Lang: C++
  Description : C++ HTTP/HTTPS server and client library

cpp-httplib is a C++11 cross platform HTTP/HTTPS library, with a focus on ease
of use. This is a multi-threaded 'blocking' HTTP library. If you are looking
for a 'non-blocking' library, this is not the one that you want.

This is a dependency of the yuzu emulator, see https://bugs.debian.org/947399

I'll upload the package to mentors soon.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYUSp3xQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRD/yQfijUdG7Yg/AQC0RAnyhQjCJWJRATBAn12rlEuoHGKW
yiNk/M0MNaQLbgD/YzUq2w429BNNi/fl6hAUUjHYunaLjh2IvQh37bpL3Ao=
=iguS
-END PGP SIGNATURE-

Bug#994556: RFS: cpp-httplib/0.9.4+ds-1 [ITP] -- C++ HTTP/HTTPS server and client library

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

I am looking for a sponsor for my package "cpp-httplib":

 * Package name: cpp-httplib
   Version : 0.9.4+ds-1
   Upstream Author : Yuji Hirose 
 * URL : https://github.com/yhirose/cpp-httplib
 * License : Expat
 * Vcs : https://github.com/yhirose/cpp-httplib
   Section : libs

It builds those binary packages:

  libcpp-httplib-dev - C++ HTTP/HTTPS server and client library - development
files
  libcpp-httplib0 - C++ HTTP/HTTPS server and client library

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

  https://mentors.debian.net/package/cpp-httplib/

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

  dget -x https://mentors.debian.net/debian/pool/main/c/cpp-httplib/cpp-
httplib_0.9.4+ds-1.dsc

Changes for the initial release:

 cpp-httplib (0.9.4+ds-1) UNRELEASED; urgency=low
 .
   * Initial release. Closes: #994547

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYUTLcRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRD/yQfijUdG7Vt+AQDPUIZ5fXlYxJ7INpcAOqydJJgMKVNa
sq4Hqr2rKsIFOQD8DKqcDsxEfetYV5U8XIl/aydnwCpvGOBIBGpAFNyTtgU=
=hS/v
-END PGP SIGNATURE-

Bug#995059: ITP: cubeb -- cross platform audio library

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: cubeb
  Version : 0.0~git20210801.6ce9596+ds-1
  Upstream Author : Mozilla Foundation
* URL : https://github.com/mozilla/cubeb
* License : ISC
  Programming Lang: C++, C
  Description : Cross platform audio library

cubeb is a cross platform audio library most notable for its use as the audio
backend within Gecko, Mozilla's browser engine. It supports multiple audio
backends and allows enumeration of audio devices and opening audio streams with
control over latency, sample rate and more.

This is a dependency of the yuzu emulator, see https://bugs.debian.org/947399

I'll upload the package to mentors soon.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYU8nlRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSW64AQD24d7gTbE/jpXmO4uwIfqNvlvNkdy1
5vJuIk81nphCvgD+JcWY6C3kV7VM9O0BfAA/MoFjoBM+5mmnPbMzqEU5Wws=
=gpwq
-END PGP SIGNATURE-

Bug#995884: ITP: zycore-c -- Zyan Core Library for C

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: zycore-c
  Version : 1.0.0
  Upstream Author : zyantific 
* URL : https://github.com/zyantific/zycore-c
* License : Expat
  Programming Lang: C
  Description : Zyan Core Library for C

Internal library providing platform independent types, macros and a fallback
for environments without LibC.

This is a dependency of Dynarmic, a dependency of the yuzu emulator -
https://bugs.debian.org/947399


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYV8edxQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSSHIAQDu4MylvOAgPfIl+nOHbZbs1C8C5rbM
8PeLOtZLuB7v6AEAm4BECL5aYeJ64g5PjJsu62GdzhgHIfD6e51emQGbsgM=
=Mk4T
-END PGP SIGNATURE-

Bug#995891: RFS: zycore-c/1.0.0-1 [ITP] -- Zyan Core Library for C

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

I am looking for a sponsor for my package "zycore-c":

 * Package name: zycore-c
   Version : 1.0.0-1
   Upstream Author : zyantific 
 * URL : https://github.com/zyantific/zycore-c
 * License : Expat
 * Vcs : https://github.com/zyantific/zycore-c
   Section : libs

It builds those binary packages:

  libzycore-dev - Zyan Core Library for C - development
  libzycore1 - Zyan Core Library for C

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

  https://mentors.debian.net/package/zycore-c/

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

  dget -x https://mentors.debian.net/debian/pool/main/z/zycore-c/zycore-
c_1.0.0-1.dsc

Changes for the initial release:

 zycore-c (1.0.0-1) unstable; urgency=low
 .
   * Initial release. Closes: #995884

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYV9VdRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSapRAQCaKUSYg2z7BVx31b26xG0lRS/E7g8S
ebpAMowgs0CJbAD9ERQnR0jFjQv0jQIQIbcS55NbgPDegSRy1AWyouvmAwE=
=Vg7d
-END PGP SIGNATURE-

Bug#996390: libzydis-dev: description says that "all" x86 extensions are supported

[Andrea Pappacoda]

Hi, I agree that the description should be changed, especially after 
the discussion we had in upstream's issue ticket. Unfortunately I'm not 
at all familiar with advanced instructions sets, so I wouldn't be able 
to determine an appropriate description that mentions the precise list 
of supported extensions.


Even if this is not a perfect solution, I think I could reword the 
sentence to something like "It supports all x64 and AMD64 instructions 
and many vendor extensions", or maybe entirely remove "and extensions" 
(I think that "instructions" means the standard x86/AMD64 instruction 
set and "extensions" refers to all the various extra instructions added 
by the various vendors, right?)


Thanks again for your help.

Bug#995993: RFS: zydis/3.1.0-1 [ITP] -- fast and lightweight x86/x86-64 disassembler library

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name: zydis
   Version : 3.1.0-1
   Upstream Author : zyantific 
 * URL : https://zydis.re
 * License : Expat
   Section : libs

It builds those binary packages:

  libzydis-dev - fast and lightweight x86/x86-64 disassembler library -
development
  libzydis3.1 - fast and lightweight x86/x86-64 disassembler library

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/z/zydis/zydis_3.1.0-1.dsc

Changes for the initial release:

 zydis (3.1.0-1) unstable; urgency=low
 .
   * Initial release. Closes: #995921

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYWHGABQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSWmMAQCPNODE2jzrDOrHuJengmbyDEVYgjGm
o2a0Mnej8iPqFwEAiXiqePle70zr/zCiObIH+uV1jlrgjuPhOYRW4CmoJAo=
=fMxW
-END PGP SIGNATURE-

Bug#995917: ITP: dynarmic -- ARM dynamic recompiler

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: dynarmic
  Version : 5
  Upstream Author : MerryMage 
* URL : https://github.com/merryhime/Dynarmic
* License : 0BSD
  Programming Lang: C++
  Description : ARM dynamic recompiler

Dynarmic is a dynamic recompiler for the ARMv6K, ARMv7A architecture, with
partial ARMv8 support.
.
In the pursuit of speed, some behavior not commonly depended upon is elided.
Therefore this emulator does not match spec.

This is a dependency of the yuzu emulator - https://bugs.debian.org/947399


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYV/69BQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSX3DAQCRKKEaB7oTLyPyCrVanUKFklZSxRg2
hmUSgjyVbPJH7AD+NsQiKZw3wJKgcB0oOqgmLwVHn8qHkTOSONrlTq9rkAE=
=yXz0
-END PGP SIGNATURE-

Bug#996653: RFS: dynarmic/5+git20211012.cce7e4e+ds-1 [ITP] -- ARM dynamic recompiler

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name: dynarmic
   Version : 5+git20211012.cce7e4e+ds-1
   Upstream Author : MerryMage 
 * URL : https://github.com/merryhime/dynarmic
 * License : 0BSD
   Section : libs

It builds those binary packages:

  libdynarmic5 - ARM dynamic recompiler
  libdynarmic-dev - ARM dynamic recompiler - development

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/dynarmic/dynarmic_5+git20211012.cce7e4e+ds-1.dsc

Changes for the initial release:

 dynarmic (5+git20211012.cce7e4e+ds-1) unstable; urgency=low
 .
   * Initial release. Closes: #995917

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYWstVhQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRD/yQfijUdG7VGiAQC1ZMt5Empo4/tAGddW8q0fIVmz6ncr
ZAkWwOkft9mAUQEA5sZ3uI3hhmgMYUbmBrycBVw5mHI1zgTLPhDWNyVIRA8=
=TBzT
-END PGP SIGNATURE-

Bug#996681: RFS: vixl/5.1.0-1 [ITP] -- ARMv8 Runtime Code Generation Library

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name: vixl
   Version : 5.1.0-1
   Upstream Author : Linaro 
 * URL : https://github.com/Linaro/vixl
 * License : BSD-3-Clause
   Section : libs

It builds those binary packages:

  libvixl5 - ARMv8 Runtime Code Generation Library
  libvixl-dev - ARMv8 Runtime Code Generation Library - develop

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/v/vixl/vixl_5.1.0-1.dsc

Changes for the initial release:

 vixl (5.1.0-1) unstable; urgency=low
 .
   * Initial release. Closes: #996576

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQSlw/BqXszDGx3GlQz/yQfijUdG7QUCYWv6DhQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRD/yQfijUdG7SwJAP9yobj+Zugm/eazcZpmfXmitNZ4c67N
LJv191MM8WeazQD/fBHupNiOxNv56I8uNEz3cDByqqgOm/U6aef/HakzAgk=
=DUYi
-END PGP SIGNATURE-

Bug#995011: extrepo: missing most of the external repositories

[Andrea Pappacoda]

Package: extrepo
Version: 0.9
Followup-For: Bug #995011

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is likely caused by commit 6b263308 (https://salsa.debian.org/extrepo-
team/extrepo/-/commit/6b2633080e0f19d88f0561af426ac8a46e6180e2). Here's what I
think happened (from my comment on that commit):

This [commit 6b263308] makes most third party repos not available, since they
are marked as compatible only with buster, bullseye and sid. All the supported
repos in extrepo-data must also be updated. vscodium is an example; it is
supported on all Debian distros (the binary is statically linked), but extrepo-
data/repos/debian/vscodium.yaml only lists buster, bullseye and sid as
supported.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYW2c9BQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSfOVAP47BbDNKi41FfSS/R8B7SoT9vDe7VF4
2ENjqNgYlL/15wD+I6lJf8t3+9IanDOroXSb65rUT89tRz4n+T0S4l44sg4=
=OMbW
-END PGP SIGNATURE-

Bug#996576: ITP: vixl -- ARMv8 Runtime Code Generation Library

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: vixl
  Version : 5.1.0
  Upstream Author : Linaro 
* URL : https://github.com/Linaro/vixl
* License : BSD-3-Clause
  Programming Lang: C++
  Description : ARMv8 Runtime Code Generation Library

Vixl is an AArch32 and AArch64 Runtime Code Generation Library.
.
It contains three components: assemblers to generate ARM code at runtime,
disassemblers that can print any instruction emitted by the assemblers and a
simulator that can simulate any instruction emitted by the A64 assembler.

This is a dependency of Dynarmic (#995917), a dependency of the yuzu emulator
(#947399)


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYWnBpRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuScMaAQDNanZekkb05SrxgLlWwHMBk3AyDIew
Nd4D51pi0w8icAEAyq+ZAQMFigCknG2VQpFGxnE2TOZEaigQCRowmDkKYQ4=
=HgSx
-END PGP SIGNATURE-

Bug#995921: ITP: zydis -- fast and lightweight x86/x86-64 disassembler library

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: zydis
  Version : 3.1.0
  Upstream Author : zyantific 
* URL : https://zydis.re
* License : Expat
  Programming Lang: C
  Description : fast and lightweight x86/x86-64 disassembler library

Zydis is a fast x86/x86-64 disassembler library. It supports all x86 and AMD64
instructions and extensions, doesn't perform dynamic memory allocations, is
thread safe by design and has no third party dependency - not even libc.

This is a dependency of Dynarmic, a dependency of the yuzu emulator -
https://bugs.debian.org/947399


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYWABQBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSa4yAP9zuIB8s4Af/J7eg30H5isW45r4s2Zk
3x10ooxot55BLQEAxyDW1HsL4+5LnTFxtsXaPO0FQ/m7OQtypjt/zUQOiw0=
=39M5
-END PGP SIGNATURE-

Bug#995891: RFS: zycore-c/1.0.0-1 - libzycore1 rename

[Andrea Pappacoda]

After some feedback from upstream in 
https://github.com/zyantific/zycore-c/pull/31#pullrequestreview-774974303 
I had to rename the library package from libzycore1 to libzycore1.0, 
since ABI compatibility is only guaranteed between patch (security) 
releases.

Bug#995760: ITP: xbyak -- JIT assembler for x86(IA32), x64(AMD64, x86-64)

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: xbyak
  Version : 6.00
  Upstream Author : MITSUNARI Shigeo 
* URL : https://github.com/herumi/xbyak
* License : BSD-3-Clause
  Programming Lang: C++
  Description : JIT assembler for x86(IA32), x64(AMD64, x86-64)

Xbyak is a C++ header library that enables dynamically to assemble
x86(IA32), x64(AMD64, x86-64) mnemonic.
.
The library supports any compiler supporting C++03 or later.
.
This package contains the development headers.

This is a dependency of the yuzu emulator, see https://bugs.debian.org/947399

I'll upload the package to mentors soon.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYVwUJhQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSQBjAQCtSAp2Nww3QQpUEyW/fAWKMkuzycI/
D/Z3TZkfwMIRKQD/UdkfiGKm6ZGnFZvb6uUFZuIdGq7GVbHJI5RhHjkPeAI=
=cTnP
-END PGP SIGNATURE-

Bug#995761: RFS: xbyak/6.00-1 [ITP] -- JIT assembler for x86(IA32), x64(AMD64, x86-64)

[Andrea Pappacoda]

Package: sponsorship-requests
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name: xbyak
   Version : 6.00-1
   Upstream Author : MITSUNARI Shigeo 
 * URL : https://github.com/herumi/xbyak
 * License : BSD-3-Clause
 * Vcs : https://github.com/herumi/xbyak.git
   Section : libdevel

It builds those binary packages:

  libxbyak-dev - JIT assembler for x86(IA32), x64(AMD64, x86-64)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/x/xbyak/xbyak_6.00-1.dsc

Changes for the initial release:

 xbyak (6.00-1) unstable; urgency=low
 .
   * Initial release. Closes: #995760

Regards,
- --
  Andrea Pappacoda


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYVwabRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSX0+APoD/sXMCVNWkQx/yFk7SLBvSkWhbHhw
UfhGZJiRjBbw4AEAhutoDnB0W7UkLNhe67QYnBWdgv0gCz/1GUayb3Khjw8=
=YQUG
-END PGP SIGNATURE-

Bug#976960: systemd: Please package systemd-userdbd and systemd-homed - bookworm

[Andrea Pappacoda]

Package: systemd
Version: 247.9-1
Followup-For: Bug #976960

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

> This can be reconsidered in bookworm.

Hi Michael, now that bullseye has been out for a while, do you believe this
could be part of the next release?

While enabling it by default is not yet possible (even though the SSH issues
are not unsolvable, see
https://www.freedesktop.org/software/systemd/man/userdbctl.html#Integration%20with%20SSH
and https://wiki.archlinux.org/title/systemd-homed#SSH_remote_unlocking) I
think that this could really be useful in multi-user workstations or in
schools, and to setups where security is important in general.

I'm trying to become a maintainer, and since working in a team is a good place
to start I could help you with the packaging of this particular part of systemd


- -- Package-specific info:

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 systemd depends on:
ii  adduser  3.118
ii  libacl1  2.3.1-1
ii  libapparmor1 3.0.3-2
ii  libaudit11:3.0.5-1
ii  libblkid12.37.2-1
ii  libc62.32-4
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.25-2
ii  libcryptsetup12  2:2.4.0-1
ii  libgcrypt20  1.9.4-3+b1
ii  libgnutls30  3.7.2-2
ii  libgpg-error01.42-3
ii  libip4tc21.8.7-1
ii  libkmod2 29-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.37.2-1
ii  libpam0g 1.4.0-10
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.9-1
ii  libzstd1 1.4.8+dfsg-2.1
ii  mount2.37.2-1
ii  systemd-timesyncd [time-daemon]  247.9-1
ii  util-linux   2.37.2-1

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
ii  systemd-container  247.9-1

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.9-1
ii  libpam-systemd   247.9-1
ii  udev 247.9-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYU+TnRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSVJMAP42QiyPs3uRZ+02tZ06UlQ8B7YSzX77
ehhUrbuq77NWYQEA1oFr85/d4wg2aHLPzz/0GBOYo2yRIYewAh6UKvN+WAQ=
=wuJc
-END PGP SIGNATURE-

Bug#994681: mbedtls: Enable CMAC support - new LTS branch

[Andrea Pappacoda]

Upstream has released a new LTS branch, 2.28.x; it is not ABI 
compatible with the 2.16.x branch, so it will be possible to enable 
CMAC without creating subtle ABI compatibility issues. Also, the 
upgrade is inevitable since support for 2.16.x will end in 2021.

Bug#1001895: Please ship also iso_week.h and co in libhowardhinnant-date-dev

[Andrea Pappacoda]

Hi David :)

I'm replying with this backup email because my main one
(and...@pappacoda.it) will still be unavailable for some time (I still
have to reconfigure my Postfix server...).

Those extra headers should definitely get included in the package, I
did not notice that the CMake script installs only [1] date.h :/

I'll patch this in the next revision! It will probably come after the
holidays though, as I'll busy studying / fixing my mail server /
partying.

Regarding the r-cran-tzdb package, you see my (short) discussion with
its maintainer in #998331 [2]

As for sponsoring, it would of course be nice, but in the meantime I'd
like you to ask a quick question about this package: do you think that
packaging it under libhowardhinnant-date-dev was a good idea? Because
I patched the project to install CMake config files with the
"howardhinnant-date" name instead of just "date", but its headers
still get installed to paths like "date/date.h". My reasoning for this
was to not pollute the global namespace with such a general name, but
I also wanted to not break projects correctly including date/date.h.

Thanks for reporting :)

1: 
https://github.com/HowardHinnant/date/blob/655b249b8f463f690c53a19d6b4110297699e3c5/CMakeLists.txt#L78

2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998331

Bug#999431: zydis: CVE-2021-41253

[Andrea Pappacoda]

Hi, thank you for the report. I'll update the package as soon as possible. 

Please note that I'm not yet an expert in packaging and security issues (I'm 
not even a Debian Maintainer), so please don't hesitate to correct me if I get 
something wrong :) 
Thanks.

Bug#1001319: ITP: microprofile -- embeddable CPU/GPU profiler

[Andrea Pappacoda]

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

* Package name: microprofile
  Version : 3.1
  Upstream Author : Jonas Meyer 
* URL : https://github.com/jonasmr/microprofile
* License : Expat
  Programming Lang: C, C++
  Description : embeddable CPU/GPU profiler

Microprofile is an embeddable CPU/GPU profiler with an in-app and HTML
visualizers, written in C++.

This is a dependency of the yuzu emulator.

I'm sending this with an unusual email address because my primary one
(and...@pappacoda.it) will be unavailable for at least one week.

Bug#997851: The doas package should be called opendoas

[Andrea Pappacoda]

I agree that having this package renamed to "opendoas" could result in 
fewer bug reports filled against the wrong upstream repo, but I also 
think that OpenDoas currently offers a better experience for Linux 
users. The persist feature is certainly nice, but (maybe more 
importantly) slicer69/doas had some serious security flaws that have 
been treated superficially by slicer69 [1], and Linux support is not 
its main focus.


In my opinion, users installing the "doas" package should get the 
"better" version by default, and by moving this package to "opendoas" 
and packaging slicer69/doas under "doas" this wouldn't be possible. A 
possible solution would be making "doas" a virtual package and 
packaging the two variants under "opendoas" and "slicer69-doas", both 
providing the virtual package. Just renaming this package to "opendoas" 
(without doing anything else) wouldn't be satisfactory because we 
wouldn't have any package providing doas.


I propose "slicer69-doas" since names like "universal doas" are not 
really descriptive and wouldn't help with identifying the actual 
version of doas that you're installing. But it isn't perfect, so maybe 
you have a better name :)


1. https://xn--1xa.duncano.de/slicer69-doas.html

Bug#1001731: linux: Please consider enabling CONFIG_TLS_DEVICE

[Andrea Pappacoda]

Source: linux
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I saw that you recently enabled the tls module. Great! It would also be nice to
enable CONFIG_TLS_DEVICE, so that the kernel can offload TLS handling to the
hardware, when supported (like with some network cards).

It seems that Ubuntu enabled it as well:
https://git.launchpad.net/~ubuntu-
kernel/ubuntu/+source/linux/+git/unstable/tree/debian.master/config/config.common.ubuntu?id=08e3a17135e7c81c89b6f8c78bd81090a2bfdf74#n11176

Thanks :)


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYbkAERQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSfg9AP9sVwJymbEa/nNGovOPKN9oC1V2/Vn5
b3X1Qqi8acNgGwD/U/trAdvj3a6L8YFyxOB4WXFtbtB7ucXz61mwuhHKPAU=
=v7EH

Bug#1055146: zydis: Compilation error on the LoongArch architecture

[Andrea Pappacoda]

Il giorno mer 1 nov 2023 alle 08:16:48 +00:00:00, wuruilong 
 ha scritto:

There is a compilation error for zydis on the loongarch machine.
Tested the patch attached to the email on the LoongArch machine and 
it resolved the issue.


Hi wuruilong, thanks for the patch! Since it has been upstreamed too, 
I'll look into adding it to the Zydis package soon.


Thanks again :)

Bug#1055514: opensysusers: ineffective diversion of /bin/systemd-sysusers due to /usr-merge and DEP17

[Andrea Pappacoda]

Hi Helmut, thanks for your report!

Il giorno mar 7 nov 2023 alle 18:07:56 +01:00:00, Helmut Grohne 
 ha scritto:
opensysusers diverts /bin/systemd-sysusers. systemd has moved this 
file
to /usr/bin/systemd-sysusers in version 255~rc1-1. While this change 
is
not visible in an installation, the diversion no longer matches it. 
Thus

what ends up at systemd-sysusers now depends on the order of unpacks.
The diversion has become ineffective. This is a known problem category
and documented in DEP17[1] as P3.

Usually, the recommended mitigation for this kind of problem is
duplicating the diversion (M18) such that both /bin/systemd-sysusers 
and

/usr/bin/systemd-sysusers are diverted. I'm attaching a patch for this
approach, but I think this is not the preferred solution for this 
case.


I dug deeper as to why opensysusers would divert systemd-sysusers,
talked to systemd maintainers and Thomas Goirand and read about 
#947847

in the process. Given this background, I believe that the use of a
diversion is not a good solution and this was echoed by the CTTE
decision, which declined to overrule and considered diversion a
mechanism for experimentation. Three years later and with two stable
releases including opensysusers I hope we are past the experimentation
phase. The diversion setup bears a significant downside: While the API
existing API of the sysusers interface is relatively stable, systemd
keeps adding features and when systemd calls systemd-sysusers it wants
to be able to rely on its latest features. A diverted systemd-sysusers
may not provide what is needed here. Looking deeper into policy 
sections

7.4 and 7.5, the virtual package systemd-sysusers looks similar to
mail-transport-agent where each implementation
provides+conflicts+replaces mail-transport-agent. I think opensysusers
should do the same. Once doing so, the diversion (and thus this bug)
goes away entirely. The downside is that opensysusers and systemd are 
no

longer coinstallable. I'm also attaching a patch for this.


I do agree with this reasoning. As mentioned in one of the old threads 
about this, in my opinion it would've been better to have a general, 
more restricted "sysusers" alternative command which could've been 
provided by opensysusers and systemd-sysusers, and would be used by 
things like dh_installsysusers and the like. Stepping into the 
"systemd-" namespace without actually supporting all the features *and* 
closely following new feature additions is asking for trouble. And, 
since the upstream developers (i.e. the Artix Linux maintainers) 
stopped development in favour of systemd-standalone-sysusers[1], I'm 
now more inclined to change approach and drop diversions.



I caution that Thomas Goirand disagrees with this approach and
recommends that these packages remain coinstallable and that users may
choose the implementation. On the flip side, a user cannot choose to
have systemd as the provider of systemd-sysusers when opensysusers is
installed.


I get Thomas' point, and I'd really like if I could keep offering 
opensysusers as a valid alternative to systemd-sysusers, but given its 
current state I don't think it's reasonable to keep doing so, 
especially considering that there's systemd-standalone-sysusers. One 
use case which systemd-standalone-sysusers doesn't cover though is 
support for non-Linux OSes, but to be fair opensysusers doesn't either. 
I did start working on a POSIX reimplemetation of the sysusers concept 
so that it could replace opensysusers entirely and also run on (the now 
dead) Debian/kFreeBSD and also Hurd, but never actually finished it.



A possible compromise could be that opensysusers stops diverting
systemd-sysusers and installs the symbolic link without diversion such
that systemd becomes the preferred provider when coinstalled. It could
detect removal of systemd using file triggers and then reinstate the
link. Such a setup also requires little cooperation from systemd
maintainers, but it relies on an symbolic link that is completely
untracked by dpkg, so there is some fragility to be found here whereas
the conflict is conceptually simpler.


I'm not sure I follow, but choosing an approach which isn't tracked by 
dpkg doesn't sound right to me.


In any case, something needs to be done here. The latest systemd 
upload

now declares an unversioned conflict with opensysusers. It can become
versioned once opensysusers has addressed this bug in some way.


I want to fix this too, and I really thank you for the help. I'm 
inclined to drop the diversions, but I'd first like to fully understand 
the consequences (e.g. would something break for someone?).


Bye :D

[1]: https://forum.artixlinux.org/index.php/topic,1839.0.html

Bug#1053533: mbedtls: enable MBEDTLS_NIST_KW_C

[Andrea Pappacoda]

On Thu, 05 Oct 2023 21:35:47 +0200 Jérôme Pouiller  
wrote:
> I have just noticed MBEDTLS_NIST_KW_C was not enabled (and obviously my
> project[1] depends on it).
> 
> I usually use the default config provided by mbedtls (which I believe
> enable all the possible options). Do you know if there is any reason to
> strip down this configuration?

Hi Jerome, thanks for your report.

We don't strip down mbedtls' configuration, we just use the default, which 
seems to not include NIST_KW_C. I haven't looked at this option in detail, but 
changing the config can, and probably will, break ABI. I've tried it before and 
it broke at least one package.

Hence we probably cannot enable this new option until we'll bump the SONAME, 
which isn't going to happen soon, probably.

I wish mbedtls were more modular so that we could enable new features without 
rebuilding the library, but unfortunately this isn't possible as far as I know.

We cannot enable all possible features either because it'd make mbedtls' attack 
surface way bigger for little benefit.

I'll look into this, but I probably won't be able to satisfy your request (for 
some time).

Bye!

Bug#1052312: cloudflare-ddns will FTFBS when systemd.pc changes the system unit directory

[Andrea Pappacoda]

On Wed, 20 Sep 2023 10:37:49 +0200 Helmut Grohne  wrote:
> systemd wants to change the location of system units in systemd.pc to
> point below /usr. Since the last upload, cloudflare-ddns consumes this
> value, but it fails to build once the value is changed, because it is
> only integrated into the upstream build system, but the .install file
> hard codes the location. I'm attaching a patch that fixes this future
> FTBFS.

Hi Helmut, thanks for your patch and for your work on /usr-merge!

While this fixes this specific issue, other systemd-related paths are
still hardcoded in the .install file. Is the approach you proposed here
the only way? Should I manually export all the systemd pkg-config
variables used in the upstream build system (sysusers.d, for instance)?

Thanks again :D

Bug#1041249: cpp-httplib: FTBFS on s390x: ../test/test.cc:5462: Failure

[Andrea Pappacoda]

Hi Emanuele, thank you for the info. I'm aware of that, and even reported the 
issue upstream[1], but the maintainer isn't interested in fixing it.

I would debug and maybe fix the issue myself, but as a DM I don't have easy 
access to porter boxes and honestly the long wait and inability to get access 
to all of them is quite demotivating. I have asked for an s390x porter box a 
couple of days ago and still didn't get access to it, and I'd now have to 
re-ask for and armhf one, and wait again... I'll eventually fix this, but I 
cannot now for factors outside of my control.

If you could please help debug the issue on the architectures you have access 
to I'd be very grateful. If you don't have time, no worries, I fully understand 
it, but please be patient :)

Thanks!

[1]: https://github.com/yhirose/cpp-httplib/issues/1199

Il 21 agosto 2023 10:53:23 CEST, Emanuele Rocca  ha scritto:
>I've bumped into a very similar failure on armhf too, so the problem is
>probably not s390x-specific.
>
>Note that the build succeeded on a second try.

Bug#1041491: marked as done (yuzu: FTBFS: Unmet build dependencies: glslang-tools:native)

[Andrea Pappacoda]

Il 13 agosto 2023 23:16:23 CEST, Debian Bug Tracking System 
 ha scritto:
>Your message dated Sun, 13 Aug 2023 23:13:56 +0200
>with message-id <0aa416df-8488-49ee-a38a-b57dbb2cf...@debian.org>
>and subject line Re: yuzu: FTBFS: Unmet build dependencies: 
>glslang-tools:native
>has caused the Debian Bug report #1041491,
>regarding yuzu: FTBFS: Unmet build dependencies: glslang-tools:native
>to be marked as done.
>
>This means that you claim that the problem has been dealt with.
>If this is not the case it is now your responsibility to reopen the
>Bug report if necessary, and/or fix the problem forthwith.
>
>(NB: If you are a system administrator and have no idea what this
>message is talking about, this may indicate a serious mail system
>misconfiguration somewhere. Please contact ow...@bugs.debian.org
>immediately.)
>
>

Bug#1043297: src:dynarmic: fails to migrate to testing for too long: unresolved RC issue

[Andrea Pappacoda]

On Tue, 8 Aug 2023 20:28:16 +0200 Paul Gevers  wrote:
> Source: dynarmic
> Version: 6.4.5+ds-1
> Severity: serious
> Control: close -1 6.4.8+ds-2
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> Control: block -1 by 1041270
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing 
> and unstable for more than 30 days as having a Release Critical bug in 
> testing [1]. Your package src:dynarmic has been trying to migrate for 33 
> days [2]. Hence, I am filing this bug. The version in unstable has an 
> unresolved RC issue as reported in bug 1041270.
> 
> If a package is out of sync between unstable and testing for a longer 
> period, this usually means that bugs in the package in testing cannot be 
> fixed via unstable. Additionally, blocked packages can have impact on 
> other packages, which makes preparing for the release more difficult. 
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that 
> hamper the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new 
> bugs, there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if 
> that version or a later version migrates, this bug will no longer affect 
> testing. I have also tagged this bug to only affect sid and trixie, so 
> it doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to 
> issues beyond your control, don't hesitate to contact the Release Team.

Hi, I have fixed this issue a while ago, and uploaded the fixed package to 
Mentors since it consists in a SONAME bump and I cannot upload it myself.

If you could please upload the package for me, it'd be really nice. There's not 
much to review anyway. You can find it on 
.

Sorry for the possibly broken reply, I'm on my phone.

Thanks!

Bug#929593: ITP: pistache -- C++ REST framework

[Andrea Pappacoda]

On Tue, 13 Sep 2022 21:56:36 +0200 Bastian Germann  
wrote:

> Is there a particular reason why pistache should be in Debian?
> There are already a number of similar HTTP libraries and this 
package is not very common amongst other Linux distros.


Yes. Upstream has been wanting to be included in Debian for a long time 
(see issue [#228] in upstream's bug tracker), and apart from that this 
particular framework is able to be highly performant while remaining 
user friendly, something that's not provided by all the alternatives. 
I've used it in the past as part of my high school thesis and wasn't 
disappointed.


It also has almost three thousand "GitHub stars", and that usually 
means that the project is at least used by somebody.


I started helping with upstream maintenance after using it in my 
project, focusing on non-core stuff (mostly the build system and 
continuous integration).


As for the fact that the package is not common amongst other distros I 
believe that's because the first release was only tagged a month ago.


Lastly, as a former user, I wished the library was available in Debian 
back when I was using it; it would've made things easier :)


[#228]: https://github.com/pistacheio/pistache/issues/228

--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1022533: foot: missing dependency on libutf8proc

[Andrea Pappacoda]

Package: foot
Version: 1.13.1-1
Severity: normal
Tags: patch

Hi, foot is currently compiled without grapheme clustering, as its
debian/control file doesn't specify libutf8proc-dev in its Build-Depe
ndencies. You can check this by running:

$ foot --version
foot version: 1.13.1 -pgo +ime -graphemes -assertions

It'd be also great if you'd consider building with PGO (Profile-Guided
Optimizations), as upstream recommends doing so to optimize foot'
s latency; a set of scripts is provided to make use of PGO relatively easy. But
that's another issue :)

For more information about foot and it's build process, see upstream's
INSTALL.md file: <https://salsa.debian.org/birger/foot/-/blob/mas
ter/INSTALL.md>

I've included a patch fixing this issue; I've also added systemd to the list of
Build-Dependencies, as upstream's build process only installs systemd unit
files if systemd's pkg-config file is installed on the build machine.


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 foot depends on:
ii  foot-terminfo   1.13.1-1
ii  libc6   2.35-3
ii  libfcft43.1.5-1
ii  libfontconfig1  2.13.1-4.5
ii  libpixman-1-0   0.40.0-1
ii  libwayland-client0  1.21.0-1
ii  libwayland-cursor0  1.21.0-1
ii  libxkbcommon0   1.4.1-1

foot recommends no packages.

Versions of packages foot suggests:
ii  foot-themes  1.13.1-1

-- no debconf information
>From 992785e5cc35385688dd9239d9d9a4dcaa9078e3 Mon Sep 17 00:00:00 2001
From: Andrea Pappacoda 
Date: Sun, 23 Oct 2022 16:20:52 +0200
Subject: [PATCH] d/control: enable grapheme clustering

---
 debian/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index 4ee1c340..80c29701 100644
--- a/debian/control
+++ b/debian/control
@@ -16,6 +16,8 @@ Build-Depends: debhelper-compat (= 13),
libfcft-dev (>= 3.0.0),
libffi-dev,
libharfbuzz-dev,
+   libutf8proc-dev,
+   systemd [linux-any],
scdoc
 Standards-Version: 4.6.1.0
 Homepage: https://codeberg.org/dnkl/foot
-- 
2.35.1

Bug#1022533: foot: pending patches

[Andrea Pappacoda]

Hi Birger, I've submitted the aforementioned patch to Salsa, together 
with a bigger one that enables profile-guided optimizations and makes 
foot provide x-terminal-emulator. It'd be great if you could review, 
and possibly accept them :)


You can find the two merge requests here:
https://salsa.debian.org/birger/foot/-/merge_requests/3
https://salsa.debian.org/birger/foot/-/merge_requests/4

Thanks for you work on the foot package!

--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#927012: libravatar.cgi on bugs.debian.org fails with 500 error

[Andrea Pappacoda]

Hi, I discovered this issue after seeing https://bugs.debian.org/950052 
- in that report it seems that lamby's avatar is shown. So 
libravatar.cgi isn't really disabled?


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1020223: nextcloud-desktop: missing dependency on qml-module-qtquick-dialogs

[Andrea Pappacoda]

Package: nextcloud-desktop
Version: 3.6.0-1
Severity: important
Tags: patch

nextcloud-desktop requires qml-module-qtquick-dialogs to show its GUI since
version 3.6.0, but the package currently doesn't depend on it.

$ nextcloud --logfile - | grep -i qml
2022-09-18 13:38:45:694 [ warning nextcloud.gui.systray
./src/gui/systray.cpp:145 ]:"qrc:/qml/src/gui/tray/Window.qml:146 Type
UserStatusSelectorPage
unavailable\nqrc:/qml/src/gui/UserStatusSelectorPage.qml:39 Type
UserStatusSelector unavailable\nqrc:/qml/src/gui/UserStatusSelector.qml:16
module \"QtQuick.Dialogs\" is not installed\n"


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 nextcloud-desktop depends on:
ii  libc6  2.34-7
ii  libcloudproviders0 0.3.1-2
ii  libgcc-s1  12.2.0-1
ii  libglib2.0-0   2.73.3-3
ii  libnextcloudsync0  3.6.0-1
ii  libqt5core5a   5.15.4+dfsg-5
ii  libqt5dbus55.15.4+dfsg-5
ii  libqt5gui5 5.15.4+dfsg-5
ii  libqt5keychain10.13.2-5
ii  libqt5network5 5.15.4+dfsg-5
ii  libqt5qml5 5.15.4+dfsg-4
ii  libqt5quick5   5.15.4+dfsg-4
ii  libqt5quickcontrols2-5 5.15.4+dfsg-2
ii  libqt5sql5-sqlite  5.15.4+dfsg-5
ii  libqt5svg5 5.15.4-2
ii  libqt5webenginecore5   5.15.10+dfsg-4
ii  libqt5webenginewidgets55.15.10+dfsg-4
ii  libqt5widgets5 5.15.4+dfsg-5
ii  libstdc++6 12.2.0-1
ii  nextcloud-desktop-common   3.6.0-1
ii  nextcloud-desktop-l10n 3.6.0-1
ii  qml-module-qt-labs-platform5.15.4+dfsg-2
ii  qml-module-qtgraphicaleffects  5.15.4-2
ii  qml-module-qtqml-models2   5.15.4+dfsg-4
ii  qml-module-qtquick-controls2   5.15.4+dfsg-2
ii  qml-module-qtquick-layouts 5.15.4+dfsg-4
ii  qml-module-qtquick-window2 5.15.4+dfsg-4
ii  qml-module-qtquick25.15.4+dfsg-4

Versions of packages nextcloud-desktop recommends:
pn  nextcloud-desktop-doc  

nextcloud-desktop suggests no packages.

-- no debconf information
>From e4b1fb44645e765e463a23d95497bc5e5112716e Mon Sep 17 00:00:00 2001
From: Andrea Pappacoda 
Date: Sun, 18 Sep 2022 14:03:12 +0200
Subject: [PATCH] d/control: depend on qml-module-qtquick-dialogs

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

diff --git a/debian/control b/debian/control
index 59da6a0ee..37c2aa9d5 100644
--- a/debian/control
+++ b/debian/control
@@ -51,6 +51,7 @@ Depends: libnextcloudsync0 (= ${binary:Version}),
  qml-module-qtgraphicaleffects,
  qml-module-qtqml-models2,
  qml-module-qtquick-controls2,
+ qml-module-qtquick-dialogs,
  qml-module-qtquick-layouts,
  qml-module-qtquick-window2,
  qml-module-qtquick2,
-- 
2.35.1

Bug#799543: dh_doxygen: fails if no docs found, even in binary-only builds

[Andrea Pappacoda]

On Sun, 4 Sep 2016 14:16:02 +0200 Helmut Grohne  
wrote:
> Documentation generators such as doxygen or sphinxdoc typically 
create
> architecture independent packages. Thus the required tools should 
reside
> in Build-Depends-Indep. Having them there means that they cannot 
easily

> be used as sequence addons (there is no dh --with-indep).

Hi Helmut, as debhelper now supports specifying sequence addons by 
adding a dh-sequence-name in Build-Depends{,-Arch,-Indep}, maybe this 
can be reconsidered?

Bug#799543: dh_doxygen: fails if no docs found, even in binary-only builds

[Andrea Pappacoda]

Il giorno dom 25 set 2022 alle 15:10:40 +02:00:00, Helmut Grohne 
 ha scritto:

I fully agree that there now should be a sequence addon.
Build-Depends-Indep: dh-sequence-doxygen seems great. Will you do it?


Great! I honestly don't know where to start, but I'll look into it :)

Bug#1020732: debhelper: dh_auto_install should invoke cmake --install

[Andrea Pappacoda]

Package: debhelper
Version: 13.9.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, this bug is really similar to #1006805, but this time the suggestion
applies to CMake.

The `cmake --install` command has existed since CMake 3.15[1], and the most
useful feature that this command has compared to plain `make install` is
support for the `--component` flag, which is really handy when doing partial
builds (-arch or -indep-only).

dh_auto_install currently invokes `cd builddir && make -j4 install DESTDIR=dir
AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true"`; this could be
roughly translated to `cmake --install builddir --prefix=dir --strip` (note
that using the DESTDIR env var instead of the --prefix option is also
supported[2]).

[1]: https://cmake.org/cmake/help/latest/release/3.15.html#command-line
[2]: https://cmake.org/cmake/help/latest/envvar/DESTDIR.html


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.0-1
ii  dpkg 1.21.9
ii  dpkg-dev 1.21.9
ii  dwz  0.14-1
ii  file 1:5.41-4
ii  libdebhelper-perl13.9.1
ii  libdpkg-perl 1.21.9
ii  man-db   2.10.2-3
ii  perl 5.34.0-5
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCYzC7ghQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p4RxAP4331ZZNBFXG8ocKa9ekxoa8o8rv23r
ijuKJDZz2n5ppQD+M4MBTjq1jACUzPQ71lDuXfZjMhFQn3un/E8+ohCfhg4=
=DlpF
-END PGP SIGNATURE-

Bug#1020732: debhelper: dh_auto_install should invoke cmake --install

[Andrea Pappacoda]

Il giorno dom 25 set 2022 alle 22:35:15 +02:00:00, Andrea Pappacoda 
 ha scritto:

this could be
roughly translated to `cmake --install builddir --prefix=dir --strip` 
(note

that using the DESTDIR env var instead of the --prefix option is also
supported[2]).


Sorry, --prefix and DESTDIR have different meaning also in the `cmake 
--install` command. Hence using the DESTDIR environment variable is the 
only option.

Bug#978748: libboost-dev: Boost 1.75

[Andrea Pappacoda]

Il giorno gio 22 set 2022 alle 22:23:55 +02:00:00, Anton Gladky 
 ha scritto:

it is "in work". We will definitely need people
for testing, filing and fixing bugs during transition.


Wonderful; I'll be sure to test it against my packages as soon as it'll 
be ready. Thanks for your work :D

Bug#978748: libboost-dev: Boost 1.75

[Andrea Pappacoda]

On Fri, 22 Apr 2022 17:39:35 +0200 Anton Gladky 
 wrote:

> I did some work a couple of months ago, packaging 1.78.
> It worked, but I did not have time to finish it. I would probably
> continue this work soon to prepare 1.79 or even 1.80 for the
> next stable Debian version.

Hi Anton, what's the status of your boost 1.80 packaging? I'm currently 
having issues with a couple of packages depending on Boost because 1.74 
contains a few bugs, and I'd be happy to help you with preparing the 
next version if needed.

Bug#1020524: d/watch: use download.libsodium.org

[Andrea Pappacoda]

Source: libsodium
Version: 1.0.18-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, d/watch currently downloads sources from libsodium's GitHub repository,
while the recommended source is download.libsodium.org. As the libsodium
website contains signed tarballs, I believe it should be appropriate for this
package to use them, also because security is especially relevant to this
package.

I've also reported this on https://github.com/gcsideal/debian-
libsodium/issues/5

If you'd like to receive help with the libsodium package I'd be happy to lend a
hand; I really like the library!

Thanks :)


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCYyyXKBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p9ALAQCIpF+iJKxZ1oSqCZUIJ7nf72wE+XUj
4YwRCa2NTrN90AEA+D/0n+spkD2AZPc9fUY9nUVStikGyMlUvBNFDsTBIgY=
=Zfz2
-END PGP SIGNATURE-

Bug#1020595: ITP: tomlplusplus -- TOML config parser and serializer for C++17

[Andrea Pappacoda]

Il giorno sab 24 set 2022 alle 11:17:21 +02:00:00, Stephan Lachnit 
 ha scritto:
I find this library interesting as well, ping me if you need a 
sponsor.


Sure! I _always_ need a sponsor :)

The package is mostly ready, but I'd also like to include some 
generated documentation with it. tomlplusplus uses Poxy, a Python 
program that is not yet packaged. As I don't know anything about 
Python's ecosystem, could you please point me in the right direction? 
Also, see 

Bug#1020595: ITP: tomlplusplus -- TOML config parser and serializer for C++17

[Andrea Pappacoda]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: tomlplusplus
  Version : 3.2.0
  Upstream Author : Mark Gillard 
* URL : https://marzer.github.io/tomlplusplus/
* License : MIT/Expat
  Programming Lang: C++
  Description : TOML config parser and serializer for C++17

Features:
- - Supports the latest TOML release (v1.0.0), plus optional support for some
unreleased TOML features
- - Passes all tests in the toml-test suite
- - Supports serializing to JSON and YAML
- - Proper UTF-8 handling (incl. BOM)
- - C++17 (plus some C++20 features where available, e.g. experimental support
for char8_t strings)
- - Doesn't require RTTI
- - Works with or without exceptions
- - Tested on Clang (6+), GCC (7+) and MSVC (VS2019)
- - Tested on x64, x86 and ARM

I've used this library in the past, and I was surprised to find out that it is
not available in Debian.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCYy4sExQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p7IMAP9BKJ8/B6nrKHvKzREXrz8n2nqxGRr5
Yuc+QCCNtjOL0wD+IWVXon6q2S5n4SUSMqRzAWw0zJXc7OppfpTaKzk7cgQ=
=dCnP
-END PGP SIGNATURE-

Bug#1020636: debhelper: dh_installdocs in subdirectories

[Andrea Pappacoda]

Package: debhelper
Version: 13.9.1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, would it be possible for dh_installdocs to support installation of files in
subdirectories of the documentation directory?

This can be necessary in cases where, for example, an HTML file references some
images in a relative path like docs/images/.

Take this package.docs file for example:

README.html
docs/images/*.png
docs/images/*.svg

The installed README.html file will point to nonexistent paths, as images will
get installed in /usr/share/doc/package/ instead of
/usr/share/doc/package/docs/images/.

What I suggest is extending the .docs format in a way similar to .install
files, but only allowing paths relative to the documentation directory. The
previous example would be converted to this:

README.html
docs/images/*.png docs/images/
docs/images/*.svg docs/images/

I'm currently working around this by installing the images in a .install file,
but those do not honour the nodoc build profile; I also dislike having to
separate the same logical concept in two different places.

Thanks for your work on debhelper!


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.0-1
ii  dpkg 1.21.9
ii  dpkg-dev 1.21.9
ii  dwz  0.14-1
ii  file 1:5.41-4
ii  libdebhelper-perl13.9.1
ii  libdpkg-perl 1.21.9
ii  man-db   2.10.2-3
ii  perl 5.34.0-5
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCYy8dOBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p8JMAP9JWPqnVM5sD5lfK/ov/dA3p0xcqJHJ
1s9N8fwXincDKQD/UT4orF4yTuTvk8Wa/51Qm8fu4bFBleuz/LdjY6PYEwo=
=V9XP
-END PGP SIGNATURE-

Bug#1020595: ITP: tomlplusplus -- TOML config parser and serializer for C++17

[Andrea Pappacoda]

Hi Stephan, I've uploaded the package to Mentors. I still haven't 
package Poxy, but in the meantime I've included the partial Markdown 
documentation. I'll add the rest in a future revision of the package.


When uploading the package, could you also transfer 
 to the debian namespace? 
The transfer button is under Settings -> General -> Advanced -> 
Transfer project

Bug#799543: dh_doxygen: fails if no docs found, even in binary-only builds

[Andrea Pappacoda]

Hi Helmut, I've added the dh-sequence-doxygen sequence and submitted it 
as a [Salsa MR]; it has been simpler than expected, as the doxygen.pm 
addon was already there. One issue I noticed though is that when 
building a package using dh_doxygen with `dpkg-buildpackage 
--build=binary` nothing happens, and I get the following warning:


   dh_doxygen: warning: No packages to build. Possible architecture 
mismatch: amd64, want: all any


Everything works as expected when using `--build=all`.

This is probably not directly related to the new dh-sequence-doxygen 
package, as it also happens when building [cubeb], a package I 
maintain; as you have some experience with cross builds, profiles, etc, 
I hope you might have an idea about what's going on :)


[Salsa MR]: https://salsa.debian.org/debian/doxygen/-/merge_requests/8
[cubeb]: 
https://salsa.debian.org/debian/cubeb/-/blob/7a17dcc60f413187b1e39c35bafd21d6bfaf3978/debian/rules#L38-43


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1021342: apt: build-dep without -Arch and -Indep dependencies

[Andrea Pappacoda]

Package: apt
Version: 2.5.3
Severity: wishlist

Hi!

apt build-dep currently supports the `--arch-only` and `--indep-only` options
to only install build deps needed to build arch dependent and independent
packages, respectively.

As far as I know though, it isn't currently possible to only ask for the
packages specified in the Build-Depends and Build-Conflicts fields, i.e. only
the ones needed to run the `clean` target. This could be useful to easily check
if the build dependencies of a package are correctly specified; for example,
see this Salsa CI thread: 

Would it be reasonable for apt to add the `--no-arch` and `--no-indep` options,
or a `--clean-only` one?

Thanks :)


-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (no /etc/apt/sources.list present) --


-- (/etc/apt/sources.list.d/debian.sources present, but not submitted) --


-- (/etc/apt/sources.list.d/extrepo_vscodium.sources present, but not 
submitted) --


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 apt depends on:
ii  adduser 3.129
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.39-1
ii  libapt-pkg6.0   2.5.3
ii  libc6   2.35-1
ii  libgcc-s1   12.2.0-3
ii  libgnutls30 3.7.7-2
ii  libseccomp2 2.5.4-1+b1
ii  libstdc++6  12.2.0-3
ii  libsystemd0 251.4-3

Versions of packages apt recommends:
ii  ca-certificates  20211016

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.21.9
ii  gnupg2.2.39-1
pn  powermgmt-base   

-- no debconf information

Bug#1021096: ITP: spaghetti -- Analysis of Network-constrained Spatial Data

[Andrea Pappacoda]

Il giorno sab 1 ott 2022 alle 23:18:20 -03:00:00, Josenilson Ferreira 
da Silva  ha scritto:

* Package name: spaghetti


Maybe spaghetti is a bit too general for a package name, what about 
python3-spaghetti or pysal-spaghetti?


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#951805: Help with glbinding

[Andrea Pappacoda]

Hi Ghislain, glbinding hasn't been updated in four years. Would you 
like some help with the package? I've used glbinding in the past, and 
I'd be happy to help with maintenance under the Science team.


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#951805: Help with glbinding

[Andrea Pappacoda]

Il giorno dom 2 ott 2022 alle 20:54:01 +02:00:00, Ghislain Vaillant 
 ha scritto:
Feel free to assist with maintenance of any of my packages under the 
Debian science team umbrella.


You don't need to ask for permission 


Thanks for the fast reply, Ghislain! I'll start working on this in a 
few days. Would you be able to sponsor my first upload and/or grant me 
DM rights to the package? If you prefer, I can publish my changes in a 
Salsa fork so that you can take a look at them before trusting me too 
much :)


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1021011: ITP: doxygen-awesome-css -- custom CSS theme for Doxygen HTML documentation

[Andrea Pappacoda]

Package: wnpp
Severity: wishlist
Owner: Andrea Pappacoda 
X-Debbugs-Cc: debian-de...@lists.debian.org, Scott Talbert 

* Package name: doxygen-awesome-css
  Version : 2.1.0
  Upstream Author : jothepro
* URL : https://jothepro.github.io/doxygen-awesome-css/
* License : MIT/Expat
  Programming Lang: CSS, JavaScript
  Description : custom CSS theme for Doxygen HTML documentation

Doxygen Awesome is a custom CSS theme for Doxygen HTML-documentation with lots
of customization parameters.
.
It features a clean and modern design, improved mobile usability, a dark mode,
and doesn't change the classic HTML structure of Doxygen documentation.

This package is required to correctly generate Doxygen documentation of zydis,
a package I'm maintaining. It also used by wxwidgets3.2, which is currently
using an embedded copy of the theme.

Bug#1021011: ITP: doxygen-awesome-css -- custom CSS theme for Doxygen HTML documentation

[Andrea Pappacoda]

I've uploaded the package to mentors, see 



--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1026846: login: PATH set to ENV_SUPATH when logging in as a regular user

[Andrea Pappacoda]

Package: login
Version: 1:4.13+dfsg1-1
Followup-For: Bug #1026846

It seems that being part of the `sudo` group isn't causing the issue. I've
created a temporary user, logged into my DE with it and observed that PATH was
set to the expected value.

One interesting thing I've noticed is that if I log into my computer with a
text-only session (on e.g. tty3), PATH is set to the correct value.

As this seems now relevant, I'm running the latest version of GNOME available
in Testing; it's a fairly minimal install. gnome-core is not installed, but
I've manually installed pretty much everything apart from the software store
and a couple of things I do not need; here's what's not present:

$ apt depends gnome-core | grep Depends | tr ' ' '\n' | grep '[[:alpha:]]'
| grep -vE '\)|:' | tr ',' ' ' | xargs apt -qq list | grep -v installed | cut
-d / -f 1 | tr '\n' ' '
at-spi2-core baobab evolution-data-server gnome-bluetooth-sendto gnome-
console gnome-contacts gnome-font-viewer gnome-logs gnome-shell-extensions
gnome-software gnome-sushi gnome-system-monitor gnome-terminal gnome-themes-
extra gnome-user-docs gnome-user-share gstreamer1.0-packagekit libatk-adaptor
nautilus totem tracker yelp


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 login depends on:
ii  libaudit1   1:3.0.7-1.1+b2
ii  libc6   2.36-6
ii  libcrypt1   1:4.4.33-1
ii  libpam-modules  1.5.2-5
ii  libpam-runtime  1.5.2-5
ii  libpam0g1.5.2-5

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#1026846: login: PATH set to ENV_SUPATH when logging in as a regular user

[Andrea Pappacoda]

Package: login
Version: 1:4.13+dfsg1-1
Severity: normal

Hi, after noticing that /usr/bin/games was not in my PATH, I tried to figure
out why. My PATH is currently set to
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, which is the same
exact value found in /etc/login.defs under the variable ENV_SUPATH, which
should be the default PATH for superusers.

This issue isn't present when logging in as a different user which isn't part
of the sudo group.

List of my groups:

tachi : tachi cdrom floppy sudo audio dip video plugdev users kvm netdev
bluetooth sbuild scanner lpadmin

List of the other user's groups:

lorenzo : lorenzo lp cdrom audio video plugdev users netdev scanner

What could be the cause of this issue?

Thanks!


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 login depends on:
ii  libaudit1   1:3.0.7-1.1+b2
ii  libc6   2.36-6
ii  libcrypt1   1:4.4.33-1
ii  libpam-modules  1.5.2-5
ii  libpam-runtime  1.5.2-5
ii  libpam0g1.5.2-5

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#1020595: Tests FTBFS on arm64

[Andrea Pappacoda]

Il giorno ven 23 dic 2022 alle 16:13:08 +01:00:00, Bastian Germann 
 ha scritto:

I have added a missing copyright statement.


Thanks.

toml.hpp is generated. Please regenerate it from source and possibly 
exclude it.


toml.hpp isn't shipped in the package (the Meson build system installs 
the "regular" flavour, not the "single header" once; see the README for 
details). Is this necessary?


In debian/rules you reference files from 
/usr/share/javascript/highlight.js
but there is no Depends on libjs-highlight.js. Why do you have that 
README.html in the first place?


Good catch, I'll add it to the Recommends. As for why README.md is 
installed as README.html, Policy 12.4[1] says that "If the package 
comes with extensive documentation in a markup format that can be 
converted to various other formats you should if possible ship HTML 
versions in a binary package". As Markdown was meant to be used to be 
converted to HTML since its creation this seems to me like a natural 
thing to do.


While adding highlight.js to the Recommends, I've also added automatic 
dark and light theme handling using the CSS prefers-color-scheme media 
query, so that my eyes won't melt again while reading the installed 
documentation :)

Bug#1027152: cmark-gfm: please mark cmark-gfm as Multi-Arch: foreign

[Andrea Pappacoda]

Source: cmark-gfm
Version: 0.29.0.gfm.6-2.1
Severity: wishlist
Tags: patch

Hi, could you please mark cmark-gfm as Multi-Arch: foreign? This would allow
packages depending on cmark-gfm to perform cross-builds without issues; they
currently have to manually specify :native on the build dependency.

I've submitted a similar bug report for the regular cmark, bug #1027147.

Thank you :)


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-- no debconf information
>From d95603460599fd61c0b8530e9cda0654cf6390e0 Mon Sep 17 00:00:00 2001
From: Andrea Pappacoda 
Date: Wed, 28 Dec 2022 18:18:56 +0100
Subject: [PATCH] d/control: mark cmark-gfm as Multi-Arch: foreign

This allows packages that depend on cmark-gfm to do cross-builds without
issues.
---
 debian/control| 1 +
 debian/control-in | 1 +
 2 files changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index 9ad7d44..97609e8 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Standards-Version: 4.6.0.1
 
 Package: cmark-gfm
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: CommonMark parsing and rendering program, GitHub flavor
  cmark-gfm is the GitHub flavor of the cmark C reference
diff --git a/debian/control-in b/debian/control-in
index e9658ab..ce82c58 100644
--- a/debian/control-in
+++ b/debian/control-in
@@ -9,6 +9,7 @@ Standards-Version: 4.6.0.1
 
 Package: cmark-gfm
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: CommonMark parsing and rendering program, GitHub flavor
  cmark-gfm is the GitHub flavor of the cmark C reference
-- 
2.39.0

Bug#1027147: cmark: please mark cmark Multi-Arch: foreign

[Andrea Pappacoda]

Source: cmark
Version: 0.30.2-5
Severity: wishlist
Tags: patch

Hi Jonas, could you please mark cmark as Multi-Arch: foreign? Cross builds of
some of my packages depending on cmark to convert Markdown documentation to
HTML are currently failing, and require me to explicitly mark the build
dependency with :native.

I'm attaching a small patch for your convenience.

Thanks!


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-- no debconf information
>From 40e1f9e6580eb431415326b6188fc6f1ebfc7d6e Mon Sep 17 00:00:00 2001
From: Andrea Pappacoda 
Date: Wed, 28 Dec 2022 17:57:44 +0100
Subject: [PATCH] d/control: mark cmark as Multi-Arch: foreign

This allows packages that depend on cmark do cross-builds without issues
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 2742834..d8eeb95 100644
--- a/debian/control
+++ b/debian/control
@@ -14,6 +14,7 @@ Build-Depends:
 
 Package: cmark
 Architecture: any
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
-- 
2.39.0

Bug#1027429: mmdebstrap: unshare backend not working

[Andrea Pappacoda]

Package: mmdebstrap
Version: 1.2.4-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, for some reason I'm unable to get the unshare backend working on one of my
machines.

When I try to create an unstable-amd64 tarball to use with sbuild I get this
strange error:

mmdebstrap --variant=apt --include=build-essential unstable unstable-
amd64.tar
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.panqVhWsFm as tempdir
W: /etc/subuid is empty
E: invalid idmap

If I force the creation of the above tarball with root mode and I then try to
use it in sbuild, I get this even bigger error:

Package: yuzu
Version: 0-1284+ds-1
Source Version: 0-1284+ds-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 401.
Use of uninitialized value $range in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 401.
Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 404.
Use of uninitialized value $range in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 404.
Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 401.
Use of uninitialized value $nsid in concatenation (.) or string at
/usr/share/perl5/Sbuild/Utility.pm line 404.
ranges: 2 argc: 5
newuidmap: Not enough arguments to form 2 mappings
usage: newuidmap [   
] ...
newuidmap failed:  at -e line 1.
child had a non-zero exit status: 256 at -e line 1.
bad exit status (29): perl -e require 'syscall.ph';pipe my $rfh, my $wfh;my
$ppid = $$;my $cpid = fork() // die "fork() failed: $!";if ($cpid == 0) {close
$wfh;0 == sysread $rfh, my $c, 1 or die "read() did not receive EOF";0 ==
system "newuidmap $ppid  0 60092 1 1  1" or die "newuidmap failed: $!";0 ==
system "newgidmap $ppid  0 60092 1 1  1" or die "newgidmap failed: $!";exit
0;}0 == syscall _unshare, 268435456 or die "unshare() failed: $!";close
$wfh;$cpid == waitpid $cpid, 0 or die "waitpid() failed: $!";if ($? != 0) {die
"child had a non-zero exit status: $?";}0 == syscall _setgid, 0 or die
"setgid failed: $!";0 == syscall _setuid, 0 or die "setuid failed: $!";0 ==
syscall _setgroups, 0, 0 or die "setgroups failed: $!";exec { $ARGV[0] }
@ARGV or die "exec() failed: $!"; chown 1:1 /tmp/tmp.sbuild.LKlB9A2jh_
E: Error creating chroot session: skipping yuzu

I've installed this system fairly recently (after the bullseye release), and I
don't have messed with it that much. One thing that comes to my mind that could
be messing with UIDs and GIDs is that I'm using systemd-homed to manage my user
and home directory.

Under systemd-homed, users aren't saved to /etc/passwd, but are retrievable
with glibc's NSS API, i.e. with getent(1) and the various getpwuid(3) C
functions. For instance,

$ diff /etc/passwd <(getent passwd)
42a43
> tachi:x:60092:60092:Andrea Pappacoda:/home/tachi:/usr/bin/zsh

How could I debug and/or solve this issue? I'm a bit lost.

Thank you for your awesome work on mmdebstrap :)


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 mmdebstrap depends on:
ii  apt  2.5.4
ii  perl 5.36.0-6
ii  python3  3.10.6-3+b1

Versions of packages mmdebstrap recommends:
ii  arch-test0.19-1
ii  fakechroot   2.20.1+ds-8
ii  fakeroot 1.29-1
ii  gpg  2.2.40-1
ii  libdistro-info-perl  1.2
ii  libdpkg-perl 1.21.13
ii  mount2.38.1-4
ii  uidmap   1:4.13+dfsg1-1

Versions of packages mmdebstrap suggests:
ii  apt [apt-transport-https]  2.5.4
pn  apt-transport-tor  
ii  apt-utils  2.5.4
pn  binfmt-support 
ii  ca-certificates20211016
ii  debootstrap1.0.128+nmu2
ii  distro-info-data   0.56
ii  dpkg-dev   1.21.13
pn  genext2fs  
pn  perl-doc   
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  

- -- no debconf information

-

Bug#1027182: glslang: please mark glslang-tools as Multi-Arch: foreign

[Andrea Pappacoda]

Source: glslang
Version: 11.12.0-1
Severity: wishlist
Tags: patch

Hi, could you please consider marking glslang-tools as Multi-Arch: foreign?
This would allow packages like yuzu to cross-build without having to manually
specify :native on the build-dependency.

I've attached a patch for your convenience, and I'll soon submit a patch to
Salsa too :)


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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
>From 6c03eeeca3d51881094d59211db2d588f4095c08 Mon Sep 17 00:00:00 2001
From: Andrea Pappacoda 
Date: Thu, 29 Dec 2022 00:04:19 +0100
Subject: [PATCH] d/control: mark glslang-tools as Multi-Arch: foreign

This allows which build-depend on it to cross-build without issues.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 47d37a6d..76ea92d6 100644
--- a/debian/control
+++ b/debian/control
@@ -17,6 +17,7 @@ Vcs-Browser: https://salsa.debian.org/xorg-team/vulkan/glslang
 
 Package: glslang-tools
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends},
  spirv-tools (>= 2022.2+1.3.216.0),
 Description: OpenGL and OpenGL ES shader front end and validator -- tools
-- 
2.39.0

Bug#1027429: mmdebstrap: unshare backend not working

[Andrea Pappacoda]

Il giorno sab 31 dic 2022 alle 14:00:54 +01:00:00, Johannes Schauer 
Marin Rodrigues  ha scritto:

Do you have a valid /etc/subuid? Mine says (josch is my username):

josch:10:65536


Nope, both /etc/subuid and subgid are empty on my system. They aren't 
on my other one that doesn't use systemd-homed, so maybe these are 
populated by useradd(8)?


It seems that systemd's issue tracker has a relevant RFE still 
unresolved, ; maybe it 
makes sense to somewhat mention it in sbuild's manual page, it might 
not be obvious for users that don't know much about unshare and user 
namespaces.


In any case, manually putting tachi:10:65536 in subuid and subgid 
solved the issue. Thanks!



How could the error message be improved?


I'm not sure, I really don't know much about this subject :/

The error message in sbuild could certainly be improved. Could you 
try out the

following patch:


Thanks, but I really don't have time know to apply it. Guess I'll let 
you know next year ;)


Thanks again!

Bug#1028407: tomlplusplus: FTBFS on some release architectures

[Andrea Pappacoda]

On Tue, 10 Jan 2023 18:21:02 +0100 Bastian Germann  
wrote:

> tomlplusplus fails to build from scratch on armel, mipsel, and ppcel.

Hi Bastian, I've noticed this too. One issue is that upstream compiles 
tests with `-march=native` unconditionally, but the flag isn't 
supported everywhere, and another one is related to some symbols 
issues. I've fixed both in revision 3, and I've just uploaded it to 
mentors. I'm not sure if that'll fix all the failures, because I only 
have access to two arm64 and mips64el porter boxes.


Feel free to upload -3 when you prefer, or to mark me as a DM of 
tomlplusplus so that I can do it myself.


Thank you for being so fast at spotting all my mistakes :)

Bug#1028304: howardhinnant-date FTBFS on 32-bit arches (may fail in testcase)

[Andrea Pappacoda]

On Mon, 9 Jan 2023 12:35:06 +0100 Helge Deller  wrote:
> Package:  howardhinnant-date
> Version: 3.0.1+ds
> Tags: hppa, patch, ftbfs
> Severity: important
>
> The testcases may fail on 32-bit arches at runtime if those are 
running on huge discs,

> e.g. see
> 
https://buildd.debian.org/status/fetch.php?pkg=howardhinnant-date=hppa=3.0.1%2Bds-1=1664074656=0

>
> This can be fixed by building it with LFS (large file support).

Hi Helge, thank you very much for the detailed report and your 
suggestion!


I've heard of LFS before but I don't know much about it. Can it cause 
issues? Does it break ABI?


I'll be sure to fix this as soon as I'll receive a reply - oh and by 
the way, please Cc me in bug emails, the BTS is unable to send me 
emails (probably due to broken DMARC, DKIM, or something similar).


Thanks again :)

Bug#1016470: I want to help add autopkgtests to Muon

[Andrea Pappacoda]

Il giorno dom 1 gen 2023 alle 08:05:35 +00:00:00, John Scott 
 ha scritto:
When the Muon package starts coming along, can you give me a poke? I 
have a few autopkgtest ideas I'd like to lend a hand in implementing.


Hi John, sure! The process has a bit stalled though as I'm still 
waiting for a reply from the KDE guys about the status of the "muon" 
package...


I think I'm just going to package muon under the "muon-meson" package 
and binary name for the time being. It's not great, but better than not 
having muon at all in Debian 12...


Unless I forget about it, I'll start actually packaging the latest 
release tomorrow (~11 hours from now).


I'm interested though, what kind of autopkgtests would you like to add? 
That's a packaging area I should definitely get better at :)

Bug#1024643: ITP: libspng -- simple, modern libpng alternative

[Andrea Pappacoda]

On Mon, 19 Dec 2022 19:11:28 +0100 Bastian Germann  
wrote:
> There is no dolphin-emu release that needs libspng. If a commit 
before
> 
https://github.com/dolphin-emu/dolphin/commit/a9edf129e35e109fe50d8b4cca444de0c60bcb52 
is imported it is not needed.

>
> So this is not really a blocker. If there is a reason to have a 
newer commit as new version in Debian please document

> that here.

Hi Bastian, yes, there's no "release" that currently uses libspng, but 
mainly because Dolphin stopped making releases ages ago, recommending 
users to use the beta versions instead ("The stable versions below are 
years out of date and missing countless features and bug fixes. Beta or 
development versions are a better choice for almost all users"). I 
recall some discussions in the debian-games IRC about the intention to 
start packaging newer commits, but I guess that never materialized.


Anyway, the Dophin thing was just a plus. I'd like to have spng in 
Debian to make C development on the distro easier; I see great value in 
having a large number of -dev packages, even if they are leaf packages.

Bug#1028281: muon: please rename package and bin/muon to muon-kde

[Andrea Pappacoda]

Source: muon
Version: 4:5.8.0-2
Severity: wishlist

Hi, could you please consider renaming the muon package and /usr/bin/muon
binary to muon-kde? /usr/bin/muon conflicts with the muon-meson build system.

KDE Muon has been archived upstream and is mostly dead. It is also a GUI
application, and thus usually launched with its .desktop file, and not invoking
the muon binary (contrary to the build system).

Please have a look at bugs #1016470 and #1017716 for more context.

Bye!


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

Bug#1024643: ITP: libspng -- simple, modern libpng alternative

[Andrea Pappacoda]

Il giorno dom 8 gen 2023 alle 12:03:17 +01:00:00, Andrea Pappacoda 
 ha scritto:
Anyway, the Dophin thing was just a plus. I'd like to have spng in 
Debian to make C development on the distro easier; I see great value 
in having a large number of -dev packages, even if they are leaf 
packages.


Turns out src:vips depends on libspng too; it prefers using libspng if 
possible, and falls back to using libpng otherwise. See 
<https://sources.debian.org/src/vips/8.13.3-2/README.md/#L201>. I'm 
thus Ccing Laszlo (gcs), the maintainer of vips.


(Pointed out by upstream in 
<https://github.com/randy408/libspng/issues/237#issuecomment-1375377510>)

Bug#1028304: howardhinnant-date FTBFS on 32-bit arches (may fail in testcase)

[Andrea Pappacoda]

Il giorno mer 11 gen 2023 alle 11:48:04 +01:00:00, Helge Deller 
 ha scritto:
It could break ABI if you would export header files for functions 
which use the "struct dirent" structure
in the parameter list. This isn't the case for your package, so you 
are fine.


Awesome, I'll do it now then. Thanks!


pappacoda.it seems ok according to https://mxtoolbox.com


Yeah my mail server is fine as far as I know, but the BTS isn't. See 
for example this recent thread on d-devel: 
 and also 
bug #754809.

Bug#1020595: Marking releases as UNRELEASED instead of unstable

[Andrea Pappacoda]

Il giorno ven 23 dic 2022 alle 18:46:02 +00:00:00, Ben Westover 
 ha scritto:

When maintaining packages that are waiting to be sponsored, it's
generally a good idea to mark the distribution in debian/changelog as
UNRELEASED, because if it's listed as unstable, your ITP keeps getting
marked pending every time you commit, and people can get the idea 
that a
release is already in Debian if it's marked unstable. In the future, 
you
should mark it UNRELEASED in Salsa and unstable in Mentors, then 
change

it to unstable when the package is uploaded and passes NEW.


Hi Ben, you're right and I find it annoying too, but in general I try 
to do the opposite, i.e. do everything in Salsa first, and then push to 
Mentors. I prefer to see the Git repo as the main place where changes 
occur, the "master project", and it should never be out of date. Doing 
things this way it is impossible to have a change in the package 
present in Mentors that isn't also in Salsa.


Admittedly it makes a lot of sense for already uploaded packages, but 
maybe not that much for ones needing a sponsor.


In any case, thanks for the suggestion. Maybe I'll put it in practice 
for the next package :)

Bug#1026379: skel.bashrc: please add foot to the color_prompt=yes check

[Andrea Pappacoda]

Package: bash
Version: 5.2-2+b1
Severity: wishlist
Tags: patch

Hi, skel.bashrc (installed as /etc/skel/.bashrc) currently sets
color_prompt=yes only if the TERM environment variable is either xterm-color or
ends with -256color. Please consider adding "foot*" to the check, as it does
support color too. You can find an explanation of foot's TERM handling in the
foot(1) manpage, also available at
.

I've attached a patch for your convenience.

Thanks for maintaining bash!


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 bash depends on:
ii  base-files   12.3
ii  debianutils  5.7-0.4
ii  libc62.36-6
ii  libtinfo66.3+20220423-2

Versions of packages bash recommends:
ii  bash-completion  1:2.11-6

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information
diff --git a/debian/skel.bashrc b/debian/skel.bashrc
index 9360f69..8e3a24f 100644
--- a/debian/skel.bashrc
+++ b/debian/skel.bashrc
@@ -37,7 +37,7 @@ fi
 
 # set a fancy prompt (non-color, unless we know we "want" color)
 case "$TERM" in
-xterm-color|*-256color) color_prompt=yes;;
+xterm-color|*-256color|foot*) color_prompt=yes;;
 esac
 
 # uncomment for a colored prompt, if the terminal has the capability; turned

Bug#1020595: Tests FTBFS on arm64

[Andrea Pappacoda]

Il 19 dicembre 2022 17:55:11 CET, Bastian Germann  ha scritto:
>Hi Andrea,
>Will you have the time to make the package build on arm64?
>Maybe Ben wants to volunteer and provide a patch?

Sure. I have just completed two exams, so I'll have plenty of time for a couple 
of weeks :)

Somewhat unrelated: Bastian, would you please have a look at my libspng 
packaging, when you have time? As always, you can find it on mentors. Thanks!

Sorry for my brevity and/or broken reply, I'm on my phone.

Bug#1026768: vulkan-loader: please consider packaging version 1.3.238

[Andrea Pappacoda]

Source: vulkan-loader
Version: 1.3.231.1-1
Severity: wishlist

Hi, could you please consider upgrading to version 1.3.238 when it is fully
released? It is currently needed by the latest release of yuzu[1], a package
I'm maintaining.

By looking at  it seems
that version 1.3.238 has been tagged with a "v" prefix, and not with an "sdk-"
one; this means that this version is still in development, right?

Anyway, thanks for maintaining this package :)

[1]: https://github.com/yuzu-emu/yuzu/pull/9480


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

Bug#1024355: opensysusers: fails to first-install

[Andrea Pappacoda]

Hi Samuel, thank you very much for the report.

On Fri, 18 Nov 2022 09:40:11 +0100 Samuel Thibault 
 wrote:

> Version 0.7.3-1 of opensysusers made it uninstallable:
>
> (Reading database ... 936343 files and directories currently 
installed.)

> Preparing to unpack .../opensysusers_0.7.3-1_all.deb ...
> Adding 'diversion of /bin/systemd-sysusers to 
/bin/systemd-sysusers.real by opensysusers'

> /var/lib/dpkg/tmp.ci/preinst: 15: 2: parameter not set
> dpkg: error processing archive 
/var/cache/apt/archives/opensysusers_0.7.3-1_all.deb (--unpack):
>  new opensysusers package pre-installation script subprocess 
returned error exit status 2

>
> Indeed, preinst uses set -u, and then tries [ -n "$2" ] (expanded 
from

> dh_installinit), thus deemed to fail under first installation.

Strange... I too noticed that version 0.7.3-1 introduced a piuparts 
error, but the release is pretty much identical to 0.7.2-1, as 0.7.2-1 
already contained the only new upstream commit in 0.7.3.


Anyway, would you simply suggest to drop the `u` shell option? I added 
it only because I usually do so, but there's no strong motivation 
behind it.


Thanks again :)

Bug#641880: Please create default-jdk-source

[Andrea Pappacoda]

On Tue, 30 Oct 2018 13:21:32 +0100 Emmanuel Bourg  
wrote:

> Patches or pull requests on Salsa are welcome :)

Hi Emmanuel, I've submitted a merge request on Salsa: 

Bug#1024246: RFP: eclipse-jdt-ls -- Java language server

[Andrea Pappacoda]

Package: wnpp
Severity: wishlist

* Package name: eclipse-jdt-ls
  Version : 1.17.0
  Upstream Author : Eclipse Foundation
* URL : https://github.com/eclipse/eclipse.jdt.ls
* License : EPL-2.0
  Programming Lang: Java
  Description : Java language server

The Eclipse JDT Language Server is a Java language specific implementation of
the Language Server Protocol and can be used with any editor that supports the
protocol, to offer good support for the Java Language.

The jdtls language server can be used to have a rich editing experience in LSP-
capable clients, like Vim, VSCode, etc. I have little knowledge of the Java
ecosystem, and no Java packaging experience, so I'm unable to package this
myself.

Thanks to anyone who will attempt to package this :)

Bug#1024658: mkdocs: Please provide dh-sequence-mkdocs

[Andrea Pappacoda]

Package: mkdocs
Version: 1.4.2+dfsg-1
Severity: wishlist

Hi, as mkdocs ships the dh_mkdocs addon, could you please make the package
provide dh-sequence-mkdocs? This would allow users of the addon to put
`Depends-Indep: dh-sequence-mkdocs` in d/control, without having to also add
`--with=mkdocs` to d/rules.

Thanks!


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 mkdocs depends on:
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1
ii  ghp-import 2.1.0-3
ii  libjs-bootstrap4   4.6.1+dfsg1-3
ii  libjs-jquery   3.6.1+dfsg+~3.5.14-1
ii  libjs-lunr 2.3.9~dfsg-1
ii  libjs-modernizr2.6.2+ds1-4
ii  python33.10.6-1
ii  python3-click  8.0.3-1
ii  python3-jinja2 3.0.3-2
ii  python3-livereload 2.6.3-2
ii  python3-lunr   0.6.2-2
ii  python3-markdown   3.4.1-2
ii  python3-mergedeep  1.3.4-3
ii  python3-packaging  21.3-1.1
ii  python3-pkg-resources  65.5.0-1
ii  python3-pyyaml-env-tag 0.1-3
ii  python3-typing-extensions  4.3.0-2
ii  python3-watchdog   2.1.9-1
ii  python3-yaml   6.0-3+b1
ii  sphinx-rtd-theme-common1.1.1+dfsg-1

mkdocs recommends no packages.

Versions of packages mkdocs suggests:
pn  mkdocs-doc 
pn  nodejs 
pn  python3-babel  

-- no debconf information

Bug#1024643: ITP: libspng -- simple, modern libpng alternative

[Andrea Pappacoda]

Package: wnpp
Severity: wishlist
Owner: Andrea Pappacoda 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-devel-ga...@lists.debian.org

* Package name: libspng
  Version : 0.7.2
  Upstream Author : Randy 
* URL : https://libspng.org
* License : BSD-2-Clause
  Programming Lang: C
  Description : simple, modern libpng alternative

libspng is a C library for reading and writing Portable Network Graphics
(PNG) format files with a focus on security and ease of use.
.
The simple API allows decoding a PNG file in just a few function calls,
and no raw pointers or callback functions are involved.
.
Following good security practises, code is written according to the rules
of the CERT C Coding Standard. All integer arithmetic is checked for
overflow and all error conditions are handled gracefully. The library
is also continuously fuzzed, scanned by static analyzers and features
over 1000 test cases.

libspng is an interesting alternative to libpng, and it is already packaged by
some other distributions. From a user point of view, I'd be happy to have this
available in my distro's repos. New versions of the dolphin-emu package, not
yet packaged by the Games Team, use libspng.

I'll need a sponsor for the first upload.

Bug#1029049: vim: please backport patch 9.0.1080

[Andrea Pappacoda]

Source: vim
Version: 2:9.0.1000
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, could you please consider backporting patch 9.0.1080? It is needed to fix
the keyprotocol option on the foot terminal, according to this upstream bug
report: https://github.com/vim/vim/issues/11781

Thank you!


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCY8XEXRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p4VHAQDZd1dcTYGJqznuA/yr06TlCBxKvQDc
mBryv33hDyJ0OgEAwopHjy9lTATjeR1Pw3IrEUXwKsQZPuignkxI+aaQigc=
=lowV
-END PGP SIGNATURE-
>From afa3f1cc7258d34c32a299a3cc6aece89f67fb47 Mon Sep 17 00:00:00 2001
From: Bram Moolenaar 
Date: Mon, 19 Dec 2022 18:56:48 +
Subject: [PATCH] patch 9.0.1080: the "kitty" terminfo entry is not widespread

Problem:The "kitty" terminfo entry is not widespread, resulting in the
kitty terminal not working properly.
Solution:   Go back to using "xterm-kitty" and avoid the problems it causes in
another way.
---
 runtime/doc/term.txt | 11 +++---
 src/os_unix.c|  5 -
 src/term.c   | 51 +---
 src/version.c|  2 ++
 4 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt
index 50ba187ab969..146ef478fe53 100644
--- a/runtime/doc/term.txt
+++ b/runtime/doc/term.txt
@@ -306,9 +306,14 @@ One of the problems is that the value for $TERM is set to 
"xterm-kitty".  For
 Vim this is an indication that the terminal is xterm-compatible and the
 builtin xterm termcap entries should be used.  Many other terminals depend on
 this.  However, Kitty is not fully xterm compatible.  The author suggested to
-ignore the "xterm-" prefix and use the terminfo entry anyway, but that
-conflicts with what is needed for other terminals.  Therefore Vim removes the
-"xterm-" prefix from "xterm-kitty" when it comes from $TERM.
+ignore the "xterm-" prefix and use the terminfo entry anyway, so that is what
+happens now, the builtin xterm termcap entries are not used.  However, the
+t_RV is set, otherwise other things would not work, such as automatically
+setting 'ttymouse' to "sgr".
+
+It is not clear why kitty sets $TERM to "xterm-kitty", the terminal isn't
+really xterm compatible.  "kitty" would be more appropriate, but a terminfo
+entry with that name is not widespread.
 
 Note that using the kitty keyboard protocol is a separate feature, see
 |kitty-keyboard-protocol|.
diff --git a/src/os_unix.c b/src/os_unix.c
index bd75ccae1403..9d8d466507ca 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -2353,6 +2353,8 @@ mch_restore_title(int which)
 /*
  * Return TRUE if "name" looks like some xterm name.
  * This matches "xterm.*", thus "xterm-256color", "xterm-kitty", etc.
+ * Do not consider "xterm-kitty" an xterm, it is not fully xterm compatible,
+ * using the "xterm-kitty" terminfo entry should work better.
  * Seiichi Sato mentioned that "mlterm" works like xterm.
  */
 int
@@ -2360,7 +2362,8 @@ vim_is_xterm(char_u *name)
 {
 if (name == NULL)
return FALSE;
-return (STRNICMP(name, "xterm", 5) == 0
+return ((STRNICMP(name, "xterm", 5) == 0
+&& STRNICMP(name, "xterm-kitty", 11) != 0)
|| STRNICMP(name, "nxterm", 6) == 0
|| STRNICMP(name, "kterm", 5) == 0
|| STRNICMP(name, "mlterm", 6) == 0
diff --git a/src/term.c b/src/term.c
index 7a70af450ca3..cd6b3b9cf62b 100644
--- a/src/term.c
+++ b/src/term.c
@@ -1675,6 +1675,12 @@ static char *(key_names[]) =
 #endif
 
 #ifdef HAVE_TGETENT
+/*
+ * Get the termcap entries we need with tgetstr(), tgetflag() and tgetnum().
+ * "invoke_tgetent()" must have been called before.
+ * If "*height" or "*width" are not zero then use the "li" and "col" entries to
+ * get their value.
+ */
 static void
 get_term_entries(int *height, int *width)
 {
@@ -2033,14 +2039,6 @@ set_termname(char_u *term)
 #endif
parse_builtin_tcap(term);
 
-   // Use the 'keyprotocol' option to adjust the t_TE and t_TI
-   // termcap entries if there is an entry maching "term".
-   keyprot_T kpc = match_keyprotocol(term);
-   if (kpc == KEYPROTOCOL_KITTY)
-   apply_builtin_tcap(term, builtin_kitty, TRUE);
-   else if (kpc == KEYPROTOCOL_MOK2)
-   apply_builtin_tcap(term, builtin_mok2, TRUE);
-
 #ifdef FEAT_GUI
if (term_is_gui(term))

Bug#1029049: [PATCH] Backport patch-9.0.1080 to fix keyprotocol option

[Andrea Pappacoda]

This fixes the keyprotocol option when using terminals supporting the
kitty keyboard protocol and modifyOtherKeys2 like foot and wezterm.

Closes: #1029049
---
Hi, I can confirm that patch 9.0.1080 fixes the issue described at
.

I've submitted a patch on Salsa at
, if you could
merge it it'd be great!

I'm also emailing the patch with git send-email for your convenience.

Bye :)

 ...sing-xterm-kitty-for-term-causes-pro.patch | 145 +++
 ...he-kitty-terminfo-entry-is-not-wides.patch | 169 ++
 ...087-autocommand-test-sometimes-fails.patch |   2 +-
 debian/patches/series |   2 +
 4 files changed, 317 insertions(+), 1 deletion(-)
 create mode 100644 
debian/patches/patch-9.0.1073-using-xterm-kitty-for-term-causes-pro.patch
 create mode 100644 
debian/patches/patch-9.0.1080-the-kitty-terminfo-entry-is-not-wides.patch

diff --git 
a/debian/patches/patch-9.0.1073-using-xterm-kitty-for-term-causes-pro.patch 
b/debian/patches/patch-9.0.1073-using-xterm-kitty-for-term-causes-pro.patch
new file mode 100644
index 0..899a90815
--- /dev/null
+++ b/debian/patches/patch-9.0.1073-using-xterm-kitty-for-term-causes-pro.patch
@@ -0,0 +1,145 @@
+From 731d00770d9006e7dab6a66e2ea86603ed5ef212 Mon Sep 17 00:00:00 2001
+From: Bram Moolenaar 
+Date: Sun, 18 Dec 2022 17:47:18 +
+Subject: [PATCH] patch 9.0.1073: using "xterm-kitty" for 'term' causes
+ problems
+
+Problem:Using "xterm-kitty" for 'term' causes problems.
+Solution:   Remove the "xterm-" part when 'term' is set from $TERM.  Detect a
+few kitty-specific properties based on the version response
+instead of the terminal name.
+---
+ runtime/doc/term.txt | 20 
+ src/term.c   | 44 +---
+ src/version.c|  2 ++
+ 3 files changed, 59 insertions(+), 7 deletions(-)
+
+diff --git a/runtime/doc/term.txt b/runtime/doc/term.txt
+index f7b65ea74..50ba187ab 100644
+--- a/runtime/doc/term.txt
 b/runtime/doc/term.txt
+@@ -294,6 +294,26 @@ When Vim receives a response to the |t_RV| (request 
version) sequence and it
+ starts with CSI, it assumes that the terminal is in 8-bit mode and will
+ convert all key sequences to their 8-bit variants.
+ 
++  *xterm-kitty* *kitty-terminal*
++The Kitty terminal is a special case.  Mainly because it works different from
++most other terminals, but also because, instead of trying the fit in and make
++it behave like other terminals by default, it dictates how applications need
++to work when using Kitty.  This makes it very difficult for Vim to work in a
++Kitty terminal.  Some exceptions have been hard coded, but it is not at all
++nice to have to make exceptions for one specific terminal.
++
++One of the problems is that the value for $TERM is set to "xterm-kitty".  For
++Vim this is an indication that the terminal is xterm-compatible and the
++builtin xterm termcap entries should be used.  Many other terminals depend on
++this.  However, Kitty is not fully xterm compatible.  The author suggested to
++ignore the "xterm-" prefix and use the terminfo entry anyway, but that
++conflicts with what is needed for other terminals.  Therefore Vim removes the
++"xterm-" prefix from "xterm-kitty" when it comes from $TERM.
++
++Note that using the kitty keyboard protocol is a separate feature, see
++|kitty-keyboard-protocol|.
++
++
+ ==
+ 2. Terminal options   *terminal-options* *termcap-options* *E436*
+ 
+diff --git a/src/term.c b/src/term.c
+index 7483974ac..7a70af450 100644
+--- a/src/term.c
 b/src/term.c
+@@ -2071,6 +2071,12 @@ set_termname(char_u *term)
+ else
+   T_CCS = empty_option;
+ 
++// Special case: "kitty" does not normally have a "RV" entry in terminfo,
++// but we need to request the version for several other things to work.
++if (strstr((char *)term, "kitty") != NULL
++ && (T_CRV == NULL || *T_CRV == NUL))
++  T_CRV = (char_u *)"\033[>c";
++
+ #ifdef UNIX
+ /*
+  * Any "stty" settings override the default for t_kb from the termcap.
+@@ -2599,15 +2605,34 @@ tgoto(char *cm, int x, int y)
+ void
+ termcapinit(char_u *name)
+ {
+-char_u*term;
++char_u*term = name;
+ 
+-if (name != NULL && *name == NUL)
+-  name = NULL;// empty name is equal to no name
+-term = name;
++if (term != NULL && *term == NUL)
++  term = NULL;// empty name is equal to no name
+ 
+ #ifndef MSWIN
++char_u*tofree = NULL;
+ if (term == NULL)
++{
+   term = mch_getenv((char_u *)"TERM");
++
++  // "xterm-kitty" is used for Kitty, but it is not actually compatible
++  // with xterm.  Remove the "xterm-" part to avoid trouble.
++  if 

Bug#1029237: fontconfig: consider adding NEWS file about changed default font in version 2.14

[Andrea Pappacoda]

Source: fontconfig
Version: 2.14.1-3
Severity: wishlist

Hi, could you please consider adding a NEWS file informing users about the fact
that Noto replaced DejaVu as the default font in fontconfig 2.14? It may mess
things up especially as the default monospace font in terminal emulators; see
for example these messages from #foot on Libera.Chat:

16:27:55  fyi, if you've just upgraded your distro recently and noticed
that the monospace font in foot is a bit off, it's because fontconfig 2.14
changed the default from DejaVu to Noto
16:28:06  See
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/208
16:29:11  > a bit off
16:29:28  it fu**ed up my setting so much that i was like, f**k xorg, and
went wayland and foot
16:29:43  only to learn that this doesnt fix my problem :D
16:30:15  but thanks for the link


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-- no debconf information

Bug#1029194: libvulkan-dev: No longer multi-arch installable

[Andrea Pappacoda]

Hi, I've submitted a patch to upstream CMake that should fix this kind
of bugs for good. You can find it at
.

Please consider reverting the patch moving the files to the libdir once
the patch is merged, either upstream or in Debian's cmake package.

Thanks!

Bug#1026768: vulkan-loader: please consider packaging version 1.3.238

[Andrea Pappacoda]

Hi, sdk-1.3.239.0 has been tagged a few days ago, could you please look
into packaging it? If you need any help, feel free to ping me!

https://github.com/KhronosGroup/Vulkan-Loader/releases/tag/sdk-1.3.239.0

Bug#1029096: bat: please rename batcat to bat

[Andrea Pappacoda]

Package: bat
Version: 0.22.1-1+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, could you please consider renaming back the batcat binary to bat? This used
to be necessary because /usr/bin/bat was also used by the bareos-bat package,
but it has been removed[1] a while back and the /usr/bin/bat file has remained
free since the release of bullseye.

Since the batcat name might be already in use, I suggest installing a symlink
or a compatibility script in /usr/bin/batcat that redirects to /usr/bin/bat,
like this:

#!/bin/sh
>&2 printf 'Invoking bat as %s is deprecated, please use bat instead\n'
"$0"
exec bat "$@"

[1]: https://bugs.debian.org/1000906


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 bat depends on:
ii  libc62.36-8
ii  libgcc-s112.2.0-13
ii  libgit2-1.5  1.5.0+ds-6

bat recommends no packages.

bat suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCY8bQVhQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3pwYjAP0UqtlMyIsVzVioyglJh8MpNPwZV1mn
/gAoPV5u1oaheQEA5P5OpbPTCvidBbd/u5Uij+hGMkBeQdIrVugQFmX78Qc=
=IDdx
-END PGP SIGNATURE-

Bug#1029414: autopkgtest: please install a doc-base file

[Andrea Pappacoda]

Package: autopkgtest
Version: 5.27
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all, could you please consider installing a doc-base file linking to the
installed HTML documentation files like
/usr/share/doc/autopkgtest/README.package-tests.html? This would make it
possible to easily browse it with tools like dochelp.

Thank you for your incredible work on autopkgtest!


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 autopkgtest depends on:
ii  apt-utils   2.5.4
ii  libdpkg-perl1.21.18
ii  procps  2:4.0.2-3
ii  python3 3.10.6-3+b1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.29-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  lxc  
pn  lxd  
ii  ovmf 2022.11-2
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.3
pn  qemu-efi-aarch64 
pn  qemu-efi-arm 
pn  qemu-system  
ii  qemu-utils   1:7.2+dfsg-1+b2
ii  schroot  1.6.13-3+b1
ii  util-linux   2.38.1-4
pn  vmdb2
pn  zerofree 

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCY81bGRQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p8tuAP9nGSrmNG0PegY0GKCRv5g/sRBguVNj
qT4CUcXMtDksBgD+NLMwKJETnwhS4HbtcBWNW4nenJtvHCZSPd7NBy0N7As=
=zjIA
-END PGP SIGNATURE-