| Message ID | 20150419110326.31c34542@free-electrons.com |
|---|---|
| State | Not Applicable |
| Headers | show |
Thomas, Petr, All, On 2015-04-19 11:03 +0200, Thomas Petazzoni spake thusly: --SNIP--] > I wanted to apply your patch, and did a couple of updates to it (see > below). However, there's a more fundamental problem to this package: it > expects the linux package to be extracted/configured *before* the > configuration of linux-backports. Unfortunately, this is not the case: > 'linux' is only in LINUX_BACKPORTS_DEPENDENCIES, so it's only > guaranteed to be here when linux-backports gets configured, not before. [--SNIP--] > I'm not sure yet of the possible solutions to this: add 'linux' to > LINUX_BACKPORT_PATCH_DEPENDENCIES ? Use the linux extension mechanism > as suggested by Arnout ? Adding 'linux' to _PATCH_DEPENDENCIES will not be enough, because all _PATCH_DEPENDENCIES guarantees is that such dependencies are extracted and patched, not that they are configured/built or whatever. So, the only option left would be to treat them as a linux extension, and drop the build+install commands from linux-backports, and use the integration strategy (instead of the packaging strategy), see: https://backports.wiki.kernel.org/index.php/Documentation/integration However, it seems to be quite involved... Regards, Yann E. MORIN.
On 19/04/15 11:03, Thomas Petazzoni wrote: > Dear Petr Vorel, > > On Sat, 18 Apr 2015 01:01:10 +0200, Petr Vorel wrote: >> https://backports.wiki.kernel.org >> >> Signed-off-by: Petr Vorel <petr.vorel@gmail.com> > > I wanted to apply your patch, and did a couple of updates to it (see > below). However, there's a more fundamental problem to this package: it > expects the linux package to be extracted/configured *before* the > configuration of linux-backports. Unfortunately, this is not the case: > 'linux' is only in LINUX_BACKPORTS_DEPENDENCIES, so it's only > guaranteed to be here when linux-backports gets configured, not before. Perhaps that's a problem in the kconfig infrastructure. The configure step depends on the DEPENDENCIES, and I'd consider the *config targets conceptually part of the configure step. Currently, *config only depends on the patch step (through $(2)_KCONFIG_FILE), perhaps we should add the depends step to that. Regards, Arnout > > So, when you run 'make linux-backports-menuconfig' from a clean > Buildroot tree (i.e without doing a full 'make'), you get: > > thomas@skate:~/projets/buildroot (master)$ make linux-backports-menuconfig > yes "" | /usr/bin/make -j5 -C /home/thomas/projets/buildroot/output/build/linux-backports-3.18.1-1 HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=arm INSTALL_MOD_PATH=/home/thomas/projets/buildroot/output/target CROSS_COMPILE=" /home/thomas/projets/buildroot/output/host/usr/bin/arm-linux-" DEPMOD=/home/thomas/projets/buildroot/output/host/sbin/depmod KLIB_BUILD=/home/thomas/projets/buildroot/output/build/linux-4.0 KLIB=/home/thomas/projets/buildroot/output/target oldconfig > make[1]: Entering directory '/home/thomas/projets/buildroot/output/build/linux-backports-3.18.1-1' > /-------------- > | Your kernel headers are incomplete/not installed. > | Please install kernel headers, including a .config > | file or use the KLIB/KLIB_BUILD make variables to > | set the kernel to build against, e.g. > | make KLIB=/lib/modules/3.1.7/ > | to compile/install for the installed kernel 3.1.7 > | (that isn't currently running.) > \-- > Makefile:40: recipe for target 'oldconfig' failed > make[1]: *** [oldconfig] Error 1 > make[1]: Leaving directory '/home/thomas/projets/buildroot/output/build/linux-backports-3.18.1-1' > package/linux-backports/linux-backports.mk:38: recipe for target '/home/thomas/projets/buildroot/output/build/linux-backports-3.18.1-1/.stamp_kconfig_fixup_done' failed > make: *** [/home/thomas/projets/buildroot/output/build/linux-backports-3.18.1-1/.stamp_kconfig_fixup_done] Error 2 > > This is because output/build/linux-4.0 is currently empty, since the > linux package has not been extracted yet. [snip]
Arnout, All, On 2015-04-19 18:20 +0200, Arnout Vandecappelle spake thusly: > On 19/04/15 11:03, Thomas Petazzoni wrote: > > Dear Petr Vorel, > > > > On Sat, 18 Apr 2015 01:01:10 +0200, Petr Vorel wrote: > >> https://backports.wiki.kernel.org > >> > >> Signed-off-by: Petr Vorel <petr.vorel@gmail.com> > > > > I wanted to apply your patch, and did a couple of updates to it (see > > below). However, there's a more fundamental problem to this package: it > > expects the linux package to be extracted/configured *before* the > > configuration of linux-backports. Unfortunately, this is not the case: > > 'linux' is only in LINUX_BACKPORTS_DEPENDENCIES, so it's only > > guaranteed to be here when linux-backports gets configured, not before. > > > Perhaps that's a problem in the kconfig infrastructure. The configure step > depends on the DEPENDENCIES, and I'd consider the *config targets conceptually > part of the configure step. Currently, *config only depends on the patch step > (through $(2)_KCONFIG_FILE), perhaps we should add the depends step to that. Well, I would not be very happy with that, since that would make the following use-case a real pain: $ make foo_defconfig $ make linux-menuconfig Currently, all it needs is the linux kernel to be extracted and patched, and none of its depedencies to be built. Otherwise, it would require the toolchain to be built, plus a sh.tload of other stuff (lzo, for one, and all its own dependencies). That's what we had before the kconfig-package infra, and that was such a pain... However, I understand we have a hole for now, nad that we need to plug it. If that requires foo-*condif to be moved as part of the configure step, then so be it, but that would be really, really painfull. At the very worse, we could manually add the proper dependencies... But that would be ugly as well. Maybe we should have a clean way of doing it with a proper dependency handling (well, I'd rather avoid introducing yet another _DEPENDENCIES variable if at all possible, either). Not an easy problem... :-( Regards, Yann E. MORIN.
Dear Yann E. MORIN, On Sun, 19 Apr 2015 18:28:39 +0200, Yann E. MORIN wrote: > Well, I would not be very happy with that, since that would make the > following use-case a real pain: > > $ make foo_defconfig > $ make linux-menuconfig > > Currently, all it needs is the linux kernel to be extracted and patched, > and none of its depedencies to be built. Otherwise, it would require the > toolchain to be built, plus a sh.tload of other stuff (lzo, for one, and > all its own dependencies). We could remove the mandatory host-lzo dependency from the linux package, by adding an option for that. Remember the recent patches also adding host-xz to the dependencies of linux, which I rejected? This would leave host-kmod as the only dependency of the linux package I believe. But well host-kmod as AUTORECONF = YES, so it pulls a whole bunch of crap. I agree that being able to do "make <foo>-menuconfig" without waiting too long is really a great feature. Thomas
Thank you Thomas for testing, thanks a lot to all of you for the comments. Sorry that I didn't test it well, I didn't expect to be able to use 'make menuconfig' without calling make or 'make linux-backports' before. I send v5 where I integrated Thomass' changes. So is it blind alley (if you don't want to tweak custom requirements), and I should try to add it as linux extension using integration strategy? Petr > Dear Yann E. MORIN, > On Sun, 19 Apr 2015 18:28:39 +0200, Yann E. MORIN wrote: > > Well, I would not be very happy with that, since that would make the > > following use-case a real pain: > > $ make foo_defconfig > > $ make linux-menuconfig > > Currently, all it needs is the linux kernel to be extracted and patched, > > and none of its depedencies to be built. Otherwise, it would require the > > toolchain to be built, plus a sh.tload of other stuff (lzo, for one, and > > all its own dependencies). > We could remove the mandatory host-lzo dependency from the linux > package, by adding an option for that. Remember the recent patches also > adding host-xz to the dependencies of linux, which I rejected? > This would leave host-kmod as the only dependency of the linux package > I believe. But well host-kmod as AUTORECONF = YES, so it pulls a whole > bunch of crap. > I agree that being able to do "make <foo>-menuconfig" without waiting > too long is really a great feature. > Thomas
Petr, All, On 2015-04-19 23:19 +0200, Petr Vorel spake thusly: > Thank you Thomas for testing, thanks a lot to all of you for the comments. > Sorry that I didn't test it well, I didn't expect to be able to use 'make menuconfig' > without calling make or 'make linux-backports' before. > > I send v5 where I integrated Thomass' changes. So is it blind alley (if you don't want to > tweak custom requirements), and I should try to add it as linux extension using > integration strategy? Well, I'm not even sure going with the integration strategy is doable either. From what I understand, the integration strategy works by cherry-picking commits onto an earlier version, which requires a git tree, and we do not use a git tree. OTOH, the packaging strategy does not work currently for the previously explained reasons. I can have a further look into that, but it will take some time before I can dedicate time to it... Anyway, thank you for your continued efforts into getting support for backports upstreamed! :-) Regards, Yann E. MORIN.
On 19/04/15 19:03, Thomas Petazzoni wrote: > Dear Yann E. MORIN, > > On Sun, 19 Apr 2015 18:28:39 +0200, Yann E. MORIN wrote: > >> Well, I would not be very happy with that, since that would make the >> following use-case a real pain: >> >> $ make foo_defconfig >> $ make linux-menuconfig >> >> Currently, all it needs is the linux kernel to be extracted and patched, >> and none of its depedencies to be built. Otherwise, it would require the >> toolchain to be built, plus a sh.tload of other stuff (lzo, for one, and >> all its own dependencies). > > We could remove the mandatory host-lzo dependency from the linux > package, by adding an option for that. Remember the recent patches also > adding host-xz to the dependencies of linux, which I rejected? > > This would leave host-kmod as the only dependency of the linux package > I believe. But well host-kmod as AUTORECONF = YES, so it pulls a whole > bunch of crap. As mentioned before, it pulls in the toolchain as well. That's a lot worse than host-lzo and host-xz - even extracting an external toolchain takes longer than host-xz (at least for me). However, we can add the dependency specifically for linux-backports. There is something to be said for the reasoning that usually/sometimes you don't need the dependencies to be present, so doing it per package sounds OK. So in this case, adding $(LINUX_BACKPORTS_KCONFIG_FILE): linux to linux-backports.mk should be sufficient. Regards, Arnout
Dear Arnout Vandecappelle, On Mon, 20 Apr 2015 22:42:28 +0200, Arnout Vandecappelle wrote: > However, we can add the dependency specifically for linux-backports. There is > something to be said for the reasoning that usually/sometimes you don't need the > dependencies to be present, so doing it per package sounds OK. > > So in this case, adding > > $(LINUX_BACKPORTS_KCONFIG_FILE): linux > > to linux-backports.mk should be sufficient. If we do this, we must also keep the 'linux' dependency in LINUX_BACKPORTS_DEPENDENCIES as well, so that the package infra remains aware of this dependency. Thomas
Arnout, All, On 2015-04-20 22:42 +0200, Arnout Vandecappelle spake thusly: > On 19/04/15 19:03, Thomas Petazzoni wrote: > > Dear Yann E. MORIN, > > > > On Sun, 19 Apr 2015 18:28:39 +0200, Yann E. MORIN wrote: > > > >> Well, I would not be very happy with that, since that would make the > >> following use-case a real pain: > >> > >> $ make foo_defconfig > >> $ make linux-menuconfig > >> > >> Currently, all it needs is the linux kernel to be extracted and patched, > >> and none of its depedencies to be built. Otherwise, it would require the > >> toolchain to be built, plus a sh.tload of other stuff (lzo, for one, and > >> all its own dependencies). > > > > We could remove the mandatory host-lzo dependency from the linux > > package, by adding an option for that. Remember the recent patches also > > adding host-xz to the dependencies of linux, which I rejected? > > > > This would leave host-kmod as the only dependency of the linux package > > I believe. But well host-kmod as AUTORECONF = YES, so it pulls a whole > > bunch of crap. > > As mentioned before, it pulls in the toolchain as well. That's a lot worse than > host-lzo and host-xz - even extracting an external toolchain takes longer than > host-xz (at least for me). > > > However, we can add the dependency specifically for linux-backports. There is > something to be said for the reasoning that usually/sometimes you don't need the > dependencies to be present, so doing it per package sounds OK. > > So in this case, adding > > $(LINUX_BACKPORTS_KCONFIG_FILE): linux > > to linux-backports.mk should be sufficient. Yes, I have the same reasoning, and I think what you suggest is good enough to be considered the good solution. If we end up having more such cases, we can revisit this in the future. Regards, Yann E. MORIN.
On 20/04/15 22:56, Thomas Petazzoni wrote: > Dear Arnout Vandecappelle, > > On Mon, 20 Apr 2015 22:42:28 +0200, Arnout Vandecappelle wrote: > >> However, we can add the dependency specifically for linux-backports. There is >> something to be said for the reasoning that usually/sometimes you don't need the >> dependencies to be present, so doing it per package sounds OK. >> >> So in this case, adding >> >> $(LINUX_BACKPORTS_KCONFIG_FILE): linux >> >> to linux-backports.mk should be sufficient. > > If we do this, we must also keep the 'linux' dependency in > LINUX_BACKPORTS_DEPENDENCIES as well, so that the package infra remains > aware of this dependency. Yes of course. Regards, Arnout
diff --git a/package/linux-backports/Config.in b/package/linux-backports/Config.in index 3e4e383..7853ba6 100644 --- a/package/linux-backports/Config.in +++ b/package/linux-backports/Config.in @@ -1,5 +1,8 @@ +comment "linux-backports needs a Linux kernel to be built" + depends on !BR2_LINUX_KERNEL + config BR2_PACKAGE_LINUX_BACKPORTS - bool "Linux kernel driver backports" + bool "linux-backports" depends on BR2_LINUX_KERNEL help The backports package includes many Linux drivers from recent diff --git a/package/linux-backports/linux-backports.mk b/package/linux-backports/linux-backports.mk index 47cb206..73179a6 100644 --- a/package/linux-backports/linux-backports.mk +++ b/package/linux-backports/linux-backports.mk @@ -1,10 +1,16 @@ -LINUX_BACKPORTS_VERSION = 3.18.1 -LINUX_BACKPORTS_REVISION = 1 -LINUX_BACKPORTS_SOURCE = backports-$(LINUX_BACKPORTS_VERSION)-$(LINUX_BACKPORTS_REVISION).tar.xz -LINUX_BACKPORTS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/projects/backports/stable/v$(LINUX_BACKPORTS_VERSION) +################################################################################ +# +# linux-backports +# +################################################################################ + +LINUX_BACKPORTS_VERSION_MAJOR = 3.18.1 +LINUX_BACKPORTS_VERSION = $(LINUX_BACKPORTS_VERSION_MAJOR)-1 +LINUX_BACKPORTS_SOURCE = backports-$(LINUX_BACKPORTS_VERSION).tar.xz +LINUX_BACKPORTS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/projects/backports/stable/v$(LINUX_BACKPORTS_VERSION_MAJOR) LINUX_BACKPORTS_DEPENDENCIES = linux -LINUX_BACKPORTS_MAKE_ENV = \ +LINUX_BACKPORTS_MAKE_OPTS = \ $(LINUX_MAKE_FLAGS) \ KLIB_BUILD=$(LINUX_DIR) \ KLIB=$(TARGET_DIR) @@ -16,11 +22,11 @@ LINUX_BACKPORTS_KCONFIG_FILE = $(BR2_PACKAGE_LINUX_BACKPORTS_CUSTOM_CONFIG_FILE) endif define LINUX_BACKPORTS_BUILD_CMDS - $(LINUX_BACKPORTS_MAKE_ENV) $(MAKE) $(LINUX_BACKPORTS_MAKE_OPTS) -C $(@D) + $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_BACKPORTS_MAKE_OPTS) -C $(@D) endef define LINUX_BACKPORTS_INSTALL_TARGET_CMDS - $(LINUX_BACKPORTS_MAKE_ENV) $(MAKE) $(LINUX_BACKPORTS_MAKE_OPTS) \ + $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_BACKPORTS_MAKE_OPTS) \ -C $(LINUX_DIR) M=$(@D) \ INSTALL_MOD_DIR=backports \ modules_install @@ -35,13 +41,13 @@ $(eval $(kconfig-package)) ifeq ($(filter source,$(MAKECMDGOALS)),) ifeq ($(BR2_PACKAGE_LINUX_BACKPORTS_USE_DEFCONFIG),y) ifeq ($(call qstrip,$(BR2_PACKAGE_LINUX_BACKPORTS_DEFCONFIG)),) -$(error No kernel defconfig name specified, check your BR2_PACKAGE_LINUX_BACKPORTS_DEFCONFIG setting) +$(error No linux-backports defconfig name specified, check your BR2_PACKAGE_LINUX_BACKPORTS_DEFCONFIG setting) endif endif ifeq ($(BR2_PACKAGE_LINUX_BACKPORTS_USE_CUSTOM_CONFIG),y) ifeq ($(call qstrip,$(BR2_PACKAGE_LINUX_BACKPORTS_CUSTOM_CONFIG_FILE)),) -$(error No kernel configuration file specified, check your BR2_PACKAGE_LINUX_BACKPORTS_CUSTOM_CONFIG_FILE setting) +$(error No linux-backports configuration file specified, check your BR2_PACKAGE_LINUX_BACKPORTS_CUSTOM_CONFIG_FILE setting) endif endif