Re: Hardware pack questions

2010-08-23 Thread Alexander Sack 
On Mon, Aug 23, 2010 at 5:14 PM, James Westby james.wes...@linaro.orgwrote:

 On Mon, 23 Aug 2010 17:06:18 +0200, Alexander Sack a...@linaro.org
 wrote:
  in theory yes, but practically I don't expect this to become a major use
  case. If it's easier assuming that there is just one in the first phase,
  lets do that.

 The big problem I see is knowing which hwpacks should supercede all
 others. Doing it by name makes sense for upgrades, but there could be
 many that could install a kernel.


Yeah. hwpacks should have a unique id in their meta info. In that way you
can figure this.



 Maybe this doesn't actually matter, but my suspicion is that it will.

  this is scotts baby i think. personally i am fine without a hwpack.deb. I
  think the idea was that configs etc. like apt source lines accompanying
 the
  hwpack could be shipped in there. Personally I think its good enough to
  start with this meta info being optionally in the tarballs somewhere.

 I think that's fine. The spec is just confusing as it suddenly starts
 discussing it in the middle.


good. whatever is easiest.



  we dont want to have magic that pulls a new hwpack at this stage.
  hwpack-install is used to install and upgrade from a local/remote-url
 that
  points to the hwpack tarball.
 
  However, as (iirc) mentioned in the spec, a hardware pack optionally can
  also ship custom apt lines, so magic upgrades without a new hwpack
 tarball
  can happen for hwpacks that come with such a location (e.g. a ppa or a
  partner hosted apt repository etc.).

 That's upgrades of the packages, not upgrades of the hwpack.


 exactly.


5. What are the use cases for tags? I can only see X/no X in the spec.
  
 
  tags are low priority. It came up with an ability to not install parts of
  the pack (like no x drivers if you dont care about X in a headless
 install
  for instance.

 Ok, tags are deferred from the initial implementation. Once we have some
 experience using them we will be able to define the user interaction
 much better.


Thanks. Thats fine.




6. What are the use cases for support information?
  
  
  We want to label hwpacks as unsupported or community so we can offer
  them to download on snapshots.linaro.org while sending a clear message
 that
  those are not official linaro hardware packs because they don't come from
 a
  linaro consolidated kernel tree for instance.

 Does that information have to go inside the hwpack. What would display
 that information? What would behave differently?


The canonical meta info like this should go into the hwpack itself. On top
we would also want to have that in the hwpack filename, so its obvious
without introspection in the download.


-- 

 - Alexander
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Hardware pack questions

2010-08-23 Thread James Westby 
On Mon, 23 Aug 2010 19:52:47 +0200, Alexander Sack a...@linaro.org wrote:
 I thought a bit more about this and i think the single hwpacks policy makes
 the clean up part mentioned in last sentence of user story 2 easier to
 implement.

Right.

Maybe we want hardware pack types in the future, so that you can have 1
of the kernel type, one of the graphics type, etc.

This is where I see some blurring of the lines between a hwpack and the
packages that it contains though, so something feels wrong about that
strategy.

I will update the spec to indicate that only a single hwpack can be
installed at one time.

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Hardware pack questions

2010-08-23 Thread Alexander Sack 
On Mon, Aug 23, 2010 at 8:29 PM, James Westby james.wes...@linaro.orgwrote:

 On Mon, 23 Aug 2010 17:06:18 +0200, Alexander Sack a...@linaro.org
 wrote:
6. What are the use cases for support information?
  
  
  We want to label hwpacks as unsupported or community so we can offer
  them to download on snapshots.linaro.org while sending a clear message
 that
  those are not official linaro hardware packs because they don't come from
 a
  linaro consolidated kernel tree for instance.

 How is this different from the support status of the packages that the
 hardware pack installs? Should it be derived from that data.


Do we already have a linaro support status for packages implemented? or are
you refering to the ubuntu style main/universe/package-set support status
here?

-- 

 - Alexander
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Git repository shuffling on git.linaro.org

2010-08-23 Thread Nicolas Pitre 
As discussed between Loïc, John and I, some kernel repositoryes have 
been moved around on git.linaro.org to better reflect their usage, and 
to give them more official sounding names.

Unless people really complain, I don't think this is worth adding 
backward compatibility symlinks at this point, as this would only 
clutter the namespace for little gain.  It should be easy for people to 
simply edit their .git/config file within the clones of those 
repositories and adjust the affected URLs.

For example:

git.linaro.org/linux/arm_next.git

is now

git.linaro.org/kernel/linux-linaro-next.git

John Rigby's Ubuntu packaging of the above are now found at:

git://git.linaro.org/ubuntu/linux-linaro.git
git://git.linaro.org/ubuntu/linux-meta-linaro.git

I also created a people/ directory under which all personal trees can be 
accessed.  Hence I'd ask those of you (amitarora, amitk, arnd, jcrigby, 
lool) to remove those symlinks from Git's root repo directory at your 
earliest convenience.  Those personal repositories may now be accessed 
by adding people/ in front of the path component of the Git URL.


Nicolas___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Hardware pack questions

2010-08-23 Thread James Westby 
On Mon, 23 Aug 2010 20:31:37 +0200, Alexander Sack a...@linaro.org wrote:
 Do we already have a linaro support status for packages implemented? or are
 you refering to the ubuntu style main/universe/package-set support status
 here?

I'm asking both conceptually and concretely.

In theory, how does the support status differ from the support status of
the package? I assume that we wouldn't have a supported hardware pack
based on an unsupported kernel, but would we ever want to release an
unsupported hardware pack containing a supported kernel?

Concretely if we have rules then this could be based on the Supported
metadata in the package indices. This is probably not available in PPAs
etc., so may not work, but let's decide if it's even something we want
to do first.

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Announcing the Linaro 2.6.35 stable kernel

2010-08-23 Thread Nicolas Pitre 

There is now a stable 2.6.35-based Linaro kernel repository now 
available from:

git://git.linaro.org/kernel/linux-linaro-2.6.35.git
http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.35.git;a=summary

Unlike the linaro-next tree which will continue to evolve and be rebuilt 
with the merge of latest developments, the stable 2.6.35 repository 
won't be rebased and will only include bug fixes and material really 
considered stable and non intrusive from now on.

This linaro-2.6.35 tree is currently made of:

 - The official 2.6.35 kernel from Linus of course;

 - The latest Linaro merge tagged linaro_merge_100811 previously 
   announced here;

 - The upstream stable branch up to 2.6.35.3;

 - A fix for symbol offset breakage with separated debug in perf by
   Dave Martin;

 - The small change required to enable ASLR on PIE executable text 
   segments.

Please report any problem with this tree as always.


Nicolas

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Beta Freeze this Thursday

2010-08-23 Thread Jamie Bennett 
Hi,
 
The Linaro Beta Freeze comes into effect Thursday 26th August 2010, i.e. this 
Thusday!  [1]. After the 
deadline _all_ uploads to the main archive will have to be approved manually by 
the release team. For 
a further explanation of what the Beta Freeze entails and how to get your 
changes into the archive, 
please see the Linaro wiki [2][3].

Regards,
Jamie.
--
Linaro Release Manager

[1] http://wiki.linaro.org/Releases/1011#Linaro10.11Schedule
[2] http://wiki.linaro.org/Releases/BetaFreeze
[3] http://wiki.linaro.org/Releases/ReleaseStages
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Common data for uImage generation

2010-08-23 Thread Loïc Minier 
Hey

 There are a bunch of places where we generate uImages and which
 duplicate information.

 a kernel build most commonly outputs a zImage; this is then converted
 to an uImage for u-boot consumption with some rune like:
mkimage -A arm -O linux -T kernel -C none \
-a 0x80008000 -e 0x80008000 -n Linux \
-d vmlinuz-2.6.35-1001-omap \
uImage-linaro

 Linaro's platform wants to output media for various boards, probably as
 a single rootfs + separate boot bits for each SoC, but probably as
 multiple [ rootfs + boot bits ] for now.

 I'd also like to setup daily kernel builds where people can directly
 grab uImages for testing.

 Linaro's platform provides .debs with zImage which get converted to an
 updated uImage at upgrade time (and get flashed when that makes sense).

 So there are already three places where this data is relevant:
 a) daily kernel builds
 b) live-helper image builds
 c) flash-kernel helper for kernel upgrade

 Finally, there are two other places in the .deb ecosystem where this
 data is also copied: in debian-installer (both in Debian and Ubuntu),
 and in debian-cd (mostly in Ubuntu, but applies to Debian).
 d) debian-installer is a package in charge of collecting the bootloader
and kernel pieces and generating installation media such as netboot
files which contain the installer
 e) debian-cd is standalone software to create installation media such
as ISOs or SD card images
 These two pieces are not used by Linaro right now, but it makes sense
 to try to come up with a solution which is usable by these pieces too.

 So there is way too much duplication of this data; there are some
 duplications we could possibly avoid, for instance we could try calling
 flash-kernel's logic from live-helper, but it's not really a good
 approach for the debian-installer build, debian-cd, or the daily kernel
 builds.  flash-kernel currently relies on being run on the target
 because it pokes /proc/cpuinfo, /proc/mtd and /dev/mtdblock*, or in
 Ubuntu the boot SD card; it's a host install, not an installation
 towards a target.

 We want a solution which is usable from a x86 build host to create an
 ARM image (daily kernel builds, debian-cd).

 I see two ways to approach this problem:
 - data driven: we have data files for each board which document the
   addresses to pass to mkimage; all interested software parses the data
   and uses it to generate images
 - scripts: we have scripts for each board to do any board specific
   stuff; all interested software calls into the scripts to generate
   images

 I think what would likely work is a combination of the two.  We should
 have generic task scripts (I want to generate a bootloader kernel
 image from a zImage), and board-specific scripts for board-specific
 logic -- I think we don't really need board-specific scripts for Linaro
 because we try to unify all platforms to the same boot interface, but
 in practice it will be needed for other architectures and we can only
 get wide acceptance of such a replacement if we support more than just
 u-boot.  This should all be backed by plain simple data files as much
 as possible so that extending support to one more board can often be
 done by dropping a data file in a directory.


 So what kind of operations do we want to be able to do?

 * generate an u-boot kernel image from a zImage
   - input: zImage, kernel load address
   - output: uImage
 * generate an u-boot initrd image from an initrd.gz
   - input: initrd.gz, initrd load address
   - output: uInitrd
 * generate a mostly boilerplate u-boot boot script with specific
   cmdline opts
   - input: cmdline opts, script load address
   - output: boot.cmd

 I wonder whether we want to wrap other operations such as:
 * writing the kernel/initrd/script to flash or to a specific partition
   according to config
 * creation of boot media (partition table, vfat etc.)
 * other bootloaders

 Comments welcome!  Other use cases, existing software, whatever!  :-)

 Cheers
-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Cross compilation with debuild

2010-08-23 Thread Loïc Minier 
On Mon, Aug 23, 2010, Dechesne, Nicolas wrote:
 I am still trying to setup a functional cross compilation
 environment for our packages. I want to be able to build without
 xdeb, using debuild command (this is mainly because we use other
 tools such as git-buildpackage).

 (You might be able to arrange for git-buildpackage to call a builder
 which calls xdeb; but cross-building directly is fine too)

 When I build a package which has dependency on another .so file, my
 ./configure script fails, pkg-config complains that it cannot find
 my package config file (which is available in
 /usr/arm-linux-gnueabi/lib/pkgconfig.
 
 If I set PKG_CONFIG_LIBDIR to /usr/arm-linux-gnueabi/lib/pkgconfig,
 then my build is fine, e.g. debuild
 -ePKG_CONFIG_LIBDIR=/usr/arm-linux-gnueabi/lib/pkgconfig -b -aarmel
 -us -uc.
 
 Is that expected? I was looking around in xdeb, and I don't find
 where this is being done, and I am sure it would be needed too since
 it ends up calling debuild...

 I think we need that now too; would you mind filing a xdeb bug about
 that?

 See Debian bug #551118 for why it's a recent in xdeb in maverick; doing
 it in dpkg-buildpackage was a kludge, but I don't think pkg-config has
 the relevant tests just yet (I don't have a triplet-pkg-config here,
 and I didn't see any tests for one in pkg.m4 from upstream git).

 xdeb should test for whether triplet-pkg-config is available and set
 PKG_CONFIG_LIBDIR if not.

   In this process I noticed that xdeb is
 also passing /etc/dpkg-cross/cross-config.armel to debuild. Should I
 do this to?

 This is the autoconf caching mechanism; it's a very nice trick:
 software using autoconf can test for stuff by trying to run some code
 during configure; this gets disabled automatically during
 cross-compilation for obvious reasons; the cool trick with cache is
 that you can provide the cached results and configure will trust the
 cache blindly.

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linux-linaro pull request

2010-08-23 Thread Tim Gardner 
On 08/23/2010 07:36 PM, John Rigby wrote:
 Tim,

 The following changes since commit 951315de2583af8b51bf73ea284fdb8999f4f51c:
Tim Gardner (1):
  UBUNTU: Linaro-2.6.35-1002.6

 are available in the git repository at:

git://git.linaro.org/ubuntu/linux-linaro.git linaro

 John Rigby (5):
LINARO: [Config] Fix vexpress config
LINARO: [Config] Add mx51 flavour
LINARO: Start new release
LINARO: [config] Update vexpress config
LINARO: Linaro-2.6.35-1003.7

   debian.linaro/abi/2.6.35-1001.5/armel/ignore   |1 -
   .../abi/2.6.35-1001.5/armel/ignore.modules |1 -
   debian.linaro/abi/2.6.35-1001.5/armel/vexpress | 7196 
 
   .../abi/2.6.35-1001.5/armel/vexpress.modules   | 1167 
   .../abi/{2.6.35-1001.5 =  2.6.35-1002.6}/abiname   |0
   debian.linaro/abi/2.6.35-1002.6/armel/linaro-mx51  | 4844 +
   .../abi/2.6.35-1002.6/armel/linaro-mx51.modules|  255 +
   .../armel/omap =  2.6.35-1002.6/armel/linaro-omap} |0
   .../armel/linaro-omap.modules} |  260 +-
   .../abi/2.6.35-1002.6/armel/linaro-vexpress| 5156 ++
   .../2.6.35-1002.6/armel/linaro-vexpress.modules|  213 +
   debian.linaro/changelog|   12 +
   .../config/armel/config.flavour.linaro-mx51|  540 ++
   .../config/armel/config.flavour.linaro-omap|  498 ++-
   .../config/armel/config.flavour.linaro-vexpress|  495 ++-
   debian.linaro/config/config.common.ubuntu  |  542 +--
   debian.linaro/control.d/vars.linaro-mx51   |8 +
   debian.linaro/d-i/kernel-versions.in   |1 +
   debian.linaro/etc/getabis  |2 +-
   debian.linaro/rules.d/armel.mk |2 +-
   20 files changed, 12176 insertions(+), 9017 deletions(-)
   delete mode 100644 debian.linaro/abi/2.6.35-1001.5/armel/ignore
   delete mode 100644 debian.linaro/abi/2.6.35-1001.5/armel/ignore.modules
   delete mode 100644 debian.linaro/abi/2.6.35-1001.5/armel/vexpress
   delete mode 100644 debian.linaro/abi/2.6.35-1001.5/armel/vexpress.modules
   rename debian.linaro/abi/{2.6.35-1001.5 =  2.6.35-1002.6}/abiname (100%)
   create mode 100644 debian.linaro/abi/2.6.35-1002.6/armel/linaro-mx51
   create mode 100644 debian.linaro/abi/2.6.35-1002.6/armel/linaro-mx51.modules
   rename debian.linaro/abi/{2.6.35-1001.5/armel/omap =
 2.6.35-1002.6/armel/linaro-omap} (100%)
   rename debian.linaro/abi/{2.6.35-1001.5/armel/omap.modules =
 2.6.35-1002.6/armel/linaro-omap.modules} (100%)
   create mode 100644 debian.linaro/abi/2.6.35-1002.6/armel/linaro-vexpress
   create mode 100644
 debian.linaro/abi/2.6.35-1002.6/armel/linaro-vexpress.modules
   create mode 100644 debian.linaro/config/armel/config.flavour.linaro-mx51
   create mode 100644 debian.linaro/control.d/vars.linaro-mx51

You're kind of playing games with the ABI files for the new mx51 
flavour, but I uploaded anyways.

-- 
Tim Gardner tim.gard...@canonical.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linux-linaro pull request

2010-08-23 Thread John Rigby 
On Mon, Aug 23, 2010 at 9:37 PM, Tim Gardner tim.gard...@canonical.com wrote:


 You're kind of playing games with the ABI files for the new mx51 flavour,
 but I uploaded anyways.
So if I bump the ABI then I don't need ABI-1 files for new flavour?

 --
 Tim Gardner tim.gard...@canonical.com


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev