Home

Awesome

FPV.WTF OPKG Repository

Custom OPKG repository for the FPV.WTF project.

This is the official reposiotry from which the WTFOS configurator pulls its packages.

Usage

Add the following entry to your opkg.conf:

src/gz fpv.wtf http://repo.fpv.wtf/pigeon

Update opkg and list packages from repository:

opkg update

Pre-releases

If you want to use pre-release packages then add the pre-release repository instead of the stable one from above to opkg.conf:

src/gz fpv.wtf http://repo.fpv.wtf/pigeon-prerelease

The prerelease repository contains pre-release packages when available, otherwise the stable packe is available.

Only use either the stable repository or the pre-release repository.

Contribute

Your contributions are very welcome, there are a lot of ways to contribute to this project:

Submitting a Pull Request

Your bugfixes and improvements are always welcome. If you are unsure about a new feature, feel free to open an issue for discussion.

When submitting your PR, please submit it against the develop branch of this repository.

Adding your package

Fork the repository and add your Github project to repositories.json, then submit a PR. The package index will be rebuilt and your packages will be automatically added once your PR has been merged into master.

Each entry consists of two fields:

{
  "repo": "user/repo-name",
  "names": [
    "name_1",
    "name_2",
  ]
}

Example: If your package is called foobar, then the ipk in your release should be called foobar_$VERSION_$ARCH.ipk and the names array should only contain one entry: foobar.

Once the deployment runs it will check the latest release of your project, fetch all matching ipk files and check the control file:

  1. fetch name_1*.ipk and name_2*.ipk
  2. Check if the Package field matches in each of the ipk's

If everything checks out a new index is build. Otherwise the build fails and the offending package will be visible in the build logs.

Package naming

We ask that you give your packages a short, simple and descriptive name. Some examples include:

Please do not tag packages with the wtfos- prefix without consulting with the team first, as it's reserved for core packages. Please also don't tag packages with the author/group name, use the Maintainer .ipk control field instead. This will be shown soon in the configurator (as of time of writing).

Entware mirroring

For maintainers, please note that make entware-mirror will fetch entware packages filtered by entware-packages.txt (the preceeding / and proceeding _ are important for exact matching) into the entware-armv7sf-k3.2 folder for mirroring. We do this (and commit the .ipks fetched) because bin.entware.com has stability issues.

Licensing

Please make sure that the package you are submitting has an open source license attached to it (preferably GPL V3). Pull Requests for packages without a license (or a too restrictive licence) will be rejected.

You can - at any point - run your own repository though (this code is GPL V3) if you are not happy with the licencing term. If you decide to do so make sure that you have some way of supporting your users, since there will be no official support for third party repositories.

Available architectures

To limit the systems on which your package can be installed, add one of the architectures (from general to specific):

IPK template

You can check out the IPK example repository. It provides a template in regards to folder structure, a Makefile and a workflow to automatically build IPK packages via Github Actions.