#repology — Public Fediverse posts

So I've finally polished and published https://crates.io/crates/libversion crate, a pure #rust implementation of version comparison algorithm #Repology depends on.

You may or may not be a fan of rewriting anything in rust, but when someone submits you rust bindings of your own C library, it's absolutely 100% the valid case.

In fact though, it was the first thing I've rewritten in rust when I started learning it 2 years ago, though it took more time to gain enough XP to implement and publish it cleanly.

@opensuse I also updated the @fedora #Rawhide package, and according to the syslog-ng page on #repology, it's already there: https://repology.org/project/syslog-ng/versions

However, Rawhide still had #syslog_ng 4.10.2, when I checked a few minutes ago...

#repology service may be intermittent due to DDoS attack on the hoster. Status and plans: https://github.com/repology/repology-rs/issues/278

#repology's linkchecker rewritten in rust and now back live (wasn't working since Aug 2024). Keep an eye for new broken upstream and download URLs in your repositories.

Does #repology have a way to filter a page like https://repology.org/project/kwallet/versions to show only the currently supported distributions? I.e. hide Fedora before 39 and so on?

On the downside, I'll have to maintain ruleset (merging related projects, splitting unrelated ones, and blacklisting incorrect versions) in whole another ecosystem, and one which lacks good package naming (names are long unicode strings which need normalization) and versioning (`v` prefix and random suffixes all over the place) traditions.

So for now I'm hesitant about making Android repos first class citizens in #repology.

#Repology only has marginal support for F-Droid, only seeing a few handpicked packages for software which is also available in Linux:

https://repology.org/projects/?inrepo=fdroid

I've recently had a few PRs which improve F-Droid support and add #IzzyOnDroid, allowing full-fledged version comparison within Android ecosystem.

I wonder if any #fdroid maintainers or @IzzyOnDroid would be interested in that.

When I don't know what library to use in my #Python project, I search my distro's repos first and then check how many distros also packaged it (using #Repology).

If a library is packaged, then some of the following things are automatically true:

• This library is used by other projects.
• This library is maintained.
• This library has a working test suite.

And if I have to use an unpackaged library, that means each distro needs to package its dependency graph, including test dependencies. Maintainers will think twice before doing this.

#Dependencies #SoftwareDevelopment

So after doing a few small projects in #rust, I've finally started rewriting #repology backend (currently in #python) in Rust.

First discovery - what I naively though of as a database-bound workload, e.g. where database RTT (for small queries) or response generation time (for complex queries) dominates, are still 5-10x faster (in terms of both max RPS and latency) in Rust!

Also rust process takes 3-10x less memory compared to single uwsgi worker, which there are 10-20 of.

If you work with #NVD, note that CPEs in NVD are subject to change. I've just discovered that a lot of CPE bindings in #Repology are outdated due to changes in CPE vendors and products (aiohttp_project:aiohttp -> aiohttp:aiohttp, stlport:stlport → stlport_project:stlport, soundexchange:sound_exchange → sox_project:sox etc). If you maintain CPE bindings for any purpose, you should revisit and update them.

#security

New repositories support added recently to #repology:
- #chromebrew (package manager for Chrome OS)
- #opam (#OCaml package manager; this should be of great help to highlight outdated packages of ocaml modules in all supported repositories)
- @serpentos

In other news, #guix is blocking access from Russia again, so it's not updated in Repology.

New repositories support added recently to #repology:
- #chromebrew (package manager for Chrome OS)
- #opam (#OCaml package manager; this should be of great help to highlight outdated packages of ocaml modules in all supported repositories)
- @serpentos

In other news, #guix is blocking access from Russia again, so it's not updated in Repology.

New repositories support added recently to #repology:
- #chromebrew (package manager for Chrome OS)
- #opam (#OCaml package manager; this should be of great help to highlight outdated packages of ocaml modules in all supported repositories)
- @serpentos

In other news, #guix is blocking access from Russia again, so it's not updated in Repology.

New repositories support added recently to #repology:
- #chromebrew (package manager for Chrome OS)
- #opam (#OCaml package manager; this should be of great help to highlight outdated packages of ocaml modules in all supported repositories)
- @serpentos

In other news, #guix is blocking access from Russia again, so it's not updated in Repology.

New repositories support added recently to #repology:
- #chromebrew (package manager for Chrome OS)
- #opam (#OCaml package manager; this should be of great help to highlight outdated packages of ocaml modules in all supported repositories)
- @serpentos

In other news, #guix is blocking access from Russia again, so it's not updated in Repology.

@bitwarden @fedora PR to add the Fedora instructions and also a #Repology badge https://github.com/doy/rbw/pull/194

@arthurzam last time i checked, unlike #repology, its api didn't have "list outdated packages for the given repository" capability. Otherwise I'd integrate it in my find-work tool.

@rrahl0 do you really have arguments for that repos should use fake versions instead of verbatim upstream versions and all tools should implement complex logic instead of just comparing versions directly?

You seem to be right that opensuse doesn't seem to use epochs, however at least `revertto` is not a common pattern there, see #repology statistics.

@jwildeboer It's yet another supply chain attack and therefore a reminder that having long staging times is useful.

Unfortunately many ecosystems still have a culture of adopting fresh upstream software immediately.
Case in point, #repology is still showing new releases in green and previous releases in red https://repology.org/project/xz/versions

Currently we are having some issues with #GitHub CI where our updates in Terra are not auto-committed properly somehow. Around 10 packages have been stuck in CI and they have been marked as outdated by #Repology.

#terrapkg #FyraLabs #Linux

Just released a #Python wrapper for #Repology API!

https://pypi.org/project/repology-client

Your contributions and bug reports are welcome.

Couldn’t find the proper place to report it so it gets fixed. Please pass it on if you know.
#Repology doesn’t list #Fedora for #eza https://repology.org/project/eza/versions but I can clearly see a package for it on Fedora 38.

@emaste as an example (just curious, I don't plan to action this), how might <https://repology.org/project/micro-editor/versions> – for 'micro' – gain a listing for editors/micro in the ports tree?

<https://www.freshports.org/editors/micro/>

Would it require a change to the ruleset? <https://github.com/repology/repology-rules#readme>

#Repology

TLP #TLPlinux 1.6.1 packages

Meanwhile, (official) distribution packages are ready:
- #ArchLinux
- #Debian Sid - Don't want to wait for the Bookworm backport? Use the package from Sid
- #OpenSUSE Tumbleweed
- #Ubuntu - still takes time (due to 23.10 freeze), use the PPA

Check #Repology for other distros.

https://archlinux.org/packages/extra/any/tlp/
https://packages.debian.org/sid/tlp
https://build.opensuse.org/package/show/openSUSE:Factory/tlp
https://launchpad.net/~linrunner/+archive/ubuntu/tlp/+packages
https://repology.org/project/tlp/versions

If you quickly scroll up and down where the Repology image is in a git repo's readme (for example) quickly enough it appears to have some yellow if there are enough red and green items distributed evenly enough within the image.

#programming #Repology #git

#buildroot is now tracked by #Repology, huge thanks to Bernd Kuhls for pointing me to usable repository data. Repository freshness is currently 56.7%.

I don't believe in paid conferences. Conferences are meant for free thought sharing with as little borders as possible, and paywall is a huge border, not only for the price but just for inconvenience of paying, especially from some countries. I've been asked several times if I'm going to represent #repology on #packagingcon. Well, I don't see any point, and I don't expect to see many enthusiasts there and I can't see how [FOSS] packaging can be improved in such unwelcome commercial environment.

Nice #website / #tool for #apps #software #distros #packages: #Repology
https://repology.org/
«Repology is a service which tracks and compares package versions in more than 120 package repositories. Repology shows you in which repositories a given project is packaged, which version is the latest and which needs updating, who maintains the package, and other related information.»
#GPL #GPLed #GNU #Linux #Unix #BSD

And #acxi is now in #slackbuilds!

https://slackbuilds.org/repository/15.0/audio/acxi/

and that was picked up quite rapidly by #repology.

https://repology.org/project/acxi/versions

I do not expect this to make any real difference, beyond maybe a few people discovering that acxi does something they find useful that might not otherwise have discovered that.

Here's to Free Audio, something not to be taken lightly or for granted, for without the tireless efforts of groups like #xiph.org and others, we would be in proprietary codec hell.

Many thanks to #altlinux devs for providing comprehensive data on packages in their repositories to #repology. The more data from repositories the more use for package maintainers and #foss project developers.

https://github.com/repology/repology-updater/pull/1204