On 7 June 2011 17:54, James Westby james.wes...@linaro.org wrote:
On Mon, 06 Jun 2011 20:29:38 -0500, Kate Stewart kate.stew...@canonical.com
wrote:
This is a format that can go outside the packages (as well as in), so
can be used without marshalling the entire Debian community to adopt it.
On Wed, Jun 8, 2011 at 12:45 AM, James Westby
james.wes...@canonical.com wrote:
On Tue, 7 Jun 2011 10:20:57 -0300, Christian Robottom Reis
k...@canonical.com wrote:
That's true, and I didn't finish my original sentence but I would have
pointed out that more complete hardware packs would
On Wed, Jun 01, 2011 at 04:13:40PM -0400, James Westby wrote:
Luckily I missed that call, I have no confusion and this sounds
perfectly sensible to me :-)
Though now I'm stuck with a confusing Subject line to compensate :-/
The config is available in /boot isn't it?
Good point.
As for
On Wed, Jun 01, 2011 at 10:33:27PM +0200, Zygmunt Krynicki wrote:
One of the things it does not capture currently is kernel
configuration. Assuming you can cat /proc/config it would be easy to
capture that as well but I would like to know what others think.
James has rightly pointed out that
On Wed, Jun 01, 2011 at 05:21:14PM -0400, James Westby wrote:
I don't think we should be looking to attribute the provenance of every
line of source that ends up in the hwpack in one report, we just need to
shorten the chain to find the information that you care about.
That is a very good
On Thu, Jun 02, 2011 at 08:48:31AM +0100, Andy Green wrote:
At least for the config,
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
Is this not used everywhere, and if not, why not?
--
Christian Robottom Reis | [+55 16] 3376 0125 | http://launchpad.net/~kiko
Canonical Ltd.| [+55
On 6 June 2011 13:40, James Westby james.wes...@canonical.com wrote:
Hi Zach,
In addition I realised that some of the information requested isn't
explicit in what you propose.
On Thu, 2 Jun 2011 16:59:46 -0500, Zach Pfeffer zach.pfef...@linaro.org
wrote:
I went through Kiko's request:
On Tue, Jun 07, 2011 at 09:59:32AM -0500, Zach Pfeffer wrote:
On 6 June 2011 13:40, James Westby james.wes...@canonical.com wrote:
Hi Zach,
In addition I realised that some of the information requested isn't
explicit in what you propose.
On Thu, 2 Jun 2011 16:59:46 -0500, Zach Pfeffer
On Tue, Jun 7, 2011 at 7:26 AM, Christian Robottom Reis k...@linaro.org wrote:
On Wed, Jun 01, 2011 at 10:33:27PM +0200, Zygmunt Krynicki wrote:
One of the things it does not capture currently is kernel
configuration. Assuming you can cat /proc/config it would be easy to
capture that as well
On Mon, 06 Jun 2011 20:29:38 -0500, Kate Stewart kate.stew...@canonical.com
wrote:
This is a format that can go outside the packages (as well as in), so
can be used without marshalling the entire Debian community to adopt it.
So, am not advocating it be pushed by Linaro engineering for
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,
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
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.
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
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
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:
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
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.
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
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
On 06/01/2011 10:21 PM, Somebody in the thread at some point said:
Another cheap thing to do would be to dump the config from the kernel
package in to the output dir, so you can see the config without having
to download the hwpack or produce an image. This can be useful, much
like the new
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
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
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
On 1 June 2011 11:41, Christian Robottom Reis k...@linaro.org wrote:
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
On Wed, Jun 01, 2011 at 12:51:12PM -0700, Deepak Saxena wrote:
All official Linaro builds are generated from a single git tree that
has branches for different kernel versions that we build from being
automatically updated during the build process. The git rev is
embedded in the kernel package
On Wed, 1 Jun 2011 15:41:05 -0300, Christian Robottom Reis k...@linaro.org
wrote:
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
On 1 June 2011 12:58, Christian Robottom Reis k...@linaro.org wrote:
On Wed, Jun 01, 2011 at 12:51:12PM -0700, Deepak Saxena wrote:
All official Linaro builds are generated from a single git tree that
has branches for different kernel versions that we build from being
automatically updated
Speaking about Ubuntu packaged kernels only...
Everything that goes into the source package is in git.
Every release has a signed tag.
Ubuntu kernel package names have a strict naming convention that makes
upgrading and abi checking work right, so from my perspective putting
the tag name
29 matches
Mail list logo
