Re: The linaro-2.6.39 kernel / Panda
On 06/04/2011 02:17 PM, Somebody in the thread at some point said: Hi - When booted on a Beagleboard-xM, the resulting kernel appears to hang after Starting kernel I haven't investigated any further. Panda chokes the same way with previously OK omap4_defconfig. Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.39-panda_reb39+ (agr...@otae.warmcat.com) (gcc version 4.5.1 20101112 (Red Hat 4.5.1-5) (GCC) ) #6 SMP PREEMPT Mon Jun 6 09:04:39 BST 2011 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c5387f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] Reserving 33554432 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES2.1 [0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 [0.00] powerdomain: waited too long for powerdomain dss_pwrdm to complete transition [0.00] PERCPU: Embedded 8 pages/cpu @c10ea000 s9728 r8192 d14848 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 109410 [0.00] Kernel command line: console=tty0 console=ttyO2,115200n8 earlycon=ttyO2,115200n8 earlyprintk=1 root=UUID=3f5789f6-fdb2-43cb-abe8-5e064f387200 rootwait ro fixrtc nocompcache vram=32M omapfb.vram=0:24M mem=463M ip=none omapfb.debug=1 [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 430MB 1MB = 431MB total [0.00] Memory: 419652k/419652k available, 54460k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xdd00 - 0xf800 ( 432 MB) [0.00] lowmem : 0xc000 - 0xdcf0 ( 463 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .init : 0xc0008000 - 0xc005 ( 288 kB) [0.00] .text : 0xc005 - 0xc0757cd4 (7200 kB) [0.00] .data : 0xc0758000 - 0xc07dff68 ( 544 kB) [0.00] Preemptable hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] Verbose stalled-CPUs detection is disabled. [0.00] NR_IRQS:410 [0.00] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] Console: colour dummy device 80x30 [0.00] console [tty0] enabled [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.002380] Calibrating delay loop... 2007.19 BogoMIPS (lpj=7839744) [0.062591] pid_max: default: 32768 minimum: 301 [0.063201] Security Framework initialized [0.063568] Mount-cache hash table entries: 512 [0.067138] CPU: Testing write buffer coherency: ok [0.067962] Calibrating local timer... 491.91MHz. [0.109649] L310 cache controller enabled [0.109710] l2x0: 16 ways, CACHE_ID 0x41c4, AUX_CTRL 0x7e47, Cache size: 1048576 B [0.186370] CPU1: Booted secondary processor [0.186401] CPU1: Unknown IPI message 0x1 [0.216491] Brought up 2 CPUs [0.216522] SMP: Total of 2 processors activated (3963.96 BogoMIPS). [0.217681] devtmpfs: initialized [0.224029] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for emif_fw [0.224060] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l3_instr [0.224090] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l3_main_1 [0.224121] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l3_main_2 [0.224151] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_abe [0.224182] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_cfg [0.224212] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_per [0.224212] omap_hwmod: _populate_mpu_rt_base found no _mpu_rt_va for l4_wkup [0.224243] omap_hwmod: _populate_mpu_rt_base found
Re: Issues with repo --mirror
Hello Nicolas, On Thu, 2 Jun 2011 23:04:42 +0200 Dechesne, Nicolas n-deche...@ti.com wrote: Paul On Thu, Jun 2, 2011 at 9:24 AM, Paul Sokolovsky paul.sokolov...@linaro.orgwrote: This is even more interesting, with Google people confirming that repo --mirror works within some bounds and limitations: http://groups.google.com/group/repo-discuss/browse_thread/thread/401656c3ad0a4a0c [] I have spent some time in the past with repo --mirror (we have internal mirrors within TI). After several attempts my conclusion was that it was not the best approach. the main problem is that repo --mirror expects that you give a manifest tree. If you have several branches in your manifest tree (like it's the case for the omapmanifest on git.omapzoom.org), repo sync will only sync the branch you've used initially. So if you have new or different trees on other branches they aren't sync'd. that pretty much means that you need 1 mirror for each manifest branch. (in fact I am the one that asked the repo --mirror question you've found!) But, as far as I understood from the mailing list thread above, it's possible for one mirror to contain different manifest branches, one just need to sync them explicitly (unlike one would think mirror would do). (That's what we do now, I just want to be sure we won't any additional surprises soon.) so i ended it doing a git mirror, and I wrote this simple helper script https://github.com/ndechesne/git-mirror which can be used to mirror a complete 'git server' using gitweb. for example, you just need to add this in a cron: git-mirror -o /data/git/repositories/ -s http://git.omapzoom.org -g git:// git.omapzoom.org Thanks, this looks interesting. and the script will mirror the server locally. everytime it runs: - it creates new trees that have appeared on the remote - updates all existing trees - removed trees that have disappeared from the remote. i have been using this script on several mirror (1 at every site) quite reliably for ~2 years. prior to that I was using repo sync and frequently had failures... Nice, thanks much for sharing the experience! We'd probably still want to use manifest as the source for what to mirror (that's the only thing that our mirror service takes as input actually), but it's great to know that using git clone --mirror works well with repo and actually improves reliability. hope this helps. -- Best regards, Paul ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v5] sdio: optimized SDIO IRQ handling for single irq
On Wed, May 11, 2011 at 6:45 PM, Chris Ball c...@laptop.org wrote:
Hi Per,
On Wed, May 11 2011, Per Forlin wrote:
From: Stefan Nilsson XK stefan.xk.nils...@stericsson.com
If there is only 1 function interrupt registered it is possible to
improve performance by directly calling the irq handler
and avoiding the overhead of reading the CCCR registers.
Signed-off-by: Per Forlin per.for...@linaro.org
Acked-by: Ulf Hansson ulf.hans...@stericsson.com
Reviewed-by: Nicolas Pitre nicolas.pi...@linaro.org
---
drivers/mmc/core/sdio_irq.c | 33 -
include/linux/mmc/card.h | 1 +
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index bb192f9..a0890ac 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -31,6 +31,17 @@ static int process_sdio_pending_irqs(struct mmc_card
*card)
{
int i, ret, count;
unsigned char pending;
+ struct sdio_func *func;
+
+ /*
+ * Optimization, if there is only 1 function interrupt registered
+ * call irq handler directly
+ */
+ func = card-sdio_single_irq;
+ if (func) {
+ func-irq_handler(func);
+ return 1;
+ }
ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, pending);
if (ret) {
@@ -42,7 +53,7 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
count = 0;
for (i = 1; i = 7; i++) {
if (pending (1 i)) {
- struct sdio_func *func = card-sdio_func[i - 1];
+ func = card-sdio_func[i - 1];
if (!func) {
printk(KERN_WARNING %s: pending IRQ for
non-existant function\n,
@@ -186,6 +197,24 @@ static int sdio_card_irq_put(struct mmc_card *card)
return 0;
}
+/* If there is only 1 function registered set sdio_single_irq */
+static void sdio_single_irq_set(struct mmc_card *card)
+{
+ struct sdio_func *func;
+ int i;
+
+ card-sdio_single_irq = NULL;
+ if ((card-host-caps MMC_CAP_SDIO_IRQ)
+ card-host-sdio_irqs == 1)
+ for (i = 0; i card-sdio_funcs; i++) {
+ func = card-sdio_func[i];
+ if (func func-irq_handler) {
+ card-sdio_single_irq = func;
+ break;
+ }
+ }
+}
+
/**
* sdio_claim_irq - claim the IRQ for a SDIO function
* @func: SDIO function
@@ -227,6 +256,7 @@ int sdio_claim_irq(struct sdio_func *func,
sdio_irq_handler_t *handler)
ret = sdio_card_irq_get(func-card);
if (ret)
func-irq_handler = NULL;
+ sdio_single_irq_set(func-card);
return ret;
}
@@ -251,6 +281,7 @@ int sdio_release_irq(struct sdio_func *func)
if (func-irq_handler) {
func-irq_handler = NULL;
sdio_card_irq_put(func-card);
+ sdio_single_irq_set(func-card);
}
ret = mmc_io_rw_direct(func-card, 0, 0, SDIO_CCCR_IENx, 0, reg);
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index d8dffc9..4910dec 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -191,6 +191,7 @@ struct mmc_card {
struct sdio_cccr cccr; /* common card info */
struct sdio_cis cis; /* common tuple info */
struct sdio_func *sdio_func[SDIO_MAX_FUNCS]; /* SDIO functions
(devices) */
+ struct sdio_func *sdio_single_irq; /* SDIO function when only
one IRQ active */
unsigned num_info; /* number of info strings */
const char **info; /* info strings */
struct sdio_func_tuple *tuples; /* unknown common tuples */
Thanks, looks good now -- pushed to mmc-next for .40.
This patch breaks libertas over SDIO, as the interrupt handler of that
driver is now called even though the hardware didn't signal any
interrupt condition. This is a problem for at least two reasons in
this case:
a) the libertas code is currently structured in a way that it calls
sdio_claim_irq() before everything is fully set up (which wasn't a
problem so far as the hardware has an own register to mask
interrupts). That results in a kernel Ooops as card-priv == NULL.
b) the libertas interrupt handler assumes that a received callback to
its interrupt handler signals activity per se
(card-priv-activty_detected = 1).
I have a patch ready for libertas that works around the first problem,
but I'm unsure if that's not fixing the wrong end. What the driver
really should do is poll the card's CCCR register to find out if there
was any interrupt at all and bail if that's not the case, but then
we're back to the implementation without this patch.
The other option is to revert the patch again.
Re: Android kernel git update frequency
Thanks for starting this topic Paul. As we role out Gerrit CI we'll need to host all the components of the Android build in Gerrit. Users will push their changes to Gerrit and the changes will automatically get tested and merged after review. It works pretty good once it all gets going. As for the upstream. We'll get the opportunity to work with the Gerrit folks to add an upstream path to the tool. I have a flow chart in a slide from the public plan review: https://wiki.linaro.org/Cycles//PublicPlanReview?action=AttachFiledo=viewtarget=Android_Dev_Platform_11.11_Public_Plan.pdf Slide: Linaro CI Loop -Zach On 16 May 2011 14:11, John Stultz john.stu...@linaro.org wrote: On Mon, 2011-05-16 at 20:23 +0300, Paul Sokolovsky wrote: I'm just trying to wrap my mind on how we'll bootstrap Continuous Integration in the next cycle, which is not far away. So, I just would like to make sure that all teams involved are on the same line to make CI work effectively, i.e. that kernel team is able to update Android kernel regularly, infrastructure team has build system which produces Android images reliably, and validation team has all hooks needed to start testing them as soon as they are built. So bootstrapping wise from the kernel's perspective, it seems like using the linaro-android-2.6.38 tree to start would be fine. As soon as Nico opens the 2.6.39 tree, I'll work to get a linaro-android-2.6.39 tree available, and you can update your fetching scripts to pull from the new branch. From that point, I think we just need to sort out the communication paths. I can try to update the linaro-android tree at a fairly regular pace (I'm thinking weekly?) with more frequent updates on demand, should something like a fix be needed from Nico's tree. If there is a more specific frequency you'd like to see, please let me know. For the last cycle I've been somewhat slow at times, as it wasn't always clear that my work (merging, resolving collisions, initial testing) was getting used. This was mostly just starting pains as the platform build process was being worked out. But it helps motivate me to update more regularly if I can get some feedback as to how the last update performed in testing. As updating a tree multiple times without anyone pulling makes it seem like unnecessary extra effort. So, I guess validation team would lead on CI start-up sequence, when they have all needed infrastructure and testsuites integrated. In particular, I'm waiting from them for details on how build notifications should be communicated to the LAVA system. Do keep me updated! thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On Thu, 2 Jun 2011 23:17:02 +0100, Ramana Radhakrishnan ramana.radhakrish...@linaro.org wrote: Sorry I'm getting into this conversation a bit late but is there also a need to figure out what toolchain was used to build this hwpack and the way in which the toolchain was configured (v7-a, neon, vfp , vfpv3-d16) and what version of the toolchain was used. If this information is already captured or there is an easy way of getting back to this. This is if you think there is a use-case of regenerating the hwpack to investigate any issues that might come up While this would be a useful thing to record it's not that easy given that the toolchain used is a couple of steps removed from the hwpack. It currently works like Source package - Binary package - Hardware pack with the toolchain being used in the first translation. We would need to record the toolchain used in the binary packages to provide this information. There's currently no mechanism to do this generally, but again if we are modifying the packaging of each piece to do this they could run something to discover the toolchain information and store this in a similar way to git-describe output used to identify the ref that was built. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Sat, Jun 4, 2011 at 2:17 PM, Tixy t...@yxit.co.uk wrote: On Thu, 2011-06-02 at 01:12 -0400, Nicolas Pitre wrote: Time to leave 2.6.38 behind and move on! We now have a 2.6.39 based Linaro kernel which can be viewed here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=summary or cloned from either of those: git://git.linaro.org/kernel/linux-linaro-2.6.39.git http://git.linaro.org/git/kernel/linux-linaro-2.6.39.git When building for OMAP there's a build error in smc91x.c which is fixed by http://permalink.gmane.org/gmane.linux.network/197474 There are also build errors to do with DSS (mentioned elsewhere in this thread). A kernel can be successfully built after disabling the following config option: Device Drivers -- Graphics support -- OMAP2+ Display Subsystem support -- DPI support When booted on a Beagleboard-xM, the resulting kernel appears to hang after Starting kernel I haven't investigated any further. The .config I'm using is that described on the wiki at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources Try disabling CONFIG_THUMB2_KERNEL and rebuilding. If this does fix the problem, this suggests that this problem is indeed Thumb-2 related. I will have a go at digging into this tomorrow. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
Hi, Apologies for asking you directly what could probably be looked up, but the spec isn't very easy to digest. On Thu, 2 Jun 2011 16:59:46 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: 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.38.orig.tar.gz This isn't the full source that was built. The source package has three parts. Can we link to three things here? If we can only link to one it should probably be the .dsc which is the description for the whole thing. 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) What's the constraints on what we put here? What's the use for it? What's listed here seems fairly tricky to produce automatically. FileName: file1 FileName: file2 FileName: file3 FileChecksum: SHA1: calculated This is all the files in the source? Creator: Person: Zach Pfeffer (zach.pfef...@linaro.org) What option do we have here? Given this is going to be produced automatically I'm not sure we should blame you for all of the mistakes ;-) PackageLicenseDeclared: GPL-2.0 Is this is single choice field? Does it cover source or binary? PackageVerificationCode: (fill in SHA1 of all souyrce files) SHA1 of all source calculated how? LicenseConcluded: GPL-2.0 LicenseInfoFromFiles: GPL-2.0 What do these mean? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On 6 June 2011 16:30, James Westby james.wes...@canonical.com wrote: We should put this info somewhere else (use Vcs-* perhaps?) so that we can provide this information for other packages too. You can add additional user-defined fields to the control file if it's required or more convenient. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On Fri, Jun 3, 2011 at 12:17 AM, Ramana Radhakrishnan ramana.radhakrish...@linaro.org wrote: On 01/06/11 19:41, Christian Robottom Reis 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. Sorry I'm getting into this conversation a bit late but is there also a need to figure out what toolchain was used to build this hwpack and the way in which the toolchain was configured (v7-a, neon, vfp , vfpv3-d16) and what version of the toolchain was used. If this information is already captured or there is an easy way of getting back to this. This is if you think there is a use-case of regenerating the hwpack to investigate any issues that might come up Is there a gcc fingerprints in binaries that we could use to extract the toolchain info? Otherwise, we probably would have to fiddle this out of the build logs and so on and it feels like quite a challenge to get this right. e.g. some packages work around toolchain bugs by compiling objects, so's and binaries with non-default compiler flags etc. so even if we try to track this manually, everything short of having that info directly in the binaries would yield to inaccurate info is my guess. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On Mon, 6 Jun 2011 16:45:35 +, Fathi Boudra fathi.bou...@linaro.org wrote: On 6 June 2011 16:30, James Westby james.wes...@canonical.com wrote: We should put this info somewhere else (use Vcs-* perhaps?) so that we can provide this information for other packages too. You can add additional user-defined fields to the control file if it's required or more convenient. I'm well aware of that, thanks. However, automatic insertion of generated new fields is not that easy, and can cause problems when interacting with e.g. version control. In addition the information is used in a variety of places, and if the rules for how to specify where the information end up don't work for you use case you are forced to push the information in to places it doesn't really belong, at best causing bloat. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On 6 June 2011 11:45, James Westby james.wes...@canonical.com wrote:
Hi,
Apologies for asking you directly what could probably be looked up, but
the spec isn't very easy to digest.
On Thu, 2 Jun 2011 16:59:46 -0500, Zach Pfeffer zach.pfef...@linaro.org
wrote:
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.38.orig.tar.gz
This isn't the full source that was built. The source package has three
parts. Can we link to three things here? If we can only link to one it
should probably be the .dsc which is the description for the whole
thing.
For reference:
http://www.spdx.org/system/files/spdx-draft20110516_0.pdf
Right now the spec has this as:
4.3.3Cardinality: Mandatory, one.
Kate would have to comment if this could change to:
4.3.3Cardinality: Mandatory, one or more.
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)
What's the constraints on what we put here? What's the use for it?
The spec says:
4.6Source Information
4.6.1Purpose: This is a free form text field that contains additional
comments about the origin of the package. For instance, this field
might include comments indicating whether the package been pulled from
a source code management system or has been repackaged.
4.6.2Intent: Here, by providing a freeform field, reviewers can
provide any additional information to describe any anomalies, or
discoveries, in the determination of the origin of the package.
4.6.3Cardinality: Optional, one
4.6.4Data Format: single line of free form text
4.6.5Tag: SourceInfo
Example:
SourceInfo: uses glibc-2_11-branch from git://sourceware.org/git/glibc.git.
What's listed here seems fairly tricky to produce automatically.
What part do you think would be tricky?
FileName: file1
FileName: file2
FileName: file3
FileChecksum: SHA1: calculated
This is all the files in the source?
Yeah.
Creator: Person: Zach Pfeffer (zach.pfef...@linaro.org)
What option do we have here? Given this is going to be produced
automatically I'm not sure we should blame you for all of the mistakes
Ha! This is just the Creator of the SPDX file. It will probably become
the PoC. Kate is there a specific field for, ask this person questions
about the package? Perhaps we need
SpdxCreator: Person: Zach Pfeffer (zach.pfef...@linaro.org)
PackageCreator: Person: Not Zach Pfeffer :)
;-)
PackageLicenseDeclared: GPL-2.0
Is this is single choice field? Does it cover source or binary?
You link all the licenses together with ANDs and ORs. Looks like it
covers both, Kate?
PackageVerificationCode: (fill in SHA1 of all souyrce files)
SHA1 of all source calculated how?
4.5.4Algorithm:
verificationcode = 0
filelist = “”
for all files in package {
if file is an “excludes” file, skip it /* exclude SPDX analysis file itself */
appended filelist with “SHA1(file) || string(file)”
}
sort filelist in ascending order by SHA1 value
verificationcode = SHA1(filelist)
LicenseConcluded: GPL-2.0
From the spec:
The licensing that the preparer of this SPDX document has concluded,
based on the evidence, actual applies to the package.
I think this is where the lawyer would say, this is the license.
LicenseInfoFromFiles: GPL-2.0
This is a field that has all the license found in the package.
What do these mean?
Thanks,
James
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On 06/06/2011 05:44 PM, Somebody in the thread at some point said: The .config I'm using is that described on the wiki at https://wiki.linaro.org/Resources/HowTo/KernelDeploy#From_Linaro_sources Try disabling CONFIG_THUMB2_KERNEL and rebuilding. If this does fix the problem, this suggests that this problem is indeed Thumb-2 related. I will have a go at digging into this tomorrow. FWIW in my tree's reference omap4_defconfig, CONFIG_THUMB2_KERNEL is disabled (this kernel just stops at the end of initrd scripts, although twice thisafternoon during dozens of boots I saw it continue as if nothing was wrong and complete a normal boot, whatever that means). On omap2plus_defconfig, CONFIG_THUMB2_KERNEL doesn't appear in the config because CPU_V6 is set. And that's the guy who blows SIGILL. -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On Mon, 6 Jun 2011 14:37:18 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: The spec says: 4.6Source Information 4.6.1Purpose: This is a free form text field that contains additional comments about the origin of the package. For instance, this field might include comments indicating whether the package been pulled from a source code management system or has been repackaged. 4.6.2Intent: Here, by providing a freeform field, reviewers can provide any additional information to describe any anomalies, or discoveries, in the determination of the origin of the package. 4.6.3Cardinality: Optional, one 4.6.4Data Format: single line of free form text 4.6.5Tag: SourceInfo Example: SourceInfo: uses glibc-2_11-branch from git://sourceware.org/git/glibc.git. So it looks like we'd have to define our own microformat here (though it's going to be consumed by humans at least to start with, so consistency doesn't really matter at this stage) What's listed here seems fairly tricky to produce automatically. What part do you think would be tricky? It depends when we are generating this file, but the format of what you specify seems a little clever for humans. If the content is freeform then we can obviously choose something that is easy to generate. FileName: file1 FileName: file2 FileName: file3 FileChecksum: SHA1: calculated This is all the files in the source? Yeah. I guess the cost of that in a kernel build is pretty small. You only list one FileChecksum here. Can that line follow every FileName line? LicenseConcluded: GPL-2.0 From the spec: The licensing that the preparer of this SPDX document has concluded, based on the evidence, actual applies to the package. I think this is where the lawyer would say, this is the license. Yeah. Again my question is source or binary? I presume this can be an AND/OR list again? LicenseInfoFromFiles: GPL-2.0 This is a field that has all the license found in the package. Just a dumping ground of every license found? My overally impression is that this is rather a large additional overhead to just be able to say the kernel was built from 0A2E345 of git://git.linaro.org/jcrigby/linux-linaro-natty.git which is the main thrust of kiko's request as I understand it. Debian packages already contain licensing info (they also have a proposed standard to make that info machine readable.) Is it worth Linaro's time to try and move everything to one of these new formats at this stage? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 2 cross-development toochain quesions
On Sat, Jun 4, 2011 at 3:02 AM, Bernard Ogden bernard.og...@arm.com wrote: I was asked to take a look at the blueprints relating to cross-toolchain development (e.g. https://blueprints.launchpad.net/ubuntu/+spec/linaro-platforms-o-linaro-cross-toolchain-stories) in advance of Monday's 'Android and Developer Platform' plan review call. I just have two questions to ask for now: 1) I would like confirmation that the Windows binaries will be 'windows native' and standalone i.e. customer does not need to install MSYS/cygwin/etc. I got the impression that this is the intention, but am not 100% clear that it's a requirement. The build will be Windows native and self contained. Cygwin will not be used and any mingw support libraries will be minimal and shipped with the binary. The goal is to have something that is usable from a NT CMD prompt, cygwin prompt, and Eclipse. 2) Will Linaro test the toolchains on Red Hat Enterprise? RHEL 5 is one the supported platforms for DS-5, so it would be useful to know if the toolchain will be validated on that platform, or if we need to test ourselves. Not at the moment but we might slip it in to meet the requirement of working on the top four development Linuxes. As Marcin says, we'd test under CentOS instead of Redhat. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On Mon, 2011-06-06 at 16:37 -0400, James Westby wrote: On Mon, 6 Jun 2011 14:37:18 -0500, Zach Pfeffer zach.pfef...@linaro.org wrote: The spec says: 4.6Source Information 4.6.1Purpose: This is a free form text field that contains additional comments about the origin of the package. For instance, this field might include comments indicating whether the package been pulled from a source code management system or has been repackaged. 4.6.2Intent: Here, by providing a freeform field, reviewers can provide any additional information to describe any anomalies, or discoveries, in the determination of the origin of the package. 4.6.3Cardinality: Optional, one 4.6.4Data Format: single line of free form text 4.6.5Tag: SourceInfo Example: SourceInfo: uses glibc-2_11-branch from git://sourceware.org/git/glibc.git. So it looks like we'd have to define our own microformat here (though it's going to be consumed by humans at least to start with, so consistency doesn't really matter at this stage) If there are some pretty common trends, we can look at adding fields to support. Its in beta right now so this sort of feedback can be gathered after all ;) What's listed here seems fairly tricky to produce automatically. What part do you think would be tricky? It depends when we are generating this file, but the format of what you specify seems a little clever for humans. If the content is freeform then we can obviously choose something that is easy to generate. FileName: file1 FileName: file2 FileName: file3 FileChecksum: SHA1: calculated This is all the files in the source? Yeah. I guess the cost of that in a kernel build is pretty small. You only list one FileChecksum here. Can that line follow every FileName line? After every FileName: there should be a FileChecksum: field. For each file listed in the package, the fields that are mandatory and should show up are: - FileName: - FileChecksum: - LicenseConcluded: - LicensesInfoInFile: - CopyrightText: The rest are optional, and can be included or not. LicenseConcluded: GPL-2.0 From the spec: The licensing that the preparer of this SPDX document has concluded, based on the evidence, actual applies to the package. I think this is where the lawyer would say, this is the license. Yeah. Again my question is source or binary? This is captured as an optional field (FileType:) at the file level. I presume this can be an AND/OR list again? LicenseInfoFromFiles: GPL-2.0 This is a field that has all the license found in the package. Just a dumping ground of every license found? If a package has multiple file, its a way of having a summary of all the licenses encountered in those files. Ideally the LicenseConcluded: at the package level, will match the LicenseInfoFromFiles:. By making this visible, its hoped over time that the package owners will look into clearing up the ambiguities. My overally impression is that this is rather a large additional overhead to just be able to say the kernel was built from 0A2E345 of git://git.linaro.org/jcrigby/linux-linaro-natty.git which is the main thrust of kiko's request as I understand it. If you just want to say the build origins, then yes its overkill for that. If you want to be able to pass on a package that has a set of patches off a known public kernel (with its own SPDX file ;) ) then it permits the licensing and copyrights to be clearly articulated. Debian packages already contain licensing info (they also have a proposed standard to make that info machine readable.) Is it worth Linaro's time to try and move everything to one of these new formats at this stage? Debian package standard has no way to track the accuracy of the file level information, so it could change underneath without there being a way of detecting it - which causes problems. If you look at: http://dep.debian.net/deps/dep5/ (machine readable info), you'll see this aspect missing (the wildcards preclude it). The DEP5 proposal was analyzed extensively last year but commercial companies didn't feel they could rely on the accuracy information provided through it, but there is a lot of common ground on the fields provided, file paragraphs, separate licensing section, etc. We've had a team of volunteer corporate lawyers (Motorola, HP, etc. ) working on the SPDX for the last year and reviewing and modifying the proposed fields extensively. Kate ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
Hi Kate, Thanks for the information. I have some responses inline. To be clear I'm veering in to commentary on the format itself for a lot of this, rather than specific statements on whether I think Linaro should use it or not. On Mon, 06 Jun 2011 18:05:54 -0500, Kate Stewart kate.stew...@canonical.com wrote: If there are some pretty common trends, we can look at adding fields to support. Its in beta right now so this sort of feedback can be gathered after all ;) That's good to know. After every FileName: there should be a FileChecksum: field. For each file listed in the package, the fields that are mandatory and should show up are: - FileName: - FileChecksum: - LicenseConcluded: - LicensesInfoInFile: - CopyrightText: The rest are optional, and can be included or not. You say for each file listed in the package, is it mandatory to list all files? It seems to me that it would be much better to allow for gradual implementation of what will be a large job for some projects, so I hope it is optional. I guess it's intended for the format to always be output from some tool rather than hand-edited, unless it's possible to put glob patterns or similar in the FileName field? LicenseConcluded: GPL-2.0 From the spec: The licensing that the preparer of this SPDX document has concluded, based on the evidence, actual applies to the package. I think this is where the lawyer would say, this is the license. Yeah. Again my question is source or binary? This is captured as an optional field (FileType:) at the file level. Well, this applies to the whole package by my understanding, so the particular file types may not matter. Take for instance a package which is dual licensed GPL-2 and something else at the source level. If you choose to build this package and link it against GPL-2 only code then some people's interpretation of the GPL would say that the binary is GPL-2 only, despite the source being dual licensed. Perhaps that's a minority opinion, but I expect there are other cases where the source and binary licenses may not match, so I am wondering if the expectation that this defines the source or binary concluded license. Perhaps what you are saying is that there will be different SPDX files for the source and binary, and the difference would be captured there? My overally impression is that this is rather a large additional overhead to just be able to say the kernel was built from 0A2E345 of git://git.linaro.org/jcrigby/linux-linaro-natty.git which is the main thrust of kiko's request as I understand it. If you just want to say the build origins, then yes its overkill for that. If you want to be able to pass on a package that has a set of patches off a known public kernel (with its own SPDX file ;) ) then it permits the licensing and copyrights to be clearly articulated. Yeah. Is the kernel going to be released with an SPDX file that we can base our work on? Debian package standard has no way to track the accuracy of the file level information, so it could change underneath without there being a way of detecting it - which causes problems. If you look at: http://dep.debian.net/deps/dep5/ (machine readable info), you'll see this aspect missing (the wildcards preclude it). The DEP5 proposal was analyzed extensively last year but commercial companies didn't feel they could rely on the accuracy information provided through it, but there is a lot of common ground on the fields provided, file paragraphs, separate licensing section, etc. We've had a team of volunteer corporate lawyers (Motorola, HP, etc. ) working on the SPDX for the last year and reviewing and modifying the proposed fields extensively. Sure, I don't doubt that a lot of effort has been put in to SPDX, and I don't want to get in to a debate about whether it is a good idea to have wildcards or not. My point was more that I don't see it being worth Linaro engineering time to push for adoption of either format inside Debian packages at this time. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What do we want our hwpack sources
On Mon, 2011-06-06 at 20:19 -0400, James Westby wrote: On Mon, 06 Jun 2011 18:05:54 -0500, Kate Stewart kate.stew...@canonical.com wrote: After every FileName: there should be a FileChecksum: field. For each file listed in the package, the fields that are mandatory and should show up are: - FileName: - FileChecksum: - LicenseConcluded: - LicensesInfoInFile: - CopyrightText: The rest are optional, and can be included or not. You say for each file listed in the package, is it mandatory to list all files? It seems to me that it would be much better to allow for gradual implementation of what will be a large job for some projects, so I hope it is optional. Afraid not. Each file gets in a package/tarball/what ever you choose to group together, gets its own file name listed. Package could be interpreted as tarball equally well as a .deb. So, yeah, its a large job for some projects. Problem is that right now alot of folks are doing the work in multiple formats already, as a necessary condition of license compliance for shipping code. So, some of the original files may not be produced by the project itself, but rather by some 3rd party, that then can be 'reviewed' and signed off by others. Yes, tools will help. I'd like to get some open source tools available to do the generation, and am working with Ninka and FOSSology on some prototypes. (help is always welcome ;) ). There are some commercial tool providers who have built up plans to produce the RDF varient of files already with their tools - BlackDuck, Open Logic, Protecode are all active participants. Tag value and the RDF have been designed to be interchangeable for this reason. I guess it's intended for the format to always be output from some tool rather than hand-edited, unless it's possible to put glob patterns or similar in the FileName field? For small projects or even single binary files that get packaged, it should be possible to hand generate. For larger packages with multiple source files, yeah, tools are going to be the key here. See comments above. ;) LicenseConcluded: GPL-2.0 From the spec: The licensing that the preparer of this SPDX document has concluded, based on the evidence, actual applies to the package. I think this is where the lawyer would say, this is the license. Yeah. Again my question is source or binary? This is captured as an optional field (FileType:) at the file level. Well, this applies to the whole package by my understanding, so the particular file types may not matter. Actually if you're shipping a binary file as its own package, like the linux kernel, then its just a package with one file, there's just one file, and the FileType: applies. If you're shipping a source tar ball with 30K+ files, in it, then the Type doesn't make much sense at the Package level, since there could be multiple types involved. There are firmware binaries in the linux kernel sources, for instance. ;) Take for instance a package which is dual licensed GPL-2 and something else at the source level. If you choose to build this package and link it against GPL-2 only code then some people's interpretation of the GPL would say that the binary is GPL-2 only, despite the source being dual licensed. This is the sort of argument that lead us down the notion of ConcludedLicense vs. LicenseInfoInFile (at the file and package levels). Perhaps that's a minority opinion, but I expect there are other cases where the source and binary licenses may not match, so I am wondering if the expectation that this defines the source or binary concluded license. Yup, its not just source and binary though that cause conflicts. BTW. Perhaps what you are saying is that there will be different SPDX files for the source and binary, and the difference would be captured there? We're still figuring out all the use cases, but I would expect the source to be packaged separately from the binary (thinking about how the archive work, this seems to be the case in practice), and there would be different SPDX files as a result. My overally impression is that this is rather a large additional overhead to just be able to say the kernel was built from 0A2E345 of git://git.linaro.org/jcrigby/linux-linaro-natty.git which is the main thrust of kiko's request as I understand it. If you just want to say the build origins, then yes its overkill for that. If you want to be able to pass on a package that has a set of patches off a known public kernel (with its own SPDX file ;) ) then it permits the licensing and copyrights to be clearly articulated. Yeah. Is the kernel going to be released with an SPDX file that we can base our work on? That's been the request from others as well. Am working with Ninka/FOSSology to see if we can make it happen in an Open Source way, and then it will be a packaging
Re: current status -- releases^H recipes needed
W dniu 07.06.2011 02:16, Zygmunt Krynicki pisze: I think at this point we should do some releases. If you agree Zygmunt, can you do that? (a) because it's nearly the end of my work day and (b) you're more experienced at it :) I guess this means uploading to pypi and building in a ppa? Do you upload releases to lp too? I'll release everything after I get myself together (staying up past 3AM again). Did this happen yet? It doesn't look like it. No :/ I got stuck making the process easier. I'll post details soon. I got unstuck but more work is required. I wrote something that assists ISV developers (like us) to develop, release and publish for multiple ubuntu versions efficiently. You can find the early version (in shell, yuck) at: lp:~zkrynicki/+junk/lava-project-ci. Have a look at the README file and at the recipes. Before you can start using this tool please build each pbuilder with lava-project-ci create $distro (for distro: lucid, maverick, natty). After that you can build the 'versiontools' package and see the recipes for more hints. I started porting all our packages over. I'll finish this tomorrow and finalize the release. HELP wanted here! Please port django (look at my code branches to lookup the relevant django backport) to speed up the process. Best regards ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
