Zram is only strictly dependent on lzo, not lz4. Break this dependency and
make the lz4 module visible in the configuration, in order for the user to
have the choice of enabling/disabling it, if (s)he sees fit.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Since commit 910df3f06c we have build in
on all X86/64 platforms the gpio-it87 driver.
Since this change I am getting the following error message on boot.
> kern.err kernel: [ 1.009416] gpio_it87: no device
I do not have this device on my system. To prevent the nonsensical
message and the loading of the module I have added this as a package, so
that it can be installed later or during image building.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reviewed-by: Philip Prindeville <philipp@redfish-solutions.com>
This updates the package to contain the kernel object (.ko) file instead
of the plain object (.o) file.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
It is generally more desirable to use older kernel versions for
dependencies, as this will require less changes when newer kernels
are added (they will by default select the newer packages).
Since we currently only have two kernels (4.14 and 4.19) in master,
this patch applies this logic by converting all LINUX_4_19 symbols
to their inverted LINUX_4_14 equivalents.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Packages kmod-bluetooth_6lowpan and kmod-ieee802154_6lowpan contain an
underscore in the package name. This causes problems in package/install
because when building a list of package files to install offline using
opkg, it uses a wildcard of the form $(dir)/$(pkg)_*.ipk.
If you were to select kmod-bluetooth=y, but kmod-bluetooth_6lowpan=m,
the latter would be picked up by that wildcard, and make package/install
would fail:
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
* for kmod-bluetooth_6lowpan:
* kmod-6lowpan
* opkg_install_cmd: Cannot install package kmod-bluetooth_6lowpan.
Changing the wildcard pattern is not trivial, and there may be other
places in the build system making this assumption about the package name
format.
Using a dash in place of the underscore avoids the issue.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
