> 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 _______________________________________________ tails-dev mailing list [email protected] https://boum.org/mailman/listinfo/tails-dev
