Arch Linux User Repository

Hi, here is an update on the libstrangle and libstrangle-git packages:

Context:
- Updates to GCC 13 and GLIBC 2.38 broke libstrangle,
- There are pending merge requests to the original upstream repo[1] to bring the package back to functional state,
- However, the upstream repo appears not to be maintained anymore and the MRs have been pending for a year,

Our AUR packages:
- libstrangle will remain based on the original upstream repo, but I updated the PKGBUILD to include all necessary changes as .patch files,
- libstrangle-git will switch to @Infernio's fork[2] of the original upstream repo,
- This brings back both packages to functional state, and give users flexibility depending on whether the origin upstream repo comes back to life, or whether @Infernio's fork is more reliable,

Finally, sorry for the long resolution delay. Since @Infernio volunteered, I added him as co-maintainer of both packages.

@Infernio, I now have more time for this maintainance work, so I should be able to contribute more reliably. But if you prefer to completely take over, let me know and I will set you as primary maintainer.

[1] https://gitlab.com/torkel104/libstrangle
[2] https://gitlab.com/Infernio/libstrangle

@Freso - Hi, done. Let me know if anything does not work as expected.

Hi! Any chance you could add 'x86_64_v3' to the $arch array? :) (See https://rfc.archlinux.page/0002-march/ )

Thanks, I think this is OK for now

Hi, here is an update on the libstrangle and libstrangle-git packages:

Context:
- Updates to GCC 13 and GLIBC 2.38 broke libstrangle,
- There are pending merge requests to the original upstream repo[1] to bring the package back to functional state,
- However, the upstream repo appears not to be maintained anymore and the MRs have been pending for a year,

Our AUR packages:
- libstrangle will remain based on the original upstream repo, but I updated the PKGBUILD to include all necessary changes as .patch files,
- libstrangle-git will switch to @Infernio's fork[2] of the original upstream repo,
- This brings back both packages to functional state, and give users flexibility depending on whether the origin upstream repo comes back to life, or whether @Infernio's fork is more reliable,

Finally, sorry for the long resolution delay. Since @Infernio volunteered, I added him as co-maintainer of both packages.

@Infernio, I now have more time for this maintainance work, so I should be able to contribute more reliably. But if you prefer to completely take over, let me know and I will set you as primary maintainer.

[1] https://gitlab.com/torkel104/libstrangle
[2] https://gitlab.com/Infernio/libstrangle

This failed to compile on my system, complaining that src/vulkan/overlay.cpp's VK_CHECK uses undefined symbols 'stderr' and 'fprintf'.

The following line added to the build's prepare statement fixes it, if someone else experiences this problem and doesn't mind editing the build script:

sed -i -e '/limiter.h/a #include <cstdio>' src/vulkan/overlay.cpp

glibc 2.38 broke libstrangle entirely:

$ strangle 60 vkcube
Strangle: fatal error: cannot find real dlsym: (null)
Aborted (core dumped)

I've switched over to MangoHud's framerate limiter instead, since libstrangle's upstream seems abandoned(?)

Edit: switched back to libstrangle after MangoHud's limiter turned out to have horrible pacing in some games. Collected the patches needed to make libstrangle work in my own fork: https://gitlab.com/Infernio/libstrangle

@qbvt i agree with @iguanajuice, a lot of package maintaners do this to make the packages work. i'm willing to take over the package if you think it's a bother

@qbvt the merge request that @Infernio mentioned literally changes a single LoC. I really wouldn't consider that "deviating from the upstream". In fact, the same fix can easily be done within the PKGBUILD itself, since the issue is so basic.

Hello @Infernio,

I don't really want to deviate from the upstream. Ideally, I would prefer that this merge request gets merged upstream, and update the package.

I will look into reproducing your issue and comment in the upstream repo that we also want this MR merged.

Doesn't build with GCC 13 anymore. There's an unmerged MR upstream that fixes it: https://gitlab.com/torkel104/libstrangle/-/merge_requests/29