I request an adopter for the approx package.
(I am no longer active with OCaml and have been using squid instead
of approx.)


The package description is:
 Approx is an HTTP-based proxy server for Debian-style package archives.
 It fetches files from remote repositories on demand,
 and caches them for local use.
 .
 Approx saves time and network bandwidth if you need to install or
 upgrade .deb packages for a number of machines on a local network.
 Each package is downloaded from a remote site only once,
 regardless of how many local clients install it.
 The approx cache typically requires a few gigabytes of disk space.
 .
 Approx also simplifies the administration of client machines:
 repository locations need only be changed in approx's configuration file,
 not in every client's /etc/apt/sources.list file.
 .
 Approx can be used as a replacement for apt-proxy,
 with no need to modify clients' /etc/apt/sources.list files,
 or as an alternative to apt-cacher.

retitle 948603 ITA: approx -- caching proxy server for Debian archive files
owner 948603 Leonardo <leonardoluxx@proton.me>
thanks

Hola a todos,

Mi nombre es Leonardo y estoy interesado en adoptar el paquete "approx" (bug #948603). He montado un entorno Debian sid y he conseguido compilar el paquete exitosamente (los 148 tests pasan).

Sin embargo, antes de hacer mi primer upload, he encontrado tres puntos que me gustaría aclarar con el equipo:

1. El tarball upstream no es reproducible con pristine-tar. `pristine-tar gentar` falla en la fase final, y el release de GitHub da 404. He generado un tarball funcional con `git archive` para testear, pero no coincide con el sha1 registrado. ¿Cómo suelen gestionar esto en el equipo?

2. Hay una incoherencia entre `debian/source/format` (que dice 3.0 quilt) y `debian/gbp.conf` (que dice pristine-tar = True), y no existe `debian/patches/`. ¿Cuál es el flujo de trabajo correcto que debo seguir?

3. He notado que nuestro .deb no lleva la dependencia `systemd | systemd-standalone-tmpfiles | systemd-tmpfiles`, aunque sí instala el archivo en `/usr/lib/tmpfiles.d/approx.conf`. El binario oficial de sid sí la lleva. ¿Es un problema de versión de debhelper o debo añadirla manualmente en debian/control?

Quedo a la espera de vuestros comentarios para proceder con el upload correctamente.

Un saludo,Leonardo

Dear maintainers,

Following up on my earlier message about taking over approx (bug #948603), I have set up a Debian sid build environment and reproduced the current packaging. I am writing to report what I found, because two of my three initial concerns turned out to be non-issues and I would rather correct the record than leave misleading impressions.

Summary of findings:

1. pristine-tar: not broken. My initial report that pristine-tar was broken was my own mistake. I had run "pristine-tar gentar" from a directory outside the git repository; pristine-tar needs the git tree to rebuild the delta base and fails there. Run from inside the repository it works perfectly and reproduces approx_5.13.orig.tar.gz byte-for-byte identically to the copy in the Debian archive. No issue here.

2. systemd-tmpfiles dependency: this one is real. approx ships /usr/lib/tmpfiles.d/approx.conf via debian/approx.tmpfiles. Rebuilding approx from its current git master against sid produces a binary whose Depends field lacks "systemd | systemd-standalone-tmpfiles | systemd-tmpfiles", whereas approx 5.13-3+b1 currently in sid has it. The cause is in debhelper, not in approx: dh_installsysusers adds the sysusers alternative through ${misc:Depends}, but dh_installtmpfiles contains no addsubstvar() call, even though its manpage states that it adds the dependency. I have prepared the one-line debian/control fix and verified that the resulting Depends field is then identical to the official binary. I have not pushed anything.

3. Source format: no change needed. debian/source/format is 3.0 (quilt) while debian/gbp.conf sets pristine-tar = True. I initially read this as an inconsistency, but it is in fact the standard combination: the OCaml team uses git-buildpackage with pristine-tar for upstream tarballs, and pristine-tar exists precisely to supply the .orig tarball that 3.0 (quilt) requires, with bit-identical checksums for dak. I am leaving it alone.

Two questions:

- Should I file a separate bug against debhelper about the dh_installsysusers / dh_installtmpfiles asymmetry? I have a draft ready including reproduction steps, and I would rather not duplicate a report someone may have already filed. I would also appreciate knowing whether the maintainers prefer that affected packages declare the dependency explicitly in the meantime.

- Lintian reports "missing-systemd-timer-for-cron-script" for /etc/cron.weekly/approx. This is pre-existing, as the official binary in sid reports the same warning, so it is not a regression. Would the team prefer it to be addressed now, by converting the cron script into a systemd timer, or left as-is? I can prepare a Merge Request either way.

I have a fix/blockers-wip branch prepared locally with the debhelper workaround and an UNRELEASED changelog entry, but I have deliberately not pushed anything and will hold off on a Merge Request until I hear from you about maintainership.

Happy to provide the debdiff or the draft debhelper bug report if useful.

Best regards,
Leonardo

Hello,

I have just opened a Merge Request with the proposed fix for the
systemd-tmpfiles dependency. You can review it here:

https://salsa.debian.org/ocaml-team/approx/-/merge_requests/10

I look forward to your feedback.

Best regards,
Leonardo