| Message ID | 1440202387-7291-1-git-send-email-yann.morin.1998@free.fr |
|---|---|
| State | Rejected |
| Headers | show |
Yann, all, On Sat, 22 Aug 2015 02:13:07 +0200, Yann E. MORIN wrote: > This package requires registration before it can be downloaded, which > means downloads can not be automated. As far as I could see, that's the > only package we have in that case. > > It installs a kernel module, but it is not possible to check whether it > also builds it or just installs a blob. It seems however that there are > source files in that module: > http://lists.busybox.net/pipermail/buildroot/2015-February/119752.html > > But since we can't download without registration, it's impossible to > check if using the kernel-module infra would work. > > We also have no license for it. > > This package does not belong to Buildroot. Remove it. I completely disagree with this. We are using this package for a real project, and we got one report from one user also using it (the user reported the fact that a firmware loading mechanism must be enabled in the system for the package to work). We did contact Bluegiga (the upstream for this package) about the annoyance caused by the registration process needed to download the tarball. However, for licensing/legal reasons, they apparently have no other choice, and they are well aware of the annoyance caused by this process. The wf111 package bundles a kernel module (built from source) and some binary only user-space tools. For the embedded Linux systems that use the Bluegiga WF111 chip, it makes things a lot easier to have the wf111 integrated in Buildroot, rather than having to build it separately. In addition, the registration process is free and can be done by anyone interested by the package. It is indeed annoying, but not that worst that any of the proprietary licensed package that we have, which all very often have weird and complicated build systems that require lots of tricks. So, I completely disagree with this removal proposal, especially since there is absolutely no real problem caused by this package. Best regards, Thomas
Thomas, All, On 2015-08-23 16:36 +0200, Thomas Petazzoni spake thusly: > On Sat, 22 Aug 2015 02:13:07 +0200, Yann E. MORIN wrote: > > This package requires registration before it can be downloaded, which > > means downloads can not be automated. As far as I could see, that's the > > only package we have in that case. > > > > It installs a kernel module, but it is not possible to check whether it > > also builds it or just installs a blob. It seems however that there are > > source files in that module: > > http://lists.busybox.net/pipermail/buildroot/2015-February/119752.html > > > > But since we can't download without registration, it's impossible to > > check if using the kernel-module infra would work. > > > > We also have no license for it. > > > > This package does not belong to Buildroot. Remove it. > > I completely disagree with this. Unsurprising. I knew you would. ;-) > We are using this package for a real project, Irrelevant. Some users of Buildroot want binary packages so they can use ipkg, opkg or rpm to install/remove/update packages on the target. We're however saying that's not something that Buildroot should provide. Some users want a compiler on the target. Yet, we're still arguing that is not a goal Buildroot should pursue. I do not think a corporate will should be the *sole* reason we have something in Buildroot. > We did contact Bluegiga (the upstream for this package) about the > annoyance caused by the registration process needed to download the > tarball. However, for licensing/legal reasons, they apparently have no > other choice, and they are well aware of the annoyance caused by this > process. OK, I would have bet you had contacted them. Sad they did not change their mind. :-( > The wf111 package bundles a kernel module (built from source) and some > binary only user-space tools. For the embedded Linux systems that use > the Bluegiga WF111 chip, it makes things a lot easier to have the wf111 > integrated in Buildroot, rather than having to build it separately. Well, that's not an excuse. > In addition, the registration process is free and can be done by anyone > interested by the package. From what I understood from their registration form (which I did not fill), is that this is a manual process on their side, and that non-coporate users will simply be treated as second-zone: Please use your business e-mail address in the form. Use of non business e-mail domains may delay account creation. > It is indeed annoying, but not that worst > that any of the proprietary licensed package that we have, which all > very often have weird and complicated build systems that require lots > of tricks. License for those packages not the problem. They are directly downloadable. There is no artificial technical barrier to getting their archives (tar/zip/git/...) That package is the *only* one we have in BR (unless I missed any) for which this is not the case. > So, I completely disagree with this removal proposal, especially since > there is absolutely no real problem caused by this package. Oh, it does not. I was surprised to not see it in the autobuilders. But that's simply because it depends on a kernel to be built, and we never build a kernel. The day we use a testing framework (like your nice pending proposal), we will start to see failures because of that package. And blacklisting it in the autobuilders' code would not be the right answer. So, I completely disagree with these non-removal arguments you made. Regards, Yann E. MORIN.
Yann, all, On Sun, 23 Aug 2015 17:37:37 +0200, Yann E. MORIN wrote: > > We are using this package for a real project, > > Irrelevant. Really? If usefulness in real life projects is irrelevant as an argument for a feature in Buildroot, then it's Buildroot that is soon going to become irrelevant. > Some users of Buildroot want binary packages so they can use ipkg, opkg > or rpm to install/remove/update packages on the target. We're however > saying that's not something that Buildroot should provide. > > Some users want a compiler on the target. Yet, we're still arguing that > is not a goal Buildroot should pursue. Those two arguments have nothing to do with the current topic. The arguments you mention are general features that we have decided to not support to keep the build system simple. The wf111 package does not add *any* complexity to Buildroot. Contrary to some other packages that have required addition/extensions to the common package infrastructure, absolutely no changes were needed for the wf111 package. So those two arguments are irrelevant. > I do not think a corporate will should be the *sole* reason we have > something in Buildroot. I agree. But it's not only corporate will: we are not the only company using it. As I said in my previous e-mail, another user on the mailing list said he was using the wf111 package. > > We did contact Bluegiga (the upstream for this package) about the > > annoyance caused by the registration process needed to download the > > tarball. However, for licensing/legal reasons, they apparently have no > > other choice, and they are well aware of the annoyance caused by this > > process. > > OK, I would have bet you had contacted them. Sad they did not change > their mind. :-( They cannot change their mind. I even met a Bluegiga representative at a trade show a few months ago, and discussed with him the matter. The problem is that their hardware include a chip from a third-party manufacturer that does not allow redistributing the code without agreeing with some stupid licensing conditions. So there's nothing Bluegiga can do (except using a different vendor for their future products, but that will not solve the problem for wf111). > > The wf111 package bundles a kernel module (built from source) and some > > binary only user-space tools. For the embedded Linux systems that use > > the Bluegiga WF111 chip, it makes things a lot easier to have the wf111 > > integrated in Buildroot, rather than having to build it separately. > > Well, that's not an excuse. Ah? Making the build process of an embedded Linux easy is not an excuse to have a feature in Buildroot? Then what is the purpose of Buildroot? > > In addition, the registration process is free and can be done by anyone > > interested by the package. > > From what I understood from their registration form (which I did not > fill), is that this is a manual process on their side, and that > non-coporate users will simply be treated as second-zone: > > Please use your business e-mail address in the form. Use of non > business e-mail domains may delay account creation. That is indeed possible, unfortunately. Not something I can control. > License for those packages not the problem. They are directly > downloadable. There is no artificial technical barrier to getting their > archives (tar/zip/git/...) > > That package is the *only* one we have in BR (unless I missed any) for > which this is not the case. At the moment, yes. Remember that some time ago, a guy from The Qt Company came on IRC and asked whether there was some interest in supporting in Buildroot the Qt components that are not freely available, but only available for paying Qt customers. What should we do in this case? Also reject the patches? > > So, I completely disagree with this removal proposal, especially since > > there is absolutely no real problem caused by this package. > > Oh, it does not. I was surprised to not see it in the autobuilders. But > that's simply because it depends on a kernel to be built, and we never > build a kernel. > > The day we use a testing framework (like your nice pending proposal), we > will start to see failures because of that package. And blacklisting it > in the autobuilders' code would not be the right answer. > > So, I completely disagree with these non-removal arguments you made. I agree that the non-testability of the package is annoying, but I don't really see how to overcome this problem. Keep this package in private tree, and have every user of wf111 struggle with their sub-optimal build system? Not ideal either. So I agree it's not ideal, but I'm not sure the removal of the package will actually make the situation better. Best regards, Thomas
I'm not going to comment on all the points made here, but my stance is: lthough I also hate what the wf111 package does, I don't think it's bad enough to remove it from buildroot. It doesn't hurt the rest of buildroot at all, and it is a useful package for some users. I'd rather get rid of sparc than getting rid of this package. On 08/23/2015 08:58 PM, Thomas Petazzoni wrote: [snip] > They cannot change their mind. I even met a Bluegiga representative at > a trade show a few months ago, and discussed with him the matter. The > problem is that their hardware include a chip from a third-party > manufacturer that does not allow redistributing the code without > agreeing with some stupid licensing conditions. So there's nothing > Bluegiga can do (except using a different vendor for their future > products, but that will not solve the problem for wf111). I registered (under a false name and with a dummy e-mail address) and downloaded the driver, and there is no license text available in it. I also did not have to agree to any license conditions in order to register or download anything. So either this representative is wrong about "does not allow redistributing without licensing conditions", or the website designer botched it. Probably the latter. Bottom line is: unless you have a separate agreement with Bluegiga, you are not allowed to use this software for any purpose. I don't understand how legal departments can let something like this pass but on the other hand get all excited about some piece of GPLv3 in your product... The source code says "Refer to LICENSE.txt included with this source code for details on the license terms.", but LICENSE.txt is missing. An earlier version of the tarball has a LICENSE.txt with a MIT-like license or GPLv2. But anyway, that obviously only applies to the sources, not to the userspace binaries that are included and much less to the firmware blobs. So we probably can't host a copy on sources.buildroot.org. [snip] >> That package is the *only* one we have in BR (unless I missed any) for >> which this is not the case. Thomas DS is trying to push support for the Cavium toolchains... [snip] >> The day we use a testing framework (like your nice pending proposal), we >> will start to see failures because of that package. And blacklisting it >> in the autobuilders' code would not be the right answer. Actually, for any package that requires some kind of string option to be set (e.g. most boot loaders), we'll always need exceptions in the autobuilders. >> >> So, I completely disagree with these non-removal arguments you made. > > I agree that the non-testability of the package is annoying, but I > don't really see how to overcome this problem. Put the tarball somewhere in each autobuild instance and feed its path into the config. Regards, Arnout > Keep this package in > private tree, and have every user of wf111 struggle with their > sub-optimal build system? Not ideal either. > > So I agree it's not ideal, but I'm not sure the removal of the package > will actually make the situation better. > > Best regards, > > Thomas > Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
On 08/24/2015 10:07 PM, Arnout Vandecappelle wrote: > I registered (under a false name and with a dummy e-mail address) and > downloaded the driver, and there is no license text available in it. I also did > not have to agree to any license conditions in order to register or download > anything. So either this representative is wrong about "does not allow > redistributing without licensing conditions", or the website designer botched > it. Probably the latter. Bottom line is: unless you have a separate agreement > with Bluegiga, you are not allowed to use this software for any purpose. I don't > understand how legal departments can let something like this pass but on the > other hand get all excited about some piece of GPLv3 in your product... > > The source code says "Refer to LICENSE.txt included with this source code for > details on the license terms.", but LICENSE.txt is missing. An earlier version > of the tarball has a LICENSE.txt with a MIT-like license or GPLv2. But anyway, > that obviously only applies to the sources, not to the userspace binaries that > are included and much less to the firmware blobs. So we probably can't host a > copy on sources.buildroot.org. Although not necessarily a version that works with this device, source for the unifi_helper program doesn't seem to be that hard to find either. https://github.com/kk30/A10-Linux-2.6.36/tree/master/modules/wifi/apm/unifi-linux license.txt suggests everything is dual licensed MIT and GPLv2 So wonder if it is really the chip vendor being the problem... Yours sincerely, Floris Bos
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: Hi, > I'm not going to comment on all the points made here, but my stance > is: lthough I also hate what the wf111 package does, I don't think > it's bad enough to remove it from buildroot. It doesn't hurt the rest > of buildroot at all, and it is a useful package for some users. I'd > rather get rid of sparc than getting rid of this package. I'm with Arnout here. While the download/binary blobs issues certainly aren't nice (and perhaps we would have had second thoughts when it was submitted if we had known about these issues), the fact is that it is in the tree today, people are using it and it doesn't cause any real problems for us - So I suggest we keep it.
Peter, On Tue, 25 Aug 2015 22:28:37 +0200, Peter Korsgaard wrote: > >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > > Hi, > > > I'm not going to comment on all the points made here, but my stance > > is: lthough I also hate what the wf111 package does, I don't think > > it's bad enough to remove it from buildroot. It doesn't hurt the rest > > of buildroot at all, and it is a useful package for some users. I'd > > rather get rid of sparc than getting rid of this package. > > I'm with Arnout here. While the download/binary blobs issues certainly > aren't nice (and perhaps we would have had second thoughts when it was > submitted if we had known about these issues) From the commit log of the package: Adds support for the BlueGiga WF111 WiFi driver and the binary utilities distributed alongside the driver. An account is required to download the sources from the BlueGiga website, which can be created freely. The driver is available for armv5, arm7a and i386. Since it is not possible to automatically retrieve the sources, because of the required user account needed on the BlueGiga website, an option is added to let the Buildroot user specify the directory where the driver tarball was downloaded. So it was 100% clear when the package was submitted that the tarball cannot be automatically retrieved, and that creating an account was needed to download the tarball. See also the initial package submission: http://lists.busybox.net/pipermail/buildroot/2015-January/118194.html Best regards, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, > So it was 100% clear when the package was submitted that the tarball > cannot be automatically retrieved, and that creating an account was > needed to download the tarball. Yeah, I should probably have been more clear. _I_ didn't notice the issue back when it was submitted (and you committed the patch). If I had, perhaps I would have commented on it. But again, it's in the tree now and people are using it, so lets leave it in.
Peter, Yann, On Wed, 26 Aug 2015 17:31:14 +0200, Peter Korsgaard wrote: > Yeah, I should probably have been more clear. _I_ didn't notice the issue > back when it was submitted (and you committed the patch). If I had, > perhaps I would have commented on it. The thing is that I'm not sure what we can do about it, or other packages for which the source/binary is not available in a way that allows automated downloading (either because creating an account is needed, or because the program/library is not free). Besides wf111, another example I gave are the different Qt5 components that are only available to paying Qt customers. On the one hand, having the package in the main Buildroot tree makes things easy for people having access to those components: it's supported by default in Buildroot. On the other hand however, since we, maintainers and core developers of Buildroot, may not have access to those components, it might be problematic for long term testing and maintenance. I'm not really sure how to solve this situation. Should we reject all such packages and ask people to keep them in their private trees (which limits a lot the sharing of such packages: the whole point of Buildroot as an open-source project is to share as many package recipes as possible). Or should we integrate them, maybe marking them in a special way that indicates that we can't test/maintain them? Best regards, Thomas
Thomas, All, On 2015-08-26 19:32 +0200, Thomas Petazzoni spake thusly: > On Wed, 26 Aug 2015 17:31:14 +0200, Peter Korsgaard wrote: > > > Yeah, I should probably have been more clear. _I_ didn't notice the issue > > back when it was submitted (and you committed the patch). If I had, > > perhaps I would have commented on it. Ditto, I just missed that back then. > The thing is that I'm not sure what we can do about it, or other > packages for which the source/binary is not available in a way that > allows automated downloading (either because creating an account is > needed, or because the program/library is not free). Besides wf111, > another example I gave are the different Qt5 components that are only > available to paying Qt customers. Well, I think my position is well defined: we should not have such package in the official Buildroot tree. Since they are not available, there is absolutely nothing we can do with them: - no maintenance (infra changes, clean-ups...) - no autobuild testing - no user support (ML or IRC) > On the one hand, having the package in the main Buildroot tree makes > things easy for people having access to those components: it's > supported by default in Buildroot. I believe that would be a false claim. It would not be "supported", since only the (limited set of) people with access to the source could help, and there's not guarantee they would stick forever (on the ML or on IRC) or that they would even commit to provide support. > On the other hand however, since we, maintainers and core developers of > Buildroot, may not have access to those components, it might be > problematic for long term testing and maintenance. That's my main concern with such packages. > I'm not really sure how to solve this situation. Should we reject all > such packages and ask people to keep them in their private trees (which > limits a lot the sharing of such packages: the whole point of Buildroot > as an open-source project is to share as many package recipes as > possible). As you said: "as possible". In this case, I believe this is not possible. > Or should we integrate them, maybe marking them in a special > way that indicates that we can't test/maintain them? Well, wf111 is in; it was an accident, let's not remove it until it proves actuallt harmfull to us in some way or another (I'll be marking the patch as rejected in Pathwork, but I'll be prompt to resend should we have an issue with that package). IMHO, we should reject any other attempt at getting such a package in the future. I don't mind we package non-free, even non-open-source (aka proprietary) packages, as long as their download can be automated and not require any manual intervention from the user. Yes, it's a pity we can't get the Qt non-free packages. But especially with Qt, they are such a critical piece of a project that I would not want we tell users hat we have such support in Buildroot. That would just be blatantly lying. OTOH, *one* way to which I *may* agree is to add something like In Build options ---> Advanced ---> config UNSUPORTED_NON_PUBLIC_PACKAGES bool "Show unsupported non-public packages" help Some packages do not have publicly accessible source code, either require registration, manual download... Buildroot has recipes for building those packages, but given that their sources ar enot freely available, there is not guarantee they do work as expected, not even build at all. Use at your own risk. Do not report problems to the Buildroot developpers. Sending patches to fix them might be accepted. At the end of package/Config.in: if UNSUPORTED_NON_PUBLIC_PACKAGES menu "Unsupportedd non-public packages" comment "****************************" comment "big fat comment explaining " comment "something like the help text" comment "on multi lines " comment "USE AT YOUR OWN RISK! " comment "****************************" source "package/wf111/Config.in" endmenu endif # UNSUPORTED_NON_PUBLIC_PACKAGES And even then, I would be very picky on those packages... Regards, Yann E. MORIN.
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: Hi, > Yes, it's a pity we can't get the Qt non-free packages. But especially > with Qt, they are such a critical piece of a project that I would not > want we tell users hat we have such support in Buildroot. That would > just be blatantly lying. > OTOH, *one* way to which I *may* agree is to add something like > In Build options ---> Advanced ---> > config UNSUPORTED_NON_PUBLIC_PACKAGES > bool "Show unsupported non-public packages" > help > Some packages do not have publicly accessible source > code, either require registration, manual download... > Buildroot has recipes for building those packages, but > given that their sources ar enot freely available, there > is not guarantee they do work as expected, not even build > at all. > Use at your own risk. Do not report problems to the > Buildroot developpers. Sending patches to fix them might > be accepted. Another alternative is that somebody maintains a set of BR2_EXTERNAL packages for this kind of stuff. I'm not sure what the best solution is, perhaps this is something to discuss during the dev days? Like with a lot of other things it is a question of tradeoffs. For users, it is very handy to have the packages available, but as you mentioned it is hard to really support them. There is imho also value in trying to convince upstream of these packages to make the sources freely available / promote the vendors that do..
Peter, All, On 2015-08-26 22:24 +0200, Peter Korsgaard spake thusly: > >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes: > > Yes, it's a pity we can't get the Qt non-free packages. But especially > > with Qt, they are such a critical piece of a project that I would not > > want we tell users hat we have such support in Buildroot. That would > > just be blatantly lying. > > > OTOH, *one* way to which I *may* agree is to add something like > > > In Build options ---> Advanced ---> > > > config UNSUPORTED_NON_PUBLIC_PACKAGES > > bool "Show unsupported non-public packages" > > help > > Some packages do not have publicly accessible source > > code, either require registration, manual download... > > > Buildroot has recipes for building those packages, but > > given that their sources ar enot freely available, there > > is not guarantee they do work as expected, not even build > > at all. > > > Use at your own risk. Do not report problems to the > > Buildroot developpers. Sending patches to fix them might > > be accepted. > > Another alternative is that somebody maintains a set of BR2_EXTERNAL > packages for this kind of stuff. I'm not sure what the best solution is, > perhaps this is something to discuss during the dev days? Yes, that would be an option. We could provide those extra packages as a br2-external tree. But then, given the current state of br2-external, if a user wants to use those packages, he can no longer provide his own br2-external tree. Or he'd have to manage his customisations in branches in that tree, which gets him back to square one, that is, not being able to manage location customisations (local configs, local packages...) in a completely separate tree. *But* there is hope! I do have a series that adds support for using multiple br2-external trees at once. And your proposal above is just one more excuse for me to push for that series to be applied! My evil plan is coming to fruition! :-] Muhahaha! https://www.youtube.com/watch?v=ulEAMKhemx8 /me is adding these to the topics for the next DevDays. Regards, Yann E. MORIN.
diff --git a/Config.in.legacy b/Config.in.legacy index 3b77b34..316ffd0 100644 --- a/Config.in.legacy +++ b/Config.in.legacy @@ -107,6 +107,9 @@ endif ############################################################################### comment "Legacy options removed in 2015.08" +config BR2_PACKAGE_WF111 + bool "wf111 package removed" + config BR2_PACKAGE_KODI_PVR_ADDONS bool "Kodi PVR addon was split" select BR2_LEGACY diff --git a/package/Config.in b/package/Config.in index c32c989..a37ab21 100644 --- a/package/Config.in +++ b/package/Config.in @@ -436,7 +436,6 @@ endif source "package/usbmount/Config.in" source "package/usbutils/Config.in" source "package/w_scan/Config.in" - source "package/wf111/Config.in" source "package/wipe/Config.in" source "package/xorriso/Config.in" endmenu diff --git a/package/wf111/Config.in b/package/wf111/Config.in deleted file mode 100644 index d2ba440..0000000 --- a/package/wf111/Config.in +++ /dev/null @@ -1,36 +0,0 @@ -config BR2_PACKAGE_WF111 - bool "wf111" - depends on BR2_LINUX_KERNEL - depends on BR2_ARM_CPU_ARMV5 || BR2_ARM_CPU_ARMV7A || BR2_i386 - # Binary tools are distributed alongside the driver, and are - # dynamically linked against the glibc. - depends on BR2_TOOLCHAIN_USES_GLIBC - help - BlueGiga WF111 WiFi driver and utilities. - - Warning: CONFIG_WIRELESS_EXT and CONFIG_WEXT_PRIV must be - selected in the Linux kernel configuration. These are blind - options (i.e. not selectable directly) so they cannot be - enabled by a change in linux/linux.mk. There are two choices - to enable these options: - - By making them non blind, with a "WF111 support" configuration - entry that selects them, for example. - - By enabling another random WiFi driver that select them. - - http://www.bluegiga.com/en-US/products/wifi-modules/wf111-wifi-module/ - -if BR2_PACKAGE_WF111 - -config BR2_PACKAGE_WF111_TARBALL_PATH - string "Local tarball location" - help - The WF111 tarball can be retrieved on the BlueGiga website - after registration. This option specifies the path where the - tarball is locally saved. - -endif - -comment "wf111 needs an (e)glibc toolchain" - depends on BR2_LINUX_KERNEL - depends on BR2_ARM_CPU_ARMV5 || BR2_ARM_CPU_ARMV7A || BR2_i386 - depends on !BR2_TOOLCHAIN_USES_GLIBC diff --git a/package/wf111/wf111.mk b/package/wf111/wf111.mk deleted file mode 100644 index 479d665..0000000 --- a/package/wf111/wf111.mk +++ /dev/null @@ -1,34 +0,0 @@ -################################################################################ -# -# wf111 -# -################################################################################ - -WF111_VERSION = 5.2.2 -WF111_SITE_METHOD = file -WF111_SITE = $(call qstrip,$(BR2_PACKAGE_WF111_TARBALL_PATH)) -WF111_DEPENDENCIES = linux - -ifeq ($(BR2_PACKAGE_WF111)$(call qstrip,$(BR2_PACKAGE_WF111_TARBALL_PATH)),y) -$(error No tarball location specified, check BR2_PACKAGE_WF111_TARBALL_PATH) -endif - -ifeq ($(BR2_ARM_CPU_ARMV7A),y) -WF111_SOURCE = wf111-linux-driver_5.2.2-r1_armv7-a.tar.gz -else ifeq ($(BR2_ARM_CPU_ARMV5),y) -WF111_SOURCE = wf111-linux-driver_5.2.2-r1_armv5t.tar.gz -else ifeq ($(BR2_i386),y) -WF111_SOURCE = wf111-linux-driver_5.2.2-r1_x86.tar.gz -endif - -define WF111_BUILD_CMDS - $(MAKE) -C $(@D) PWD=$(@D) \ - $(LINUX_MAKE_FLAGS) KDIR=$(LINUX_DIR) \ - install_static -endef - -define WF111_INSTALL_TARGET_CMDS - cp -dpfr $(@D)/output/* $(TARGET_DIR) -endef - -$(eval $(generic-package))
This package requires registration before it can be downloaded, which means downloads can not be automated. As far as I could see, that's the only package we have in that case. It installs a kernel module, but it is not possible to check whether it also builds it or just installs a blob. It seems however that there are source files in that module: http://lists.busybox.net/pipermail/buildroot/2015-February/119752.html But since we can't download without registration, it's impossible to check if using the kernel-module infra would work. We also have no license for it. This package does not belong to Buildroot. Remove it. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Peter Korsgaard <jacmet@uclibc.org> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Antoine Ténart <antoine.tenart@free-electrons.com> --- I'd be happy to withdraw that patch if the archive was publicly availble and could be downloaded without manual intervention (i.e. bypass registration with a direct link?). --- Config.in.legacy | 3 +++ package/Config.in | 1 - package/wf111/Config.in | 36 ------------------------------------ package/wf111/wf111.mk | 34 ---------------------------------- 4 files changed, 3 insertions(+), 71 deletions(-) delete mode 100644 package/wf111/Config.in delete mode 100644 package/wf111/wf111.mk