OpenOCD v.0.12.0

[joelsa]

Hi, thank you for creating this great repo.

OpenOCD v0.12.0 has been released in January and I would like to try out the GD32VF103 support, but the official repositories for Ubuntu 22.04 Jammy Jellyfish only contain v0.11.0.

Can you trigger the workflow to build it?

I could build OpenOCD v0.12.0 successfully on my local machine using the commands for the workflow, so it should work. There are some additional configuration flags though, maybe some of these are interesting.

Also, even though the dependencies are still contained in official ubuntu-20.04 repos, it might be a good idea to upgrade to ubuntu-22.04 for the workflow, which also is ubuntu-latest since December.

[rleh]

Can you trigger the workflow to build it?

https://github.com/rleh/openocd-build/actions/runs/4349155188

[joelsa]

Also, even though the dependencies are still contained in official ubuntu-20.04 repos

That turned out to not be true for libjaylink-dev, which is 0.1.0 on Focal Fossa and 0.2.0 on Jammy Jellyfish. Sorry, I checked only the main dependencies, not the ones needed for all programmers.

[joelsa]

Shall I also bump https://github.com/rleh/openocd-build/blob/1ede6ac15a82d7c18998c5d3465f5c10d14d6609/rpm-package/openocd.spec#L2 and maybe remove the version number from the rpm build here: https://github.com/rleh/openocd-build/blob/1ede6ac15a82d7c18998c5d3465f5c10d14d6609/.github/workflows/build.yml#L116?

[rleh]

That is already done in #8, together with updating the Fedora OS from 33 to 37.

The version number from the rpmbuild source folder can't be easily removed, rpmbuild requires the source (archive) to habe the version number in it's name (for (good) reasons).

[joelsa]

rpmbuild requires the source (archive) to have the version number

That requirement is sensible, cloning an arbitray state of the repo into a possibly different name maybe less so.

Proposal:

export openocd_version=0.12.0
git clone --branch v${openocd_version} --single-branch --depth 1 http://openocd.zylin.com/openocd.git openocd-${openocd_version}

[rleh]

The idea of this builds was/is to not just have the latest official release (that is already (more or less fast) done by the package maintainers of your linux distro), but to provide builds of the latest master branch. Lately this has gotten better, but after 0.10 it took OpenOCD 4 years to release version 0.11.0.

I wanted to use 0.11.999 (or similar) as the version number, but that didn't work for some reason I can't remember. The current state is from my point of view but also acceptable, because the OpenOCD master build also has version number 0.12.0+dev-snapshot which kind of matches the package version:

$ openocd --version
Open On-Chip Debugger 0.12.0+dev-snapshot (2023-03-07-03:12)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html

$ dnf info openocd
Name         : openocd
Version      : 0.12.0
Release      : master.20230307.0311
# ...

It is also necessary to replace the version number inside the Spec file to match the source "archive": https://github.com/rleh/openocd-build/blob/7db4dbb765a6082f72a1d2659e9ab98a30c796ad/rpm-package/openocd.spec#L2

[joelsa]

The idea of this builds was/is to not just have the latest official release

That sounds reasonable, I think everybody who is interested in using only the latest stable version can either use a fast-paced/rolling release distro (even Fedora and Debian have v0.12.0 already in their package sources) and/or they can just build it from source, which is easy enough to do.

[rleh]

I tried to change to openocd version to 0.12.0+dev-snapshot in #9 (and only define once), let's see if it works...

[joelsa]

The only restriction placed on the version is that it cannot contain a dash "-".

Meh.

[rleh]

DEB package versions strings are only allowed to contain A-Za-z0-9.+-:~