Hi
I've applied these approximately as requested, [...]
Anyway, the end result is that all the driver sources end up identical
to 3.4-rc1.
Thank you Ben!
Let us know if there are any important fixes after that, though I hope I'll
spot them anyway.
I'd like to give that kernel one a try on
On Mon, 2012-04-09 at 13:47 +0200, Mathieu Simon wrote:
Hi
I've applied these approximately as requested, [...]
Anyway, the end result is that all the driver sources end up identical
to 3.4-rc1.
Thank you Ben!
Let us know if there are any important fixes after that, though I hope
On Mon, 2012-04-02 at 14:04 +0200, Mathieu Simon wrote:
Am 02.04.2012 10:55, schrieb Mathieu Simon:
I attached a list with patches that hopefully arrives on BTS with
It seems it hasn't arrived on BTS, therefore I send it in the mail.
(Sorry for this long message)
I've applied these
Hi,
Ok, I have tried to prepare a list based on Jonathan's inputs.
It seems v3.2.12 is the current base for wheezy's kernel.
I attached a list with patches that hopefully arrives on BTS with:
git log --oneline --no-merges v3.2.12..v3.4-rc1 -- drivers/staging/hv/ \
drivers/hv/ tools/hv/
Am 02.04.2012 10:55, schrieb Mathieu Simon:
I attached a list with patches that hopefully arrives on BTS with
It seems it hasn't arrived on BTS, therefore I send it in the mail.
(Sorry for this long message)
- Mathieu
86cbce4 hv: remove the second argument of k[un]map_atomic()
da24e90
Hi,
Mathieu Simon wrote:
But I'm not fully sure about your answer, if I understood you correctly
this means
cherry-picking every single related patch from 3.4-rcX to 3.2.(12) let's
say from gregkh. - Right?
I suppose my answer was less helpful than it could have been. :)
Patches in the
G'day
Am 02.04.2012 02:36, schrieb Jonathan Nieder:
I suppose my answer was less helpful than it could have been. :)
Thanks Jonathan for enlightening me, now I was able to understand :)
[...]
The baseline for the current sid kernel is gregkh's 3.2.y kernel.
When patches meet the criteria
Mathieu Simon wrote:
I'd like to help getting the patches in right shape - if possible.
[...]
Does Debian prefer 1 patch per upstream commit or have one big patch
per driver/file?
I believe the kernel team is happiest if there's a public git tree
based against 3.2, gregkh's 3.2.y, or some
G'day
Am 31.03.2012 15:01, schrieb Jonathan Nieder:
Does Debian prefer 1 patch per upstream commit or have one big patch
per driver/file?
I believe the kernel team is happiest if there's a public git tree
based against 3.2, gregkh's 3.2.y, or some similar release like
gregkh's 3.0.y to pull
9 matches
Mail list logo
