Sometimes it is useful to override the default version detection, for
example when local patches are applied to a repo. Allow providing a
version number using a file called .scmversion, which is the same that
the Linux kernel and U-Boot use.
v2: In contrast to the last patches, this is now built on top of ssh
only, without using e.g. 9pfs. Furthermore it works also with
arbitary remote hosts on any target/architecture. Also the
scripts were renamed and moved to /scripts.
The aim of this commit is to allow fast rebuild cycles during the
development of gluon packages.
Currently the following workflow can be used:
# start a local qemu instance
scripts/run_qemu.sh output/images/factory/[...].img
# do your changes in the file you want to patch
vi package/gluon-ebtables/files/etc/init.d/gluon-ebtables
# rebuild and update the package
scripts/push_pkg.sh package/gluon-ebtables/
# test your changes
...
# do more changes
...
# rebuild and update the package
scripts/push_pkg.sh package/gluon-ebtables/
# test your changes
...
(and so on...)
Implementation details:
- Currently this is based on ssh/scp.
- Opkg is used to install/update the packages in the remote machine.
Benefits:
- This works with compiled and non-compiled packages.
- This works with native OpenWrt and Gluon packages.
- This even performs the check_site.lua checks as they are integrated
as post_install scripts into the openwrt package.
- It works for all architectures/targets.
The rewrite of the feature handling introduced multiple major bugs. One
of them was caused by the way Lua's logical operators work:
An expression of the form
_'autoupdater' and _'web-advanced'
would return 'web-advanced' rather than the boolean true when _ returned
both strings unchanged (because the features are enabled).
As entries with more than a single feature name in their expressions did
not set no_default, Gluon would then attempt to add gluon-web-advanced to
the package selection, as web-advanced is a "pure" feature.
To fix this, and get rid of the annoying nodefault, separate handling of
"pure" feature and handling of logical expressions into two separate
functions, called feature() and when(). To simplify the feature
definitions, the package list is now passed directly to these functions
rather than in a table with a single field 'packages'.
Fixes: ee5ec5afe5 ("build: rewrite features.sh in Lua")
The `features` file is converted to a Lua-based DSL.
A helper function `_` is used in the DSL; this will return the original
string for enabled features, and nil for disabled features. This allows
to use boolean operations on features without making the code too
verbose.
Besides having more readable and robust code, this also fixes the bug
that all files `packages/*/features` were evaluated instead of only
using the feature definitions of currently active feeds.
This change stores a Kernel with Debug-Symbols for the current
architecture in a new output directory '<outputdir>/debug'.
This allows a developer or operator of a network to store the kernel
along with the actual images. In case of a kernel oops the debug
information can be used with the script
'scripts/decode_stacktrace.sh' in the kernel source tree to get the
names to the symbols of the stack trace.
OpenWRT already provides the CONFIG_COLLECT_KERNEL_DEBUG -option that
creates a kernel with debug-symbols in the OpenWRT output directory.
This change enables this option and copies the generated kernel to the
gluon output directory.
Signed-off-by: Chrissi^ <chris@tinyhost.de>
This summaries giving an overview of a scripts function and a short summary
how it's doing this. Only the scripts are covered, that are used by the
Freifunk-Berlin firmwarebuiler too.
[Matthias Schiffer: slightly reworded some descriptions]
$(TOPDIR) does not contain a trailing slash.
Thus the 'gluon.mk'-include must include
the trailing slash. (Just like the link to
$(INCLUDE_DIR)/package.mk does.)
Signed-off-by: Chris Fiege <chris@tinyhost.de>
To reduce the number of packages that need to be listed in
GLUON_SITE_PACKAGES, this adds a new variable GLUON_FEATURES. Sets of
packages are enabled automatically based on the combination of listed
feature flags.
Site-specified package feeds can provide their own feature flag
definitions.
