Fixing packages with Repology

A little example of how to use Repology to find solutions to packaging problems (which might’ve been already solved by someone).

There is a game engine called LÖVE. A sad thing about it is that its major releases are not backwards compatible, resulting in that games written for older versions of LÖVE (such as 7.x or 8.x) will not run with other versions including the current one. So in order to preserve these games, we have to keep and maintain unsupported older LÖVE versions in our package repositories.

The two nice games I would not like to lose, and which require older LÖVE are GunFu Deadlands (Far West themed 2D shooter featuring bullet time), and Mari0 (Super Mario Bros clone with portals).

love07 and love08 ports required by these games have been broken (1, 2) for quite some time. My bad for missing this breakage (tooling required for reliable monitoring of such cases is what I plan to write someday), but better late than never these ports must be fixed.

The right long-term solution would be to fix the games instead. It would require much more effort as in learning LÖVE, understanding the game code, porting it to the newer engine version and in some cases, even taking maintainership of it, because, it’s unfortunately not uncommon for original upstream to abandon the project.

Maybe next time, but if you’re looking for contribution possibilities, here’s a definite candidate.

It also turned out that Mari0 has new version which works with LÖVE 11, neat.

Errors from the build logs

modules/graphics/opengl/SpriteBatch.cpp:77:3: error: use of undeclared identifier 'glGenBuffers'
                glGenBuffers(2, vbo);
modules/graphics/opengl/SpriteBatch.cpp:79:3: error: use of undeclared identifier 'glBindBuffer'
                glBindBuffer(GL_ARRAY_BUFFER, vbo[0]);
modules/graphics/opengl/SpriteBatch.cpp:80:3: error: use of undeclared identifier 'glBufferData'
                glBufferData(GL_ARRAY_BUFFER, sizeof(vertex)*size*4, vertices, gl_usage);
modules/graphics/opengl/SpriteBatch.cpp:81:3: error: use of undeclared identifier 'glBindBuffer'
                glBindBuffer(GL_ARRAY_BUFFER, 0);

suggest OpenGL related problems - declarations of some functions are no longer visible to the compiler. I could’ve started digging and recalling in which headers these methods are declared, how their visibility is controlled and what change has caused a breakage, and it would take some time and effort. It could be saved though if someone has already fixed the same problem, and we could find that solution.

Earlier this year I’ve made Repology aware of where recipes (e.g. Makefiles, PKGBUILDs, ebuilds, .specs, etc) are located for most repositories and made it aggregate these links into a single list (one for love07). With that it’s possible to quickly skim through all the recipes in other repositories and discover which options and flags other maintainers use in their packages, which changes they make, which patches they apply and how they fix problems.

So we click through the recipe list looking for something GL related. A few extra clicks are needed to check out stuff not included in the recipe itself (e.g. patch files), but it bears fruit: AUR, Nix, and Gentoo have patches which look relevant:

diff --unified --recursive --text love-HEAD.orig/src/modules/graphics/opengl/Framebuffer.cpp
--- love-HEAD.orig/src/modules/graphics/opengl/Framebuffer.cpp	2019-03-14 12:46:55.032982224 -0400
+++	2019-03-14 12:47:22.356175299 -0400
@@ -1,3 +1,5 @@
 #include "Framebuffer.h"
 #include <common/Matrix.h>

and suggest that GL_GLEXT_PROTOTYPES define should be present. And voila, with similar changes applied FreeBSD ports are fixed.

I plan to improve this feature of Repology, allowing it to fetch recipes and show them all on a single page without need to follow a lot of links along with additional improvements such as duplicate removal and full text search support.

Repology can already handle patches the same way it handles recipes, but unfortunately not many (see Patches column) repositories provide required information yet. If you are related to development of package repository with not too many check marks on that page, you can likely help by publishing more package metadata.