Re: Hardware pack questions
On Tue, Sep 14, 2010 at 09:16:15AM +0200, Alexander Sack wrote: Is it intended that pre-release hwpacks will be long-lived? I expected the same rules to apply as to pre-release images: ephemeral objects used during development that would be replaced at release time by images built from the final archive, leaving no lingering obligation to provide easy access to source for images we're no longer distributing. Are the hwpacks not going to follow this same release cycle? Right, I think legally we might really not be required to do this; however, technically it still makes sense to me to have the sources used to produce a certain hwpack. Especially since we use ppa's or some other archives for hwpacks which have no guarantees to keep history etc. Yes, if we're going to be building hwpacks out of ppas, getting the sources out of the PPA afterwards would be a problem; so best to keep them with the hwpack. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On Mon, Sep 13, 2010 at 11:49 AM, Scott Bambrough scott.bambro...@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. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On Mon, 2010-09-13 at 11:56 +0200, Alexander Sack wrote: On Mon, Sep 13, 2010 at 11:49 AM, Scott Bambrough scott.bambro...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On Mon, Sep 13, 2010 at 12:25 PM, Scott Bambrough scott.bambro...@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.bambro...@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. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On Mon, Sep 13, 2010 at 4:03 PM, James Westby james.wes...@canonical.com wrote: On Mon, 13 Sep 2010 10:50:29 +0200, Alexander Sack a...@linaro.org wrote: You can see the hwpacks at http://jameswestby.net:8080/view/Hardware%20Packs/ 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/lastSuccessfulBuild/artifact/ 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/lastBuild/console 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! -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On Mon, Sep 13, 2010 at 4:03 PM, James Westby james.wes...@canonical.com wrote: On Mon, 13 Sep 2010 12:35:05 +0200, Alexander Sack a...@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%7Ea10.1-1ubuntu1%7Elinaro3.dsc -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On Mon, 13 Sep 2010 17:03:16 +0200, Alexander Sack a...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On Fri, 27 Aug 2010 15:13:11 -0300, Christian Robottom Reis k...@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-packs 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
[ resending with the correct address ] On Fri, 27 Aug 2010 14:03:32 -0400, James Westby james.wes...@canonical.com wrote: On Fri, 20 Aug 2010 16:26:46 -0400, James Westby james.wes...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
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. -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On 27 Aug 2010, at 19:05, James Westby wrote: On Fri, 27 Aug 2010 14:03:32 -0400, James Westby james.wes...@canonical.com wrote: On Fri, 20 Aug 2010 16:26:46 -0400, James Westby james.wes...@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. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
On Mon, 2010-08-23 at 17:06 +0200, Alexander Sack wrote: 2. What is the purpose of the hwpack.deb that is mentioned in places? 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. This was my idea. It was to put everything about the hardware pack in a deb, and install it first. On second thought, it seems overkill, and it should probably be scrubbed from the spec. Scott -- Scott Bambrough scott.bambro...@linaro.org Linaro Infrastructure Team Lead ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Hardware pack questions
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
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
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
Re: Hardware pack questions
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
Re: Hardware pack questions
On Fri, 20 Aug 2010 19:15:31 -0300, Christian Robottom Reis k...@canonical.com wrote: I'm not sure I understand your question, though. Are you asking if packages could be excluded at hardware-pack install time or at creation time? I mean at install time. The only use case I have seen so far is --no-X. That's fine to support, we can just mark whether a package is X related in some way, and so exclude it if necessary. I would like to know of any other use cases though. One thing which is nice about tags is that it's clear what platforms are supported in which configurations. So you can look at board X and see ah, it has a no-X gstreamer hardware pack, but no X gstreamer pack, which means at the moment there's no X acceleration for it. Using X to mean x.org and an arbitrary board is mighty confusing :-) Your use case above implies some more tools than are currently in the spec. How much nicer is it than just seeing which packages are installed? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
