Move the kernel versions and hash to dedicated files.
This makes kernel bump quicker and fix some annoying
problem with rebasing when multiple kernel bump are proposed.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
[Rebased on top of current master]
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
(cherry picked from commit 0765466a42)
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
[Rebased on top of current openwrt-21.02]
Package with whitespace in their build directory are not correctly
removed when CONFIG_AUTOREMOVE is enabled. This is caused by xargs that
use whitespace as delimiters. To handle this use \0 as the delimiter and
set find to use \0 as the delimiter.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
(cherry picked from commit dccee21792)
While experimenting with the AUTOREMOVE option in search of a way to use
prebuilt host tools in different buildroot, it was discovered that the
md5 generated by find_md5 in depends.mk is not reproducible.
Currently the hash is generated by the path of the file in addition to
the file mod time. Out of confusion, probably, there was an idea that
such command was used on the package build_dir. Reality is that this
command is run on the package files. (Makefile, patches, src)
This is problematic because the package Makefile (for example) change at
each git clone and base the hash on the Makefile mtime doesn't really
reflect if the Makefile actually changes across a buildroot or not.
A better approach is to generate an hash of each file and then generate
an hash on the sort hash list. This way we remove the problem of git
clone setting a wrong mtime while keeping the integrity of checking if a
file changed for the package as any change will result in a different
hash.
Introduce a new kind of find_md5 function, find_md5_reproducible that
apply this new logic and limit it only with AUTOREMOVE option set to
prevent any kind of slowdown due to additional hash generation.
(cherry picked from commit 53a08e3743)
[ reworked mkhash to old implementation ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
python3.11 beta is out but fails to run the makefile currently
this supports python versions from 3.6 to 3.99 with the python3 binary
it also checks specifically for 3.11 as it is the latest version out
Signed-off-by: Oscar Molnar <oscar@tymscar.com>
(cherry picked from commit a9e8eec221)
Signed-off-by: Michal Vasilek <michal.vasilek@nic.cz> [rebase for 21.02]
Dependency on xxd was added in commit c4dd2441e7 ("tools: add xxd
(from vim)") as U-Boot requires xxd to create the default environment
from an external file.
Later in commit 2b94aac7a1 ("tools: xxd: use more convenient source
tarball"), xxd from another source was used instead, but that source is
currently unavailable, so let's fix it by using simple xxdi.pl Perl
script instead.
Fixes: #10555
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit eae2fb8027)
This uses kernel's generic variable and doesn't require patching it with
a custom Makefile change. It's expected *not* to change any behaviour.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 1d42af720c)
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
(cherry picked from commit 24e27bec9a)
The empty executable is causing problems with meson builds, due to the
error: OSError: [Errno 8] Exec format error: 'ldconfig'
This patch changes the empty ldconfig stub to symlink to /bin/true to
work around this issue.
Fixes: FS#4117
Fixes: 3bd31cc4d2 ("tools/meson: update to 0.60.0")
Signed-off-by: Damien Mascord <tusker@tusker.org>
Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> # Tested on Debian 11
Tested-By: Lucian Cristian <lucian.cristian@gmail.com>
Tested-By: Baptiste Jonglez <git@bitsofnetworks.org>
Cc: Rosen Penev <rosenp@gmail.com>
(cherry picked from commit 6a5b4228e3)
Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org>
[backport to fix prereq check when moving from 22.03 branch to 21.02]
For debugging purposes, we need to know if users are using modified
U-boot versions or not. Currently, the U-boot version is somehow
stripped. This is a little bit problematic when there are
backported/wip/to-upstream patches.
To make it more confusing, there was (before this commit) two U-boot
versioning. U-boot compiled by OpenWrt build bots are missing ``Build:``
This is also the case when the U-boot is compiled locally.
Example:
```
U-Boot SPL 2022.01 (Jan 27 2022 - 00:24:34 +0000)
U-Boot 2022.01 (Jan 27 2022 - 00:24:34 +0000)
```
On the other hand, if you run full build, you can at least see, where it
was compiled. Notice added ``Build:``.
Example:
```
U-Boot 2022.01 (Jan 27 2022 - 00:24:34 +0000), Build: jenkins-turris-os-packages-burstlab-omnia-216
```
In both cases, it is not clear to U-boot developers if it is an unmodified
build. This is also caused that there is a missing ``.git`` file from
U-boot folder, and so there is no history. It leads to that it can not
contain suffix ``-dirty`` (uncommitted modifications) or even something
else like number of commits, etc. [1]
When U-boot is compiled as it should be, the version should look like
this: ``U-Boot 2022.04-rc1-01173-g278195ea1f (Feb 11 2022 - 14:46:50 +0100)``
The date is not changed daily when there are new OpenWrt builds.
This commit adds OpenWrt specific version, which could be verified by
using strings.
```
$ strings bin/targets/mvebu/cortexa9/u-boot-omnia/u-boot-spl.kwb | grep -E "OpenWrt*"
U-Boot SPL 2022.01-OpenWrt-r18942+54-cbfce92367 (Feb 21 2022 - 13:17:34 +0000)
arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 11.2.0 r18942+54-cbfce92367) 11.2.0
2022.01-OpenWrt-r18942+54-cbfce92367
U-Boot 2022.01-OpenWrt-r18942+54-cbfce92367 (Feb 21 2022 - 13:17:34 +0000)
```
[1] https://u-boot.readthedocs.io/en/latest/develop/version.html
Reported-by: Pali Rohár <pali@kernel.org>
Suggested-by: Karel Kočí <karel.koci@nic.cz>
[rebased for OpenWrt 21.02]
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
(cherry picked from commit d6aa9d9e07)
The following patch was integrated upstream:
target/linux/bcm4908/patches-5.4/180-i2c-brcmstb-fix-support-for-DSL-and-CM-variants.patch
All other updated automatically.
The new config option CONFIG_BPF_UNPRIV_DEFAULT_OFF is now handled too.
Compile-tested on: lantiq/xrx200, armvirt/64
Runtime-tested on: lantiq/xrx200, armvirt/64
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Many changes were done in drivers/pinctrl/bcm/pinctrl-bcm2835.c between
5.4.171 and 5.4.179.
The following 3 patches do not apply any more:
* target/linux/bcm27xx/patches-5.4/950-0316-pinctrl-bcm2835-Add-support-for-BCM2711-pull-up-func.patch
This was already integrated in kernel v5.4-rc1, it was never needed.
* target/linux/bcm27xx/patches-5.4/950-0328-Revert-pinctrl-bcm2835-Pass-irqchip-when-adding-gpio.patch
* target/linux/bcm27xx/patches-5.4/950-0362-pinctrl-bcm2835-Change-init-order-for-gpio-hogs.patch
I think these were done to fix the problem which was really fixed in
commit 75278f1aff5e ("pinctrl: bcm2835: Change init order for gpio
hogs") from v5.4.175
target/linux/generic/backport-5.4/716-v5.5-net-sfp-move-fwnode-parsing-into-sfp-bus-layer.patch
Move fwnode_device_is_available to the same position as in kernel 5.10.
target/linux/layerscape/patches-5.4/302-dts-0083-arm64-ls1028a-qds-correct-bus-of-rtc.patch
Applied in commit 65816c1034769e714edb70f59a33bc5472d9e55f ("arm64: dts:
ls1028a-qds: move rtc node to the correct i2c bus")
Compile-tested: lantiq/xrx200, bcm27xx/bcm2710
Run-tested: lantiq/xrx200
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
All updated automatically.
Compile-tested on: lantiq/xrx200, armvirt/64
Runtime-tested on: lantiq/xrx200, armvirt/64
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Removed upstreamed:
target/linux/mvebu/patches-5.4/001-PCI-aardvark-Wait-for-endpoint-to-be-ready-before-tr.patch
target/linux/mvebu/patches-5.4/016-PCI-aardvark-Train-link-immediately-after-enabling-t.patch
target/linux/mvebu/patches-5.4/017-PCI-aardvark-Improve-link-training.patch
target/linux/mvebu/patches-5.4/018-PCI-aardvark-Issue-PERST-via-GPIO.patch
target/linux/mvebu/patches-5.4/020-arm64-dts-marvell-armada-37xx-Set-pcie_reset_pin-to-.patch
The following patch does not apply to upstream any more and needs some
more work to make it work fully again. I am not sure if we are still
able to set the UART to a none standard baud rate.
target/linux/ath79/patches-5.4/921-serial-core-add-support-for-boot-console-with-arbitr.patch
These patches needed manually changes:
target/linux/generic/pending-5.4/110-ehci_hcd_ignore_oc.patch
target/linux/ipq806x/patches-5.4/0065-arm-override-compiler-flags.patch
target/linux/layerscape/patches-5.4/804-crypto-0016-MLKU-114-1-crypto-caam-reduce-page-0-regs-access-to-.patch
target/linux/mvebu/patches-5.4/019-PCI-aardvark-Add-PHY-support.patch
target/linux/octeontx/patches-5.4/0004-PCI-add-quirk-for-Gateworks-PLX-PEX860x-switch-with-.patch
All others updated automatically.
Compile-tested on: malta/le, armvirt/64, lantiq/xrx200
Runtime-tested on: malta/le, armvirt/64, lantiq/xrx200
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
While the binary `python3.10` is correctly detected by the build system
the default `python3` binary is currently not detected if pointing to a
Python 3.10 installation.
Fix this by extending the grep regex.
Signed-off-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit 56ea2bf2ee)
Fedora 35 contains Python 3.10 as default version. Make use of it.
Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>
[fix commit subject]
Signed-off-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit e1c03ca185)
Fix Fedora 34/35 issue where 'which' detection of 'which' wasn't working
because Fedora use alias and proc
Fixup of fca5ad55d2 prereq-build: fix `which` detection on Fedora
Reported-by: Jani Partanen <rtfm@iki.fi>
Suggest-by: Etienne Champetier <champetier.etienne@gmail.com>
Tested-by: Georgi Valkov <gvalkov@abv.bg>
Signed-off-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit 0d1ebf0d6d)
