quill as Ubuntu package

[3manifold]

Given that quill is not directly available through official Ubuntu repos, is there a Personal Package Archives (PPA) that one can find it? It would be super-handy instead of having to build it from source.

[odygrd]

Currently not, it is a header only library so all you need is to copy the include folder of this repo, you do not need to build anything.

It is available on multiple package managers https://github.com/odygrd/quill?tab=readme-ov-file#installation

[3manifold]

I see; the downside is that, since they are included directly into the project's source files, they are compiled using the project's compiler flags.

[odygrd]

Yes, but the library is designed to be warning-free without requiring special flags—considerable effort has been put into that.

For better compile times, you can build the backend as a separate library and share it across translation units using a quill_wrapper library.

The frontend remains header-only due to its reliance on templates and for performance reasons.

I submitted a Debian package request a while ago, but since they only accept packages from existing maintainers, I don’t think it will make it there soon. For anyone interested, here’s the process: Debian WNPP Requested Packages.

[Syed-Shahrukh-OSSRevival]

Hi, I’m Shahrukh from OSS Revival. We specialize in revitalizing and maintaining open-source projects for long-term stability.

I’m interested in packaging this project for Debian and intend to contribute by preparing and maintaining it within the Debian ecosystem.

[odygrd]

Hey Shahrukh, that sounds amazing—really appreciate it! You can use the latest release, 8.2.0, instead of the older version in that request. The library is header-only, so packaging should be straightforward. Let me know if you need any info—I’d be happy to help with anything needed. Thanks!

[Syed-Shahrukh-OSSRevival]

Hi,
I am pretty much done with debian packaging. Will be working on the CI aspect of the packaging. Debian supports multi arch (amd64, arm64, armel,armhf, i386, loong64, ppc64el, riscv64 and s390x).

I have verified the package installation and also tested some demo applications using cmake find package and pkgconfig. For pkgconfig i had to add a debian package patch as it was being installed /usr path directly. I will be creating a PR for pkgconfig path fix in CMakeLists.txt.

Screenshot for package warnings.

1. https://lintian.debian.org/tags/newer-standards-version (can be ignored)
2. https://lintian.debian.org/tags/repeated-path-segment
3. https://lintian.debian.org/tags/debian-watch-does-not-check-openpgp-signature
4. https://lintian.debian.org/tags/duplicate-files
5. https://lintian.debian.org/tags/very-long-line-length-in-source-file

Most of the issue are self explanatory, for point 3 please enable signed archives and share your gpg key which i can place in debian packaging.

Point 2-4 are most important to be fixed, while if all the warning are removed this will hopefully ensure smooth sponsorship of the package :-).

Thank you for your support.

[odygrd]

thank you so much for doing this @Syed-Shahrukh-OSSRevival !
I am going to look into those issues in the following days

[odygrd]

I’ve addressed most of the warnings in this PR:
#713

A few questions:

1. Would it be possible to exclude the docs folder from packaging? I believe it makes sense to exclude it, as some warnings—like the long lines in the draw.io file—don’t seem relevant to packaging.

2. Regarding point 3 (OpenPGP signature verification), would it be possible to skip this requirement? Signing each release would introduce an extra manual step, which I'd prefer to avoid. Many established libraries don’t require this, and given that Quill is a logging library rather than a security-critical component like a database, I believe it should be fine without it.

3. If you decide to run the tests after package installation, please avoid running the full test suite. Some tests are highly detailed and take a long time to complete. Instead, I recommend running a single test:

   ctest --build-config Release --output-on-failure -R "^multi_frontend_threads$". 

This should provide a reasonable verification without excessive runtime overhead.

Thanks again for your help!

[Syed-Shahrukh-OSSRevival]

Thank you for providing the fixes.

1. This is experimental. Debian package itself is only the debian folder, while the package original is the tar file that is downloaded from the upstream. I can apply small patches to fix bug etc, while AFAIK any structural changes are not possible. I tried to make a patch to remove docs but the build failed.

dpkg-source: info: if patch '002_docs_rem.patch' is correctly applied by quilt, use 'quilt refresh' to update it
dpkg-source: info: if the file is present in the unpacked source, make sure it is also present in the orig tarball
dpkg-source: info: restoring quilt backup files for 002_docs_rem.patch
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/002_docs_rem.patch/ --reject-file=- < quill/debian/patches/002_docs_rem.patch subprocess returned exit status 1
gbp:error: 'git-pbuilder' failed: it exited with 2

2. Well this is experimental. Most newer packages have signing. This ensure package download are authentic, no change in the middle.
3. I hadn't planned to add the tests, I will now :-)

[odygrd]

Hey,

I've fixed the remaining warnings in the docs folder—hopefully, everything is now good on master.

I understand your point about GPG-signed releases, but for a header-only logging library, it feels like overkill. Every time I make a release, I’d have to download the tarball, sign it with my GPG key, and then upload the additional .asc file. It just adds an extra step for each release, which I’d prefer to avoid if possible.

Regarding the tests, it's up to you. You can run a single test for verification, or none at all—it should still be fine.

Once you're happy with the current master, I’m happy to tag a new release so you can package it. That way, we can include any fixes you need, like the pkgconfig path.

Let me know how you'd like to proceed!

[Syed-Shahrukh-OSSRevival]

Thank you for addressing the issues,

Yes it is possible to package without GPG signatures.

Sounds perfect, I will get back to with packaging results of current master.

[Syed-Shahrukh-OSSRevival]

There were few remaining for which I am creating a PR for your review.

The last remaining is README.md which is an svg, I will remove this through a patch on debian side.