fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

8.8K
active users

#repology

0 posts0 participants0 posts today

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

Continued thread

Major Linux (stable) distributions with #gnuplot v6.0.2 per #Repology <repology.org/project/gnuplot/v>:
Arch(!) Linux
Gentoo
Kali Linux rolling(!)
Manjaro Stable

The other place I had in mind was/is #pkgsOrg pkgs.org/ ... nope, did not find there either. Guess v6.0.2 is too spanking new.

Instead, major OSen/distributions with v6.0.1 <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.

repology.orggnuplot package versions - RepologyList of package versions for project gnuplot in all repositories
Continued thread

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 .

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

repology.org/projects/?inrepo=

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

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

repology.orgProjects list - RepologyMultiple package repositories analyzer

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.

So after doing a few small projects in , I've finally started rewriting backend (currently in ) 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 , note that CPEs in NVD are subject to change. I've just discovered that a lot of CPE bindings in 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.

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" 😃

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

Replied in thread

@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 repology.org/project/xz/versio

repology.orgxz package versions - RepologyList of package versions for project xz in all repositories