[chirp_devel] [PATCH] [AnyTone 5888UV] Add simple squelch mode & additional file identifier and add extra channel attributes
Attached is the patch with my Anytone 5888UV changes folded together. This takes the place of those earlier sent: [AnyTone 5888UV] Add limited squelch mode & fix file identifier [AnyTone 5888UV] Add extra channel attributes
Thanks for the help.
In the future, when I work on multiple issues in the same file(s), is there a better procedure to use so I don't end up folding them together into one patch when there are changes needed due to feedback from the team? The approach taken this time will combine a bug fix and a feature into a single changeset.
At some point do I invoke qfinish on my patches or does the series continue to grow indefinitely?
Brad Schuler K0BAS
Attached is the patch with my Anytone 5888UV changes folded together. This takes the place of those earlier sent: [AnyTone 5888UV] Add limited squelch mode & fix file identifier [AnyTone 5888UV] Add extra channel attributes
Thanks for the help.
In the future, when I work on multiple issues in the same file(s), is there a better procedure to use so I don’t end up folding them together into one patch when there are changes needed due to feedback from the team? The approach taken this time will combine a bug fix and a feature into a single changeset.
I think there may have been some confusion here, likely me being not super clear and definitely related to me processing a big backlog of patches. So, apologies.
When I asked you to squash things together, I was asking you to do that for the new driver you had proposed, not for these fixes to the existing driver. It's really nice to have separate fixes and features be added in separate patches, which is more of what you had here. Looking at this, *ideally* this would have been three patches:
1. Fix file identifier (really: add a new one you found in the field) 2. Add limited squelch mode (which is kind of a fix, it looks like) 3. Add extra channel attributes (new features).
That way later if we find someone that reports a new problem with, say, the squelch stuff, we can look back and see "ah, here's the full scope of the changes related to squelch stuff, unrelated to extra channel attributes, that's probably where the problem is." Also, this patch will get tagged to all the related bugs, which means people watching a bug about a file ID problem will see a new commit related to it which appears to primarily be about squelch features.
What I was trying to avoid was actually with the other patch (which I still need you to update) is having a commit history that looks like this:
1. Add a new driver that doesn't pass tests 2. Make some more changes 3. Fix the driver so it actually finally works
That is why I wanted you to squash those things. I think the confusion came because you asked if I wanted a patch-to-the-patch in question, which I don't want, because like the new driver example above, it ends up looking like this:
1. Fix a thing 2. No, actually fix a thing
Which we should avoid if we can. So, I said "please send a single patch" because I meant I wanted you to just update and re-send *that* patch. When I said "please squash the multiple patches" I meant for the new driver and its associated revision patches.
In the future, when you're working on a fix or feature and need to make a change to it, just qpush/qpop so it's on top, make a change and qrefresh that change into the patch.
At some point do I invoke qfinish on my patches or does the series continue to grow indefinitely?
No, when I apply a patch you can just qdelete it from your stack and then 'hg pull' from the main repo when it's applied (as it is now).
This patch also has a lot of style fails related to long lines. To avoid making you go back and revise this again, I'm just going to fix those for you, but in the future, please run the style checks first (tox -estyle).
One last thing, you need to actually put '#' in front of your issue numbers, both because that's how redmine knows to update the issue with a link to the commit, but also because my local commit hook will refuse the commit as a check, if it's not tagged to at least one issue. I've fixed that locally as well, but just FYI for the future.
Thanks!
--Dan
Dan,
I'm sorry for the confusion as well.
I'll submit a patch with the final/complete Anytone 5888UVIII new driver.
Yes, we ran into trouble when my 5888UV bug fixes needed modification from feedback, but the feature was built on top of those bug fixes. I’ll figure that out locally next time and send new/replacement patches that include the feedback. I can do that with these if you like, so we can have the changes separated by issue. Doing that will nullify the style fixes you’ve done though. Let me know if you’d like that.
I'd like to be able to run tox, but on Windows it always errors on setup.py, line 5, "from chirp import CHIRP_VERSION" as below. This happens when testing as well. Any ideas?
C:\Users\Brad\Documents\CHIRP-dev\chirp.hg>tox -estyle
GLOB sdist-make: C:\Users\Brad\Documents\CHIRP-dev\chirp.hg\setup.py
style inst-nodeps: C:\Users\Brad\Documents\CHIRP-dev\chirp.hg.tox.tmp\package\1\UNKNOWN-0.0.0.zip
ERROR: invocation failed (exit code 1), logfile: C:\Users\Brad\Documents\CHIRP-dev\chirp.hg.tox\style\log\style-3.log
================================== log start ==================================
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.
Processing c:\users\brad\documents\chirp-dev\chirp.hg.tox.tmp\package\1\unknown-0.0.0.zip
ERROR: Command errored out with exit status 1:
command: 'C:\Users\Brad\Documents\CHIRP-dev\chirp.hg.tox\style\Scripts\python.EXE' -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'c:\users\brad\appdata\local\temp\pip-req-build-_izazd\setup.py'"'"'; __file__='"'"'c:\users\brad\appdata\local\temp\pip-req-build-_izazd\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base 'c:\users\brad\appdata\local\temp\pip-pip-egg-info-y8awnl'
cwd: c:\users\brad\appdata\local\temp\pip-req-build-_izazd\
Complete output (5 lines):
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "c:\users\brad\appdata\local\temp\pip-req-build-_izazd\setup.py", line 5, in <module>
from chirp import CHIRP_VERSION
ImportError: No module named chirp
----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.
=================================== log end ===================================
___________________________________ summary ___________________________________
ERROR: style: InvocationError for command 'C:\Users\Brad\Documents\CHIRP-dev\chirp.hg.tox\style\Scripts\python.EXE' -m pip install --no-deps -U '.tox.tmp\package\1\UNKNOWN-0.0.0.zip' (exited with code 1)
Brad Schuler
K0BAS
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com On Behalf Of Dan Smith via chirp_devel Sent: Friday, November 20, 2020 2:29 PM To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] [PATCH] [AnyTone 5888UV] Add simple squelch mode & additional file identifier and add extra channel attributes
Attached is the patch with my Anytone 5888UV changes folded together.
This takes the place of those earlier sent:
[AnyTone 5888UV] Add limited squelch mode & fix file identifier
[AnyTone 5888UV] Add extra channel attributes
Thanks for the help.
In the future, when I work on multiple issues in the same file(s), is there a better procedure to use so I don’t end up folding them together into one patch when there are changes needed due to feedback from the team? The approach taken this time will combine a bug fix and a feature into a single changeset.
I think there may have been some confusion here, likely me being not super clear and definitely related to me processing a big backlog of patches. So, apologies.
When I asked you to squash things together, I was asking you to do that for the new driver you had proposed, not for these fixes to the existing driver. It's really nice to have separate fixes and features be added in separate patches, which is more of what you had here. Looking at this, *ideally* this would have been three patches:
1. Fix file identifier (really: add a new one you found in the field) 2. Add limited squelch mode (which is kind of a fix, it looks like) 3. Add extra channel attributes (new features).
That way later if we find someone that reports a new problem with, say, the squelch stuff, we can look back and see "ah, here's the full scope of the changes related to squelch stuff, unrelated to extra channel attributes, that's probably where the problem is." Also, this patch will get tagged to all the related bugs, which means people watching a bug about a file ID problem will see a new commit related to it which appears to primarily be about squelch features.
What I was trying to avoid was actually with the other patch (which I still need you to update) is having a commit history that looks like this:
1. Add a new driver that doesn't pass tests 2. Make some more changes 3. Fix the driver so it actually finally works
That is why I wanted you to squash those things. I think the confusion came because you asked if I wanted a patch-to-the-patch in question, which I don't want, because like the new driver example above, it ends up looking like this:
1. Fix a thing
2. No, actually fix a thing
Which we should avoid if we can. So, I said "please send a single patch" because I meant I wanted you to just update and re-send *that* patch. When I said "please squash the multiple patches" I meant for the new driver and its associated revision patches.
In the future, when you're working on a fix or feature and need to make a change to it, just qpush/qpop so it's on top, make a change and qrefresh that change into the patch.
At some point do I invoke qfinish on my patches or does the series continue to grow indefinitely?
No, when I apply a patch you can just qdelete it from your stack and then 'hg pull' from the main repo when it's applied (as it is now).
This patch also has a lot of style fails related to long lines. To avoid making you go back and revise this again, I'm just going to fix those for you, but in the future, please run the style checks first (tox -estyle).
One last thing, you need to actually put '#' in front of your issue numbers, both because that's how redmine knows to update the issue with a link to the commit, but also because my local commit hook will refuse the commit as a check, if it's not tagged to at least one issue. I've fixed that locally as well, but just FYI for the future.
Thanks!
--Dan
_______________________________________________
chirp_devel mailing list
chirp_devel@intrepid.danplanet.commailto:chirp_devel@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
I'd like to be able to run tox, but on Windows it always errors on setup.py, line 5, "from chirp import CHIRP_VERSION" as below. This happens when testing as well. Any ideas?
I don't have a windows development environment handy to play with this, so people that want this to work on windows are going to have to do a little to help with it.
The problem is, I think, that setup.py doesn't really work for the 'sdist' target, which tox needs to build the package. This is totally untested, but try this (or a similar) hack to make it run the normal build stuff in setup.py if inside tox. I dunno if the forward slash paths in the default_build() are going to be a problem on windows or if the libraries will translate those, so you might have to mess with that a bit.
--Dan
diff -r 3e2cf83e9483 setup.py --- a/setup.py Fri Nov 20 17:15:58 2020 -0500 +++ b/setup.py Sat Nov 21 12:09:32 2020 -0800 @@ -105,7 +105,8 @@ from distutils.core import setup from glob import glob
- os.system("make -C locale clean all") + if sys.platform != 'win32': + os.system("make -C locale clean all")
desktop_files = glob("share/*.desktop") # form_files = glob("forms/*.x?l") @@ -150,9 +151,9 @@ f.close()
-if sys.platform == "darwin": +if sys.platform == "darwin" and 'TOX_ENV' not in os.environ: macos_build() -elif sys.platform == "win32": +elif sys.platform == "win32" and 'TOX_ENV' not in os.environ: win32_build() else: default_build() diff -r 3e2cf83e9483 tox.ini --- a/tox.ini Fri Nov 20 17:15:58 2020 -0500 +++ b/tox.ini Sat Nov 21 12:09:32 2020 -0800 @@ -7,6 +7,8 @@ passenv = HOME whitelist_externals = bash deps = future +setenv = + TOX_ENV=yes
[testenv:unit] deps =
Dan,
I had the same error and was able to run the tests on my driver like this:
C:\chirpdev>python tests/run_tests.py -d TYT_TH-UV88
Perhaps that will help someone else until tox works as designed 😉
From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com Date: Saturday, 21 November 2020 at 20:14 To: chirp_devel@intrepid.danplanet.com chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] [PATCH] [AnyTone 5888UV] Add simple squelch mode & additional file identifier and add extra channel attributes
I'd like to be able to run tox, but on Windows it always errors on setup.py, line 5, "from chirp import CHIRP_VERSION" as below. This happens when testing as well. Any ideas?
I don't have a windows development environment handy to play with this, so people that want this to work on windows are going to have to do a little to help with it.
The problem is, I think, that setup.py doesn't really work for the 'sdist' target, which tox needs to build the package. This is totally untested, but try this (or a similar) hack to make it run the normal build stuff in setup.py if inside tox. I dunno if the forward slash paths in the default_build() are going to be a problem on windows or if the libraries will translate those, so you might have to mess with that a bit.
--Dan
diff -r 3e2cf83e9483 setup.py --- a/setup.py Fri Nov 20 17:15:58 2020 -0500 +++ b/setup.py Sat Nov 21 12:09:32 2020 -0800 @@ -105,7 +105,8 @@ from distutils.core import setup from glob import glob
- os.system("make -C locale clean all") + if sys.platform != 'win32': + os.system("make -C locale clean all")
desktop_files = glob("share/*.desktop") # form_files = glob("forms/*.x?l") @@ -150,9 +151,9 @@ f.close()
-if sys.platform == "darwin": +if sys.platform == "darwin" and 'TOX_ENV' not in os.environ: macos_build() -elif sys.platform == "win32": +elif sys.platform == "win32" and 'TOX_ENV' not in os.environ: win32_build() else: default_build() diff -r 3e2cf83e9483 tox.ini --- a/tox.ini Fri Nov 20 17:15:58 2020 -0500 +++ b/tox.ini Sat Nov 21 12:09:32 2020 -0800 @@ -7,6 +7,8 @@ passenv = HOME whitelist_externals = bash deps = future +setenv = + TOX_ENV=yes
[testenv:unit] deps =
_______________________________________________ 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 (3)
-
Brad & Cindy Schuler -
Dan Smith -
James Berry