bug: package build fails on ubuntu 24.04

[safesintesi]

steps to reproduce the issue from clean distro install:

apt-get update 
apt-get install -y --no-install-recommends \
        build-essential \
        cmake \
        curl \
        git \
        libsystemd-dev \
        make \
        openssl \
        pkgconf \
        python3-full \
        python3-pip
pip3 install --break-system-packages apkg 

git clone --branch v3.13.5 --depth 1 https://github.com/CESNET/libyang.git
cd libyang
apkg build -b

apkg returns with error 42 and the following log

root@455f78f13770:/src# apkg build -i
I building packages
I target distro: ubuntu 24.04
I installing build deps
I target distro: ubuntu 24.04
I build deps from template: distro/pkg/deb
I installing 5 build deps...
$ apt-get satisfy -y cmake 'debhelper (>= 10)' 'libcmocka-dev <!nocheck>' libpcre2-dev pkg-config
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  autoconf automake autopoint autotools-dev bsdextrautils cmocka-doc debhelper
  debugedit dh-autoreconf dh-strip-nondeterminism dwz file gettext
  gettext-base groff-base intltool-debian javascript-common
  libarchive-cpio-perl libarchive-zip-perl libcmocka-dev libcmocka0
  libdebhelper-perl libdw1t64 libelf1t64 libfile-stripnondeterminism-perl
  libjs-jquery libltdl-dev libltdl7 libmagic-mgc libmagic1t64
  libmail-sendmail-perl libpcre2-16-0 libpcre2-32-0 libpcre2-dev
  libpcre2-posix3 libpipeline1 libsub-override-perl libsys-hostname-long-perl
  libtool libuchardet0 m4 man-db po-debconf
0 upgraded, 43 newly installed, 0 to remove and 1 not upgraded.
...
I creating dev source package
I target distro: ubuntu 24.04
I creating dev archive
I running make_archive_script: distro/scripts/make-archive.sh
I archive created: pkg/archives/dev/libyang-.tar.gz
✓ made archive: pkg/archives/dev/libyang-.tar.gz
unable to parse version from archive file name: libyang-.tar.gz

[safesintesi]

Ok, so the issue is due to --depth 1 passed to git.
This is done to speed up cloning of all repos and usually is not an issue since the VERSION commit is the same as the tag commit.
This time, a follow-up patch commit was added and broke the setup.

I increased the depth to 2 for this release to fix this. Maybe a backup check with git describe could be useful?

[michalvasko]

You were using the parameter --depth 1, right? If you have ideas how to improve the scripts, you can make a PR but I think they are fine.

[safesintesi]

You were using the parameter --depth 1, right?

Yes, that's what I said.

If you have ideas how to improve the scripts, you can make a PR.

I suggested using git describe, but it really depends on how you make new releases. Is the version release dictated by the VERSION commit or by the tag?
In this case why didn't they coincide? Was the tag moved? Would ever happen that a tag is moved?

[michalvasko]

Yes, that's what I said.

I meant that you used that parameter yourself, it is not part of any of the scripts in the repository.

Is the version release dictated by the VERSION commit or by the tag?

Generally, you should be able to create a package of any version of libyang to take full advantage of the scripts being part of the repo. But official releases create tags with the current version in the cmake list, which is increased only by those commits. So, I do not think there is anything for us to improve and you should clone the repo with more history depth. Normally, the version increase is the last commit but if some unrelated bugs show up (such as missing files in the tests), increasing the version seems redundant.

[safesintesi]

So, from my understanding, if I retrieve the version from the CMakeLists.txt, I don't need the git history.