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

RFC: modify buildsystem docs in README.md #825

Closed
wants to merge 1 commit into from
Closed

RFC: modify buildsystem docs in README.md #825

wants to merge 1 commit into from

Conversation

Akira25
Copy link
Member

@Akira25 Akira25 commented Jun 28, 2020

This is meant to be an first improvement for the issues in documentation addressed in #824. This commit mainly takes some of documentation of weimarnetz and adds that to our README.md

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
@SvenRoederer
Copy link
Contributor

Improved docs are always welcome.

Before putting much work into this, we should discuss on #765 as it will change many of the existing folders.

@Akira25
Copy link
Member Author

Akira25 commented Jul 3, 2020

Improved docs are always welcome.

Before putting much work into this, we should discuss on #765 as it will change many of the existing folders.

I'm already finished. I'd prefer to have this merged fairly soon, as anyone how like to use our buildsystem now, would need to invest much debugging effort into it, until he gets to know, where to configure anything.

@Akira25
Copy link
Member Author

Akira25 commented Jul 3, 2020

Besides that, regarding our current development velocity, I don't think we will have a decision on #765 within the next 1.5 Years.

README.md Outdated Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
Copy link

@foudfou foudfou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very helpful!

README.md Outdated Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated
* a tutorial ([en](https://wiki.freifunk.net/Berlin:Firmware:En:Howto) / [de](https://wiki.freifunk.net/Berlin:Firmware:Howto)) on router configuration
More user relevant information on the firmware are on the wiki page at:
https://wiki.freifunk.net/Berlin:Firmware. There you can also find the
* [ReleaseNotes](https://wiki.freifunk.net/Berlin:Firmware/v1.0.2) and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hedy-1.0.6 is out and should be referenced here. But this can be a separate commit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to use a variable which accesses the latest tagged release version. (for the separate commit which will someday materialize)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the Readme belongs to the Codebase of a release, releasing something with an old or template value here, will end in having this template in the released Readme. Updating it after releasing creates a new version of the file (commit) which should cause to release again. So the never ending loop has started ...

In long-term I suggest to get rid of the release-history in the Readme of the firmware-buildsystem, like I did here: https://github.com/freifunk-berlin/firmware/tree/745bda009b313cf3ce4eaacd82e232a4644f8a03

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As the page for v1.0.6 does not exist, I linked the page for v1.0.3

README.md Outdated

patches/ - Patches against the OpenWRT directory
packagelists/ - Package Lists
profiles/ - List of router profiles for each architecture - names come
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably use "target architecture" to keep the common target term

README.md Outdated
patches/ - Patches against the OpenWRT directory
packagelists/ - Package Lists
profiles/ - List of router profiles for each architecture - names come
from the Imagebuilder
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it worth to mention "make info" here?

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
The default target is `ar71xx-generic`. For a complete list of supported targets
look at `configs/` for the target-specific configs. Each of these targets need a
matching file in `profiles/` with the profiles (boards) that should be build
with the imagebuilder.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"should be build by the imagebuilder"?

Copy link
Contributor

@pmelange pmelange Jul 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"should be built by" would be the queen's english.

should work at least in theory. Wifi should be ath9k / ath10k. mt76 also appears
to work.

You can use the Imagebuilder to get a list of all supported models for a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably the better place, than the mentioned above, to reference "make info" if we want to reference it at all.

README.md Outdated
[http://buildbot.berlin.freifunk.net/buildbot/unstable/](http://buildbot.berlin.freifunk.net/buildbot/unstable/)
Note that in the directory there is no reference to the branch name; unstable builds can be identified by build number only.
Note that in the directory there is no reference to the branch name; unstable
builds can be identified by their build number only.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you willing to referernce the VERSION.txt file here

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
…m. Wrap lines to meet needs of 80-char-terminal.
Copy link
Contributor

@SvenRoederer SvenRoederer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far thanks for your work

* a tutorial ([en](https://wiki.freifunk.net/Berlin:Firmware:En:Howto) / [de](https://wiki.freifunk.net/Berlin:Firmware:Howto)) on router configuration
More user relevant information about the firmware are on the wiki page at: https://wiki.freifunk.net/Berlin:Firmware.
There you can also find the
* [ReleaseNotes](https://wiki.freifunk.net/Berlin:Firmware/v1.0.3)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To reflect the current state: It feels to me, that we should not reference the wiki here, as nobody takes care of updating the pages. It seems best to reference the Github-release pages (https://github.com/freifunk-berlin/firmware/releases) here, which link to the correct ReleaseNotes of the corresponding release.


The idea is to download OpenWrt via git, patch it with all patches in the
`patches/` folder and configure it according to the configuration snippets in
`configs`. Then use the OpenWrt buildsystem to build all packages and the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be configs/ , as it's a folder

`patches/` folder and configure it according to the configuration snippets in
`configs`. Then use the OpenWrt buildsystem to build all packages and the
Imagebuilder and use the latter to assemble the final image with lists of
packages in packages for the router.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"with lists of packages in packaglists/ for the router.

`configs`. Then use the OpenWrt buildsystem to build all packages and the
Imagebuilder and use the latter to assemble the final image with lists of
packages in packages for the router.
All additional packages can be found at http://github.com/freifunk-berlin/packages_berlin.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we mention "gluon-packages" and "freifunk-potsdam-packages" also. (not shure if ffp-packages made it up to this repo already)

```
:: Settings

config.mk - OpenWrt git repository, revision, select what package lists to build
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"OpenWrt git repository, revision" is controlled by modules-file

:: Settings

config.mk - OpenWrt git repository, revision, select what package lists to build
feeds.conf - OpenWrt feeds.conf that is used for the package feeds during build
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"feeds.conf" is converted to modules

config.mk - OpenWrt git repository, revision, select what package lists to build
feeds.conf - OpenWrt feeds.conf that is used for the package feeds during build

configs/ - further configurations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"further configurations" replace by "snippets of the OpenWrt config-options (compare to call "make menuconfig" in openwrt/)" or something alike

some boards to initially install OpenWrt.
As you notice there are several different image variants ("manual", "notunnel",
etc.).
+ These different *packages lists* are defined in `packages/`. See the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

packages/ --> packagelists/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You talk here on the "firmware" folder, right? Then this packages folder is just the storage-repo of all packages available.These packages will be included according to the flavors in packagelists/ to the image or used as source then running opkg install on the router.

All branches with names not fitting the "X.Y.Z" pattern are built and put into
the "unstable" directory: [http://buildbot.berlin.freifunk.net/buildbot/unstable/](http://buildbot.berlin.freifunk.net/buildbot/unstable/)
Note that in the directory there is no reference to the branch name; unstable
builds can be identified by build number only.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

referencing the VERSION.txt file? As this is the best place to look up on which branch and revision a build is based on.

the codename in the README and config files (./configs/*)
For a new release, create a new branch. The branch name must be a semantic
version number. Make sure you change the semantic version number and, for major
releases, the codename in the README and config files (`./configs/`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(./configs/) --> in all other places we did not prefix the path by "./"

@Akira25
Copy link
Member Author

Akira25 commented Oct 10, 2020

@SvenRoederer There were 37 (±2) requests for changes in total. Please feel free to include them into the README-File. It might be faster to do it by yourself, then writing me, what I should change. I will no longer invest effort into this. You seem to be the only one, who knows how this buildsystem works.

Sadly, the documentation will still document a different state than the current one.

@Akira25 Akira25 closed this Oct 10, 2020
@SvenRoederer
Copy link
Contributor

@SvenRoederer There were 37 (±2) requests for changes in total. Please feel free to include them into the README-File. It might be faster to do it by yourself, then writing me, what I should change.

That's the downside of having the PR source from your private Repo-fork ... Only you have permission to commit to it. My impression was, that the most of the open changes were were most "consistency of terms" and generic comments.

I will no longer invest effort into this. You seem to be the only one, who knows how this buildsystem works.

I got used to it and found some smart ideas inside. Sadly I seems to be the only one still working on it, as the "old" developers (@sarumpaet @booo @andrenarchy @lynxis ) seem to have retired.

Sadly, the documentation will still document a different state than the current one.

Indeed your updated documentation somehow based on the outdated system before switching to "modules"-file.

But thanks for your work so far. I'll reopen, in case someone else likes to continue here.

@SvenRoederer SvenRoederer reopened this Oct 20, 2020
SvenRoederer added a commit that referenced this pull request Jun 27, 2021
SvenRoederer added a commit that referenced this pull request Jun 27, 2021
SvenRoederer added a commit that referenced this pull request Jul 11, 2021
SvenRoederer added a commit that referenced this pull request Jul 11, 2021
SvenRoederer added a commit that referenced this pull request Jul 18, 2021
@FFHener FFHener deleted the branch freifunk-berlin:master June 24, 2024 08:02
@FFHener FFHener closed this Jun 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants