Updates the existing static binaries

[ivan-hc]

Hi, I'm the developer of "AM", a package manager for AppImages and other portable programs... just like your static binaries.

My project also supports databases maintained by third parties... and recently, Soarpkg, which included over 1000 static binaries ("bincache", divided by families, for example GLIBC, Busybox...) and many more programs (pkgcache), stopped publishing and updating its binaries on github because they were too many to keep up to date, in addition to being limited by github restrictions, so it decided to publish them in registries not accessible via wget and curl. That's why I came across your project, which I find very interesting and great for users looking for this kind of programs.

I saw that you haven't updated your releases since July 2024. Maybe you would like to include some automated process that starts your workflows weekly or monthly?

It would be great to have always updated builds of your programs.

Adding your project to "AM" as a third-party database would provide support for installations, updates, a dedicated list, a query and semi-complete descriptions with reference URLs, info about installed programs and dedicated flags and extensions for your database. See the screenshots on the old "AM" 9.5 release that have this support https://github.com/ivan-hc/AM/releases/tag/9.5 just to have an idea.

In the meantime, I have already started a CI to create lists, direct download URLs and descriptions (taken from Arch Linux and AUR) for all your programs:

• this is the script that generates the lists https://github.com/ivan-hc/am-extras/blob/main/1bin/lister.sh
• this is the list of programs in "releases/latest" (generated by YOUR lister.sh) https://github.com/ivan-hc/am-extras/blob/main/1bin/x86_64.md

...and note, I have disabled the reference URL and version in the script, as they are releases maintained by you (variable "$site") and not updated yet (variable "version").

This is a preview on how the list should appear for the 1bin repository

You will not have to do anything, you will only have to keep the releases updated.

If you need a dedicated CI flow, let me know, I will help you.

Let me know if you are interested.

[nikvdp]

Hey @ivan-hc thanks for the detailed report and suggestion! AM looks like a cool project. Yeah having automated builds is a great idea, I'll set that up. Is there anything else I need to do on my end for 1bin packages to show up in AM?

One reason I haven't done this previously is that sometimes the builds from upstream (conda-forge) are not in a working state and I didn't want to automatically update and "break" existing builds, especially given that for now at least there's no versioning available through 1bin.org (though old versions are all available in the github releases). Could AM help with this? The ideal would be something that automatically sanity tests the binaries to make sure they at least run correctly on both mac and linux

[ivan-hc]

hi, for sanity tests I can't help much... but for versioning releases I can help, and also to keep alive this repo, so you can have backup releases trough versioning and leave the repo working on its own (if workflow runners will still work).

[ivan-hc]

About showing 1bin programs in AM and AM support, you have nothing to worry about... it is all ready, I have just to uncomment these three lines to enable your binaries in AM https://github.com/ivan-hc/am-extras/blob/0144850b9ee0c51da2a8bbf5552a169c729b63e5/am-extras#L2

[ivan-hc]

by "versioning" do you mean the versions of the individual binaries created or the "releases" tags of this repo?

[nikvdp]

Both, but the version numbers for the individual programs is more of an issue. It's quite simplistic at the moment and essentially just pulls "latest" from conda-forge for each, but it gets a little tricky because there are at least 3 different versions to think about. There's the version of the underlying software, the version of the conda-forge recipe/feedstock that was used to build the conda package for it (which 1bin relies on indirectly), and then the release version of each 1bin run that packages all the conda-forge packages up into self-extracting executables.

Maybe I need to make some sort of compound version numbering system that reflects all three of those, since an issue in any of those places could cause the resulting 1bin build (and now maybe the resulting AM package!) to break for that binary

[ivan-hc]

If you need a workflow for versionin releases, you can take a look to the one I use for Virtualbox AppImage

https://github.com/ivan-hc/VirtualBox-appimage/blob/main/.github/workflows/junest-CI.yml

EDIT: the only tip, the file ./version you see here https://github.com/ivan-hc/VirtualBox-appimage/blob/0fff5739fe70980155cdcded9eb87b09c916202c/.github/workflows/junest-CI.yml#L30 is created from the script here https://github.com/ivan-hc/VirtualBox-appimage/blob/0fff5739fe70980155cdcded9eb87b09c916202c/.github/workflows/junest-CI.yml#L24 as well as the AppImage

[ivan-hc]

About overwriting the existing work... you need to open a separated repo you may want to name "My-workbench" (mine is named like this) where you can test all changes you will add to your repositories. Any repository you have. Upload there your workflows and scripts and use github actions there for testing purposes, and if all is ok, reupload on the "serious" repo, so you are aware that nothing will be wrong.

[ivan-hc]

There is another aspect that I would like to point out, when talking about versions of programs from a custom repository. See the versions column for these two currently supported databases:

• https://github.com/ivan-hc/am-extras/blob/main/appbundlehub/x86_64.md
• https://github.com/ivan-hc/am-extras/blob/main/busybox/x86_64.md

Do you notice anything strange?

The versions are identical, and this is because the programs are produced by their respective maintainers.

• AppbundleHUB is a set of portable programs similar to AppImage, whose release is weekly (if I'm not mistaken), and since they are not official, the developer uses a date and a serial number as version. They are compiled by Arch Linux and are snapshots of their version;
• BusyBox needs no introduction, the binary files come from the official site (even if I re-hosted them because the official site is very slow), and all of them have the version indicated by BusyBox itself.

Besides, I also created a list for your currently available programs, with the version indicated by you

• https://github.com/ivan-hc/am-extras/blob/main/1bin/x86_64.md

...maybe you might want to use a publication date, as version. But it's your choice of course. I think the format you've used so far is already great, in my opinion.