0.9.7: test suite build fails with gcc 14.x

[kloczek]

Looks like last version build fails with latest gcc 14.x which is now used in fedora rawhide.

Build fails with

make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/multipath-tools-0.9.7/multipathd'
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/multipath-tools-0.9.7/tests'
building alias.o because of alias.c ../libmpathutil/strbuf.h ../libmpathutil/util.h ../libmultipath/alias.h test-log.h globals.c ../libmultipath/defaults.h ../libmultipath/structs.h ../libmultipath/prio.h ../libmultipath/checkers.h ../libmultipath/list.h ../libmpathutil/vector.h ../libmultipath/byteorder.h ../libmultipath/generic.h ../libmultipath/config.h ../libmpathutil/globals.h ../libmpathutil/debug.h ../libmpathutil/log_pthread.h ../libmultipath/alias.c ../libmpathutil/uxsock.h ../libmultipath/file.h ../libmultipath/devmapper.h ../libmultipath/autoconfig.h ../libmpathutil/time-util.h ../libmultipath/lock.h
alias.c:1766:12: error: function declaration isn’t a prototype [-Werror=strict-prototypes]
 1766 | static int test_get_user_friendly_alias()
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
alias.c:1984:12: error: function declaration isn’t a prototype [-Werror=strict-prototypes]
 1984 | static int test_bindings_order()
      |            ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[1]: *** [Makefile:74: alias.o] Error 1
make[1]: Target 'all' not remade because of errors.
rm alias.o.wrap
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/multipath-tools-0.9.7/tests'
make: *** [Makefile:121: test] Error 2

[kloczek]

Tested new version and so far looks like it build correctly now 👍

BTW .. is it possible to start making github releases?🤔

On create github release entry is created email notification to those whom have set in your repo the web UI Watch->Releases.
gh release can contain additional comments (li changelog) or additional assets like release tar balls (by default it contains only assets from git tag) however all those part are not obligatory.
In simplest variant gh release can be empty because subiekt of the sent email contains git tag name.

I'm asking because my automation process uses those email notifications by trying to make preliminary automated upgrades of building packages, which allows saving some time on maintaining packaging procedures.
Probably other people may be interested to be instantly informed about release new version as well.

Documentation and examples of generate gh releases:
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository
https://cli.github.com/manual/gh_release_upload/
jbms/sphinx-immaterial#282
https://github.com/marketplace/actions/github-release
https://pgjones.dev/blog/trusted-plublishing-2023/
jbms/sphinx-immaterial#281 (comment)
tox target to publish on pypi and make gh release https://github.com/jaraco/skeleton/blob/928e9a86d61d3a660948bcba7689f90216cc8243/tox.ini#L42-L58

[mwilck]

Thanks for the suggestion. Indeed I think that the amount of work necessary for a GH release wouldn't be much different from what I do for a "version update PR" today. @cvaroqui would be the only person who has the necessary permissions on this repository (AFAICS it requires at least "write" permissions). I am not sure if he has time and resources to do this. So far you @kloczek, are the only person who has asked for this.

[kloczek]

So far you @kloczek, are the only person who has asked for this.

Many people are not aware that can receive email notifications about new release 😋