#repology — Public Fediverse posts

Semi-announcing new project (kind of related to #repology). Please welcome https://wiyci.org, package build log aggregator, which presents packaging ecosystem as an impromptu CI for #FOSS upstreams.

In short, it fetches package build logs for projects and (for now) parses compiler warnings and failed tests from these.

Interesting fact: >80% of most popular projects produce compiler warnings. Does the community have a blind spot here, which wiyci now covers?

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.

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...

@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.

#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

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.

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.

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

@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.

@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

@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

@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.

I think I may be able to answer my own question, just after posting I realized that I forgot about #repology.

https://repology.org/project/rust/badges

I converted my `jq`-based hack to show stale packages into a named tool.

Welcome `nix-olde`: a tool to find the outdated packages used in your NixOS system against repology.org database: https://github.com/trofi/nix-olde

Initial `jq`-based hack reported 15% of outdated packages against my system. `nix-olde` reports 25% and I think it's closer to reality.

#nixpkgs #repology

nixpkgs is known to be one of the up-to-date package repositories know to repology.

But those are average numbers. How many outdated packages does your system have? I wrote a hack based on repology data a while ago. https://trofi.github.io/posts/272-peeking-at-stale-nixpkgs-packages.html gives a glimpse on data used for the hack.

My system has 15% of outdated packages.

#nixpkgs #repology

Looks like #Redhat's #EPEL packagers realized that when #inxi docs say you should always update repos to use current inxi, that's a good idea (because inxi will never create dependency issues in a repo based on packages version requirements, outside of #Perl and #Coremodules). Much to my surprise, checked #repology and saw EPEL 7, 8, 9 all shipping inxi current, 3.3.23. Hats off packagers, this helps your users and you. There's never a reason to ship old inxi's, no matter how old the repo.

NixOS 22.11 is up on #repology

#nixos