On 04.01.2025 03:26:56 MSK you wrote:
> Le ven. 3 janv. 2025 à 19:13, Jérémy Lal <kapouer@melix.org> a écrit :
> > Yes, I am reviewing it and will sponsor it.
> > I forked it to
> > https://salsa.debian.org/debian/ada-url
> > and gave you maintainer access.
> > Can you update the links in debian/control, please ?
OK. Moved. Though, you've forked my Git repository, can you remove link to the
origin project? And I'd like to delete the project in my personal namespace and
avoid duplication.
https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#unlink-a-fork
I can't, apparently I'm not the project owner.
You're welcome to push your changes to debian/ada-url now.
> > First question: can you see if it is possible to run the tests as
> > autopkgtests ?
> - adaparse could be compiled and distributed (along with a manpage and
> docs/cli.md)
The automated tests and the adaparse utility can't be easily compiled offline
because CMake scripts try to download dependencies from GitHub. Fortunately,
this will be fixed in the coming upstream version.
> - Use dh-sequence-doxygen to generate the docs
I've added a separate libadaurl-doc package with an HTML generated documentation.
https://salsa.debian.org/debian/ada-url/-/compare/upstream%2Flatest...mymedia%2Fmaster
Nice.
Note that dh-sequence-doxygen already depends on doxygen,
so there is no need to explicitly depend on doxygen.
ABI considerations become especially important when we have a bunch of
dependents. At present, only two packages, telegram-desktop and nodejs, are
going to use libadaurl, and in case of an ABI change, we can test run-time
linking manually. It's nice to have deb-src-symbols(5) to track ABI. But I
abandoned the symbols file because it grew too large, and my package uses only
few functions from the library.
In that case, if there is no ABI tracking at all, the soname must be incremented
on each new release, so that it is libada2-1, libada2-2, etc...
We need to figure this out before uploading the package to NEW.
Jérémy