#repology service may be intermittent due to DDoS attack on the hoster. Status and plans: https://github.com/repology/repology-rs/issues/278
#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.
Major Linux (stable) distributions with #gnuplot v6.0.2 per #Repology <https://repology.org/project/gnuplot/versions>:
Arch(!) Linux
Gentoo
Kali Linux rolling(!)
Manjaro Stable
The other place I had in mind was/is #pkgsOrg https://pkgs.org/ ... nope, did not find there either. Guess v6.0.2 is too spanking new.
Instead, major OSen/distributions with v6.0.1 <https://pkgs.org/search/?q=gnuplot> (filters missing from the URL):
Fedora 41
NetBSD 10
That ... also looks that is bit too new.
Both lists are entirely missing v9 of Rocky Linux & AlmaLinux for whatever reasons.
Ok. Looks like I would be installing Fedora 41 in a virtual machine on Rocky Linux 8 next week.
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:
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.
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.
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.
lcrq v0.2.1 has been uploaded to Debian Unstable and repolology has noticed.
Unfortunately this turns all older versions red. I wish there was some way to customize this, so that only unsupported versions showed up red, and current versions were some neutral colour.
Is it the Chinese who think of red as being a positive colour? Perhaps we should consider the red versions are "mature"
@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.
On #repology the #xz package of version 5.6.1 is still marked as "green", while the older versions people are advised to downgrade to, are marked "yellow" or "red".
Does anyone know how and when they get updates for vulnerabilites?
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
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.