Bug#1069357: cpp-httplib: FTBFS fixed on mentors

[Andrea Pappacoda]

Hi all, I've uploaded a fixed version on Mentors, available here: 
https://mentors.debian.net/package/cpp-httplib/


If you're a DD, I'd greatly appreciate a sponsored upload :D

Bye.

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

Bug#1069357: marked as pending in cpp-httplib

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1069357 in cpp-httplib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/cpp-httplib/-/commit/da7a05c0c81b4105baf63a8919ed2806132aabf8


d/patches: use static certs for tests

Closes: #1069357
Closes: #1073440


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069357

Bug#1073440: marked as pending in cpp-httplib

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1073440 in cpp-httplib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/cpp-httplib/-/commit/da7a05c0c81b4105baf63a8919ed2806132aabf8


d/patches: use static certs for tests

Closes: #1069357
Closes: #1073440


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1073440

Bug#1069357: marked as pending in cpp-httplib

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1069357 in cpp-httplib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/cpp-httplib/-/commit/b1ac1a8091c049edf533dc92fce345005508998c


d/patches: use static certs for tests

Closes: #1069357
Closes: #1073440


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069357

Bug#1073440: marked as pending in cpp-httplib

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1073440 in cpp-httplib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/cpp-httplib/-/commit/b1ac1a8091c049edf533dc92fce345005508998c


d/patches: use static certs for tests

Closes: #1069357
Closes: #1073440


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1073440

Bug#1069357: OpenSSL 3.2 breaks cpp-httplib

[Andrea Pappacoda]

Control: forwarded -1 https://github.com/yhirose/cpp-httplib/issues/1798

Hi all, a Gentoo developer has confirmed that this issue has been 
caused by the OpenSSL 3.2 update, as I suspected. In almost two months, 
nobody has been able to provide a fix. What should I do?

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#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#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#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#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#1041270: marked as pending in dynarmic

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1041270 in dynarmic reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/dynarmic/-/commit/0b8afc2381e9fd8b8e5186100a68d189b1cfd957


d/{control,patches}: set soversion to major.minor

Closes: #1041270


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1041270

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#1034226: marked as pending in cloudflare-ddns

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1034226 in cloudflare-ddns reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/tachi/cloudflare-ddns/-/commit/f82000e4cc2f6b71c504935862371ba5b6cdc0a7


d/patches: use systemd.pc to get systemd paths

Using systemd.pc to get systemd unit and sysusers.d paths avoids having
to hardcode paths, which leads to issues when files have to be installed
outside of /usr, like with unit files in bookworm.

Closes: #1034226
Thanks: Andreas Henriksson for the patch!


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1034226

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#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#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#1027913: marked as pending in howardhinnant-date

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1027913 in howardhinnant-date reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/howardhinnant-date/-/commit/b8e4338b25d9ac5ace44ed6797cbd1bf77cbf51d


d/control: depend on tzdata

Closes: #1027913


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1027913

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#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#980609: missing i386-cpuinfo.h

[Andrea Pappacoda]

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

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