Building offline

[pallaswept]

My intention here is an RPM package, a typical '-git' package of the latest source code.

I understand that we don't really need to build ble.sh from sources, since it's just shell scripts, and we can just use the release archives directly. However, I would like to build from the most recent sources, and the nightly build might be some time away, and also, it's a little tricky to specifically version (re-version?) the v0.4.0-devel3 release. So, it would be nice to build it in the RPM package.

But when I tried I got an error, it seems the build tries to go online, and RPM packages are built without any network access, so that fails:

[    9s]   /usr/bin/gawk -f make/mwg_pp.awk ble.pp >/dev/null
[    9s] fatal: unable to access 'https://github.com/akinomyoga/ble.sh/': Could not resolve host: github.com
[    9s] fatal: could not fetch 5c2a688532d1f50b7686923241e05e7a16b8b14e from promisor remote
[    9s] ble.pp! Failed to get the commit id (version = 0.4.0-devel4+).
[    9s] make: *** [GNUmakefile:54: out/ble.sh] Error 1
[    9s] make: *** Deleting file 'out/ble.sh'
[    9s] error: Bad exit status from /var/tmp/rpm-tmp.edwwle (%build)
[    9s] 
[    9s] RPM build errors:
[    9s]     Bad exit status from /var/tmp/rpm-tmp.edwwle (%build)

There is a good chance that I could pass a commit hash into the script, if it could be supplied using an environment variable or similar?

Any help would be appreciated :) If this isn't really practical, I will just use the nightly release, and date-stamp the release...but it would be nice to do a real build in such a package.

Cheers

[akinomyoga]

and the nightly build might be some time away,

The nightly build is updated by GitHub Action immediately after every push to the master branch. It usually takes less than 30 seconds before the nightly tarball is updated. Would 30s of the delay become a problem for you?

and also, it's a little tricky to specifically version (re-version?) the v0.4.0-devel3 release.

Could you explain it? I don't want packagers to change the version embedded in ble.sh. The embedded version needs to be used as an identifier for the version. The package version (such as devel3p1, devel3p2, etc. following the rule of the package repository) can be independent of the embedded version.

But when I tried I got an error, it seems the build tries to go online,

This happens when the source is incomplete. You need to prepare the full source including the contents of both ble.sh and blesh-contrib. How do you prepare and arrange the source?

There is a good chance that I could pass a commit hash into the script,

The problem with the commit hash is an issue separate from the network issue. It happens when the .git directory is missing. This is also related to how the source code is prepared or arranged.

Any help would be appreciated :) If this isn't really practical, I will just use the nightly release,

I actually recommend this.

and date-stamp the release...

A date might not be sufficient when the push to ble.sh occurs more than once in one day and you publish the package accordingly.

[akinomyoga]

and also, it's a little tricky to specifically version (re-version?) the v0.4.0-devel3 release.

Could you explain it?

I'm still unsure if I correctly understand what you specifically cared about, but maybe did you want to pin the version of the nightly build? Actually, all the past nightly builds are available with permalinks:

https://github.com/akinomyoga/ble.sh/releases/tag/nightly

[pallaswept]

Would 30s of the delay become a problem for you?

Hahaha no, that is perfect :laughing: I had noticed that it seemed to be very recent every time I built it, but I assumed from 'nightly' that was one release per 24 hours, that's my mistake, sorry about that.

The package version (such as devel3p1, devel3p2, etc. following the rule of the package repository) can be independent of the embedded version.

That's fine, I meant the package version, I don't want to change any part of ble.sh, it's wonderful how it is :)

and date-stamp the release...

A date might not be sufficient when the push to ble.sh occurs more than once in one day and you publish the package accordingly.

I agree, I'm sorry I left out too much detail. The real version ended up being like so: 0.4.0_devel3+git20240824.70b89e5 but I will name it exactly as it is on the release tag link you posted ble-nightly-20240824+9270b52

So anyway, I will use that, and I don't need to build from source, but for your reference, it might be interesting that I did get that error message when I was missing the .git directory, but it was slightly different. I'm sorry I did not copy it and I have since fixed that problem. I did see your note in the readme about needing the .git directory.

But, once I fixed that, I got to this, where it failed because it can't go online: Could not resolve host: github.com. RPM packaging does this 'no internet during builds' thing, so I bump into it sometimes.

I hope that it's OK if I close this anyway, with the releases handled as they are, I really don't see any need to build packages from source, even considering RPM and distros' stricter policies, because there are no binaries.

Thanks again for your help mate, sorry I hit send too soon!

I've been playing with ble.sh all day with the new colours and some fzf here and there. The whole thing blows my mind.

[pallaswept]

Sorry @akinomyoga one minor question has arisen here:

RPM does not allow a hyphen in the package's version, I think it's because they use the hyphen to delimit the package version. I could replace the hyphen with underscores like ble_nightly_20240824+9270b52 (including the package name, package version, etc, that would be like ble.sh-ble_nightly_20240824+9270b52-1.0), or just call it ble.sh-20240824+9270b52 or ble.sh-nightly20240824+9270b52 or ... well I can call it almost anything without a hyphen it seems. I like to stay true to upstream but this one character will have to be different somehow, so I would prefer to adhere to your preference on how to change it.

I feel like this is the best TL;DR of how RPM treats the different characters, perhaps it will be helpful.

Thanks again for your advice

[akinomyoga]

I prefer the package main name to be blesh since all the other packages that I'm aware of use blesh. nightly is a kind of the build state (such as a for alpha or rc for release candidates instead of the version number), so I prefer to have 0.4.0 at the beginning of the version.

I don't have strong preferences for the rest part of the version string, but according to the mentioned https://github.com/semver/semver/issues/145#issuecomment-780717028, it needs to be separated from 0.4.0 by ~ such as blesh-0.4.0~nightly20240824 because it hasn't yet been released. The tricky part is the commit hash, which cannot be simply sorted. For example, in AUR, the commit hash in the version string, if any, is prefixed by the number of commits obtained by git rev-list --count HEAD, such as ~nightly20240824.r2180+9270b52. This might feel too long, in which case it may just be ~nightly20240824.r2180 or even ~r2180. Or, if the number of commits is not useful because it cannot be determined using the tarball, one might alternatively use a sequential number determined manually or automatically based on the "Assets" links on the nightly release page.

[pallaswept]

Hi @akinomyoga just FYI I had a chance to update this package. It ended up like this, if that's OK with you? I can change it however you like if this is not OK.

> zypper info blesh
...
Version        : 0.4.0~devel3nightly20240829.r246+670c7ea0-11.1
...

> ble --version
ble.sh, version 0.4.0-nightly+670c7ea (noarch)

I made this for my own purposes but you are welcome to use this package: https://build.opensuse.org/package/show/home:pallaswept/blesh OpenSUSE users could install blesh using instructions from the above link or automatically with this link https://software.opensuse.org/ymp/home:pallaswept/openSUSE_Tumbleweed/blesh.ymp (It is still necessary to manually edit the .bashrc, I did not think it appropriate to automate that part)

If you have a repository on https://openbuildservice.org/ then I can submit my package there so that you can 'own' the official repo but you don't have to do any work on the package :)

Updating this package to a new nightly version is a single button click on the webpage. It will trigger the build service to download a new archive of the nightly build, and also query git for the current version, to apply to the packaging scripts.

I hope this is helpful

[akinomyoga]

@pallaswept Sorry for the delayed reply. The package name looks good! Thank you!

I made this for my own purposes but you are welcome to use this package: https://build.opensuse.org/package/show/home:pallaswept/blesh

I'm sorry but I so far don't have time to check the package. My default distribution is Fedora and Arch Linux, and I test openSUSE in a virtual machine only when an openSUSE user reports a problem that doesn't seem to be reproducible in other environments.

https://software.opensuse.org/ymp/home:pallaswept/openSUSE_Tumbleweed/blesh.ymp (It is still necessary to manually edit the .bashrc, I did not think it appropriate to automate that part)

I actually agree with it (though I know some package maintainers try to load ble.sh forcibly using /etc/profile.d or a similar mechanism). If the loading of ble.sh is forced, that package cannot be installed on multiuser hosts.

If you have a repository on https://openbuildservice.org/ then I can submit my package there so that you can 'own' the official repo but you don't have to do any work on the package :)

I don't have a repository, and I'm busy now to learn how it works and what I should care about. I guess you can own a repository there. Or does Open Build Service require the upstream developer to own the repository?

[akinomyoga]

> zypper info blesh
...
Version        : 0.4.0~devel3nightly20240829.r246+670c7ea0-11.1
...

@pallaswept Sorry, I wrote the package name seemed good, but I noticed that the above string contains "devel3". The devel version for the present nightly builds is actually "devel4". The "devel3" is the number for the previous pre-release, and the current version is "devel4" as coded in GNUmakefile:

https://github.com/akinomyoga/ble.sh/blob/21b1bb3d4fe3f42c7ff44c7b38e81ee2df5439ca/GNUmakefile#L41

If you want to include the number of the form "develX" in the version string, you can probably extract it from GNUmakefile, but I think you can simply drop the number "develX" in the package name of a nightly version.

[pallaswept]

No problem! The toolchain was using the 'parent tag' and that is v0.4.0-devel3, but I have removed the -devel3 now. The result is: blesh-0.4.0~nightly20240923.r251+537c6504. I hope that is better.

I don't have a repository, and I'm busy now to learn how it works and what I should care about. I guess you can own a repository there. Or does Open Build Service require the upstream developer to own the repository?

That's fine, I can take care of the package in my personal repository there for now. I don't think anyone else is using it yet, but they are able, if they want to. If there is a need, or you just would like to do it, we can think about a more 'official' repository later :)