On 19 February 2013 18:54, Alexander Sack <a...@linaro.org> wrote: > On Tue, Feb 19, 2013 at 6:03 PM, James Tunnicliffe > <james.tunnicli...@linaro.org> wrote: >> On 19 February 2013 16:08, Alexander Sack <a...@linaro.org> wrote: >>> On Tue, Feb 19, 2013 at 2:53 PM, James Tunnicliffe >>> <james.tunnicli...@linaro.org> wrote: >>>> Good point! I would be pleasantly surprised if an image + hwpack from >>>> 2010 worked with our current tools. >>> >>> Actually, I am surprised if they do not work. >>> >>> Our official promise on lit has always been that: >>> 1. all hwpacks and rootfs ever produced before a lmc release will >>> work with that lmc >>> 2. lmc will work well on most recent Ubuntu release as well as on all >>> Ubuntu LTS still supported by Canonical >>> >>> So moving forward let's do this: >>> + find out if latest lmc works with the hwpack/rootfs stuff above - >>> maybe it is all good actually - the wiki instructions refer to an old >>> lmc version. >>> + ensure that we have hwpack rootfs version as old as the above in our CI >>> + use this opportunity to review if our CI tests have other gaps that >>> we need to fill to know whether we are green wrt 1. and 2. above >>> + fix failures including removing online requirement when they come up. >>> >>> Guess a blueprint about "lmc legacy support investigation and >>> resurrection" might be the way to go. >> >> Interesting. We have had a blueprint about dropping Hardware Pack v1 >> support ready to go for a while. There is a lot of "if v1, else" code >> in Linaro Image Tools that we would like to get rid of. >> >> In the original case we have an image based on an unsupported Ubuntu >> version, which no longer has packages on >> http://ports.ubuntu.com/dists/, so there is no way to support it since >> it can't be installed. It isn't useful to have non-functioning OS > > It's not a given thing that it can't be installed. Actually, except > for corner cases ALL the bits you need should be in rootfs and hwpack > combined. > > For me all hwpack/rootfs that don't have all the bits are actually > BUGGY and I would like to kill online support from lmc just for the > sake to ensure that our hwpacks/rootfs really have everything.
Good to know. I was so used to seeing the apt-get update that I had come to see it as a requirement. >> binaries on releases.linaro.org, so we should either delete them/move >> them to an archive location or perhaps put them behind a warning page. >> We could use BUILDINFO.txt to implement the warning. > > That's an independent discussion. > > Right now LMC is buggy as it cannot install stuff without the upstream > archives still being there. Let's fix that first and then go and talk > about a policy how to phase out old stuff (even though right now I > believe all releases should stay around forever). Patch incoming :-) Just doing some more tests, but it seems that we are fine when we pull updates if possible rather than failing when apt-get update fails. BeagleBoard had a missing parameter we needed for hwpack V1 support, but we now have a sensible default. >> Our CI jobs for image tools only go back to Linaro 11.06. I don't know >> when our releases switched to use Ubuntu 11.04 but it would be around >> then. We could try going back further, but it may only get us 6 months >> of testing a release that very few people are using. > > Yes, please go back to the oldest we have, treat them as bugs and > systematically discuss case by case if we really don't support it. > >> >> Binaries from ports.ubuntu.com will vanish after their support window >> has expired, so it seems likely that 11.04 and 11.10 based images will >> be unusable in a years time. > > As from above: our hwpacks should have everything they need in them. > If not, its a hwpack bug and we want to know about them (through lmc > hwpack-create and create failing unless you pass > --download-missing-anyway or something). > >> >> James > > > > -- > Alexander Sack > Director, Linaro Platform Engineering > http://www.linaro.org | Open source software for ARM SoCs > http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog -- James Tunnicliffe _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
