On 19/02/25 21:30, Luis Felipe wrote:
On 19/02/25 17:16, Ludovic Courtès wrote:Hi,Luis Felipe <sirga...@zoho.com> skribis:Yes, it seems bayfront is now using the version of Artanis that introduced a "plugins" system and it is expecting the Guix Packages Website to have a "conf/plugins.scm" module, which it hasn't because current version was tested for Artanis 0.6 and 1.0. Should I start specifying the versions of the dependencies to avoid these kinds of problems? I think this is not the first time this happens.Yes, maybe we need to pin the version of Artanis that is used for guix-packages-website, unless Artanis 1.0 makes promises about API stability?I don't think it does, but I asked Artanis to be sure: https://gitlab.com/hardenedlinux/artanis/-/issues/130.In the meantime, I upgraded the source code of the application to work with Artanis 1.2.2¹ and added a channels specification² to make it easier to get the right package dependencies.I'm going to test a new version of the Guix Packages Website in a production-like environment, and intend to send a patch for the service in bayfront if everything seems to work fine.
The previous patch updates the Guix Packages Website service to use version 0.4.0 of the software which I released yesterday (https://codeberg.org/luis-felipe/guix-packages-website/releases/tag/0.4.0).
I tested the service in a virtual machine and everything seems to work alright:
☑ Index page works as expected ☑ Package page works as expected ☑ Product page works as expected ☑ Searching works as expected ☑ GUIX_PACKAGES_WEBSITE_DOMAIN_NAME takes effect on badge codes ☑ SVG badge files are served Please let me know if this works for you. Have a nice day,
OpenPGP_0x0AB0D067012F08C3.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
