Re: Areas of Emdebian to integrate into Debian
Hi,
2011/4/3 Neil Williams <codehelp@debian.org>:
>> * Add a field which allows a package to be cross buildable (that
>> might be delayed until we gain support for all that in Debian)
>
> I'm not sure about this one. I think every package should be assumed to
> be cross-buildable until proven otherwise.
Sorry, my use case is setting a flag which allows Debian autobuilders
to cross build a package, instead of natively build. Why do we want
that? ARM autobuilders take about 24hrs to complete current official
supported kernel builds, that is a big blocker to add more platforms
and think as well when there is a security flaw which needs to get
fixed, Debian kernels have to delay the fix until all architectures
are built. This is one situation where cross building could improve
status quo.
>> * Regarding kernels...
>> We could easily setup an autobuilder which cross compiles kernels
>> and place the packages into emdebian.org repository, but we need to
>> agree what we want to support, probably a cross built version of
>> Debian kernel package with extra configs they do not enable?
>
> How many embedded devices can actually use a reconfigured but otherwise
> unpatched vanilla kernel? Balloon cannot. It takes time to get
> board-specific patches into the mainline kernel - time that many
> embedded developers do not have. (Time that our Debian kernel team
> don't have either.)
Merging patches into mainline, it is seen as a time waste from some,
but it is really the only way those kernels can be enabled in Debian
in a supported way.
> In many cases, I suspect it would be a case of turning off config
> options rather than enabling more but the major problem is in the area
> of patches, not configurations.
Yes, but also those potential kernels need to be tested, in other
words, we need to make sure those kernels at least boot, so I probably
need the hardware to do proper support.
> There's a completely different argument here about why we *have* so
> many variant boards which need varying kernel support. Kernel people
> aren't happy with the constant variability of board-specific support
> systems. Personally, I question whether each individual board needs to
> have a bespoke config supported by bespoke patches which conflict with
> other bespoke patches for other similar boards, so I'm with Linus on
> this one.
>
> https://lkml.org/lkml/2011/3/17/492
Nothing we can do to solve current situation.
> Recently, balloon added support for having a single kernel for multiple
> board configurations and handling the results via the vmlinuz.cmdline
> support. That would seem to be the way forward to me because then we
> could have a single set of patches which enable everything (even if not
> present on a particular board) and then rely on the specific
> commandline for that specific board to sort things out at boot. This
> also lends itself to runtime kernel package upgrades and easier porting
> of the patch set to newer kernels because more people are working on
> the same patches, not their own.
Is not that a way around device trees?
>> Do we
>> want to build out of mainline kernels?
>
> Do you mean mainline kernels with random patches applied elsewhere or
> mainline kernels with patches we apply ourselves? Who is in control of
> the patches and how are those updated for later kernels?
For example, Freescale has a board support package which supports
2.6.31 kernels, then they are releasing 2.6.35. Patches are a 150MB
diff against mainline kernel, plus if something it is borked you get
no support, no security updates, etc...
Note, I do not think it is good policy for us, emdebian guys, to
manage kernel patchsets, we have not time for that.
>> Should we provide security
>> fixes on those out of mainline tree kernels? Or should we just build
>> kernel versions which are marked as long term support (2..6.32,2.6.37)
>> and/or long term support for embedded (2.6.35)?
>
> We don't have limitless resources.
Sure, that is why, we could concentrate in one version, the one tagged
by embedded community (which hopefully will be the same that kernel
guys tag as long term support, in the future). It would not be such a
pain to get this one kernel version right for next release (and
probably it might be linux kernel that Debian and other distros
release).
Cheers,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
Reply to: