[arch-general] ARCH .y kernel releases do not match kernel.org's
Hi, I was having some sound issue with ARCH 2.6.38.3 stock kernel so I started to bisect it from Greg KH's 2.6.38.y stable tree. .38.2 was good and .38.3 was bad (so I thought) but I hadn't any single bad commit during bisecting. However, .38.4 /was/ bad. I could finally find the guilty commit (which is in .38.4) but couldn't understand why I was hit by this issue even with 2.6.38.3-ARCH. Then I diff'd both .38.3 patches and found out that Arch's one includes patches that are not in Greg's release. It seems we include patches that are still in -stable patch queue. Finally, I just have one question: is that normal? All I can say is that it made my bisecting session a real PITA. Please give me back my CPU cycles :P Cheers. -- Emmanuel
Am Sonntag 24 April 2011 schrieb Emmanuel Benisty:
Hi,
I was having some sound issue with ARCH 2.6.38.3 stock kernel so I started to bisect it from Greg KH's 2.6.38.y stable tree. .38.2 was good and .38.3 was bad (so I thought) but I hadn't any single bad commit during bisecting. However, .38.4 /was/ bad. I could finally find the guilty commit (which is in .38.4) but couldn't understand why I was hit by this issue even with 2.6.38.3-ARCH. Then I diff'd both .38.3 patches and found out that Arch's one includes patches that are not in Greg's release. It seems we include patches that are still in -stable patch queue. Finally, I just have one question: is that normal? All I can say is that it made my bisecting session a real PITA. Please give me back my CPU cycles :P
Cheers. -- Emmanuel The .3 contained some prepatches from the stable queue. That is the explanation for it.
greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Sun, Apr 24, 2011 at 1:38 PM, Tobias Powalowski <t.powa@gmx.de> wrote:
Am Sonntag 24 April 2011 schrieb Emmanuel Benisty:
Hi,
I was having some sound issue with ARCH 2.6.38.3 stock kernel so I started to bisect it from Greg KH's 2.6.38.y stable tree. .38.2 was good and .38.3 was bad (so I thought) but I hadn't any single bad commit during bisecting. However, .38.4 /was/ bad. I could finally find the guilty commit (which is in .38.4) but couldn't understand why I was hit by this issue even with 2.6.38.3-ARCH. Then I diff'd both .38.3 patches and found out that Arch's one includes patches that are not in Greg's release. It seems we include patches that are still in -stable patch queue. Finally, I just have one question: is that normal? All I can say is that it made my bisecting session a real PITA. Please give me back my CPU cycles :P
Cheers. -- Emmanuel The .3 contained some prepatches from the stable queue. That is the explanation for it.
Thanks Tobias but I already learned that the hard way :P Should we really do that? Or in that case, shouldn't the package be given another version? That is really confusing. Furthermore, those patches are still being tested in a way. Here's what Greg KH says in the announcement: "If anyone has any issues with these being applied, please let us know." That is before the .y release...
On 04/24/2011 03:07 AM, Emmanuel Benisty wrote:
On Sun, Apr 24, 2011 at 1:38 PM, Tobias Powalowski<t.powa@gmx.de> wrote:
Am Sonntag 24 April 2011 schrieb Emmanuel Benisty:
Hi,
I was having some sound issue with ARCH 2.6.38.3 stock kernel so I started to bisect it from Greg KH's 2.6.38.y stable tree. .38.2 was good and .38.3 was bad (so I thought) but I hadn't any single bad commit during bisecting. However, .38.4 /was/ bad. I could finally find the guilty commit (which is in .38.4) but couldn't understand why I was hit by this issue even with 2.6.38.3-ARCH. Then I diff'd both .38.3 patches and found out that Arch's one includes patches that are not in Greg's release. It seems we include patches that are still in -stable patch queue. Finally, I just have one question: is that normal? All I can say is that it made my bisecting session a real PITA. Please give me back my CPU cycles :P
Cheers. -- Emmanuel The .3 contained some prepatches from the stable queue. That is the explanation for it.
Thanks Tobias but I already learned that the hard way :P
Should we really do that? Or in that case, shouldn't the package be given another version? That is really confusing.
Furthermore, those patches are still being tested in a way. Here's what Greg KH says in the announcement: "If anyone has any issues with these being applied, please let us know."
That is before the .y release...
I don't think including additional patches is a big deal. But I've seen discussion lately on how to include them. I think separating the ARCH patches from the .y patch would be nice. And then additional patches should be added individually.
participants (3)
-
Emmanuel Benisty
-
Matthew Monaco
-
Tobias Powalowski