* [Buildroot] [PATCH] intel-microcode: new package @ 2012-09-20 15:12 Richard Braun 2012-09-20 20:36 ` Thomas Petazzoni 0 siblings, 1 reply; 21+ messages in thread From: Richard Braun @ 2012-09-20 15:12 UTC (permalink / raw) To: buildroot Signed-off-by: Richard Braun <rbraun@sceen.net> --- package/Config.in | 1 + package/intel-microcode/Config.in | 7 +++++++ package/intel-microcode/intel-microcode.mk | 22 ++++++++++++++++++++++ 3 files changed, 30 insertions(+), 0 deletions(-) create mode 100644 package/intel-microcode/Config.in create mode 100644 package/intel-microcode/intel-microcode.mk diff --git a/package/Config.in b/package/Config.in index 58dd5e8..e8a3f50 100644 --- a/package/Config.in +++ b/package/Config.in @@ -212,6 +212,7 @@ source "package/hwdata/Config.in" source "package/i2c-tools/Config.in" source "package/input-event-daemon/Config.in" source "package/input-tools/Config.in" +source "package/intel-microcode/Config.in" source "package/iostat/Config.in" source "package/irda-utils/Config.in" source "package/kbd/Config.in" diff --git a/package/intel-microcode/Config.in b/package/intel-microcode/Config.in new file mode 100644 index 0000000..495ebd7 --- /dev/null +++ b/package/intel-microcode/Config.in @@ -0,0 +1,7 @@ +config BR2_PACKAGE_INTEL_MICROCODE + bool "intel-microcode" + depends on BR2_x86_64 || BR2_i386 + help + This package provides an Intel microcode data file that can be + used to correct processor errors. The iucode-tool package and + proper kernel support are required to upload the microcode. diff --git a/package/intel-microcode/intel-microcode.mk b/package/intel-microcode/intel-microcode.mk new file mode 100644 index 0000000..5f60272 --- /dev/null +++ b/package/intel-microcode/intel-microcode.mk @@ -0,0 +1,22 @@ +############################################################# +# +# intel-microcode +# +############################################################# + +INTEL_MICROCODE_VERSION = 20120606 +INTEL_MICROCODE_SOURCE = microcode-$(INTEL_MICROCODE_VERSION).tgz +INTEL_MICROCODE_SITE = http://downloadmirror.intel.com/21385/eng +INTEL_MICROCODE_LICENSE = PROPRIETARY + +# N.B. Don't strip any path components during extraction. +define INTEL_MICROCODE_EXTRACT_CMDS + gzip -d -c $(DL_DIR)/$(INTEL_MICROCODE_SOURCE) | tar --strip-components=0 -C $(INTEL_MICROCODE_DIR) -xf - +endef + +define INTEL_MICROCODE_INSTALL_TARGET_CMDS + $(INSTALL) -D -m 0644 $(@D)/microcode.dat \ + $(TARGET_DIR)/usr/share/misc/intel-microcode.dat +endef + +$(eval $(generic-package)) -- 1.7.2.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] intel-microcode: new package 2012-09-20 15:12 [Buildroot] [PATCH] intel-microcode: new package Richard Braun @ 2012-09-20 20:36 ` Thomas Petazzoni 2012-09-20 21:12 ` Richard Braun 0 siblings, 1 reply; 21+ messages in thread From: Thomas Petazzoni @ 2012-09-20 20:36 UTC (permalink / raw) To: buildroot Dear Richard Braun, On Thu, 20 Sep 2012 17:12:29 +0200, Richard Braun wrote: > +INTEL_MICROCODE_VERSION = 20120606 > +INTEL_MICROCODE_SOURCE = microcode-$(INTEL_MICROCODE_VERSION).tgz > +INTEL_MICROCODE_SITE = http://downloadmirror.intel.com/21385/eng > +INTEL_MICROCODE_LICENSE = PROPRIETARY Is there a license file somewhere that states that even though it is proprietary, one has the right to redistribute the binaries? > +# N.B. Don't strip any path components during extraction. > +define INTEL_MICROCODE_EXTRACT_CMDS > + gzip -d -c $(DL_DIR)/$(INTEL_MICROCODE_SOURCE) | tar --strip-components=0 -C $(INTEL_MICROCODE_DIR) -xf - You can use $(@D) instead of $(INTEL_MICROCODE_DIR) here. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] intel-microcode: new package 2012-09-20 20:36 ` Thomas Petazzoni @ 2012-09-20 21:12 ` Richard Braun 2012-09-21 8:35 ` Thomas Petazzoni 0 siblings, 1 reply; 21+ messages in thread From: Richard Braun @ 2012-09-20 21:12 UTC (permalink / raw) To: buildroot On Thu, Sep 20, 2012 at 10:36:46PM +0200, Thomas Petazzoni wrote: > Is there a license file somewhere that states that even though it is > proprietary, one has the right to redistribute the binaries? On the Intel download site, after searching for the last version of the microcode data file [1], the download link leads to a license agreement page which describes three license terms, depending on the nature of the distributor (network administrator, end user or OEM). I think the OEM license applies to most buildroot users. Here is the content : "OEM LICENSE: You may reproduce and distribute the Software only as an integral part of or incorporated in Your product or as a standalone Software maintenance update for existing end users of Your products, excluding any other standalone products, subject to these conditions: 1. This Software is licensed for use only in conjunction with Intel component products. Use of the Software in conjunction with non-Intel component products is not licensed hereunder. 2. You may not copy, modify, rent, sell, distribute or transfer any part of the Software except as provided in this Agreement, and you agree to prevent unauthorized copying of the Software. 3. You may not reverse engineer, decompile, or disassemble the Software. 4. You may only distribute the Software to your customers pursuant to a written license agreement. Such license agreement may be a "break-the- seal" license agreement. At a minimum such license shall safeguard Intel's ownership rights to the Software. 5. The Software may include portions offered on terms in addition to those set out here, as set out in a license accompanying those portions." -- Richard Braun [1] http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21385&keyword=microcode&lang=eng ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] intel-microcode: new package 2012-09-20 21:12 ` Richard Braun @ 2012-09-21 8:35 ` Thomas Petazzoni 2012-09-22 9:42 ` Richard Braun 0 siblings, 1 reply; 21+ messages in thread From: Thomas Petazzoni @ 2012-09-21 8:35 UTC (permalink / raw) To: buildroot Dear Richard Braun, On Thu, 20 Sep 2012 23:12:55 +0200, Richard Braun wrote: > On the Intel download site, after searching for the last version of the > microcode data file [1], the download link leads to a license agreement > page which describes three license terms, depending on the nature of the > distributor (network administrator, end user or OEM). I think the OEM > license applies to most buildroot users. Here is the content : Ok. Thanks. And there is no zip file or tarball that contains both the license and the firmware? I'm simply worried about having just FOO_LICENSE = PROPRIETARY without a proper license file that indicates what license it is. Or maybe we need to put a special license file in package/intel-microcode/ and find a way to tell the license infrastructure that the license file is here rather than in the package itself? Cc'ing Luca on this. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] intel-microcode: new package 2012-09-21 8:35 ` Thomas Petazzoni @ 2012-09-22 9:42 ` Richard Braun 2012-09-28 12:17 ` Richard Braun 0 siblings, 1 reply; 21+ messages in thread From: Richard Braun @ 2012-09-22 9:42 UTC (permalink / raw) To: buildroot On Fri, Sep 21, 2012 at 10:35:13AM +0200, Thomas Petazzoni wrote: > Ok. Thanks. And there is no zip file or tarball that contains both > the license and the firmware? I'm simply worried about having just > FOO_LICENSE = PROPRIETARY without a proper license file that indicates > what license it is. Or maybe we need to put a special license file in > package/intel-microcode/ and find a way to tell the license > infrastructure that the license file is here rather than in the package > itself? Unfortunately no, the microcode file is the only one. -- Richard Braun ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] intel-microcode: new package 2012-09-22 9:42 ` Richard Braun @ 2012-09-28 12:17 ` Richard Braun 2012-09-28 12:20 ` [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages Richard Braun 2012-09-28 12:20 ` [Buildroot] [PATCH] intel-microcode: new package Richard Braun 0 siblings, 2 replies; 21+ messages in thread From: Richard Braun @ 2012-09-28 12:17 UTC (permalink / raw) To: buildroot On Sat, Sep 22, 2012 at 11:42:03AM +0200, Richard Braun wrote: > Unfortunately no, the microcode file is the only one. While it's the only file, the license is actually embedded inside, in plain text. I've modified the package to extract the license as a separate file in the build directory. The package infrastructure also had to be slightly change to save legal info for proprietary packages. Patches will follow. -- Richard Braun ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-09-28 12:17 ` Richard Braun @ 2012-09-28 12:20 ` Richard Braun 2012-09-28 12:23 ` Thomas Petazzoni 2012-09-28 12:20 ` [Buildroot] [PATCH] intel-microcode: new package Richard Braun 1 sibling, 1 reply; 21+ messages in thread From: Richard Braun @ 2012-09-28 12:20 UTC (permalink / raw) To: buildroot Signed-off-by: Richard Braun <rbraun@sceen.net> --- package/pkg-generic.mk | 6 +----- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk index ffe7dfb..1bfaed2 100644 --- a/package/pkg-generic.mk +++ b/package/pkg-generic.mk @@ -444,7 +444,6 @@ $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2) endif # legal-info: declare dependencies and set values used later for the manifest -ifneq ($$($(2)_LICENSE),PROPRIETARY) ifneq ($$($(2)_SITE_METHOD),local) ifneq ($$($(2)_SITE_METHOD),override) # Packages that have a tarball need it downloaded and extracted beforehand @@ -455,7 +454,6 @@ $(2)_MANIFEST_LICENSE_FILES = $$($(2)_LICENSE_FILES) endif endif endif -endif # defaults for packages without tarball or license files $(2)_MANIFEST_TARBALL ?= not saved $(2)_MANIFEST_LICENSE_FILES ?= not saved @@ -464,9 +462,7 @@ $(2)_MANIFEST_LICENSE_FILES ?= not saved $(1)-legal-info: # Packages without a source are assumed to be part of Buildroot, skip them. ifneq ($(call qstrip,$$($(2)_SOURCE)),) -ifeq ($$($(2)_LICENSE),PROPRIETARY) -# Proprietary packages: nothing to save -else ifeq ($$($(2)_SITE_METHOD),local) +ifeq ($$($(2)_SITE_METHOD),local) # Packages without a tarball: don't save and warn @$(call legal-warning-pkg-savednothing,$$($(2)_RAWNAME),local) else ifeq ($$($(2)_SITE_METHOD),override) -- 1.7.2.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-09-28 12:20 ` [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages Richard Braun @ 2012-09-28 12:23 ` Thomas Petazzoni 2012-09-28 16:40 ` Thomas De Schampheleire 0 siblings, 1 reply; 21+ messages in thread From: Thomas Petazzoni @ 2012-09-28 12:23 UTC (permalink / raw) To: buildroot Dear Richard Braun, This will need a review and ACK from Luca, Cc'ing him. Thomas On Fri, 28 Sep 2012 14:20:01 +0200, Richard Braun wrote: > > Signed-off-by: Richard Braun <rbraun@sceen.net> > --- > package/pkg-generic.mk | 6 +----- > 1 files changed, 1 insertions(+), 5 deletions(-) > > diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk > index ffe7dfb..1bfaed2 100644 > --- a/package/pkg-generic.mk > +++ b/package/pkg-generic.mk > @@ -444,7 +444,6 @@ $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2) > endif > > # legal-info: declare dependencies and set values used later for the manifest > -ifneq ($$($(2)_LICENSE),PROPRIETARY) > ifneq ($$($(2)_SITE_METHOD),local) > ifneq ($$($(2)_SITE_METHOD),override) > # Packages that have a tarball need it downloaded and extracted beforehand > @@ -455,7 +454,6 @@ $(2)_MANIFEST_LICENSE_FILES = $$($(2)_LICENSE_FILES) > endif > endif > endif > -endif > # defaults for packages without tarball or license files > $(2)_MANIFEST_TARBALL ?= not saved > $(2)_MANIFEST_LICENSE_FILES ?= not saved > @@ -464,9 +462,7 @@ $(2)_MANIFEST_LICENSE_FILES ?= not saved > $(1)-legal-info: > # Packages without a source are assumed to be part of Buildroot, skip them. > ifneq ($(call qstrip,$$($(2)_SOURCE)),) > -ifeq ($$($(2)_LICENSE),PROPRIETARY) > -# Proprietary packages: nothing to save > -else ifeq ($$($(2)_SITE_METHOD),local) > +ifeq ($$($(2)_SITE_METHOD),local) > # Packages without a tarball: don't save and warn > @$(call legal-warning-pkg-savednothing,$$($(2)_RAWNAME),local) > else ifeq ($$($(2)_SITE_METHOD),override) -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-09-28 12:23 ` Thomas Petazzoni @ 2012-09-28 16:40 ` Thomas De Schampheleire 2012-09-28 17:05 ` Thomas Petazzoni 0 siblings, 1 reply; 21+ messages in thread From: Thomas De Schampheleire @ 2012-09-28 16:40 UTC (permalink / raw) To: buildroot Op 28 sep. 2012 14:23 schreef "Thomas Petazzoni" < thomas.petazzoni@free-electrons.com> het volgende: > > Dear Richard Braun, > > This will need a review and ACK from Luca, Cc'ing him. Additionally, it would be nice to get some context. Why do you need this? What its the use case? The proprietary packages are not in the current legal info, precisely because you wouldn't distribute them. If you have a package that you distribute under a non open-source license, I think it makes more sense to provide a real name to the license. Best regards, Thomas > > On Fri, 28 Sep 2012 14:20:01 +0200, Richard Braun wrote: > > > > Signed-off-by: Richard Braun <rbraun@sceen.net> > > --- > > package/pkg-generic.mk | 6 +----- > > 1 files changed, 1 insertions(+), 5 deletions(-) > > > > diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk > > index ffe7dfb..1bfaed2 100644 > > --- a/package/pkg-generic.mk > > +++ b/package/pkg-generic.mk > > @@ -444,7 +444,6 @@ $(2)_KCONFIG_VAR = BR2_PACKAGE_$(2) > > endif > > > > # legal-info: declare dependencies and set values used later for the manifest > > -ifneq ($$($(2)_LICENSE),PROPRIETARY) > > ifneq ($$($(2)_SITE_METHOD),local) > > ifneq ($$($(2)_SITE_METHOD),override) > > # Packages that have a tarball need it downloaded and extracted beforehand > > @@ -455,7 +454,6 @@ $(2)_MANIFEST_LICENSE_FILES = $$($(2)_LICENSE_FILES) > > endif > > endif > > endif > > -endif > > # defaults for packages without tarball or license files > > $(2)_MANIFEST_TARBALL ?= not saved > > $(2)_MANIFEST_LICENSE_FILES ?= not saved > > @@ -464,9 +462,7 @@ $(2)_MANIFEST_LICENSE_FILES ?= not saved > > $(1)-legal-info: > > # Packages without a source are assumed to be part of Buildroot, skip them. > > ifneq ($(call qstrip,$$($(2)_SOURCE)),) > > -ifeq ($$($(2)_LICENSE),PROPRIETARY) > > -# Proprietary packages: nothing to save > > -else ifeq ($$($(2)_SITE_METHOD),local) > > +ifeq ($$($(2)_SITE_METHOD),local) > > # Packages without a tarball: don't save and warn > > @$(call legal-warning-pkg-savednothing,$$($(2)_RAWNAME),local) > > else ifeq ($$($(2)_SITE_METHOD),override) > > > > -- > Thomas Petazzoni, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120928/986bfe2c/attachment.html> ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-09-28 16:40 ` Thomas De Schampheleire @ 2012-09-28 17:05 ` Thomas Petazzoni 2012-09-28 18:52 ` Thomas De Schampheleire 0 siblings, 1 reply; 21+ messages in thread From: Thomas Petazzoni @ 2012-09-28 17:05 UTC (permalink / raw) To: buildroot Thomas, On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: > Additionally, it would be nice to get some context. Why do you need this? > What its the use case? > > The proprietary packages are not in the current legal info, precisely > because you wouldn't distribute them. > If you have a package that you distribute under a non open-source license, > I think it makes more sense to provide a real name to the license. There are things like firmware, or DSP blobs or other stuff that are just provided in binary form, but their license allows free redistribution. Should we mark those as PROPRIETARY, or should we have a different license name for those? Basically, the context is the intel-microcode package, which bundles a binary-only firmware for some Intel hardware. Which license informations should we attach to it? Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-09-28 17:05 ` Thomas Petazzoni @ 2012-09-28 18:52 ` Thomas De Schampheleire 2012-09-30 14:22 ` Arnout Vandecappelle 0 siblings, 1 reply; 21+ messages in thread From: Thomas De Schampheleire @ 2012-09-28 18:52 UTC (permalink / raw) To: buildroot Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" < thomas.petazzoni@free-electrons.com> het volgende: > > Thomas, > > On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: > > > Additionally, it would be nice to get some context. Why do you need this? > > What its the use case? > > > > The proprietary packages are not in the current legal info, precisely > > because you wouldn't distribute them. > > If you have a package that you distribute under a non open-source license, > > I think it makes more sense to provide a real name to the license. > > There are things like firmware, or DSP blobs or other stuff that are > just provided in binary form, but their license allows free > redistribution. Should we mark those as PROPRIETARY, or should we have > a different license name for those? > > Basically, the context is the intel-microcode package, which bundles a > binary-only firmware for some Intel hardware. Which license > informations should we attach to it? I think we need a specific category for those packages that are not intended for distribution. That is, when you generate the legal info, these packages are not included. Next to that, I can understand that there is another category of 'packages' that may be proprietary, but are intended for redistribution. I think we should keep this separate. Now, whether we use the name 'proprietary' for the first or second category is an open question. I'm not familiar with the microcode example that you give. I assume that they have some kind of legal text associated with them? Can we really assume that two such proprietary packages from different vendors have the exact same redistribution conditions? My gut says no, in which case there'd be a separate term for each variant. In Gentoo Linux there it's such a mechanism. In order to install a given package, you have to agree to the specific license, e.g. an Adobe Flash one. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120928/db04dfca/attachment.html> ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-09-28 18:52 ` Thomas De Schampheleire @ 2012-09-30 14:22 ` Arnout Vandecappelle 2012-10-02 13:41 ` Luca Ceresoli 0 siblings, 1 reply; 21+ messages in thread From: Arnout Vandecappelle @ 2012-09-30 14:22 UTC (permalink / raw) To: buildroot On 28/09/12 20:52, Thomas De Schampheleire wrote: > > Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com > <mailto:thomas.petazzoni@free-electrons.com>> het volgende: >> >> Thomas, >> >> On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: >> >> > Additionally, it would be nice to get some context. Why do you need this? >> > What its the use case? >> > >> > The proprietary packages are not in the current legal info, precisely >> > because you wouldn't distribute them. >> > If you have a package that you distribute under a non open-source license, >> > I think it makes more sense to provide a real name to the license. >> >> There are things like firmware, or DSP blobs or other stuff that are >> just provided in binary form, but their license allows free >> redistribution. Should we mark those as PROPRIETARY, or should we have >> a different license name for those? >> >> Basically, the context is the intel-microcode package, which bundles a >> binary-only firmware for some Intel hardware. Which license >> informations should we attach to it? > > I think we need a specific category for those packages that are not intended for distribution. That is, when you > generate the legal info, these packages are not included. > > Next to that, I can understand that there is another category of 'packages' that may be proprietary, but are intended > for redistribution. I think we should keep this separate. Agreed. > Now, whether we use the name 'proprietary' for the first or second category is an open question. The word "proprietary" implies that it's not for redistribution. [1] Something like 'Intel microcode license' would be appropriate however. Two packages should only use the same license name if they have the same terms of use and redistribution (although the exact wording or the exact conditions may be different, cfr. various BSD-3c versions or exceptions in GPLv2 licenses). If we want to make it explicit that this is not an open source package, we could make it 'Intel microcode license (non-free)'. Regards, Arnout [1] http://en.wiktionary.org/wiki/proprietary > I'm not familiar with the microcode example that you give. I assume that they have some kind of legal text associated > with them? Can we really assume that two such proprietary packages from different vendors have the exact same > redistribution conditions? My gut says no, in which case there'd be a separate term for each variant. In Gentoo Linux > there it's such a mechanism. In order to install a given package, you have to agree to the specific license, e.g. an > Adobe Flash one. -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-09-30 14:22 ` Arnout Vandecappelle @ 2012-10-02 13:41 ` Luca Ceresoli 2012-10-02 14:35 ` Arnout Vandecappelle ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Luca Ceresoli @ 2012-10-02 13:41 UTC (permalink / raw) To: buildroot Arnout Vandecappelle wrote: > On 28/09/12 20:52, Thomas De Schampheleire wrote: >> >> Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" >> <thomas.petazzoni@free-electrons.com >> <mailto:thomas.petazzoni@free-electrons.com>> het volgende: >>> >>> Thomas, >>> >>> On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: >>> >>> > Additionally, it would be nice to get some context. Why do you >>> need this? >>> > What its the use case? >>> > >>> > The proprietary packages are not in the current legal info, >>> precisely >>> > because you wouldn't distribute them. >>> > If you have a package that you distribute under a non open-source >>> license, >>> > I think it makes more sense to provide a real name to the license. >>> >>> There are things like firmware, or DSP blobs or other stuff that are >>> just provided in binary form, but their license allows free >>> redistribution. Should we mark those as PROPRIETARY, or should we have >>> a different license name for those? >>> >>> Basically, the context is the intel-microcode package, which bundles a >>> binary-only firmware for some Intel hardware. Which license >>> informations should we attach to it? >> >> I think we need a specific category for those packages that are not >> intended for distribution. That is, when you >> generate the legal info, these packages are not included. >> >> Next to that, I can understand that there is another category of >> 'packages' that may be proprietary, but are intended >> for redistribution. I think we should keep this separate. > > Agreed. > >> Now, whether we use the name 'proprietary' for the first or second >> category is an open question. > > The word "proprietary" implies that it's not for redistribution. [1] > Something like 'Intel microcode license' would be appropriate however. > > Two packages should only use the same license name if they have the same > terms of use and redistribution (although the exact wording or the exact > conditions may be different, cfr. various BSD-3c versions or > exceptions in > GPLv2 licenses). > > If we want to make it explicit that this is not an open source > package, we > could make it 'Intel microcode license (non-free)'. The current legal-info implementation is based on the assumption that Buildroot is used to build the root fs for an embedded device, for which packages can be divided in two broad categories: * open-source packages that are publicly available, whose source code can or must be redistributed; * packages for which copying rights are reserved and the source is not available in the public; these packages are often developed by (or for) the device manufacturer and are kept proprietary as part of the device industrial secret. All packages in the second category a marked as _LICENSE = PROPRIETARY, which means a) that they're not freely licensed and b) that the tarball will not be saved by Buildroot. This clearly prevents to specify in better detail the license of these packages. This is a short path I took based on the above assumptions, but it is not correct is all cases. intel-microcode is clearly not fitting any of the two categories: we want to describe its license, but we are not allowed to redistribute it freely, as the license text reported from Richard seems to signify. A clean solution is probably to let the _LICENSE do its work, i.e. simply describe the license, and add a new _REDISTRUBUTE parameter (defaulting to YES), to specify if the tarball must be copied or not. Defining the license and choosing whether or not to redistribute would become technically independent, which is more correct. Examples: MYAPP_LICENSE = PROPRIETARY would become MYAPP_LICENSE = PROPRIETARY MYAPP_REDISTRIBUTE = NO or MYAPP_LICENSE = Copyright (C) 2012 My Company # just an idea MYAPP_REDISTRIBUTE = NO INTEL_MICROCODE_LICENSE = PROPRIETARY would become INTEL_MICROCODE_LICENSE = Intel microcode license INTEL_MICROCODE_REDISTRIBUTE = NO Of course this would make package files more verbose for non-redistributed packages, but they are a minor part so it is probably not a problem. What do people think about such a solution? Another solution would be to totally ignore the problem because it is affecting very few packages. But this would prevent Buildroot to provide intel-microcode in a "legally safe" way. Luca ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-10-02 13:41 ` Luca Ceresoli @ 2012-10-02 14:35 ` Arnout Vandecappelle 2012-10-02 17:50 ` Thomas De Schampheleire 2012-10-16 15:42 ` Richard Braun 2 siblings, 0 replies; 21+ messages in thread From: Arnout Vandecappelle @ 2012-10-02 14:35 UTC (permalink / raw) To: buildroot On 02/10/12 15:41, Luca Ceresoli wrote: > INTEL_MICROCODE_LICENSE = Intel microcode license > INTEL_MICROCODE_REDISTRIBUTE = NO > > Of course this would make package files more verbose for non-redistributed > packages, but they are a minor part so it is probably not a problem. I would say this is even desirable, so Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-10-02 13:41 ` Luca Ceresoli 2012-10-02 14:35 ` Arnout Vandecappelle @ 2012-10-02 17:50 ` Thomas De Schampheleire 2012-10-16 15:42 ` Richard Braun 2 siblings, 0 replies; 21+ messages in thread From: Thomas De Schampheleire @ 2012-10-02 17:50 UTC (permalink / raw) To: buildroot Hi Luca, all, On Tue, Oct 2, 2012 at 3:41 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote: > Arnout Vandecappelle wrote: >> >> On 28/09/12 20:52, Thomas De Schampheleire wrote: >>> >>> >>> Op 28 sep. 2012 19:05 schreef "Thomas Petazzoni" >>> <thomas.petazzoni@free-electrons.com >>> <mailto:thomas.petazzoni@free-electrons.com>> het volgende: >>>> >>>> >>>> Thomas, >>>> >>>> On Fri, 28 Sep 2012 18:40:04 +0200, Thomas De Schampheleire wrote: >>>> >>>> > Additionally, it would be nice to get some context. Why do you need >>>> this? >>>> > What its the use case? >>>> > >>>> > The proprietary packages are not in the current legal info, precisely >>>> > because you wouldn't distribute them. >>>> > If you have a package that you distribute under a non open-source >>>> license, >>>> > I think it makes more sense to provide a real name to the license. >>>> >>>> There are things like firmware, or DSP blobs or other stuff that are >>>> just provided in binary form, but their license allows free >>>> redistribution. Should we mark those as PROPRIETARY, or should we have >>>> a different license name for those? >>>> >>>> Basically, the context is the intel-microcode package, which bundles a >>>> binary-only firmware for some Intel hardware. Which license >>>> informations should we attach to it? >>> >>> >>> I think we need a specific category for those packages that are not >>> intended for distribution. That is, when you >>> generate the legal info, these packages are not included. >>> >>> Next to that, I can understand that there is another category of >>> 'packages' that may be proprietary, but are intended >>> for redistribution. I think we should keep this separate. >> >> >> Agreed. >> >>> Now, whether we use the name 'proprietary' for the first or second >>> category is an open question. >> >> >> The word "proprietary" implies that it's not for redistribution. [1] >> Something like 'Intel microcode license' would be appropriate however. >> >> Two packages should only use the same license name if they have the same >> terms of use and redistribution (although the exact wording or the exact >> conditions may be different, cfr. various BSD-3c versions or exceptions in >> GPLv2 licenses). >> >> If we want to make it explicit that this is not an open source package, >> we >> could make it 'Intel microcode license (non-free)'. > > > The current legal-info implementation is based on the assumption that > Buildroot > is used to build the root fs for an embedded device, for which packages can > be > divided in two broad categories: > * open-source packages that are publicly available, whose source code can > or > must be redistributed; > * packages for which copying rights are reserved and the source is not > available in the public; these packages are often developed by (or for) > the > device manufacturer and are kept proprietary as part of the device > industrial secret. > > All packages in the second category a marked as _LICENSE = PROPRIETARY, > which > means a) that they're not freely licensed and b) that the tarball will not > be > saved by Buildroot. This clearly prevents to specify in better detail the > license of these packages. > > This is a short path I took based on the above assumptions, but it is not > correct is all cases. > > intel-microcode is clearly not fitting any of the two categories: we want to > describe its license, but we are not allowed to redistribute it freely, as > the license text reported from Richard seems to signify. > > A clean solution is probably to let the _LICENSE do its work, i.e. simply > describe the license, and add a new _REDISTRUBUTE parameter (defaulting to > YES), to specify if the tarball must be copied or not. > Defining the license and choosing whether or not to redistribute would > become technically independent, which is more correct. > > Examples: > > MYAPP_LICENSE = PROPRIETARY > would become > MYAPP_LICENSE = PROPRIETARY > MYAPP_REDISTRIBUTE = NO > or > MYAPP_LICENSE = Copyright (C) 2012 My Company # just an idea > MYAPP_REDISTRIBUTE = NO > > INTEL_MICROCODE_LICENSE = PROPRIETARY > would become > INTEL_MICROCODE_LICENSE = Intel microcode license > INTEL_MICROCODE_REDISTRIBUTE = NO > Of course this would make package files more verbose for non-redistributed > packages, but they are a minor part so it is probably not a problem. > > What do people think about such a solution? I think it is a clean and suitable solution for this problem. > > Another solution would be to totally ignore the problem because it is > affecting very few packages. But this would prevent Buildroot to provide > intel-microcode in a "legally safe" way. > Best regards, Thomas ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-10-02 13:41 ` Luca Ceresoli 2012-10-02 14:35 ` Arnout Vandecappelle 2012-10-02 17:50 ` Thomas De Schampheleire @ 2012-10-16 15:42 ` Richard Braun 2012-10-20 20:51 ` Luca Ceresoli 2 siblings, 1 reply; 21+ messages in thread From: Richard Braun @ 2012-10-16 15:42 UTC (permalink / raw) To: buildroot On Tue, Oct 02, 2012 at 03:41:38PM +0200, Luca Ceresoli wrote: > intel-microcode is clearly not fitting any of the two categories: we want to > describe its license, but we are not allowed to redistribute it freely, as > the license text reported from Richard seems to signify. Actually, there is a license text embedded in the microcode file. It reads : Redistribution. Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met: .Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution. .Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission. .No reverse engineering, decompilation, or disassembly of this software is permitted. ."Binary form" includes any format commonly used for electronic conveyance which is a reversible, bit-exact translation of binary representation to ASCII or ISO text, for example, "uuencode." The disclaimer is a common 'this software is distributed "as is"' notice. I'm not exactly sure what "redistribute it freely" means here, since I'm much more used to free licenses, but it seems to me that redistribution is actually allowed as buildroot isn't in any way violating any of these conditions, as long as this text appears in the list of licenses, which my patch takes care of. Do you agree with that, and if yes, how would that change the rework proposal ? -- Richard Braun ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-10-16 15:42 ` Richard Braun @ 2012-10-20 20:51 ` Luca Ceresoli 2012-10-20 21:55 ` Richard Braun 0 siblings, 1 reply; 21+ messages in thread From: Luca Ceresoli @ 2012-10-20 20:51 UTC (permalink / raw) To: buildroot Richard Braun wrote: > On Tue, Oct 02, 2012 at 03:41:38PM +0200, Luca Ceresoli wrote: >> intel-microcode is clearly not fitting any of the two categories: we want to >> describe its license, but we are not allowed to redistribute it freely, as >> the license text reported from Richard seems to signify. > Actually, there is a license text embedded in the microcode file. It > reads : > > Redistribution. Redistribution and use in binary form, without modification, are > permitted provided that the following conditions are met: > .Redistributions must reproduce the above copyright notice and the following > disclaimer in the documentation and/or other materials provided with the > distribution. > .Neither the name of Intel Corporation nor the names of its suppliers may be used > to endorse or promote products derived from this software without specific prior > written permission. > .No reverse engineering, decompilation, or disassembly of this software is > permitted. > ."Binary form" includes any format commonly used for electronic conveyance > which is a reversible, bit-exact translation of binary representation to ASCII or > ISO text, for example, "uuencode." This in confusing. In your previous e-mail dated Sep 20you quoted the "Intel Software License Agreement", that one is supposed to accept before downloading the package from the web page: > "OEM LICENSE: You may reproduce and distribute the Software only as an > integral part of or incorporated in Your product or as a standalone > Software maintenance update for existing end users of Your products, > excluding any other standalone products, (http://downloadcenter.intel.com/confirm.aspx?httpDown=http://downloadmirror.intel.com/21385/eng/microcode-20120606.tgz&lang=eng&Dwnldid=21385&keyword=microcode) This means we cannot redistribute the code, except as part of a product. OTOH in the downloaded file, that one may simply download at http://downloadmirror.intel.com/21385/eng/microcode-20120606.tgz without accepting any agreement, contains the (different) license that you're quoting right now, which would permit redistribution. I used to think big companies can afford good lawyers, but this does not seem to be happening at Intel. > The disclaimer is a common 'this software is distributed "as is"' > notice. > > > I'm not exactly sure what "redistribute it freely" means here, since I'm > much more used to free licenses, but it seems to me that redistribution > is actually allowed as buildroot isn't in any way violating any of these > conditions, as long as this text appears in the list of licenses, which > my patch takes care of. > > Do you agree with that, and if yes, how would that change the rework > proposal ? I agree with your interpretation of the license in the .dat file, although this does not clarify whether the applicable text is the Agreement on the web page or this one license. In both cases I don't think my proposal needs to be changed. The principle is still true: one package may be redistributable or not. If it is not, one may still want to describe its license in the _LICENSE variable with a more descriptive text than "PROPRIETARY". What hurts me a little is that, if intel-microcode turns out to be redistributable, we would have no use case in mainline Buildroot that makes use of such a feature to the legal-info code. But I would go on and implement it anyway, since it could be useful to other Buildroot users and not hurt the other ones. Luca ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages 2012-10-20 20:51 ` Luca Ceresoli @ 2012-10-20 21:55 ` Richard Braun 0 siblings, 0 replies; 21+ messages in thread From: Richard Braun @ 2012-10-20 21:55 UTC (permalink / raw) To: buildroot On Sat, Oct 20, 2012 at 10:51:00PM +0200, Luca Ceresoli wrote: > This in confusing. In your previous e-mail dated Sep 20you quoted the > "Intel Software License Agreement", that one is supposed to accept before > downloading the package from the web page: Confusing indeed. > What hurts me a little is that, if intel-microcode turns out to be > redistributable, we would have no use case in mainline Buildroot that > makes use of such a feature to the legal-info code. That's what troubles me as well. I don't want to introduce dead code. But if you do it as you seem to have planned, then I won't worry about it and just wait for the feature. I'll try to get some clarification from Intel in the meanwhile. Thanks for your answer. -- Richard Braun ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] intel-microcode: new package 2012-09-28 12:17 ` Richard Braun 2012-09-28 12:20 ` [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages Richard Braun @ 2012-09-28 12:20 ` Richard Braun 2012-09-28 12:24 ` Thomas Petazzoni 2012-09-29 9:31 ` Thomas De Schampheleire 1 sibling, 2 replies; 21+ messages in thread From: Richard Braun @ 2012-09-28 12:20 UTC (permalink / raw) To: buildroot Signed-off-by: Richard Braun <rbraun@sceen.net> --- package/Config.in | 1 + package/intel-microcode/Config.in | 7 +++++++ package/intel-microcode/intel-microcode.mk | 24 ++++++++++++++++++++++++ 3 files changed, 32 insertions(+), 0 deletions(-) create mode 100644 package/intel-microcode/Config.in create mode 100644 package/intel-microcode/intel-microcode.mk diff --git a/package/Config.in b/package/Config.in index 58dd5e8..e8a3f50 100644 --- a/package/Config.in +++ b/package/Config.in @@ -212,6 +212,7 @@ source "package/hwdata/Config.in" source "package/i2c-tools/Config.in" source "package/input-event-daemon/Config.in" source "package/input-tools/Config.in" +source "package/intel-microcode/Config.in" source "package/iostat/Config.in" source "package/irda-utils/Config.in" source "package/kbd/Config.in" diff --git a/package/intel-microcode/Config.in b/package/intel-microcode/Config.in new file mode 100644 index 0000000..495ebd7 --- /dev/null +++ b/package/intel-microcode/Config.in @@ -0,0 +1,7 @@ +config BR2_PACKAGE_INTEL_MICROCODE + bool "intel-microcode" + depends on BR2_x86_64 || BR2_i386 + help + This package provides an Intel microcode data file that can be + used to correct processor errors. The iucode-tool package and + proper kernel support are required to upload the microcode. diff --git a/package/intel-microcode/intel-microcode.mk b/package/intel-microcode/intel-microcode.mk new file mode 100644 index 0000000..16323e2 --- /dev/null +++ b/package/intel-microcode/intel-microcode.mk @@ -0,0 +1,24 @@ +############################################################# +# +# intel-microcode +# +############################################################# + +INTEL_MICROCODE_VERSION = 20120606 +INTEL_MICROCODE_SOURCE = microcode-$(INTEL_MICROCODE_VERSION).tgz +INTEL_MICROCODE_SITE = http://downloadmirror.intel.com/21385/eng +INTEL_MICROCODE_LICENSE = PROPRIETARY +INTEL_MICROCODE_LICENSE_FILES = license.txt + +# N.B. Don't strip any path components during extraction. +define INTEL_MICROCODE_EXTRACT_CMDS + gzip -d -c $(DL_DIR)/$(INTEL_MICROCODE_SOURCE) | tar --strip-components=0 -C $(@D) -xf - + head -n 33 $(@D)/microcode.dat > $(@D)/license.txt +endef + +define INTEL_MICROCODE_INSTALL_TARGET_CMDS + $(INSTALL) -D -m 0644 $(@D)/microcode.dat \ + $(TARGET_DIR)/usr/share/misc/intel-microcode.dat +endef + +$(eval $(generic-package)) -- 1.7.2.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] intel-microcode: new package 2012-09-28 12:20 ` [Buildroot] [PATCH] intel-microcode: new package Richard Braun @ 2012-09-28 12:24 ` Thomas Petazzoni 2012-09-29 9:31 ` Thomas De Schampheleire 1 sibling, 0 replies; 21+ messages in thread From: Thomas Petazzoni @ 2012-09-28 12:24 UTC (permalink / raw) To: buildroot Dear Richard Braun, On Fri, 28 Sep 2012 14:20:17 +0200, Richard Braun wrote: > > Signed-off-by: Richard Braun <rbraun@sceen.net> > --- > package/Config.in | 1 + > package/intel-microcode/Config.in | 7 +++++++ > package/intel-microcode/intel-microcode.mk | 24 ++++++++++++++++++++++++ > 3 files changed, 32 insertions(+), 0 deletions(-) > create mode 100644 package/intel-microcode/Config.in > create mode 100644 package/intel-microcode/intel-microcode.mk Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 21+ messages in thread
* [Buildroot] [PATCH] intel-microcode: new package 2012-09-28 12:20 ` [Buildroot] [PATCH] intel-microcode: new package Richard Braun 2012-09-28 12:24 ` Thomas Petazzoni @ 2012-09-29 9:31 ` Thomas De Schampheleire 1 sibling, 0 replies; 21+ messages in thread From: Thomas De Schampheleire @ 2012-09-29 9:31 UTC (permalink / raw) To: buildroot Hi, On Fri, Sep 28, 2012 at 2:20 PM, Richard Braun <rbraun@sceen.net> wrote: > > Signed-off-by: Richard Braun <rbraun@sceen.net> > --- > package/Config.in | 1 + > package/intel-microcode/Config.in | 7 +++++++ > package/intel-microcode/intel-microcode.mk | 24 ++++++++++++++++++++++++ > 3 files changed, 32 insertions(+), 0 deletions(-) > create mode 100644 package/intel-microcode/Config.in > create mode 100644 package/intel-microcode/intel-microcode.mk > > diff --git a/package/Config.in b/package/Config.in > index 58dd5e8..e8a3f50 100644 > --- a/package/Config.in > +++ b/package/Config.in > @@ -212,6 +212,7 @@ source "package/hwdata/Config.in" > source "package/i2c-tools/Config.in" > source "package/input-event-daemon/Config.in" > source "package/input-tools/Config.in" > +source "package/intel-microcode/Config.in" > source "package/iostat/Config.in" > source "package/irda-utils/Config.in" > source "package/kbd/Config.in" > diff --git a/package/intel-microcode/Config.in b/package/intel-microcode/Config.in > new file mode 100644 > index 0000000..495ebd7 > --- /dev/null > +++ b/package/intel-microcode/Config.in > @@ -0,0 +1,7 @@ > +config BR2_PACKAGE_INTEL_MICROCODE > + bool "intel-microcode" > + depends on BR2_x86_64 || BR2_i386 > + help > + This package provides an Intel microcode data file that can be > + used to correct processor errors. The iucode-tool package and > + proper kernel support are required to upload the microcode. > diff --git a/package/intel-microcode/intel-microcode.mk b/package/intel-microcode/intel-microcode.mk > new file mode 100644 > index 0000000..16323e2 > --- /dev/null > +++ b/package/intel-microcode/intel-microcode.mk > @@ -0,0 +1,24 @@ > +############################################################# > +# > +# intel-microcode > +# > +############################################################# > + > +INTEL_MICROCODE_VERSION = 20120606 > +INTEL_MICROCODE_SOURCE = microcode-$(INTEL_MICROCODE_VERSION).tgz > +INTEL_MICROCODE_SITE = http://downloadmirror.intel.com/21385/eng > +INTEL_MICROCODE_LICENSE = PROPRIETARY See the parallel discussion about this. I think we need to clear this out before accepting this patch. > +INTEL_MICROCODE_LICENSE_FILES = license.txt > + > +# N.B. Don't strip any path components during extraction. > +define INTEL_MICROCODE_EXTRACT_CMDS > + gzip -d -c $(DL_DIR)/$(INTEL_MICROCODE_SOURCE) | tar --strip-components=0 -C $(@D) -xf - I think this should be $(TAR) instead of plain tar. On some systems, $(TAR) may be a host-tar. > + head -n 33 $(@D)/microcode.dat > $(@D)/license.txt > +endef > + > +define INTEL_MICROCODE_INSTALL_TARGET_CMDS > + $(INSTALL) -D -m 0644 $(@D)/microcode.dat \ > + $(TARGET_DIR)/usr/share/misc/intel-microcode.dat > +endef > + > +$(eval $(generic-package)) > -- > 1.7.2.5 Best regards, Thomas ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2012-10-20 21:55 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-20 15:12 [Buildroot] [PATCH] intel-microcode: new package Richard Braun 2012-09-20 20:36 ` Thomas Petazzoni 2012-09-20 21:12 ` Richard Braun 2012-09-21 8:35 ` Thomas Petazzoni 2012-09-22 9:42 ` Richard Braun 2012-09-28 12:17 ` Richard Braun 2012-09-28 12:20 ` [Buildroot] [PATCH] pkg-infra: produce legal info for proprietary packages Richard Braun 2012-09-28 12:23 ` Thomas Petazzoni 2012-09-28 16:40 ` Thomas De Schampheleire 2012-09-28 17:05 ` Thomas Petazzoni 2012-09-28 18:52 ` Thomas De Schampheleire 2012-09-30 14:22 ` Arnout Vandecappelle 2012-10-02 13:41 ` Luca Ceresoli 2012-10-02 14:35 ` Arnout Vandecappelle 2012-10-02 17:50 ` Thomas De Schampheleire 2012-10-16 15:42 ` Richard Braun 2012-10-20 20:51 ` Luca Ceresoli 2012-10-20 21:55 ` Richard Braun 2012-09-28 12:20 ` [Buildroot] [PATCH] intel-microcode: new package Richard Braun 2012-09-28 12:24 ` Thomas Petazzoni 2012-09-29 9:31 ` Thomas De Schampheleire
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox