Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug/11423 draft alternatives for the uvk5 99 #1087

Closed

Conversation

ei2081
Copy link
Contributor

@ei2081 ei2081 commented Aug 15, 2024

CHIRP PR Guidelines

The following must be true before PRs can be merged:

  1. All tests must be passing. The "PR Checks" job is speculative and failure doesn't always indicate a critial problem, but generally it needs to pass as well.
  2. Commits should be rebased (or simply rebase-able in the web UI) on current master. Do not put merge commits in a PR.
  3. Commits in a single PR should be related. Squash intermediate commits into logical units (i.e. "fix tests" commits need not survive on their own). Keep cleanup commits separate from functional changes.
  4. Major new features or bug fixes should reference a CHIRP issue in the commit message. Do this with the pattern Fixes #1234 or Related to #1234 so that the ticket system links the commit to the issue.
  5. Please write a reasonable commit message, especially if making some change that isn't totally obvious (such as adding a new model, adding a feature, etc). The first line of every commit is emailed to the users' list after each build. It should be short, but meaningful for regular users (examples: "thd74: Fixed tone decoding" or "uv5r: Added settings support").
  6. New drivers should be accompanied by a test image in tests/images (except for thin aliases where the driver is sufficiently tested already). All new drivers must use MemoryMapBytes. New drivers and radio models will affect the Python3 test matrix. You should regenerate this file with tox -emakesupported and include it in your commit.
  7. All files must be GPLv3 licensed or contain no license verbiage. No additional restrictions can be placed on the usage (i.e. such as noncommercial).
  8. Do not add new py2-compatibility code (No new uses of six, future, etc).

and foldable multi-line comments ftw!
Updated comment to foldable. Referred DTCS and CTCSS tone codes to the chirp_common as they are the same. Made a bunch of other changes but reverted.
Added a registered radio variant with the firmward code of my handset only.
Tested it with connect radio, download memories (ca. 10 of), replace memories (ca. 125 of - repeaters, marine, pmr, etc), wrote to radio.
Radio still works so far.
didn't mean for that one to commit
style checks were not happy, lets see how this goes
@ei2081
Copy link
Contributor Author

ei2081 commented Aug 15, 2024

TOX help pls - looks like unit-test suggests this model i added is part of an alias ? (... # Make sure the alias model is NOT in the directory...)
Perhaps it ought to be simple an addition to the supported firmware codes ?

Will look into the support matrix fun after that

ty!

@pbarrette
Copy link
Contributor

Looks to me like you're adding a new model called "UV-K5(99)" but it already exists as an alias that's mapped to "UV-K5" in the "/chirp/share/model_alias_map.yaml" file.

chirp/drivers/uvk5.py Show resolved Hide resolved
chirp/drivers/uvk5.py Show resolved Hide resolved
chirp/drivers/uvk5.py Show resolved Hide resolved
@ei2081 ei2081 closed this Aug 16, 2024
@ei2081 ei2081 deleted the bug/11423-draft-alternatives-for-the-uvk5-99 branch August 16, 2024 12:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants