[ resending with the correct address ]
On Fri, 27 Aug 2010 14:03:32 -0400, James Westby james.westby@canonical.com wrote:
On Fri, 20 Aug 2010 16:26:46 -0400, James Westby james.westby@linaro.org wrote:
There is also one larger question, which is that I disagree that we shouldn't provide anything that will go in a hardware pack in the linaro images. I think that having the images be useful by themselves has lots of benefits.
- Being able to quickly spin up an image in QEMU makes for easier testing.
- Requiring a hardware pack for every operation will make some things more tedious.
- If everything in a hardware pack becomes more consolidated then hardware packs probably become less useful.
- Not having a flag day where suddenly our images aren't installable and hwpack-install has to work well, and before that date we can't test hwpack-install on the images we produce.Having not had anyone convince me that stripping our images is the right thing to do I have carried on attempting to write the spec without requiring this. There will be a few issues, such as ensuring that the kernel we want is the one that boots, but we have that problem on hwpack upgrades anyway, so it doesn't go away by stripping the images.
I have
https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks
to a state where I am happy to start implementation now. Feedback on the spec is still welcome, and things will still be subject to change. In particular there are still a number of TODOs in the spec where I don't know how to proceed, but I believe that none of those block us starting implementation of other parts.
Is the current status quo to create specs under the "linaro" project on Launchpad? I'll create a spec for this so that we can track work items for it.
Thanks,
James
On Fri, Aug 27, 2010 at 02:05:30PM -0400, James Westby wrote:
https://wiki.linaro.org/Platform/UserPlatforms/Specs/10.11/HardwarePacks
to a state where I am happy to start implementation now. Feedback on the spec is still welcome, and things will still be subject to change. In particular there are still a number of TODOs in the spec where I don't know how to proceed, but I believe that none of those block us starting implementation of other parts.
Is the current status quo to create specs under the "linaro" project on Launchpad? I'll create a spec for this so that we can track work items for it.
Yes. Scott B. or Ian may have a linaro-infrastructure project or project group in the wings to which we should move it later if so, but don't let yourself get blocked for lack of a place to put it ;-)
Thanks very much for the help with this, James.
On Fri, 27 Aug 2010 15:13:11 -0300, Christian Robottom Reis kiko@linaro.org wrote:
Yes. Scott B. or Ian may have a linaro-infrastructure project or project group in the wings to which we should move it later if so, but don't let yourself get blocked for lack of a place to put it ;-)
Created:
https://blueprints.launchpad.net/linaro/+spec/infrastructure-m-hardware-pack...
Does anything need to be done such that it will get picked up by the tracker etc?
As for the spec itself, it's rather light on the endgame right now. What does success look like for this project? What further steps do we need to take once we have scripts to create and install hardware packs, and the ability to generate them in lexbuilder?
Already a workitem: Branch(es) containing the hardware pack specifications for hardware packs we want to contain daily.
Other ideas:
* documentation: of what? where? * distribution: does the existing system we have for images cover us here? * testing: do we need to add these to the ISO tracker?
What criteria are we going to use to judge if it was worth our time to do this work? How are we going to decide if we are better off with hardware packs, or more images?
Thanks,
James
Hi,
A hardware pack creation script is now available, so we can generate them, and the install script is close to being finished too. I have a lexbuidler backend that we can use later, but these things have so few requirements to build that I can do it with a cron job or something for now.
Therefore I need to know what harware packs we want to build, and which packages we want them to contain, and I will start creating them daily.
For each hardware pack I need:
* a name (like a package name) * which (debian) architectures to build it for * Optionally: - Origin (short string, e.g. Linaro) - Maintainer (like in a debian/control file) - Support information ("unsupported" or "supported") * A list of archives to take packages from * A list of packages to include.
Thanks,
James
On Thu, 02 Sep 2010 22:36:51 -0400, James Westby james.westby@canonical.com wrote:
As for the spec itself, it's rather light on the endgame right now. What does success look like for this project? What further steps do we need to take once we have scripts to create and install hardware packs, and the ability to generate them in lexbuilder?
Still looking for answers to these questions though.
Already a workitem: Branch(es) containing the hardware pack specifications for hardware packs we want to contain daily.
Other ideas:
- documentation: of what? where?
- distribution: does the existing system we have for images cover us here?
- testing: do we need to add these to the ISO tracker?
What criteria are we going to use to judge if it was worth our time to do this work? How are we going to decide if we are better off with hardware packs, or more images?
Thanks,
James
On Fri, Sep 10, 2010 at 5:53 PM, James Westby james.westby@canonical.com wrote:
Hi,
A hardware pack creation script is now available, so we can generate them, and the install script is close to being finished too. I have a lexbuidler backend that we can use later, but these things have so few requirements to build that I can do it with a cron job or something for now.
If the separate lexbuilder backend deployment causes any issues we can also just hook this up to live-helper so we produce the hwpacks in the headless run.
Therefore I need to know what harware packs we want to build, and which packages we want them to contain, and I will start creating them daily.
I created a hwpack simple file for a really simple support i did locally for live-helper. This should give you an idea what we want to be in there for now:
http://bazaar.launchpad.net/~linaro-maintainers/linaro/live-helper.config.ma...
For each hardware pack I need:
* a name (like a package name) * which (debian) architectures to build it for * Optionally: - Origin (short string, e.g. Linaro) - Maintainer (like in a debian/control file) - Support information ("unsupported" or "supported") * A list of archives to take packages from * A list of packages to include.
OK, a first set of hwpack packages below. Supported/unsupported might need tweakage; and maybe we need an update too. If you create one branch with all hwpack configs we can later update them as we go:
linaro-omap3 + Name: Linaro OMAP3 + Architectures: armel + Origin: Linaro + Maintainer: Linaro Platform linaro-dev@lists.linaro.org + Support: supported + Archives: Ubuntu main/universe + Linaro overlay + with dep Packages: linux-image-linaro-omap + without dep: u-boot-linaro-omap3-beagle x-loader-omap xserver-xorg-video-omap3
linaro-vexpress + Name: Linaro VExpress + Architectures: armel + Origin: Linaro + Maintainer: Linaro Platform linaro-dev@lists.linaro.org + Support: supported + Archives: Ubuntu main/universe + Linaro overlay + with dep Packages: linux-image-linaro-vexpress + without dep: u-boot-linaro-ca9x4-ct-vxp xserver-xorg-video-fbdev
linaro-imx51: + Name: Linaro IMX51 + Architectures: armel + Origin: Linaro + Maintainer: Linaro Platform linaro-dev@lists.linaro.org + Support: unsupported + Archives: Ubuntu main/universe, linaro overlay, linaro kernel ppa + with dep Packages: linux-image-linaro-mx51 + without dep: u-boot-linaro-mx51evk xserver-xorg-video-fbdev
linaro-bsp-omap4: + Name: Linaro BSP OMAP4 + Architectures: armel + Origin: Ubuntu + Maintainer: Linaro BSP Team linaro-dev@lists.linaro.org + Support: unsupported + Archives: Ubuntu main/universe + with dep Packages: linux-image-omap4 + without dep: u-boot-linaro-omap4-panda x-loader-omap4 xserver-xorg-video-fbdev
linaro-bsp-ux500: + Name: Linaro BSP UX500 + Architectures: armel + Origin: Linaro (BSP) + Maintainer: Linaro BSP Team linaro-dev@lists.linaro.org + Support: unsupported + Archives: Ubuntu main/universe, linaro overlay, linaro kernel ppa + with dep Packages: linux-image-ux500 + without dep: u-boot-linaro-ux500 xserver-xorg-video-fbdev
On Thu, 02 Sep 2010 22:36:51 -0400, James Westby james.westby@canonical.com wrote:
As for the spec itself, it's rather light on the endgame right now. What does success look like for this project?
Here a few: 1. if we manage to produce N rootfs with M hardware support in N+M rather than N*M tarballs/downloads/build-runs 2. if vendors can ship non-free, click-through hwpacks for highly proprietary graphics, codec and other support 3. if we can track/bi-sect hwpack regressions against a stable rootfs 4. if community releases hwpacks for not-linaro supported boards at some point. 5. ...
What further steps do we need to take once we have scripts to create and install hardware packs, and the ability to generate them in lexbuilder?
1. setup a config branch(es) for hwpacks that lexbuilder can work on; enable them 2. update linaro-image-tools package to contain your latest goodies 4. add support for installing hwpacks in linaro-media-create 5. either add linaro-image-tools to headless and head images 5a. ... or install and remove it during linaro-media-creation 6. update plars "download image" script to get the appropriate hwpack together with the head the user wants.
On Mon, 2010-09-13 at 10:50 +0200, Alexander Sack wrote:
If the separate lexbuilder backend deployment causes any issues we can also just hook this up to live-helper so we produce the hwpacks in the headless run.
No, this shouldn't be the case. Do it right the first time, and have a longer term vision in mind. A hack like Alexander proposes is just a waste of time and effort IMHO.
Scott
On Mon, Sep 13, 2010 at 11:49 AM, Scott Bambrough scott.bambrough@linaro.org wrote:
On Mon, 2010-09-13 at 10:50 +0200, Alexander Sack wrote:
If the separate lexbuilder backend deployment causes any issues we can also just hook this up to live-helper so we produce the hwpacks in the headless run.
No, this shouldn't be the case. Do it right the first time, and have a longer term vision in mind. A hack like Alexander proposes is just a waste of time and effort IMHO.
If making a standalone hwpack backend cause delay to linaro-n cycle, the effort to hook it up in live-helper is really worth it imo. It's not much effort after all to put it in a lh helper script, so the waste (if you really want to call it that way) would be well confined.
On Mon, 2010-09-13 at 11:56 +0200, Alexander Sack wrote:
On Mon, Sep 13, 2010 at 11:49 AM, Scott Bambrough scott.bambrough@linaro.org wrote:
On Mon, 2010-09-13 at 10:50 +0200, Alexander Sack wrote:
If the separate lexbuilder backend deployment causes any issues we can also just hook this up to live-helper so we produce the hwpacks in the headless run.
No, this shouldn't be the case. Do it right the first time, and have a longer term vision in mind. A hack like Alexander proposes is just a waste of time and effort IMHO.
If making a standalone hwpack backend cause delay to linaro-n cycle, the effort to hook it up in live-helper is really worth it imo. It's not much effort after all to put it in a lh helper script, so the waste (if you really want to call it that way) would be well confined.
No, James and I should be able to solve the deployment problem. It would be better to concentrate on the actual hardware packs themselves and fix/improve the backend to meet our needs. The infrastructure to create and deploy an individual hardware pack now exists and needs real world testing. In order to test and shake out problems with the backend we really need several hardware packs defined.
James can help out with the mechanics of creating the hardware pack and getting them built automatically. However the contents of the hardware pack should be driven by those in Linaro defining the images we want to build. I haven't seen a relevant head to use with the hardware packs yet, and that IMHO is not an infrastructure problem. What head is available for combination with a hardware pack by linaro-media-create is available?
Scott
On Mon, Sep 13, 2010 at 12:25 PM, Scott Bambrough scott.bambrough@linaro.org wrote:
On Mon, 2010-09-13 at 11:56 +0200, Alexander Sack wrote:
On Mon, Sep 13, 2010 at 11:49 AM, Scott Bambrough scott.bambrough@linaro.org wrote:
On Mon, 2010-09-13 at 10:50 +0200, Alexander Sack wrote:
If the separate lexbuilder backend deployment causes any issues we can also just hook this up to live-helper so we produce the hwpacks in the headless run.
No, this shouldn't be the case. Do it right the first time, and have a longer term vision in mind. A hack like Alexander proposes is just a waste of time and effort IMHO.
If making a standalone hwpack backend cause delay to linaro-n cycle, the effort to hook it up in live-helper is really worth it imo. It's not much effort after all to put it in a lh helper script, so the waste (if you really want to call it that way) would be well confined.
No, James and I should be able to solve the deployment problem. It would be better to concentrate on the actual hardware packs themselves and fix/improve the backend to meet our needs. The infrastructure to create and deploy an individual hardware pack now exists and needs real world testing. In order to test and shake out problems with the backend we really need several hardware packs defined.
Right, I sent the info about initial hwpack content in a previous mail.
James can help out with the mechanics of creating the hardware pack and getting them built automatically. However the contents of the hardware pack should be driven by those in Linaro defining the images we want to build. I haven't seen a relevant head to use with the hardware packs yet, and that IMHO is not an infrastructure problem. What head is available for combination with a hardware pack by linaro-media-create is available?
headless is already available and can already be used for testing (even if omap3 is in there atm). The other heads are failing to build because we don't have hardware packs yet.
Now that you say that we won't hook up hwpack-create there, i will make a new live-helper that allows runs without kernel etc. and then we should be able to get the alip/efl/plasma heads without hw support rather quickly.
James, please ping me on IRC to get info how to test these with headless.
On Mon, 13 Sep 2010 12:35:05 +0200, Alexander Sack asac@linaro.org wrote:
headless is already available and can already be used for testing (even if omap3 is in there atm). The other heads are failing to build because we don't have hardware packs yet.
Now that you say that we won't hook up hwpack-create there, i will make a new live-helper that allows runs without kernel etc. and then we should be able to get the alip/efl/plasma heads without hw support rather quickly.
What do you mean "runs without kernel etc."?
Thanks,
James
On Mon, Sep 13, 2010 at 4:03 PM, James Westby james.westby@canonical.com wrote:
On Mon, 13 Sep 2010 12:35:05 +0200, Alexander Sack asac@linaro.org wrote:
headless is already available and can already be used for testing (even if omap3 is in there atm). The other heads are failing to build because we don't have hardware packs yet.
Now that you say that we won't hook up hwpack-create there, i will make a new live-helper that allows runs without kernel etc. and then we should be able to get the alip/efl/plasma heads without hw support rather quickly.
What do you mean "runs without kernel etc."?
live-helper refuses to run if you don't add any linux_flavour. its a simple fix and i already did that in my ppa live-helper:
From changelog:
* functions/defaults.sh: + in turn allow builds without kernel flavours
https://edge.launchpad.net/~asac/+archive/armel1/+files/live-helper_2.0%7Ea1...
On Mon, 13 Sep 2010 16:51:34 +0200, Alexander Sack asac@linaro.org wrote:
On Mon, Sep 13, 2010 at 4:03 PM, James Westby james.westby@canonical.com wrote:
On Mon, 13 Sep 2010 12:35:05 +0200, Alexander Sack asac@linaro.org wrote:
headless is already available and can already be used for testing (even if omap3 is in there atm). The other heads are failing to build because we don't have hardware packs yet.
Now that you say that we won't hook up hwpack-create there, i will make a new live-helper that allows runs without kernel etc. and then we should be able to get the alip/efl/plasma heads without hw support rather quickly.
What do you mean "runs without kernel etc."?
live-helper refuses to run if you don't add any linux_flavour. its a simple fix and i already did that in my ppa live-helper:
From changelog:
- functions/defaults.sh:
- in turn allow builds without kernel flavours
https://edge.launchpad.net/~asac/+archive/armel1/+files/live-helper_2.0%7Ea1...
Sorry, I don't follow. Can you be more specific about what the change allows you to do?
Thanks,
James
On Mon, Sep 13, 2010 at 4:59 PM, James Westby james.westby@canonical.com wrote:
On Mon, 13 Sep 2010 16:51:34 +0200, Alexander Sack asac@linaro.org wrote:
From changelog:
- functions/defaults.sh:
+ in turn allow builds without kernel flavours
https://edge.launchpad.net/~asac/+archive/armel1/+files/live-helper_2.0%7Ea1...
Sorry, I don't follow. Can you be more specific about what the change allows you to do?
Sure: with this change we can produce our images without any kernel whatsoever (e.g. as those are coming from hwpacks).
On Mon, 13 Sep 2010 17:03:16 +0200, Alexander Sack asac@linaro.org wrote:
Sure: with this change we can produce our images without any kernel whatsoever (e.g. as those are coming from hwpacks).
Ok, we're back to this again. I still haven't heard any convincing arguments for why that is a good idea. Could you please tell me why you think we should do that?
Thanks,
James
On Mon, 13 Sep 2010 11:08:19 -0400, James Westby james.westby@canonical.com wrote:
On Mon, 13 Sep 2010 17:03:16 +0200, Alexander Sack asac@linaro.org wrote:
Sure: with this change we can produce our images without any kernel whatsoever (e.g. as those are coming from hwpacks).
Ok, we're back to this again. I still haven't heard any convincing arguments for why that is a good idea. Could you please tell me why you think we should do that?
Talking to Alexander he gave some good reasons to do this eventually, basically boiling down to it being a waste when we have hwpacks.
We agreed that we should have hwpacks that we know work ok before doing this though.
Therefore the timeline is:
* Make hwpacks available * Keep omap3, vexpress, etc. headless images * Drop linux flavours from all the other images * Make linaro-media-create etc. work well with hwpacks * If we are happy then drop the flavours from headless too
Thanks,
James
On Mon, 13 Sep 2010 10:50:29 +0200, Alexander Sack asac@linaro.org wrote:
If the separate lexbuilder backend deployment causes any issues we can also just hook this up to live-helper so we produce the hwpacks in the headless run.
I've used hudson to build them for now, as it took just a few minutes as I had admin access, and we can focus on a single change with OEM.
Hudson is definitely not a long term solution, at least in the current form.
You can see the hwpacks at
http://jameswestby.net:8080/view/Hardware%20Packs/
Unfortunately the names change, and I don't know how to set up a "current" link. However, there are stable URLs that get you most of the way there, e.g.
http://jameswestby.net:8080/view/Hardware%20Packs/job/linaro-omap3%20hwpack/...
They are currently set up to build nightly, and on any change to the config branch:
lp:~linaro-maintainers/linaro-image-configs/hwpacks
I can give others access to trigger builds etc. on request, and can also add people to the list of recipients of the build failure emails.
OK, a first set of hwpack packages below. Supported/unsupported might need tweakage; and maybe we need an update too. If you create one branch with all hwpack configs we can later update them as we go:
Thanks.
Inclusion of dependencies isn't implemented yet, so these hwpacks aren't going to be usable as snapshots we can come back to yet. If that's really important then I can have that fixed today.
Also, the "Name" has the same restrictions as the package name, so I just took the "linaro-omap3" style, rather than the "Linaro OMAP3" one.
linaro-bsp-ux500:
- Name: Linaro BSP UX500
- Architectures: armel
- Origin: Linaro (BSP)
- Maintainer: Linaro BSP Team linaro-dev@lists.linaro.org
- Support: unsupported
- Archives: Ubuntu main/universe, linaro overlay, linaro kernel ppa
- with dep Packages: linux-image-ux500
- without dep: u-boot-linaro-ux500 xserver-xorg-video-fbdev
http://jameswestby.net:8080/view/Hardware%20Packs/job/linaro-bsp-ux500/lastB...
"The cache has no package named 'linux-image-ux500'"
On Thu, 02 Sep 2010 22:36:51 -0400, James Westby james.westby@canonical.com wrote:
As for the spec itself, it's rather light on the endgame right now. What does success look like for this project?
Here a few:
- if we manage to produce N rootfs with M hardware support in N+M
rather than N*M tarballs/downloads/build-runs 2. if vendors can ship non-free, click-through hwpacks for highly proprietary graphics, codec and other support
What do you mean by "click-through"?
This wasn't highlighted in the spec, so if it is important there will be a little more work to support this.
- if we can track/bi-sect hwpack regressions against a stable rootfs
- if community releases hwpacks for not-linaro supported boards at some point.
- ...
What further steps do we need to take once we have scripts to create and install hardware packs, and the ability to generate them in lexbuilder?
- setup a config branch(es) for hwpacks that lexbuilder can work on;
enable them 2. update linaro-image-tools package to contain your latest goodies
I'm awaiting some further reviews from my team in order to land all of the branches that are being used to create them.
- add support for installing hwpacks in linaro-media-create
Salgado was working on this, but has been out for a few days. It's obviously important to be able to install.
Guilherme, are you happy to continue working on this, or would you like me to carry on your work?
- either add linaro-image-tools to headless and head images
5a. ... or install and remove it during linaro-media-creation 6. update plars "download image" script to get the appropriate hwpack together with the head the user wants.
How do we work hwpacks in to the ISO tracker?
Thanks,
James
On Mon, Sep 13, 2010 at 4:03 PM, James Westby james.westby@canonical.com wrote:
On Mon, 13 Sep 2010 10:50:29 +0200, Alexander Sack asac@linaro.org wrote: You can see the hwpacks at
awesome ... i will check those a bit later.
Unfortunately the names change, and I don't know how to set up a "current" link. However, there are stable URLs that get you most of the way there, e.g.
http://jameswestby.net:8080/view/Hardware%20Packs/job/linaro-omap3%20hwpack/...
I know that some partners might have problems to access this on port 8080 ... is there a way to make these available on port 80 for now?
I can give others access to trigger builds etc. on request, and can also add people to the list of recipients of the build failure emails.
I think Steve L., Jamie (and me for a while) probably want those mails.
Also, the "Name" has the same restrictions as the package name, so I just took the "linaro-omap3" style, rather than the "Linaro OMAP3" one.
OK. thought it was the "readable name" field. fine with me.
linaro-bsp-ux500: + Name: Linaro BSP UX500 + Architectures: armel + Origin: Linaro (BSP) + Maintainer: Linaro BSP Team linaro-dev@lists.linaro.org + Support: unsupported + Archives: Ubuntu main/universe, linaro overlay, linaro kernel ppa + with dep Packages: linux-image-ux500 + without dep: u-boot-linaro-ux500 xserver-xorg-video-fbdev
http://jameswestby.net:8080/view/Hardware%20Packs/job/linaro-bsp-ux500/lastB...
"The cache has no package named 'linux-image-ux500'"
yes, jcribgy did not add the meta package to the kernel ppa yet. CCed him so we can have those asap.
2. if vendors can ship non-free, click-through hwpacks for highly proprietary graphics, codec and other support
What do you mean by "click-through"?
This wasn't highlighted in the spec, so if it is important there will be a little more work to support this.
This is outside of the spec. the idea is that if hwpacks can only be distributed through special means (aka click through, registration), vendors can put those full packs on their own website with their own click through mechanism etc. In this way we don't need to bother about the problems with non-free packs.
So for now, we as linaro won't distribute hwpacks in that way in a daily fashion.
2. update linaro-image-tools package to contain your latest goodies
I'm awaiting some further reviews from my team in order to land all of the branches that are being used to create them.
OK, let me know if you need anything from our side.
4. add support for installing hwpacks in linaro-media-create
Salgado was working on this, but has been out for a few days. It's obviously important to be able to install.
Guilherme, are you happy to continue working on this, or would you like me to carry on your work?
5. either add linaro-image-tools to headless and head images 5a. ... or install and remove it during linaro-media-creation 6. update plars "download image" script to get the appropriate hwpack together with the head the user wants.
How do we work hwpacks in to the ISO tracker?
I have no strong opinion on how we do that. I think Paul had some ideas (CCed)
Thanks,
Thanks to you for your great work!
On Mon, 13 Sep 2010 16:48:52 +0200, Alexander Sack asac@linaro.org wrote:
Unfortunately the names change, and I don't know how to set up a "current" link. However, there are stable URLs that get you most of the way there, e.g.
http://jameswestby.net:8080/view/Hardware%20Packs/job/linaro-omap3%20hwpack/...
I know that some partners might have problems to access this on port 8080 ... is there a way to make these available on port 80 for now?
I can proxy through apache, I'll try and do that later.
I can give others access to trigger builds etc. on request, and can also add people to the list of recipients of the build failure emails.
I think Steve L., Jamie (and me for a while) probably want those mails.
Ok. It would be great if we had aliases for this sort of thing, release@linaro.org, infrastructure@linaro.org. Unfortunately I have to edit the config for each hwpack in order to update this list right now.
2. if vendors can ship non-free, click-through hwpacks for highly proprietary graphics, codec and other support
What do you mean by "click-through"?
This wasn't highlighted in the spec, so if it is important there will be a little more work to support this.
This is outside of the spec. the idea is that if hwpacks can only be distributed through special means (aka click through, registration), vendors can put those full packs on their own website with their own click through mechanism etc. In this way we don't need to bother about the problems with non-free packs.
So for now, we as linaro won't distribute hwpacks in that way in a daily fashion.
Great, that's fine by me.
Thanks,
James
On Mon, Sep 13, 2010 at 4:03 PM, James Westby james.westby@canonical.com wrote:
Inclusion of dependencies isn't implemented yet, so these hwpacks aren't going to be usable as snapshots we can come back to yet. If that's really important then I can have that fixed today.
the important use case is really the kernel package whose name changes for each and every upload... so having hwpack-create pulling the direct depends of the stable meta package name is all that is required for the time being.
For all the other packages I tend to say that they need to be either explicitly mentioned in the hwpack config or they should be assumed to be in the heads image (if not it can be considered a bug somewhat).
On Mon, 13 Sep 2010 16:53:57 +0200, Alexander Sack asac@linaro.org wrote:
On Mon, Sep 13, 2010 at 4:03 PM, James Westby james.westby@canonical.com wrote:
Inclusion of dependencies isn't implemented yet, so these hwpacks aren't going to be usable as snapshots we can come back to yet. If that's really important then I can have that fixed today.
the important use case is really the kernel package whose name changes for each and every upload... so having hwpack-create pulling the direct depends of the stable meta package name is all that is required for the time being.
For all the other packages I tend to say that they need to be either explicitly mentioned in the hwpack config or they should be assumed to be in the heads image (if not it can be considered a bug somewhat).
When we discussed it on IRC the other day I thought we had consensus that we should do this more automatically, including all dependencies, and having a way to specify one or more packages as a "baseline" that can be assumed to be installed.
This is what I have implemented (at least the tricky part of), and it makes the most sense to me. Yes, it will make the hwpacks larger, but you were wanting to have hwpacks that can be used to bisect, and the only way to do that reliably is to include more packages.
Thanks,
James
On Mon, 13 Sep 2010 23:11:05 -0400, James Westby james.westby@canonical.com wrote:
When we discussed it on IRC the other day I thought we had consensus that we should do this more automatically, including all dependencies, and having a way to specify one or more packages as a "baseline" that can be assumed to be installed.
This is what I have implemented (at least the tricky part of), and it makes the most sense to me. Yes, it will make the hwpacks larger, but you were wanting to have hwpacks that can be used to bisect, and the only way to do that reliably is to include more packages.
I've now finished the implementation of this, so we need a package (or list of packages) that we can assume are installed on all images, and the hardware pack will not include any of those debs (though it won't prevent installation on images without them.)
Could you provide this?
Note that the package has to be available in the sources specified for the hardware pack, therefore something in the overlay PPA won't work for things built from just the ubuntu archive. In that case we either need to add the extra source, or pick packages in Ubuntu.
Thanks,
James
On Mon, 2010-09-13 at 10:03 -0400, James Westby wrote: [...]
- add support for installing hwpacks in linaro-media-create
Salgado was working on this, but has been out for a few days. It's obviously important to be able to install.
Guilherme, are you happy to continue working on this, or would you like me to carry on your work?
I'm more than happy to continue working on this. I'm hoping to land the new linaro-hwpack-install script today and then I can work on linaro-media-create to make use of that.
On 27 Aug 2010, at 19:05, James Westby wrote:
On Fri, 27 Aug 2010 14:03:32 -0400, James Westby james.westby@canonical.com wrote:
On Fri, 20 Aug 2010 16:26:46 -0400, James Westby james.westby@linaro.org wrote: Is the current status quo to create specs under the "linaro" project on Launchpad? I'll create a spec for this so that we can track work items for it.
Yes.
The Ubuntu project was chosen for the initial blueprints for a number of reasons, all of which were not really valid (we had a lot of discussions about this) but from now on, unless your blueprint is a working group blueprint, please target at the Linaro project.
Thanks,
James
Regards, Jamie.
-
Alexander Sack -
Christian Robottom Reis -
Guilherme Salgado -
James Westby -
James Westby -
Jamie Bennett -
Scott Bambrough