> So I'm wondering what is the right way to go from here. Hence two
> questions.
>
> 1. Do you consider this build failure against a kernel that is not
> part of Squeeze (although part of squeeze-backports) to be a bug
> that is worth reporting to the Debian BTS... and worth pushing to
> s-p-u? (Cherry-picking some patches from a newer 3.2.x upstream
> release would be needed, it seems.)
You can report it for documentation reasons, personally I don't mind. However,
the solution you propose is not right IMO. There is no reason to push vbox into
s-p-u with fixes for a backports kernel. Instead I would prefer the current
vbox version being backported to squeeze as you suggest in here:
> 2. Current testing packages are trivial to backport for Squeeze, and
> the backported -dkms package builds nicely against 2.6.38 headers.
> On the other hand, I'm aware committing to maintain such backports
> on the long run involves quite more work. Do you intend, as a team,
> to maintain Virtualbox 4.x in squeeze-backports during the Squeeze
> life-cycle?
In general yes, we did so for lenny, but I'm not sure when/if I find the time
doing this in the near future. To be honest it does not really involve that
much work.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
