Ref: https://openwrt.org/docs/guide-developer/packages for overall format and construction
All packages you commit or submit by pull-request should follow these simple guidelines:
<jdh@jdhs-email-provider.org
>). Listing multiple maintainers is encouraged in
order to keep the package active and up-to-date. Leaving this blank will also
be accepted, however the review process may not be as quick as one with a
maintainer.Pull requests are the easiest way to contribute changes to git repos at Github. They are the preferred contribution method, as they offer a nice way for commenting and amending the proposed changes.
You need a local "fork" of the Github repo.
Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request. Workflow using "feature_x" as the example:
git checkout -b feature_x
git push -u origin feature_x
. That
creates the "feature_x" branch at your Github fork and sets it as the
remote of this branchIf you later need to add new commits to the pull request, you can simply
commit the changes to the local branch and then use git push
to
automatically update the pull request.
If you need to change something in the existing pull request (e.g. to add a
missing signed-off-by line to the commit message), you can use git push -f
to overwrite the original commits. That is easy and safe when using a feature
branch. Example workflow:
git checkout feature_x
git commit --amend
to do thatgit rebase -i HEAD~X
(X = number of commits to
edit) to possibly squash some commitsgit push -f
to overwrite the
original commits in the "feature_x" branch with the new ones. The pull
request gets automatically updated(Complete list can be found at: https://spdx.org/licenses)
Full Name | Identifier |
---|---|
Apache License 1.0 | Apache-1.0 |
Apache License 1.1 | Apache-1.1 |
Apache License 2.0 | Apache-2.0 |
Artistic License 1.0 | Artistic-1.0 |
Artistic License 1.0 w/clause 8 | Artistic-1.0-cl8 |
Artistic License 1.0 (Perl) | Artistic-1.0-Perl |
Artistic License 2.0 | Artistic-2.0 |
BSD 2-Clause "Simplified" License | BSD-2-Clause |
BSD 2-Clause FreeBSD License | BSD-2-Clause-FreeBSD |
BSD 2-Clause NetBSD License | BSD-2-Clause-NetBSD |
BSD 3-Clause "New" or "Revised" License | BSD-3-Clause |
BSD with attribution | BSD-3-Clause-Attribution |
BSD 3-Clause Clear License | BSD-3-Clause-Clear |
BSD 4-Clause "Original" or "Old" License | BSD-4-Clause |
BSD-4-Clause (University of California-Specific) | BSD-4-Clause-UC |
BSD Protection License | BSD-Protection |
GNU General Public License v1.0 only | GPL-1.0-only |
GNU General Public License v1.0 or later | GPL-1.0-or-later |
GNU General Public License v2.0 only | GPL-2.0-only |
GNU General Public License v2.0 or later | GPL-2.0-or-later |
GNU General Public License v3.0 only | GPL-3.0-only |
GNU General Public License v3.0 or later | GPL-3.0-or-later |
GNU Lesser General Public License v2.1 only | LGPL-2.1-only |
GNU Lesser General Public License v2.1 or later | LGPL-2.1-or-later |
GNU Lesser General Public License v3.0 only | LGPL-3.0-only |
GNU Lesser General Public License v3.0 or later | LGPL-3.0-or-later |
GNU Library General Public License v2 only | LGPL-2.0-only |
GNU Library General Public License v2 or later | LGPL-2.0-or-later |
Fair License | Fair |
ISC License | ISC |
MIT License | MIT |
No Limit Public License | NLPL |
OpenSSL License | OpenSSL |
X11 License | X11 |
zlib License | Zlib |
To simplify review and require less human resources, a CI tests all packages. Passing CI tests are not a hard requirement but a good indicator what the Buildbots will think about the proposed patch.
The CI builds modified packages for multiple architectures using the latest
snapshot SDK. For supported architectures (aarch64_generic
,
arm_cortex-a15_neon-vfpv4
, i386_pentium4
and x86_64
) an additional
runtime test is executed. A running OpenWrt is simulated which tries to install
created packages and runs a script called test.sh
located next to the package
Makefile. The script is executed with the two arguments PKG_NAME
and
PKG_VERSION
. The PKG_NAME
can be used to distinguish package variants, e.g.
foobar
vs. foobar-full
. The PKG_VERSION
can be used for a trivial test
checking if foobar --version
prints the correct version. PKG_VERSION
is the
OpenWrt version and therefore includes the PKG_RELEASE
, which isn't usually
part of the running programs version.
The following snippet show a script that tests different binaries, depending
what IPK package was installed. The gpsd
Makefile produces both a gpsd
and
a gpsd-clients
IPK package.
#!/bin/sh
case "$1" in
"gpsd")
gpsd -V 2>&1 | grep "$2"
;;
"gpsd-clients")
cgps -V 2>&1 | grep "$2"
;;
esac
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。