Dear mentors,

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

 * Package name     : picohttpparser
   Version          : 1.2-1
   Upstream contact : Kazuho Oku <kazuhooku@gmail.com>
 * URL              : https://github.com/h2o/picohttpparser
 * License          : Expat or Artistic-1
 * Vcs              : https://salsa.debian.org/debian/libpicohttpparser
   Section          : libs

The source builds the following binary packages:

  libpicohttpparser1 - the (shared) parser library
  libpicohttpparser-dev - the develpoment files

The package is intended by upstream to be embedded as source and
several Debian packages already embed is.

https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies

I noticed picohttpparser since mosquitto (where I am one of the
maintainers) started embedding it. Embedding of source that processes
incoming network data is IMHO undesirable. So I am packaging this.

Please take an especially close look at the patches. I am rarely
writing makefiles, suggestions are very welcome.

You can download the package with 'dget' using this command:

  dget -x
https://www.heute-morgen.de/debian/repo/trixie/main/source/libs/libpicohttpparser_1.2-1.dsc


Regards,
Joachim Zobel

Hi Joachim,

I am not a Debian Developer or uploader, so I cannot sponsor the upload
myself, but I did a review and local build of 1.2-1 to see if I could help.

What I checked:

- fetched the source with dget from the URL in the RFS
- built it locally with dpkg-buildpackage -us -uc -b on arm64
- checked the resulting package contents, SONAME metadata, and lintian output

I think there is one real packaging issue in the current shared-library
setup:

- the built library file is libpicohttpparser.so.1.2
- the ELF SONAME inside it is libpicohttpparser.so.1
- the -dev package creates libpicohttpparser.so -> libpicohttpparser.so.1
- but the runtime package does not actually ship
  libpicohttpparser.so.1 -> libpicohttpparser.so.1.2

So at the moment the unversioned development symlink points to the SONAME
path, but that SONAME path is not present in the runtime package.

This seems to come directly from the current Makefile patch: it builds the
real file as libpicohttpparser.so.${DEB_VERSION_UPSTREAM} and sets the
SONAME to libpicohttpparser.so.1, but does not create the SONAME symlink.

I also noticed a test inconsistency:

- debian/changelog says the tests were changed to test the installed library
  with autopkgtest
- but I do not see a debian/tests/ autopkgtest setup in the source package
- and debian/rules currently disables dh_auto_test in normal builds via
  DEB_BUILD_OPTIONS filtering for "check", not "nocheck"

So as uploaded, the package builds, but the tests do not appear to run during
normal package builds, and I do not see the promised autopkgtest coverage
either.

For reference, lintian additionally reported:

- libpicohttpparser-dev: extended-description-is-probably-too-short
- libpicohttpparser1: symbols-file-missing-build-depends-package-field

I tried two small prototype fixes for the SONAME issue, both of which built
cleanly locally and produced the expected link layout:

1. Makefile-side fix
   - create libpicohttpparser.so.1 -> libpicohttpparser.so.1.2 during build
   - patch attached as an example: libpicohttpparser-soname-fix.patch

2. Debian-side packaging fix
   - keep the current Makefile patch as-is
   - add an override_dh_link rule in debian/rules to create the SONAME link
     in the runtime package
   - patch attached as an example:
     libpicohttpparser-soname-fix-debian-rules.patch

I am not suggesting that either prototype is the only correct fix, only that
both seem to address the missing SONAME symlink cleanly.

The package itself is definitely useful. The security-tracker
embedded-code-copies list currently shows picohttpparser embedded in bind9,
feersum, identity4c, libhttp-parser-xs-perl, and monitoring-plugins, so
getting a good shared library package in would help.

Regards,
James

Hi.

Thanks for reviewing this, I am actually unsure if what I did is
correct.

Am Samstag, dem 25.04.2026 um 13:44 +0000 schrieb
james_montgomery@disroot.org:

It actually does. After installing the package an activate-noawait
ldconfig trigger has created the link:

$ ls -l /usr/lib/x86_64-linux-gnu/libpicohttpparser.so*
lrwxrwxrwx 1 root root    24 25. Apr 18:00 /usr/lib/x86_64-linux-
gnu/libpicohttpparser.so.1 -> libpicohttpparser.so.1.2
-rw-r--r-- 1 root root 14248 28. Mär 10:42 /usr/lib/x86_64-linux-
gnu/libpicohttpparser.so.1.2

I don't know why this link is created by a trigger while the others
have to be explicitly installed. Actually I had to silence 2 library
symlink related lintian warnings, which is one of the reasons I am
unsure. But the result seems correct to me.

Thanks,
Joachim

Hi Joachim,

Thanks, and you are right.

I had checked the built package payload and staged package tree, but I did
not carry that through to the installed-state behavior. In this case, the
dh_makeshlibs/ldconfig trigger creates the libpicohttpparser.so.1 symlink
after installation, so my earlier SONAME concern was too strong.

So please disregard that part of my previous mail.

The part that still looks worth checking is the test side:

- debian/changelog says the tests were changed to test the installed library
  with autopkgtest
- I still do not find a debian/tests/ setup in the source package
- and debian/rules appears to disable dh_auto_test in normal builds by
  filtering on "check" rather than "nocheck"

So unless I am missing something else, I think the remaining question is not
the SONAME link, but whether the intended test/autopkgtest coverage is really
in place yet.

Regards,
James

Am Samstag, dem 25.04.2026 um 13:44 +0000 schrieb
james_montgomery@disroot.org:

Ouch, thanks for spotting that. Will be fixed.

This is intended. As soon as the tests are patched to use the installed
library they won't work locally any more.

Autopkgtests should of course work. 

Thanks.
Joachim