I went through Kiko's request:
- What kernel tree it was built from (A URL to the git tree) - What revision (A revision ID) - What patches were applied on top of it (A URL to the patchset, maybe?) - What kernel config was used to build it (A separate file in the hwpack directory?)
and the spdx spec:
http://spdx.org/system/files/spdx-draft20110516_0.pdf
And wrote this:
PackageName: linux-linaro-omap 2.6.38-1002.3 #https://launchpad.net/ubuntu/+source/linux-linaro-omap PackageDownloadLocation: https://launchpad.net/ubuntu/+archive/primary/+files/linux-linaro-omap_2.6.3... PackageChecksum: SHA1: cf0b587742611328f095da4b329e9fc7 # from https://launchpad.net/ubuntu/+source/linux-linaro-omap/2.6.38-1002.3 SourceInfo: uses Linux v2.6.38.1 SourceInfo: uses linaro-linux-2.6.38-upstream-29Mar2011 SourceInfo: uses (fill in patch1) SourceInfo: uses (fill in patch2) SourceInfo: uses (fill in patch3) SourceInfo: uses <text> CONFIG_ etc... </text>
FileName: file1 FileName: file2 FileName: file3 FileChecksum: SHA1: calculated
SPDXVersion: SPDX-1.0 Creator: Person: Zach Pfeffer (zach.pfeffer@linaro.org) Created: 2011-06-02T13:18:00Z PackageLicenseDeclared: GPL-2.0 PackageVerificationCode: (fill in SHA1 of all souyrce files) LicenseConcluded: GPL-2.0 LicenseInfoFromFiles: GPL-2.0 PackageCopyrightText: <text> Copyright 2008-2010 John Smith </text>
I think this generally adheres to the spec (I put all the licensing info below the packaging into and also used # comment)
I've added Kate to the thread to tell me I'm wrong... :)
I can't really express how important it is for Linaro to get its legal house in order now. With binary blobs and various components coming together, we can get in front of this issue instead of "creating our own thing." Right now things are in Beta so if we have feed back we should give it.
-Zach
On 1 June 2011 13:41, Christian Robottom Reis kiko@linaro.org wrote:
Hello there,
This week I initiated a confused conversation during the techleads call about having a way to describe what the hardware pack was built from. We had a couple of false starts but I think we agreeing that there needs to be some form of manifest that describes what the hardware pack contains.
I seem to be hung up on having a way of saying "this hardware pack's kernel was built from this git tree with this config", so I wanted to explore the use cases a bit more:
- My #1 use case is, once I've installed a hardware pack, running into a problem and then being able to verify whether it contains a certain patch or was built with a certain config option. I'd like to know that because it's the first thing the KWG and LT people ask me when I go to report the bug.
- I think there's also a use case of wanting to know how to get that hwpack rebuilt with slightly updated kernel code or configs. If it's much easier to just document how to build and replace a kernel for a running image, that may cater for most of that use case, the exception being weird bugs caused by our build process and/or toolchain.
- I wonder if there's a use case for understanding and/or replacing the other contents of the hardware pack. I normally think of the hardware pack as "a built kernel and not much else" XXX.
Zach suggested SPDX (as in spdx.org) as a solution to this problem; I'm not sure I understand enough about it (Loïc's provided a sample file at http://spdx.org/wiki/sample-partial-spdx-file-geronimo) but here's my strawman proposal of what data we should give people quick access to:
- What kernel tree it was built from (A URL to the git tree) - What revision (A revision ID) - What patches were applied on top of it (A URL to the patchset, maybe?) - What kernel config was used to build it (A separate file in the hwpack directory?)
How does that sound? Too simplistic?
Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev