[chirp_devel] Invalid version: 'py3dev' breaks build.
Hi Dan, Since our (Mageia) most recent python3 updates sometime this month chirp-next builds fail with:
packaging.version.InvalidVersion: Invalid version: 'py3dev'
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/rpm/pythondistdeps.py", line 626, in <module> raise RuntimeError("Error: pythondistdeps.py generator encountered an unhandled exception and was terminated.") from exc RuntimeError: Error: pythondistdeps.py generator encountered an unhandled exception and was terminated. error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHONDISTDEPS_GENERATORS_FAILED *** Provides: application() application(chirp.desktop) chirp = 1:0.4.0-0.20230101.1.mga Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: python(abi) = 3.10 python3.10dist(future) python3.10dist(pyserial) python3.10dist(requests) python3.10dist(six) python3.10dist(yattag)
/--------------------------------------
For now I have used:
sed -i 's/py3dev/%{version}/' chirp/__init__.py
.. in our spec. to fix the above issue for our package.
Since you do not make releases it's difficult to decide on any sort of versioning that makes sense for our packages.
I use 0.4.0 as version and add the date from git into the release, which keeps our packages in order but means little outside of the distro. e.g. chirp-0.4.0-0.20230125.2
I really wish you actually made releases.
/OT Today's package works fine with my test radio. (UV5RE) :)
Cheers, Barry
Barry Jackson via chirp_devel wrote:
Hi Dan, Since our (Mageia) most recent python3 updates sometime this month chirp-next builds fail with:
packaging.version.InvalidVersion: Invalid version: 'py3dev'
Since you do not make releases it's difficult to decide on any sort of versioning that makes sense for our packages.
I use 0.4.0 as version and add the date from git into the release, which keeps our packages in order but means little outside of the distro. e.g. chirp-0.4.0-0.20230125.2
The date stamp alone (20230125) is a valid version for Python packaging purposes, which should also work for RPMs. Once PEP-517 support is implemented (for the Python package build process), this will become more of an issue as checks will be stricter.
On 26/01/2023 02:39, Charlie Li via chirp_devel wrote:
The date stamp alone (20230125) is a valid version for Python packaging purposes, which should also work for RPMs. Once PEP-517 support is implemented (for the Python package build process), this will become more of an issue as checks will be stricter.
Hi Charlie, Thanks, this is what I have now done, however this seems to cause a dialogue to appear on every launch nagging that there is a newer version available.
How can I disable this dialogue or the check that triggers it?
I'm guessing that with daily 'releases' this will never go away, so a method to disable is desirable.
Would it not be preferable to just have a "Check for updates" option under the Help menu?
Barry
Thanks, this is what I have now done, however this seems to cause a dialogue to appear on every launch nagging that there is a newer version available.
How can I disable this dialogue or the check that triggers it?
I'm guessing that with daily 'releases' this will never go away, so a method to disable is desirable.
There's more to why you should not set CHIRP_VERSION to something other than the build, because it affects what we report in the log as well as what is checked against for updates, etc. That version is also stamped in the image metadata and used to help warn when opening an image from a newer version of chirp in an older one. It would be a lot better if you would:
sed "s/CHIRP_VERSION/'$VERSION'/" setup.py
in your script and leave chirp/__init__.py alone for consistency with all the other builds and tooling. The draconian opinionated python tooling is all you need to appease, so please limit the delta to just what is needed.
--Dan
On 29/01/2023 15:47, Dan Smith via chirp_devel wrote:
sed "s/CHIRP_VERSION/'$VERSION'/" setup.py
Actually, let me just do this in the sdist. I don't love it, but since from-sdist people will have to do this eventually, doing it in the build of the tarball will make them all consistent.
--Dan
Excellent!
Also: For now I used chirp.1 man page but swapped all the 'chirpw' for 'chirp'. sed -i 's/chirpw/chirp/g' chirp/share/chirpw.1
Barry
Since our (Mageia) most recent python3 updates sometime this month chirp-next builds fail with:
packaging.version.InvalidVersion: Invalid version: 'py3dev'
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/rpm/pythondistdeps.py", line 626, in <module> raise RuntimeError("Error: pythondistdeps.py generator encountered an unhandled exception and was terminated.") from exc RuntimeError: Error: pythondistdeps.py generator encountered an unhandled exception and was terminated. error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHONDISTDEPS_GENERATORS_FAILED *** Provides: application() application(chirp.desktop) chirp = 1:0.4.0-0.20230101.1.mga Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: python(abi) = 3.10 python3.10dist(future) python3.10dist(pyserial) python3.10dist(requests) python3.10dist(six) python3.10dist(yattag)
/--------------------------------------
Since you're seeing py3dev I assume that means you're building directly from git? Why?
For now I have used:
sed -i 's/py3dev/%{version}/' chirp/__init__.py
.. in our spec. to fix the above issue for our package.
Since you do not make releases it's difficult to decide on any sort of versioning that makes sense for our packages.
I do releases, every day that there was a change. The versions are stamped into the tarballs, which you should be using to build your packages.
I use 0.4.0 as version and add the date from git into the release, which keeps our packages in order but means little outside of the distro. e.g. chirp-0.4.0-0.20230125.2
I really wish you actually made releases.
I really wish you wouldn't randomly choose version numbers that don't match our automated releases, wasting your users time and ours when we try to figure out what actual code someone is running when they report a bug. Also, we actually did have an 0.4.0, which was in 2014, so putting that in your version string is not helping anyone.
96% of the users run bundled builds, and a shockingly high percentage of those are running the latest version (as in from yesterday) when they report bugs. So by "I wish you did releases" I assume you mean "I wish you released features and fixes to the users less often to make my life easier", which I'm not interested in doing[1].
--Dan
[1]: https://en.wikipedia.org/wiki/Release_early,_release_often
Thanks for your reply
On 26/01/2023 03:05, Dan Smith via chirp_devel wrote:
Since you're seeing py3dev I assume that means you're building directly from git? Why?
Because according to the README.md:
"This is the official git repository for the CHIRP project."
and it has recent commits.
I do releases, every day that there was a change.
I don't see any releases only daily builds which don't interest me from a packaging point of view.
I really wish you wouldn't randomly choose version numbers that don't match our automated releases > wasting your users time and ours when we try to figure out what
actual code someone is running when they report a bug. Also, we actually did have an 0.4.0, which was in 2014, so putting that in your version string is not helping anyone.
It was not chosen randomly. The last release in the "the official git repository" was 0.4.0 in 2014 so since then (I started maintaining the chirp package in 2014) I have used that as 'version' with a date string appended in the rel.
96% of the users run bundled builds, and a shockingly high percentage of those are running the latest version (as in from yesterday) when they report bugs.
If we receive a bug report about chirp which an update will fix then we will update the package, otherwise versions in stable distro releases are not randomly updated.
So by "I wish you did releases" I assume you mean "I wish you released features and fixes to the users less often to make my life easier", which I'm not interested in doing[1].
Not at all. I mean create a release with a proper PEP 440 type release number. If you saying that each 'daily build' is a 'release' and that the date string is the 'release number' then that is very unconventional but we could live with it if that is how it will remain.
Once we have a release number like 20230125 (over 20,000,000) there is no going back without an epoch! (Been there once already during the py3 transition)
I will look at a daily tarball.
Barry
Dan, I have looked at the latest daily tarball and building from that I see the same error, albeit with another invalid CHIRP_VERSION as far as python3 is concerned.
packaging.version.InvalidVersion: Invalid version: 'next-20230126'
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/rpm/pythondistdeps.py", line 626, in <module> raise RuntimeError("Error: pythondistdeps.py generator encountered an unhandled exception and was terminated.") from exc RuntimeError: Error: pythondistdeps.py generator encountered an unhandled exception and was terminated. error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHONDISTDEPS_GENERATORS_FAILED *** Provides: application() application(chirp.desktop) chirp = 20230126-1.mga Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: python(abi) = 3.10 python3.10dist(future) python3.10dist(pyserial) python3.10dist(requests) python3.10dist(six) python3.10dist(yattag)
I appreciate that 'n' is alpha-numeric and I have not read all of this[1], but unless this is fixed somehow it won't go away.
[1]https://peps.python.org/pep-0440/
Barry
January 25, 2023 at 9:05 PM, "Dan Smith via chirp_devel" chirp_devel@intrepid.danplanet.com wrote:
Since our (Mageia) most recent python3 updates sometime this month chirp-next builds fail with:
packaging.version.InvalidVersion: Invalid version: 'py3dev'
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/rpm/pythondistdeps.py", line 626, in <module> raise RuntimeError("Error: pythondistdeps.py generator encountered an unhandled exception and was terminated.") from exc RuntimeError: Error: pythondistdeps.py generator encountered an unhandled exception and was terminated. error: Dependency tokens must begin with alpha-numeric, '_' or '/': *** PYTHONDISTDEPS_GENERATORS_FAILED *** Provides: application() application(chirp.desktop) chirp = 1:0.4.0-0.20230101.1.mga Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: python(abi) = 3.10 python3.10dist(future) python3.10dist(pyserial) python3.10dist(requests) python3.10dist(six) python3.10dist(yattag)
/--------------------------------------
Since you're seeing py3dev I assume that means you're building directly from git? Why?
I'd like to piggy back on this conversation. Dan, would it be possible to publish a file or set up a redirect for package maintainers to get to the latest release tar ball that is posted on the downloads page? Maybe I've just overlooked it, but I haven't come across anything like that. git seems to be the easiest place to get the latest sources.
If there was a URL like `https://trac.chirp.danplanet.com/chirp_next/latest%60 which either contained simple text or redirected to "https://trac.chirp.danplanet.com/chirp_next/next-YYYYMMDD/chirp-next-YYYYMMD..." that would really help out, at least from what I've seen with snap, flatpak and appimage building thus far.
Tony
If there was a URL like `https://trac.chirp.danplanet.com/chirp_next/latest%60 which either contained simple text or redirected to "https://trac.chirp.danplanet.com/chirp_next/next-YYYYMMDD/chirp-next-YYYYMMD..." that would really help out, at least from what I've seen with snap, flatpak and appimage building thus far.
The link on the download page almost does this:
https://trac.chirp.danplanet.com/download?stream=next
and will redirect to the build dir. You could pull the build name out of the URL it sends you to:
$ curl -Ls -o/dev/null -w '%{url_effective}' https://trac.chirp.danplanet.com/download?stream=next https://trac.chirp.danplanet.com/chirp_next/next-20230127/
$ basename $(curl -Ls -o/dev/null -w '%{url_effective}' https://trac.chirp.danplanet.com/download?stream=next) next-20230127
--Dan
Hi Dan,
It is weird how I cannot load any images from James that were renamed from what the auto generated name would be. It seems to have changed the metadata blob in some way. So far I have not found a way to duplicate the problem here, but 100% of the files that had the filenames edited are unreadable.
I think I have found a solution for the new broadcast FM frequency storage method. The driver figures out which method is used, shifts the setting if needed, and shifts it back if necessary before storing.
I have attached the patch and some sample images so you can review it before I push it to you. Let me know if I should have done something different.
The files with "m2" in the filename are the older (u16) format. The file with the "m3" is the latest (ul16) format. I don't think there are any radios that utilize the original "m1" format supported by this driver.
Let me know what you think. There is no rush.
Jim
Perfect, that works for me.
I'll share what I've got for the benefit of anyone else since the curl result contains `next-YYYYMMDD` and the source tarball does not contain `next-` so it needs to be removed with another simple step in bash:
ver_with_next=$(basename $(curl -Ls -o/dev/null -w '%{url_effective}' https://trac.chirp.danplanet.com/download?stream=next)) ver_without_next=${ver_with_next//next-/} curl -o ./chirp-src.tar.gz https://trac.chirp.danplanet.com/chirp_next/$%7Bver_with_next%7D/chirp-$%7Bv... https://trac.chirp.danplanet.com/chirp_next/$%7Bver_with_next%7D/chirp-$%7Bv...
Tony
January 27, 2023 at 10:52 PM, "Dan Smith via chirp_devel" chirp_devel@intrepid.danplanet.com wrote:
If there was a URL like `https://trac.chirp.danplanet.com/chirp_next/latest%60 which either contained simple text or redirected to "https://trac.chirp.danplanet.com/chirp_next/next-YYYYMMDD/chirp-next-YYYYMMD..." that would really help out, at least from what I've seen with snap, flatpak and appimage building thus far.
The link on the download page almost does this:
https://trac.chirp.danplanet.com/download?stream=next
and will redirect to the build dir. You could pull the build name out of the URL it sends you to:
$ curl -Ls -o/dev/null -w '%{url_effective}' https://trac.chirp.danplanet.com/download?stream=next https://trac.chirp.danplanet.com/chirp_next/next-20230127/
$ basename $(curl -Ls -o/dev/null -w '%{url_effective}' https://trac.chirp.danplanet.com/download?stream=next) next-20230127
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
participants (5)
-
Barry Jackson -
Charlie Li -
Dan Smith -
Jim Unroe -
Tony Fuller