Bug#1069357: cpp-httplib: FTBFS: Test SSLClientServerTest.ClientCertPresent fails with timeout

[Andrea Pappacoda]

Hi all,

it indeed seems that this issue hasn't been caused by any recent
cpp-httplib update, since I've been able to reproduce it on versions as
old as 0.10.8+ds-1.

I suspect maybe an OpenSSL update broke something for this package? Why
didn't ci.d.n notice the breakage?

I'll try to see if I can find the breaking update...

Bug#1069357: Fwd: Re: Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-m

[Andrea Pappacoda]

 Messaggio originale 
Da: Andrea Pappacoda 
Inviato il: 3 maggio 2024 07:39:59 CEST
A: Stuart Prescott 
Oggetto: Re: Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd 
obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 
MESON_TESTTHREADS=4 meson test --timeout-multiplier=3 
--test-args=--gtest_filter=-\*_Online returned exit code 1

Hi Stuart, thanks for the ping.

I've been aware of these test failures for a while, but haven't been able to 
determine the cause of them. They actually ran successfully when I first 
uploaded the package, but broke after some package upload which I haven't yet 
identified.

It is possible that this is indeed a bug in cpp-httplib, but it has only showed 
up after an unknown package has been updated in unstable.

Citing a previous mail of mine, sent to Bastian Germann the 7th of April:

> When I uploaded the package to mentors the tests ran fine in an unstable 
> chroot, and still do when running them on my local machine (which runs 
> Testing). I haven't yet tried running them in a chroot which pulls things 
> from experimental, but if I run them now in an unstable chroot I get a 
> failure in the SSLClientServerTest.ClientCertPresent test, and a timeout 
> afterwards.

The issue shows up in cpp-httplib's Server::listen() function.

Do you have any suggestions regarding how I can "bisect" such an issue?

Thanks!

P.S. this mail may look broken - I've sent it from my phone.

Bug#1069820: android-sdk-meta: Split udev rules in separate package

[Andrea Pappacoda]

Source: android-sdk-meta
Version: 28.0.2+10
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, thanks for your work on the android-sdk!

Would you consider splitting the udev rules currently shipped in the android-
sdk-platform-tools-common into a separate source package, like "android-udev-
rules", which has  as the
upstream? To me, this would provide the following advantages:

- - The udev rules can be updated independently of the Android SDK, which is
important given how hard it is to maintain the SDK in Debian
- - The rules don't risk being removed from testing because of bugs in the SDK
package or its dependencies (which is currently the case)
- - Users who specifically only want to install the udev rules can do so

I've uploaded an initial packaging of the new android-udev-rules package on
Salsa; it's not complete yet (some things like the correct Breaks: and
Replaces: fields on android-sdk-platform-tools-common are missing) you can find
it here: 

Let me know what you think! I'm ready to maintain the package :)


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

Kernel: Linux 6.6.15-amd64 (SMP w/4 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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZioy4RQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p9HcAQDrZkR/SspsPrPyGUatgWGMWA9DOi/7
us+XC8VpvUBHlwEAwf47z6c4hXrQQaWckApX6E8jNBSN3U5e+P1bQyW9Aw0=
=IUul
-END PGP SIGNATURE-

Bug#1068129: ITP: redict - Licensing questions

[Andrea Pappacoda]

(Ccing Drew since he's way more knowledgeable of me - great new post
btw!)

Hi Maytham, thanks for accepting my request to join the Redict team!

I've started taking a look at the work you've done, and I have a few
questions regarding the debian/copyright file you wrote. I've noticed
that you've marked all the files as LGPL-3.0-only, but I'm not sure
that's correct.

Most Redict files come from Redis 7.2.4, where they were licensed under
the BSD-3-Clause license. While Redict is distributed under the
LGPL-3.0-only, the files themselves still carry the original copyright
properties, thus the d/copyright file should list them as licensed under
the BSD-3-Clause, or under both the old and new license. Or at least,
that's my understanding of how these things work.

For example, I think that the following file block:

Files: *
Copyright:
 2006-2014 Salvatore Sanfilippo 
 2024 Redict contributors
License: LGPL-3.0-only

should instead look something like:

Files: *
Copyright:
 2006-2014 Salvatore Sanfilippo 
 2024 Redict contributors
License: LGPL-3.0-only and BSD-3-Clause

This is also one of the few cases where I think that using the top-level
optional License field is appropriate. I'd use it to indicate that,
while the individual files have historically been licensed under the
BSD-3-Clause, Redict itself is distributed under the LGPL-3.0-only:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Contact: Drew DeVault 
Upstream-Name: redict
Source: https://redict.io
License: LGPL-3.0-only

(Also, the Source field should say "https://codeberg.org/redict/redict;,
but that's a pretty minor issue).

Let me know what you think! Bye :)

Bug#1068129: ITP: redict -- Distributed key/value store - forked from Redis

[Andrea Pappacoda]

On Tue, 02 Apr 2024 11:06:16 +0300 Maytham Alsudany  
wrote:
> If you are interested in packaging redict and you'd like to join the team,
> please go to https://salsa.debian.org/redict-team and request access.

Hi Maytham, thanks for your work on this! I'd live to work on Redict packaging 
too, and I've sent a request to join the redict-team group on Salsa.

I'm not a DD, so I can't help with sponsoring, but I think I'll apply for 
becoming one soon - I've been contributing to Debian for some years now.

Bye!

Bug#1036231: mbedtls: please update to 3.4.0 for cmake support

[Andrea Pappacoda]

On Thu, 22 Feb 2024 08:05:41 +0100 Jakob Haufe  wrote:
> On Wed, 17 May 2023 21:51:44 +0200 Andrea Pappacoda  
> wrote:
> 
> > I'd love to package the 3.x branch, but there currently isn't any LTS 
> > release for it; the latest LTS is 2.28.x. I'm not going to package 
> > non-LTS versions in Debian, since they don't fit nicely with the stable 
> > release scheme.
> 
> I think that ship has sailed. According to [1], 2.28.x will be supported
> until the end of 2024, so it will be EOL during the bookworm stable period.
> 
> Would you be open to package 3.x for experimental so ITPs depending on it can
> progress?
> 
> If you intend to have 2.x around for longer, maybe a separate source package
> (mbedtls3 ?) is necessary to allow packaging them in parallel.

Hi Jakob, thanks for your interest!

Luckily upstream has just released version 3.6 LTS, so I'll package that
as soon as possible, just after uploading the last 2.28.8 release.

I'll need help from a Debian Developer though, since I cannot upload
packages to NEW myself (which would be required due to SONAME changes).

Bye :D

P.S. please always CC me in replies, as my mail server discards emails
without proper DKIM signatures, like emails from the BTS.

Bug#1063252: Proposed fix broke pristine-tar for me

[Andrea Pappacoda]

Hi, thanks for your fix!

Unfortunately it seems that your patch has broke tarball generation for 
one of the packages I maintain, dynarmic.


   $ gbp export-orig
   gbp:info: Creating /home/tachi/dev/deb/dynarmic_6.5.0+ds.orig.tar.xz
   gbp:error: Pristine-tar couldn't verify 
"dynarmic_6.5.0+ds.orig.tar.xz": pristine-tar: 
/home/tachi/dev/deb/dynarmic/../dynarmic_6.5.0+ds.orig.tar.xz does not 
match stored hash (expected 
46a18274c7d15c9bcc9eced74d050af412728ebf03083b76fb650b70acf8, got 
7b56e580ab2c12003490dc2e2708106f37d51ebe4588b377f7557d5f7db34a6b)


I've been able to solve this issue locally by manually editing the `if 
(!$threads_set)` check to push `-T2` instead of `-T1` if no `-T` option 
was previously set, but I don't fully understand why this solves the 
issue.


Wouldn't it be better to unconditionally pass `-T0` and depend on 
xz-utils >= 5.3.0 so that the multi-threaded compressor is always used 
and the output format is the same regardless of the machine used to 
generate the compressed archive?


Thanks again!

Bug#1041275: sbuild: Using eatmydata with the unshare backend

[Andrea Pappacoda]

Hi Jochen, thanks for the reply!

On Fri Jan 5, 2024 at 1:17 PM CET, Jochen Sprickerhof wrote:
> Given enough RAM you can use a tmpfs like this:
>
> $unshare_tmpdir_template = '/dev/shm/tmp.sbuild.XX';

That's great, thanks! I also noticed that it is in the sbuild Wiki, but
I guess I missed it :)

Still, it'd be nice to be able to use eatmydata in cases where RAM isn't
enough. But thanks!

I know this isn't the best place to ask, but speaking of the wiki I'd
like to add a section about configuring sbuild to run autopkgtest when
using the unshare backend, since I haven't been able to do it myself and
I think could be helpful to others. If you know how to do it, please let
me know!

Bye :)

Bug#1060170: ITP: sirit -- library for runtime SPIR-V assembly

[Andrea Pappacoda]

Il giorno sab 6 gen 2024 alle 21:09:47 +00:00:00, David James 
 ha scritto:

* Package name: sirit
  Version : 0.0~git20230509
  Upstream Contact: Yuzu-emu team 
* URL : https://github.com/yuzu-emu/sirit
* License : BSD
  Programming Lang: C++, CMake
  Description : library for runtime SPIR-V assembly

I am woking towards packaging the Citra Nintendo 3DS emulator. This 
is the

second of five dependencies I need to package before I can do this.

[...]

I plan to maintain this myself but I would need a sponsor to upload 
it for

me.


Hi David, thanks for your interest in packaging Citra! I'm currently 
the maintainer of yuzu (but I haven't updated the package in a long 
time) and its dependencies, and I've looked into packaging Sirit in the 
past.


I would recommend you to avoid packaging this library, as Sirit is 
meant to be statically linked and does not guarantee any API or ABI 
stability, as mentioned upstream in 
. It's also pretty 
small, so it shouldn't be a big deal. yuzu currently does the same.


Thanks for your work! Bye :)

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

Bug#1053252: lcov: Missing runtime dependency on libdatetime-perl and libcapture-tiny-perl

[Andrea Pappacoda]

Hi all, I've submitted a small patch to fix this bug at
.

This bug is currently causing CI failures on all Debian Testing runners
we're using at .

Looking forward to its merge!

Bye :)

Bug#1059737: cpp-httplib: CMake support

[Andrea Pappacoda]

Control: tags -1 wontfix

Hi kiwixz, thanks for your report!

Il giorno dom 31 dic 2023 alle 04:20:25 +01:00:00, kiwixz 
 ha scritto:
I'd like to use this library from CMake and I believe upstream has 
direct support for it.

Could you please include the CMake config files in the package ?

The typical way to import the library in CMake would be:

find_package(httplib)

But with the current Debian package I need to use the provided 
pkg-config:


find_package(PkgConfig)
pkg_search_module(httplib IMPORTED_TARGET cpp-httplib)


This has been discussed upstream already at 
, and the main 
issue is that to generate CMake Config files you need to build the 
project with CMake. Why is it an issue? Because building with CMake 
would not generate a pkg-config file, and not shipping a pkg-config 
file would make the project unusable from Make, the Autotools, shell 
scripts, Muon, etc.


As a workaround I'd recommend you to use this CMake Find Module that I 
and another yuzu contributor (abouvier) wrote: 



I hope you now understand why this is a wontfix, at least for now!

Bye :)

Bug#1018037: ITP: cemu -- Wii U Emulator

[Andrea Pappacoda]

Control: noowner -1

Hi, I'm sorry but I no longer intend to package the Cemu emulator, at 
least for now, as life got way busier lately. Still, I've spent quite 
some time looking at Cemu's code, so if you intend to package this 
emulator yourself, feel free to ask for help!


Bye :)

Bug#1055517: opensysusers: modifies host system instead of target environment

[Andrea Pappacoda]

Hi Ansgar,

On Tue, 07 Nov 2023 19:38:25 +0100 Ansgar  wrote:
> opensysusers doesn't really implement the `--root` option (though it
> pretends a bit).  Functions like `add_group` always access
> `/etc/group` and use tools like `groupadd`:
> 
> ```sh
> grep -q "^$1:" /etc/group || groupadd -r "$1"
> ```
> 
> So they will always modify the host system, even when supposed to
> operate on some chroot environment.
> 
> Applying changes intended for some other environment to the host
> system looks like a potential security issue.

Thanks for the report, I wasn't aware of this issue and I agree with you
that yeah, this can be a security issue, and quite an unexpeted
behaviour.

How do you think this should be handled? opensysusers is pretty much
dead upstream (they accept patches, but the Artix Linux community isn't
working on it anymore), so I don't expect them to fix this bug. I'll
report it though.

Still, groupadd and useradd support a "--root" option which seems to do
exactly what we need here, so writing a patch to fix the issue looks
reasonable. I'm not sure how to test such patch though.

> AFAIR there are other incompatibilities with systemd-sysusers so that
> opensysusers should arguably not claim to be a compatible drop-in
> replacement.

This has been discussed both recently and some years ago, and while
using opensysusers as a drop-in replacement seemed appropriate in the
past, I don't think it still is *that* compelling, not because using a
systemd-sysusers alternative doesn't make sense (I have personally
worked to develop one in the past), but because opensysusers is
Linux-only, and it can be used in the same exact scenarios as the
standalone version of systemd-sysusers, so from a technical point of
view I don't really see opensysusers' usefulness anymore (a standalone
version of systemd-sysusers hasn't always existed). You could say that
opensysusers is "more secure" because it isn't written in C, but the
sh scripting language isn't exactly that secure compared to e.g. Rust
or Go.

In conclusion, I'm still not sure what the best thing to do right now
is. For now, I'll limit myself at fixing this bug.

Thanks again! Bye :)

Bug#1057636: ITP: swift-tools -- Swift cluster cli helpers utilities

[Andrea Pappacoda]

Hi Thomas, maybe swift-tools is a bit too generic as the name of this package. 
The first thing I though when reading it, was a set of tools to help 
development with the Swift programming language. Maybe it'd be better to add 
"openstack" or "cluster" to the package name?

Thanks for your work! Bye :)

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#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#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#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#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#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#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#1041270: dynarmic: broke ABI without SONAME bump

[Andrea Pappacoda]

Hi all, I've uploaded a fixed Dynarmic package a while back on mentors, if 
somebody could upload it for me it'd be great.

I'm currently on vacation, so I don't have access to a computer and won't be 
able to make changes to it, but it should be fine.

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

Thanks!

Il 21 luglio 2023 16:50:01 CEST, Andrea Pappacoda  ha 
scritto:
>> Hi Sebastian, thanks for your report. I've uploaded a new version with 
>> a possible fix on Mentors, you can find it at 
>> <https://mentors.debian.net/package/dynarmic/>. I've also attached a 
>> debdiff for your convenience.
>> 
>> Feel free to upload it to unstable if you find this solution 
>> reasonable. Since this is only a soname change, without any actual 
>> library change, I believe that uploading to experimental first is 
>> unnecessary.
>> 
>> If it doesn't look right to you, I'll be happy to hear your feedback :)
>
>My previous solution was broken since it introduced a new package with
>the same contents as the older libdynarmic6 package, causing an unpack
>error. Luckly upstream has merged my patch and tagged a new release,
>so I simply updated to the new upstream version, getting rid of the file
>conflict and bumping the ABI.
>
>I don't have access to my private OpenPGP keys right now, so I can't upload
>the new release on Mentors, but I'll attach a debdiff nonetheless containing
>the 6.5.0-1 release. You can also find it on Salsa at
><https://salsa.debian.org/debian/dynarmic/-/tags/debian%2F6.5.0+ds-1>.

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

[Andrea Pappacoda]

Il giorno lun 24 lug 2023 alle 09:05:30 +02:00:00, Sebastian Ramacher 
 ha scritto:
Please prepare transitions in experimental first. This would avoid 
such

issues.

If there are no news regarding a fix for this bug, please revert
cpp-httplib 0.11.4 to get back to a good state.


Hi, I'll be sure to do it next time. I've looked into this, but I 
couldn't find any change which would cause test failures on s390x 
specifically. cpp-httplib's test suite is a bit flaky though, so it may 
have been just an unlucky run (this is an issue in itself, but I have 
already reported it upstream and it didn't get much attention). Is it 
possible to re-try the build?


Thanks :)

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

Bug#1041270: dynarmic: broke ABI without SONAME bump

[Andrea Pappacoda]

> Hi Sebastian, thanks for your report. I've uploaded a new version with 
> a possible fix on Mentors, you can find it at 
> . I've also attached a 
> debdiff for your convenience.
> 
> Feel free to upload it to unstable if you find this solution 
> reasonable. Since this is only a soname change, without any actual 
> library change, I believe that uploading to experimental first is 
> unnecessary.
> 
> If it doesn't look right to you, I'll be happy to hear your feedback :)

My previous solution was broken since it introduced a new package with
the same contents as the older libdynarmic6 package, causing an unpack
error. Luckly upstream has merged my patch and tagged a new release,
so I simply updated to the new upstream version, getting rid of the file
conflict and bumping the ABI.

I don't have access to my private OpenPGP keys right now, so I can't upload
the new release on Mentors, but I'll attach a debdiff nonetheless containing
the 6.5.0-1 release. You can also find it on Salsa at
.

dynarmic_6.5.0+ds-1.debdiff
Description: Binary data

Bug#1041270: dynarmic: broke ABI without SONAME bump

[Andrea Pappacoda]

On Sun, 16 Jul 2023 18:34:16 +0200 Sebastian Ramacher 
 wrote:

> Source: dynarmic
> Version: 6.4.8+ds-2
> Severity: serious
>
> 
https://ci.debian.net/data/autopkgtest/testing/amd64/y/yuzu/35884387/log.gz

>
>  60s yuzu-cmd: symbol lookup error: yuzu-cmd: undefined symbol: 
_ZN8Dynarmic3A327Context4RegsEv


Hi Sebastian, thanks for your report. I've uploaded a new version with 
a possible fix on Mentors, you can find it at 
<https://mentors.debian.net/package/dynarmic/>. I've also attached a 
debdiff for your convenience.


Feel free to upload it to unstable if you find this solution 
reasonable. Since this is only a soname change, without any actual 
library change, I believe that uploading to experimental first is 
unnecessary.


If it doesn't look right to you, I'll be happy to hear your feedback :)

Thanks again!

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

diff -Nru dynarmic-6.4.8+ds/debian/changelog dynarmic-6.4.8+ds/debian/changelog
--- dynarmic-6.4.8+ds/debian/changelog	2023-07-05 22:03:58.0 +0200
+++ dynarmic-6.4.8+ds/debian/changelog	2023-07-20 19:13:04.0 +0200
@@ -1,3 +1,9 @@
+dynarmic (6.4.8+ds-3) unstable; urgency=medium
+
+  * d/{control,patches}: set soversion to major.minor (Closes: #1041270)
+
+ -- Andrea Pappacoda   Thu, 20 Jul 2023 19:13:04 +0200
+
 dynarmic (6.4.8+ds-2) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru dynarmic-6.4.8+ds/debian/control dynarmic-6.4.8+ds/debian/control
--- dynarmic-6.4.8+ds/debian/control	2023-07-05 22:03:58.0 +0200
+++ dynarmic-6.4.8+ds/debian/control	2023-07-20 19:11:30.0 +0200
@@ -25,7 +25,7 @@
  In the pursuit of speed, some behavior not commonly depended upon is elided.
  Therefore this emulator does not match spec.
 
-Package: libdynarmic6
+Package: libdynarmic6.4
 Architecture: any-amd64 any-arm64
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
@@ -39,7 +39,7 @@
 Section: libdevel
 Architecture: any-amd64 any-arm64
 Depends: libboost-dev,
- libdynarmic6 (= ${binary:Version}),
+ libdynarmic6.4 (= ${binary:Version}),
  llvm-dev,
  ${misc:Depends}
 Description: ${source:Synopsis} - development
diff -Nru dynarmic-6.4.8+ds/debian/libdynarmic6.4.install dynarmic-6.4.8+ds/debian/libdynarmic6.4.install
--- dynarmic-6.4.8+ds/debian/libdynarmic6.4.install	1970-01-01 01:00:00.0 +0100
+++ dynarmic-6.4.8+ds/debian/libdynarmic6.4.install	2023-07-20 19:11:30.0 +0200
@@ -0,0 +1 @@
+usr/lib/*/libdynarmic.so.6.4*
diff -Nru dynarmic-6.4.8+ds/debian/libdynarmic6.install dynarmic-6.4.8+ds/debian/libdynarmic6.install
--- dynarmic-6.4.8+ds/debian/libdynarmic6.install	2023-07-05 22:03:58.0 +0200
+++ dynarmic-6.4.8+ds/debian/libdynarmic6.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/*/libdynarmic.so.6*
diff -Nru dynarmic-6.4.8+ds/debian/patches/series dynarmic-6.4.8+ds/debian/patches/series
--- dynarmic-6.4.8+ds/debian/patches/series	2023-07-05 22:03:58.0 +0200
+++ dynarmic-6.4.8+ds/debian/patches/series	2023-07-20 19:04:31.0 +0200
@@ -1 +1,2 @@
 revert-catch2-v3.patch
+soname.patch
diff -Nru dynarmic-6.4.8+ds/debian/patches/soname.patch dynarmic-6.4.8+ds/debian/patches/soname.patch
--- dynarmic-6.4.8+ds/debian/patches/soname.patch	1970-01-01 01:00:00.0 +0100
+++ dynarmic-6.4.8+ds/debian/patches/soname.patch	2023-07-20 19:06:45.0 +0200
@@ -0,0 +1,28 @@
+Description: build: set SOVERSION to major.minor
+ Dynarmic uses semantic versioning, restricting backwards-incompatible
+ changes to major releases. This backwards compatibility, though, refers
+ to API changes, and disregards ABI stability. Since having to maintain a
+ compatible ABI between major releases is somewhat of a pain, and it
+ arguably doesn't matter that much for dynarmic, setting the SOVERSION to
+ major.minor allows for breaking ABI changes to be made between feature
+ releases, and not only major ones.
+ .
+ To be clear, this patch doesn't try to enforce a new policy, but just
+ reflects how the project has handled ABI changes in the past. That is,
+ these kind of changes have been made already.
+Author: Andrea Pappacoda 
+Origin: upstream, https://github.com/merryhime/dynarmic/pull/758
+Bug-Debian: https://bugs.debian.org/1041270
+Last-Update: 2023-07-20
+
+--- dynarmic-6.4.8+ds.orig/src/dynarmic/CMakeLists.txt
 dynarmic-6.4.8+ds/src/dynarmic/CMakeLists.txt
+@@ -455,7 +455,7 @@ target_include_directories(dynarmic PUBL
+ )
+ set_target_properties(dynarmic PROPERTIES
+ VERSION ${dynarmic_VERSION}
+-SOVERSION ${dynarmic_VERSION_MAJOR}
++SOVERSION ${dynarmic_VERSION_MAJOR}.${dynarmic_VERSION_MINOR}
+ )
+ target_compile_options(dynarmic PRIVATE ${DYNARMIC_CXX_FLAGS})
+ target_link_libraries(dynarmic

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

[Andrea Pappacoda]

On Sun, 16 Jul 2023 16:07:00 +0200 Sebastian Ramacher 
 wrote:

> Source: cpp-httplib
> Version: 0.13.1+ds-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in 
the past)

>
> When starting an uncoordinated transition, please at least ensure 
that

> the package at least builds on all suported platforms.

Hi Sebastian, thanks for the report. It isn't easy for me to test that 
cpp-httplib's test suite passes on all architectures, since I only have 
access to amd64 machines. Nonetheless, I'll look into this as soon as 
possible.


Thanks again!

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

Bug#1041275: sbuild: Using eatmydata with the unshare backend

[Andrea Pappacoda]

Package: sbuild
Version: 0.85.2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, I somewhat recently switched to the unshare backend, using tarballs
generated by mmdebstrap, and it has been great!

One thing that is a bit less nice than schroot, though, is the inability of the
unshare backend to use eatmydata to speed up package builds. Not only speed,
but I also fear that continuous (and unnecessary) disk writes may degrade my
disk's lifespan ever so slightly.

Is there a way possible to use eatmydata with the unshare backend? So far I
tried to start the build with `eatmydata sbuild`, but it doesn't seem to work.
The eatmydata package is installed in the tarball.

Thanks!


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

Kernel: Linux 6.3.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

Versions of packages sbuild depends on:
ii  adduser 3.134
ii  libsbuild-perl  0.85.2
ii  perl5.36.0-7

Versions of packages sbuild recommends:
ii  autopkgtest  5.29
ii  debootstrap  1.0.128+nmu2
ii  schroot  1.6.13-3+b2
ii  uidmap   1:4.13+dfsg1-1+b1

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.47.0-2
ii  kmod   30+20230519-1
ii  wget   1.21.3-1+b2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZLRGkBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p3/IAQDy9M1Se2vwiTLyj5ZXtB2D8/SsZbKK
gmPZJhpBBLueXQD/QHitxrjCK+f5Vg3eoZ+f6uz7PJwQHXjLvd+se4Xylwk=
=d+oF
-END PGP SIGNATURE-

Bug#1041074: bookworm-pu: package cpp-httplib/0.11.4+ds-1+deb12u1

[Andrea Pappacoda]

Il giorno sab 15 lug 2023 alle 16:35:01 +01:00:00, Adam D. Barratt 
 ha scritto:

Please go ahead.


Uploaded and accepted, thanks!

Bug#1037100: cpp-httplib: CVE-2023-26130

[Andrea Pappacoda]

Il giorno gio 13 lug 2023 alle 19:07:28 +02:00:00, Salvatore Bonaccorso 
 ha scritto:

The issue (CVE-2023-26130) in fact does not warrant a DSA, cf. as well
already the status in
https://security-tracker.debian.org/tracker/CVE-2023-26130 .

Can you fix it please via an upcoming point release? If you are fast
enough it can make it as well even for the 12.1 release.


Hi Salvatore, thanks for the suggestion.

I've prepared the stable upload (see 
) 
and just filled a bug on release.debian.org. You can find the bug at 
.


Bastian: could you please have a look at the new cpp-httplib I have 
posted on Mentors, please?


Thanks all!

Bug#1041074: bookworm-pu: package cpp-httplib/0.11.4+ds-1+deb12u1

[Andrea Pappacoda]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: cpp-http...@packages.debian.org
Control: affects -1 + src:cpp-httplib

Hi all, I'd like to push a stable update for cpp-httplib fixing a security
vulnerability. Since the vulnerability is not that serious (no-dsa) the
security team advised me to send it here instead of pushing it to bookworm-
security.

[ Reason ]
This fixes a security vulnerability (CRLF Injection).

[ Impact ]
cpp-httplib will have a security vulnerability in bookworm.

[ Tests ]
Upstream CI, autopkgtest, lintian, manual review.

[ Risks ]
This should be completely risk free.

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

[ Changes ]
cpp-httplib (0.11.4+ds-1+deb12u1) bookworm; urgency=medium

  * d/gbp.conf: adjust branch names for bookworm
  * d/patches: fix fox CVE-2023-26130.
Backport of the security fix for CVE-2023-26130, a CRLF Injection, from
upstream commit 5b397d455d25a391ba346863830c1949627b4d08 included in
upstream release 0.12.4 and newer. (Closes: #1037100)

 -- Andrea Pappacoda   Thu, 13 Jul 2023 00:26:06 +0200

[ Other info ]
That's it. This is a small update.
diff -Nru cpp-httplib-0.11.4+ds/debian/changelog 
cpp-httplib-0.11.4+ds/debian/changelog
--- cpp-httplib-0.11.4+ds/debian/changelog  2023-01-12 16:39:07.0 
+0100
+++ cpp-httplib-0.11.4+ds/debian/changelog  2023-07-13 00:26:06.0 
+0200
@@ -1,3 +1,13 @@
+cpp-httplib (0.11.4+ds-1+deb12u1) bookworm; urgency=medium
+
+  * d/gbp.conf: adjust branch names for bookworm
+  * d/patches: fix fox CVE-2023-26130.
+Backport of the security fix for CVE-2023-26130, a CRLF Injection, from
+upstream commit 5b397d455d25a391ba346863830c1949627b4d08 included in
+upstream release 0.12.4 and newer. (Closes: #1037100)
+
+ -- Andrea Pappacoda   Thu, 13 Jul 2023 00:26:06 +0200
+
 cpp-httplib (0.11.4+ds-1) unstable; urgency=medium
 
   * New upstream version 0.11.4+ds
diff -Nru cpp-httplib-0.11.4+ds/debian/gbp.conf 
cpp-httplib-0.11.4+ds/debian/gbp.conf
--- cpp-httplib-0.11.4+ds/debian/gbp.conf   2023-01-12 16:39:07.0 
+0100
+++ cpp-httplib-0.11.4+ds/debian/gbp.conf   2023-07-13 00:26:06.0 
+0200
@@ -1,8 +1,8 @@
 [DEFAULT]
 
 dist = DEP14
-debian-branch = debian/latest
-upstream-branch = upstream/latest
+debian-branch = debian/bookworm
+upstream-branch = upstream/0.11.x
 pristine-tar = True
 pristine-tar-commit = True
 sign-tags = True
diff -Nru cpp-httplib-0.11.4+ds/debian/patches/cve-2023-26130.patch 
cpp-httplib-0.11.4+ds/debian/patches/cve-2023-26130.patch
--- cpp-httplib-0.11.4+ds/debian/patches/cve-2023-26130.patch   1970-01-01 
01:00:00.0 +0100
+++ cpp-httplib-0.11.4+ds/debian/patches/cve-2023-26130.patch   2023-07-13 
00:26:06.0 +0200
@@ -0,0 +1,173 @@
+Description: Fix for CVE-2023-26130
+Author: Andrea Pappacoda 
+Origin: backport, 
https://github.com/yhirose/cpp-httplib/commit/5b397d455d25a391ba346863830c1949627b4d08
+Bug-Debian: https://bugs.debian.org/1037100
+Last-Update: 2023-07-12
+
+--- cpp-httplib-0.11.4+ds.orig/httplib.h
 cpp-httplib-0.11.4+ds/httplib.h
+@@ -5707,8 +5707,8 @@ inline void Server::apply_ranges(const R
+   res.headers.erase(it);
+ }
+ 
+-res.headers.emplace("Content-Type",
+-"multipart/byteranges; boundary=" + boundary);
++res.set_header("Content-Type",
++   "multipart/byteranges; boundary=" + boundary);
+   }
+ 
+   auto type = detail::encoding_type(req, res);
+@@ -6385,32 +6385,32 @@ inline bool ClientImpl::write_request(St
+   // Prepare additional headers
+   if (close_connection) {
+ if (!req.has_header("Connection")) {
+-  req.headers.emplace("Connection", "close");
++  req.set_header("Connection", "close");
+ }
+   }
+ 
+   if (!req.has_header("Host")) {
+ if (is_ssl()) {
+   if (port_ == 443) {
+-req.headers.emplace("Host", host_);
++req.set_header("Host", host_);
+   } else {
+-req.headers.emplace("Host", host_and_port_);
++req.set_header("Host", host_and_port_);
+   }
+ } else {
+   if (port_ == 80) {
+-req.headers.emplace("Host", host_);
++req.set_header("Host", host_);
+   } else {
+-req.headers.emplace("Host", host_and_port_);
++req.set_header("Host", host_and_port_);
+   }
+ }
+   }
+ 
+-  if (!req.has_header("Accept")) { req.headers.emplace("Accept", "*/*"); }
++  if (!req.has_header("Accept")) { req.set_header("Accept", "*/*"); }
+ 
+

Bug#1037100: cpp-httplib: CVE-2023-26130

[Andrea Pappacoda]

Il giorno gio 13 lug 2023 alle 12:08:28 +02:00:00, Bastian Germann 
 ha scritto:

2.: Please email the security team with the debdiff instead.


Ok, so they'll push it to the archive for me? Perfect!

Bug#1037100: cpp-httplib: CVE-2023-26130

[Andrea Pappacoda]

Il giorno gio 13 lug 2023 alle 08:46:47 +02:00:00, Bastian Germann 
 ha scritto:
The wasted effort is writing this paragraph. If you want me to 
sponsor the upload you _must_ eliminate the unpublished revision.


Yesterday night I was pretty tired and lazy, but yeah, I'll do it now.

You do not need to upload to mentors. But with the new upstream 
version, please wait for it to pass NEW before posting the security 
fix to the security team. That is the major drawback and in case of a 
more serious bug that would have beend unacceptable.


Oh okay, now I got it. I didn't quite understand what you were trying 
to explain to be before, but now I got it. Having a security fix wait 
in NEW is not ideal. Thanks for making me realize it.



Lintian is giving me this error:


I guess that is okay.


Perfect.

I'll re-do the updates more appropriately, roughly in this order:

1. Backport the fix in unstable, and push it to the archive
2. Backport the fix in bookworm-security, and push it to the archive
3. Package the latest upstream version, and push it to mentors

Does this look ok to you?

Bug#1037100: cpp-httplib: CVE-2023-26130

[Andrea Pappacoda]

Il giorno mer 12 lug 2023 alle 14:19:34 +02:00:00, Bastian Germann 
 ha scritto:
When you fix the unstable version via a patch and later upgrade to a 
new upstream version there is almost no additional work. So please go 
that route.


Yeah but this time I had already upgraded to a new upstream version 
(for experimental and now unstable), so it was easier for me to just 
create a new debian/bookworm git branch and backport the fix there.


Your new version still has an experimental 0.12 in the changelog that 
was never uploaded.


I'd prefer not to remove the experimental 0.12 from the changelog, 
since I have already uploaded everything to git and mentors. It's also 
something that actually happened, but I simply didn't find a sponsor in 
time and a new unstable release was prepared before uploading the 
experimental one. Unless I really _must_ remove the experimental entry 
from the changelog and git history I'd prefer to keep everything as is; 
it just looks like wasted effort to me, and I'd like to spend my time 
packaging a new yuzu version instead :)


I've uploaded the bookworm-security branch on Git, see 
. 
I'm unable to upload it to mentors because bookworm-security hasn't 
been added to the site yet.


I think that everything is ok, but Lintian is giving me this error:

   E: cpp-httplib changes: bad-distribution-in-changes-file 
bookworm-security

   N:
   N: You've specified an unknown target distribution for your upload 
in the
   N: debian/changelog file. It is possible that you are uploading for 
a
   N: different distribution than the one Lintian is checking for. In 
that case,

   N: passing --profile $VENDOR may fix this warning.
   N:
   N: Note that the distributions non-free and contrib are no longer 
valid.
   N: You'll have to use distribution unstable and Section: 
non-free/xxx or

   N: Section: contrib/xxx instead.
   N:
   N: Please refer to Distribution (Section 5.6.14) in the Debian 
Policy Manual

   N: for details.
   N:
   N: Visibility: error
   N: Show-Always: no
   N: Check: fields/distribution

If you think that this is a false positive, I can continue with the 
process.


Thanks :D

Bug#1037100: cpp-httplib: CVE-2023-26130

[Andrea Pappacoda]

On Mon, 12 Jun 2023 17:50:25 +0200 Bastian Germann  
wrote:

> Hi Andrea,
>
> As there was no upload to unstable after the bookworm version, just 
upload an unstable 0.11.4+ds-2 with the upstream
> patch (excluding or backporting the test) and mentioning the CVE in 
the changelog. Then add a bookworm-security
> changelog entry and debdiff the resulting package to 0.11.4+ds-1. 
You send the debdiff to the security team to operate on.

>
> See also 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security


Hi Bastian, sorry for not replying earlier but I did not receive your 
email (it was sent to 1037100-submitter@bugs.d.o).


I've uploaded an updated version of cpp-httplib to Mentors, because of 
soname changes (and a need to upload to NEW).


As for fixing the version in bookworm, I'll do it as soon as possible.

Thanks for the continuous help!

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

Bug#1028910: wlroots: Please fix in stable - Invalid WLR_RENDERER value: "vulkan"

[Andrea Pappacoda]

Source: wlroots
Version: 0.15.1-6
Followup-For: Bug #1028910

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all, could you please consider backporting the fix into bookworm? While
Jinesh reported this as severity "normal", this missing renderer creates
serious flickering on Sway when the nvidia-driver package is installed, making
its usage frustrating at best.

I'm only a DM, so I can't do this myself, unfortunately.

Thanks for your work!


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

Kernel: Linux 6.1.0-9-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-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZIuCexQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3px2yAQDCB9I7ukp2O0TRXm/7+jOAZfg6WC2k
+qhkPFf0EUbtzAEAziFSGAX/AqC9J9nGhf97f2GcL9Eh2mSmCyIH1wRTMQc=
=FKtc
-END PGP SIGNATURE-

Bug#1038006: nvidia-graphics-drivers: please package systemd power management scripts

[Andrea Pappacoda]

Source: nvidia-graphics-drivers
Version: 525.105.17-1
Severity: wishlist

Hi, could you please consider packaging the systemd power management scripts
provided by Nvidia? They are currently located in /usr/share/doc/xserver-xorg-
video-nvidia/examples/, and are not installed and enabled by the Debian
package.

The official driver installer, on the other hand, installs them automatically
since version 465.

You can find more information about these scripts in chapter 21 of the driver
documentation - the file is /usr/share/doc/nvidia-
driver/html/powermanagement.html

In short, the driver simply needs to install some systemd unit files and an
"nvidia-sleep.sh" script in /usr/bin.

Installing these scripts is required, for example, to use Wayland on GNOME with
the Nvidia drivers, as a udev rule installed by gdm3 checks for their presence
and disables Wayland support if they are not enabled - the rule is in
/lib/udev/rules.d/61-gdm.rules

Thanks!


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

Kernel: Linux 6.1.0-9-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#1037100: cpp-httplib: CVE-2023-26130

[Andrea Pappacoda]

Hi Salvatore, thanks for your report.

Il giorno dom 4 giu 2023 alle 21:13:04 +02:00:00, Salvatore Bonaccorso 
 ha scritto:

The following vulnerability was published for cpp-httplib.

CVE-2023-26130[0]:
| Versions of the package yhirose/cpp-httplib before 0.12.4 are
| vulnerable to CRLF Injection when untrusted user input is used to 
set

| the content-type header in the HTTP .Patch, .Post, .Put and .Delete
| requests. This can lead to logical errors and other misbehaviors.
| **Note:** This issue is present due to an incomplete fix for
| [CVE-2020-11709](https://security.snyk.io/vuln/SNYK-UNMANAGED-
| YHIROSECPPHTTPLIB-2366507).

The related CVE-2020-11709 was fixed before the initial upload to
Debian.

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


Fixing this in stable shouldn't be hard, but since I've little 
experience in backporting security fixes to stable I'm not sure how I 
should act. Should I simply push the updated package to 
bookworm-security? I'm only a Debian Maintainer, can I still do it? If 
not, could you please sponsor my upload?


Thanks again :D

Bug#1036231: mbedtls: please update to 3.4.0 for cmake support

[Andrea Pappacoda]

Il giorno mer 17 mag 2023 alle 20:26:52 +02:00:00, Matthias Geiger 
 ha scritto:
please update mbedtls to 3.4.0 . The 3.x release track includes the 
.cmake file

I'd need for another library I'm trying to package.


Hi Matthias, thanks for the report.

I'd love to package the 3.x branch, but there currently isn't any LTS 
release for it; the latest LTS is 2.28.x. I'm not going to package 
non-LTS versions in Debian, since they don't fit nicely with the stable 
release scheme.


If what you need for your package is just CMake dependency discovery, 
and not any library feature specific to the 3.x branch, what you could 
do instead is to patch the upstream build script to make use of a Find 
module which doesn't rely on .cmake Config files being available.


I currently do this for the yuzu package, which also depends on 
mbedtls. You can find my FindMbedTLS.cmake here: 



That file is tuned to yuzu's needs, i.e. it checks for the non-default 
CMAC support and only looks for the mbedcrypto library. If you can 
point me to the upstream project I'd be able to suggest a more 
appropriate file, or even send a patch upstream.


Thanks again for your report! I'll wait for your reply :)

Bug#1036218: Could I request a rebase of the yuzu Debian bookworm package?

[Andrea Pappacoda]

Package: yuzu
Version: 0-1335+ds-1
Severity: important

Hi Eric, thanks for your interest in the yuzu package!

Il giorno mer 17 mag 2023 alle 12:02:45 +01:00:00, Eric Curtin 
 ha scritto:

Apparently there's been a significant performance recently:

https://tech4gamers.com/yuzu-performance-boost/

It's also segfaulting and crashing on my machine as soon as I start
the game, I'm using a arm64 Chromebook to run the Debian bookworm yuzu
package.


Debian bookworm is currently in hard freeze[1], meaning that I cannot 
update the yuzu package to include new features or performance 
improvements, but I can only make small changes and bug fixes. This 
means that no, I cannot update the yuzu package to its latest, faster, 
version, but I can try to fix your segfaults and crashes on arm64.


Could you please share more details about your crashes? What's the 
oldest working version that works for you?


You can find all the releases on the yuzu-mainline GitHub page: 



Please also check that a manual vcpkg build (from source) of version 
1335 works for you, to make sure that this isn't an issue specific to 
the Debian packaging.


Thanks for your report!

[1]: https://release.debian.org/bookworm/freeze_policy.html

Bug#1034226: cloudflare-ddns: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Andrea Pappacoda]

Hi all,

Il giorno mar 11 apr 2023 alle 09:37:27 +02:00:00, bi...@debian.org ha 
scritto:
It seems that your package cloudflare-ddns is shipping files 
(.service, .socket or

.timer) in /usr/lib/systemd/system.

This is not supported by the version of dh_installsystemd/debhelper 
currently
in unstable and bookworm (See: #1031695). That means that currently 
your

service might not be enabled at boot and/or started as expected.


Thanks for the info! Having to install stuff outside of /usr kinda 
sucks, but I guess we don't have alternatives :/


Il giorno mar 11 apr 2023 alle 16:31:32 +02:00:00, Andreas Henriksson 
 ha scritto:

The culprit seems to be hard-coded paths in the upstream build system
at:
https://sources.debian.org/src/cloudflare-ddns/2.0.0-3/exe/meson.build/#L70

Since I wasn't sure about how configure_file directive in meson works
and the documentation at
https://mesonbuild.com/Reference-manual_functions.html#configure_file
says install_dir takes a subdirectory I had to try it out.

The attached debdiff should solve the problem.


Thanks you very much for the patch! Using systemd.pc certainly is the 
most appropriate thing to do, but the way you've approached this makes 
systemd a required dependency on Linux, which I'd prefer to avoid. I'll 
simply make th dependency `required: false`, so that files get 
installed only if systemd.pc is found on the system; this has the 
advantage of not making systemd required, and could also potentially 
work on non-Linux systems with systemd-compatible software (yeah, 
InitWare[1] is, or was, a thing).


I'll fix this upstream and in the Debian package as soon as possible, 
thanks again :)


[1]: https://github.com/InitWare/InitWare

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

Bug#1027429: mmdebstrap: unshare backend not working

[Andrea Pappacoda]

Il giorno gio 16 mar 2023 alle 03:57:42 +01:00:00, Johannes Schauer 
Marin Rodrigues  ha scritto:

I found another actionable in your bug report. mmdebstrap should not
automatically choose unshare mode if that cannot work on your system. 
To that

end I wrote:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/055e1719b95960496a0cda88535fd00e9a395516

If you like, please try that out on your system with --mode=unshare 
as well as

with --mode=auto. The messages and logic should be much better now.


Hi Josch, sorry for my super late reply and thanks for your fix! The 
error message is much cleaner now, and it gives the user a useful 
pointer so that the issue can be manually fixed/worked around.


Thanks again, keep up with the great work :D

Bug#1034125: unblock: mbedtls/2.28.2-1

[Andrea Pappacoda]

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

Please unblock package mbedtls

[ Reason ]
Upstream released a new LTS bugfix version, and I'd like to have it in
bookworm. Since mbedtls is a crypto library and backporting single commits can
be dangerous, importing new versions is the safest and most appropriate thing
to do, especially since the upstream developers do a pretty good job in
maintaining LTS versions for a long time.

[ Impact ]
If not granted, Debian will release with a somewhat vulnerable/buggy version of
a widely used crypto library.

[ Tests ]
I've manually reviewed the changelog and diffs of the new release, tested it
locally with the upstream test suite and autopkgtest, and it has passed all the
CI checks on Salsa (repo available at
).

[ Risks ]
Risks should be low, as upstream usually does a good job with backporting. The
"only" issue is that between 2.28.2 and 2.28.3 they have adopted a new code
style, and reformatted the whole codebase accordingly; this means that the
debdiff is huge, even though the changes are only a few. To make reviewing
easier for me and you too, I've prepared three git diffs that exclude the
upstream commits that reformatted the code, and another one that adds the
string "\emptydescription" to many documentation strings in the source files.
As upstream also always backports test code along with fixes, these diffs only
include changes from the include/ and library/ directories, since that's where
the code that gets into the binary packages resides.
.
The diffs were generated with these commands:
.
$ git clone https://github.com/Mbed-TLS/mbedtls.git
$ cd mbedtls
$ git diff v2.28.2..160df1d13621ca3ee70e1fa19d0da88398da9683~1 include/
library/
$ git diff
b37f6c1b95815d39fea26b2a17e318602eefe709..b361e04207831f753a29d6036361d44473bc~1
include/ library/
$ git diff 7a5168e90db359e17e72591cb5ddb06ef5f0388f..v2.28.3 include/
library/

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

[ Other info ]
I mistakenly uploaded the new mbedtls version to unstable because I didn't
realize it was a key package, and thought that a regular 20 days of waiting
would suffice. This is also my first unblock request, so please be clement with
me, thanks! :D

Also, the debdiff is not directly attached to this email to avoid hitting the
size limit of the mailing list. You can find it here:


unblock mbedtls/2.28.2-1
diff --git a/include/mbedtls/bn_mul.h b/include/mbedtls/bn_mul.h
index a3fc36381..bce9ce38c 100644
--- a/include/mbedtls/bn_mul.h
+++ b/include/mbedtls/bn_mul.h
@@ -84,6 +84,7 @@
 
 #endif /* bits in mbedtls_mpi_uint */
 
+/* *INDENT-OFF* */
 #if defined(MBEDTLS_HAVE_ASM)
 
 #ifndef asm
@@ -1001,4 +1002,5 @@
 #endif /* C (generic)  */
 #endif /* C (longlong) */
 
+/* *INDENT-ON* */
 #endif /* bn_mul.h */
diff --git a/include/mbedtls/check_config.h b/include/mbedtls/check_config.h
index 7ae1ff94d..2ab99823e 100644
--- a/include/mbedtls/check_config.h
+++ b/include/mbedtls/check_config.h
@@ -28,6 +28,7 @@
 #ifndef MBEDTLS_CHECK_CONFIG_H
 #define MBEDTLS_CHECK_CONFIG_H
 
+/* *INDENT-OFF* */
 /*
  * We assume CHAR_BIT is 8 in many places. In practice, this is true on our
  * target platforms, so not an issue, but let's just be extra sure.
@@ -143,6 +144,11 @@
 #error "MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED defined, but 
MBEDTLS_ECDH_LEGACY_CONTEXT not disabled"
 #endif
 
+#if defined(MBEDTLS_ECP_RESTARTABLE)   && \
+!defined(MBEDTLS_ECP_C)
+#error "MBEDTLS_ECP_RESTARTABLE defined, but not all prerequisites"
+#endif
+
 #if defined(MBEDTLS_ECDSA_DETERMINISTIC) && !defined(MBEDTLS_HMAC_DRBG_C)
 #error "MBEDTLS_ECDSA_DETERMINISTIC defined, but not all prerequisites"
 #endif
@@ -955,4 +961,5 @@
  */
 typedef int mbedtls_iso_c_forbids_empty_translation_units;
 
+/* *INDENT-ON* */
 #endif /* MBEDTLS_CHECK_CONFIG_H */
diff --git a/include/mbedtls/cipher.h b/include/mbedtls/cipher.h
index 6d83da882..ce100d3ed 100644
--- a/include/mbedtls/cipher.h
+++ b/include/mbedtls/cipher.h
@@ -917,13 +917,13 @@ int mbedtls_cipher_crypt( mbedtls_cipher_context_t *ctx,
  *  parameter-verification failure.
  * \return  A cipher-specific error code on failure.
  */
-int mbedtls_cipher_auth_encrypt( mbedtls_cipher_context_t *ctx,
- const unsigned char *iv, size_t iv_len,
- const unsigned char *ad, size_t ad_len,
- const unsigned char *input, size_t ilen,
- unsigned char *output, size_t *olen,
- unsigned char *tag, size_t tag_len )
-   

Bug#1030670: Does not depend on libspng0

[Andrea Pappacoda]

Hi Jordi, thanks for the fast report!

On Mon Feb 6, 2023 at 12:09 PM CET, Jordi Mallach wrote:
> While trying to build against the new libspng-dev, I found that even my
> build was issuing -lspng, it would fail because it could not find it.
>
> It turns out you're missing a dependency against libspng0 itself.

Whoops, I wonder how I missed that. I thought lintian had a check for
this too, but aparently it doesn't.

> Additionally, I've seen the following too:
>
> - spng.pc declares:
>
> Requires.private: zlib
>
> If I understand correctly, this is not a public dependency, which means
> libspng-dev does not need to depend on zlib-dev. In fact, that's one of
> the features SPNG advertises.

Yeah, it's not part of the public interface (i.e. not exposed in the
header file), but it's still required to statically link to the library.
Not only that, but even if shared linking is required, pkg-config
requires all the Requires.private dependencies if the --cflags flag is
specified. If you try to remove zlib.pc and ask pkgconf to find spng,
here's what happens:

$ pkg-config --cflags --libs spng   
Package zlib was not found in the pkg-config search path.
Perhaps you should add the directory containing `zlib.pc'
to the PKG_CONFIG_PATH environment variable
Package 'zlib', required by 'spng', not found

In short, zlib-dev is a required dependency. As for what spng
advertises, yeah, you _can_ avoid zlib, but by using minz instead.

> - I would downgrade the Recommends on libspng-doc to a Suggests, to
>   avoid pulling in fonts and other unneeded packages on the 95% of
>   cases.

I'd prefer to keep it a recommendation instead. I find offline
documentation extremely important, as you don't always have internet
access; not only that, you can only grep it for what you're looking for,
etc, etc. Some make documentation part of the -dev package itself, but
with a Recommends it won't pulled in by a buildd, where it really is
unneeded.

That being said, I find pulling in an extra font package annoying too,
so I'll look into dropping that.

Thanks again for the report and suggestions! I've pushed the fix to
Salsa, and I'll do an upload ASAP.

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#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#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-

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#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#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#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#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#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#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#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#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#1028252: tomlplusplus FTBFS: dpkg-checkbuilddeps: error: Unmet build dependencies: cmark-gfm:native

[Andrea Pappacoda]

On Mon, 09 Jan 2023 00:23:21 +0200 Adrian Bunk  wrote:
> Source: tomlplusplus
> Version: 3.2.0+ds-1
> Severity: serious
> Tags: ftbfs
>
> cmark-gfm is not Multi-Arch: allowed

Hi Adrian, thanks for the report. When I tagged the 3.2.0+ds-1 release 
I had to mark cmark-gfm with :native to make cross-builds work. 
cmark-gfm (and cmark) have been marked as Multi-Arch: foreign since 
then, so the :native thing should be indeed removed now.


Bastian has already pushed the fix to Salsa, and I've now uploaded -2 
to Mentors.

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

[Andrea Pappacoda]

Il giorno sab 7 gen 2023 alle 23:42:24 +01:00:00, Andrea Pappacoda 
 ha scritto:
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).


Hi John, I've uploaded the muon-meson package to Mentors: 
https://mentors.debian.net/package/muon-meson/


It is also available on Salsa at 
https://salsa.debian.org/tachi/muon-meson - somebody will eventually 
move it to the debian namespace though.

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#1023178: microprofile: Contains non-free source

[Andrea Pappacoda]

Control: tag -1 + pending

I've just fixed the mentioned issues and uploaded the package to 
mentors.

Bug#1023178: microprofile: Contains non-free source

[Andrea Pappacoda]

On Mon, 31 Oct 2022 11:02:55 +0100 Bastian Germann  
wrote:
> The files src/microprofile*.html contain JavaScript code from 
https://gist.github.com/mjackson/5311256
> which never got a license even though people have asked for it. So 
please exclude them.


Hi Bastian, thank you for the report. I'll fix it as soon as possible, 
possibly in the 4.0 release. I've already uploaded the latest release 
to mentors, but it doesn't contain this fix.


As a sidenote, the BTS doesn't send me emails, probably because of its 
broken DMARC/DKIM setup. In the future, please Cc me in emails you send 
to the BTS.


Thanks, as always!

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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]

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#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#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