Arch teams, please consider stabilizing =sys-kernel/gentoo-sources-2.6.35-r4 and matching =sys-kernel/vanilla-sources-2.6.35.3 These kernels contain important security fixes and should be the latest stable for gentoo. [1] [1] http://theinvisiblethings.blogspot.com/2010/08/skeletons-hidden-in-linux-closet.html
wrt https://bugs.gentoo.org/show_bug.cgi?id=312385#c14 Is it a good idea to have 2.6.35 stable without stable dhcpcd-5?
(In reply to comment #1) > wrt https://bugs.gentoo.org/show_bug.cgi?id=312385#c14 > Is it a good idea to have 2.6.35 stable without stable dhcpcd-5? > That would be dhcpcd-5.2.7 then, but that one hasn't been in tree for 1 month yet.
(In reply to comment #2) > (In reply to comment #1) > > wrt https://bugs.gentoo.org/show_bug.cgi?id=312385#c14 > > Is it a good idea to have 2.6.35 stable without stable dhcpcd-5? > > > > That would be dhcpcd-5.2.7 then, but that one hasn't been in tree for 1 month > yet. > I was already running kernel 2.6.35 vanilla for some time and had the problem of dhcpcd not working properly. I just did a build test on dhcpcd-5.2.7 (with and without the zeroconf use flag) and tested the functionality of this version. My problems with the old dhcpcd disappeared and no other problems surfaced. If the new kernel fixes security problems then I think the arches should at least give a shot on stabilizing dhcpcd-5.2.7.
x86 stable
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > wrt https://bugs.gentoo.org/show_bug.cgi?id=312385#c14 > > > Is it a good idea to have 2.6.35 stable without stable dhcpcd-5? > > > > > > > That would be dhcpcd-5.2.7 then, but that one hasn't been in tree for 1 month > > yet. > > > > I was already running kernel 2.6.35 vanilla for some time and had the problem > of dhcpcd not working properly. I just did a build test on dhcpcd-5.2.7 (with > and without the zeroconf use flag) and tested the functionality of this > version. My problems with the old dhcpcd disappeared and no other problems > surfaced. > > If the new kernel fixes security problems then I think the arches should at > least give a shot on stabilizing dhcpcd-5.2.7. > As I understand it's incompatible with baselayout-1 (bug 262097), which is currently stable. So, looks like this bug should depend on OpenRC stabilization.
Stable for HPPA.
(In reply to comment #5) > (In reply to comment #3) > > If the new kernel fixes security problems then I think the arches should at > > least give a shot on stabilizing dhcpcd-5.2.7. > > > > As I understand it's incompatible with baselayout-1 (bug 262097), which is > currently stable. So, looks like this bug should depend on OpenRC > stabilization. It would probably be quicker to patch baselayout-1 than wait for OpenRC stabilization, although I'm not sure how much inertia needs to be overcome for the former.
As it stands, the stable tree on x86 and hppa is now broken because baselayout-1 does not handle dhcpcd-5 correctly. One of two things needs to happen before dhcpcd-5.2.7 can go to stable. baselayout-1 needs to be fixed to handle dhcpcd-5.2.7 or openrc needs to be stabilized. I've added the dhcpcd stabilization request I have open to the dependencies for this bug as well as the bug regarding dhcpcd and bl1.
Readding HPPA because of bug #262097, then.
Equally...
x86/hppa, should we revert the stabilizations of dhcpcd-5.2.7 on your arch's since it should not have been stabilized in the first place due to bug #262097?
27 Aug 2010; William Hubbs <williamh@gentoo.org> dhcpcd-5.2.7.ebuild: I reverted this stabilization wrt bug #262097. In its current state, dhcpcd-5.2.7 will not work with baselayout-1.
Reverted to ~hppa.
x86/kernel teams, should we revert the stabilization of gentoo-sources-2.6.35-r4? Thanks, William
No. Kernel Security bug trumps all.
(In reply to comment #15) > No. Kernel Security bug trumps all. > But the same fixes was provided for 2.6.34 branch, right?
I need all of our supported kernels to have this fix.
I've submitted a patch for testing on the dhcpcd thing, so just give it a little time. Vapier has said he will release a new baselayout with a working fix.
Hi All, After upgrade to 2.6.35 I unable to use DHCP at all (both 4.x and 5.x version of dhcpcd) - problems with carrier. As I understand it's a bug 333035. In my opinion it should be blocker for these bug, because e1000e is very spread Ethernet adapters.
(In reply to comment #19) > After upgrade to 2.6.35 I unable to use DHCP at all (both 4.x and 5.x version > of dhcpcd) - problems with carrier. As I understand it's a bug 333035. In my > opinion it should be blocker for these bug, because e1000e is very spread > Ethernet adapters. See the discussion above, the stable keyword has been revoked.
(In reply to comment #20) > (In reply to comment #19) > > After upgrade to 2.6.35 I unable to use DHCP at all (both 4.x and 5.x version > > of dhcpcd) - problems with carrier. As I understand it's a bug 333035. In my > > opinion it should be blocker for these bug, because e1000e is very spread > > Ethernet adapters. > > See the discussion above, the stable keyword has been revoked. > As I see we have several issues related with networking with this kernel. First one is that dhcpcd shall be upgraded to 5.x but, to do this we need to have new baselayout. In my opinion, this issue is enough to revert stabilization, because the system with stable packages is broken (even worse, the only way is upgrade to OpenRC, because the patch for baselayout-1 is still on review, and looks like it doesn't fix the issue - bug 262097, comment 32). In addition we have second second issue - bug 333035. Depending on hardware networking may works with workaround, and may not. Kernel bugzilla has fixed bug https://bugzilla.kernel.org/show_bug.cgi?id=16187 for this issue, and it sad that it shall works with dhcpcd-5.2.7, but in my case it doesn't works (and it works fine with 2.6.34), so we have a regression in new stable kernel.
(In reply to comment #14) > x86/kernel teams, > should we revert the stabilization of gentoo-sources-2.6.35-r4? > Thanks, > William (In reply to comment #15) > No. Kernel Security bug trumps all. (In reply to comment #13) > Reverted to ~hppa. Are there any other issues on hppa? If not, according to Mike's comment above, I think we should undo the revert and make this kernel hppa instead of ~hppa. What do you think?
It's a week now and there are still 10 open bugs for this kernel on x86 32/64bit
(In reply to comment #23) > It's a week now and there are still 10 open bugs for this kernel on x86 > 32/64bit > Could you set these bugs as a blockers to this one?
Maybe this bug should be split for .34 and .35 since there are different issues going on that are blocked by different bugs?
Sorry, misread the summary, ignore me. :(
2.6.35-r4 tested ADM64 for a month, dhcpd and all other software i use (1500 packages) worked perfectly fine with it i had absoulutely no issues. i say stable amd64
Don't forget to update or close this bug now that 2.6.35-r4 is no longer in the tree.
g-s ok on amd64.
For me 2.6.35 is really shaky on x86, I get hangs (temporarily and break-downs), sound is cracking a lot, WLAN connection is lost (it is a staging driver though). What is long-time experience of other users on x86?
I've been running the 2.6.35 series for quite some time (couple of weeks) on a x86 home server, with no problems at all.
(In reply to comment #31) > I've been running the 2.6.35 series for quite some time (couple of weeks) on a > x86 home server, with no problems at all. > Are you use WLAN and sound on server (as it was described in comment 30)? Could you also clarify if you use e1000e based Ethernet adapter, which was broken on early 2.6.35 releases (I don't really know if it was fixed in 2.6.35 branch)?
I have some other x86 systems running 2.6.35 for a couple of days with no problems. one is a media pc hooked up to my amplifier to play sound using mpd, no wlan though and also no e1000e based ethernet. The other system is a eee pc, both sound and wlan are functioning fine. No e1000e based ethernet though. These systems are running 2.6.35 for a couple of days though, not a couple of weeks as the server.
With 2.6.35-r11 on x86 I have experienced some random crashes on the desktop, the likes of which had not happened since KMS was new and exciting. Coincidence? Anyway, it happened enough that I reverted back to .34, but I'll start testing .35-r12 now. My amd64 machine has been running .35-r12 for over a week without incident, however I don't use it as much as the x86 machine.
(In reply to comment #30) > For me 2.6.35 is really shaky on x86, I get hangs (temporarily and > break-downs), sound is cracking a lot, WLAN connection is lost (it is a staging > driver though). What is long-time experience of other users on x86? > Christian, Have you tried 2.6.36 on the same machines? I've been running .35 for a long time now on amd64 and x86 with no issues, but I would like to know if your issues manifest themselves on .36.
@amd64: I will let arch testers decide whether .35 is stable for us or not, because I cannot use .35 for a variety of reasons. Mike, feel free to stabilize it for amd64 if you want along with bug #312385 as both of them have to be stabilized at the same time.
(In reply to comment #35) > (In reply to comment #30) > > For me 2.6.35 is really shaky on x86, I get hangs (temporarily and > > break-downs), sound is cracking a lot, WLAN connection is lost (it is a staging > > driver though). What is long-time experience of other users on x86? > > > > Christian, > > Have you tried 2.6.36 on the same machines? I've been running .35 for a long > time now on amd64 and x86 with no issues, but I would like to know if your > issues manifest themselves on .36. Started using it today, the problems are infrequent and not really reproducable by me. So, even if it is shaky for me, it definitely will solve a lot of issues for more people...so I am fine with it going stable on x86 if noone else reports so many problems.
(In reply to comment #30) > For me 2.6.35 is really shaky on x86, I get hangs (temporarily and > break-downs), sound is cracking a lot, WLAN connection is lost (it is a staging > driver though). What is long-time experience of other users on x86? I'm using 2.6.35-r4 since August 27th and 2.6.35-r11 since October 22nd. No WLAN, but I'm using e1000e module and I'm listening to a lot of music from Amarok as well as streaming from last.fm and grooveshark.com. No problems that I can identify as kernel related. nepomukservices often reports segfaults in libsoprano.so.4.3.0 after logon to KDE (4.4.5) and akonadi sometimes crashes when logging off, but I'm not sure if these are related to the kernel. Sound occasionally hangs when streaming from Firefox, but this happened with older kernels too and can be fixed by restarting Firefox.
I've just tested 2.6.35-r12 on my work PC. For me the network problem is still present. I used dcpdcd 5.2.28 for testing. The results are: 1. gentoo-sources-2.6.34-r12 - DHCP works fine. 2. gentoo-sources-2.6.35-r12 - DHCP lease failed. looks like no carrier. 3. gentoo-sources-2.6.36 - DHCP works fine. Unfortunately 2.6.36 is incompatible with stable nvidia-drivers (bug 334223). Looks like the fix for e1000e was not ported to 2.6.35 branch (bug 333035). Maybe it is possible to make patch for e1000e module based on changes performed in 2.6.36 or at least to revert the commit in which the module was broken (see this thread http://www.spinics.net/lists/netdev/msg134330.html)? My Ethernet adapter is: Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection (rev 02) (integrated in the Intel DG965RY motherboard).
Just mentioning that I haven't seen any of the desktop crashes on .35-r12 that I expected.
Until now, 2.6.36 behaves way better than 35.
(In reply to comment #41) > Until now, 2.6.36 behaves way better than 35. > yeah. on my x86 laptop, with .36 no problem until now
(In reply to comment #41) > Until now, 2.6.36 behaves way better than 35. > Yes, but not all versions of nvidia-drivers are compatible with 2.6.36 :(
(In reply to comment #41) > Until now, 2.6.36 behaves way better than 35. Although some of the problems persist. In general, .35 is good to go on x86.
Let's try it again on x86.
(In reply to comment #45) > Let's try it again on x86. > network works fine now but I just reported 346693, for me unuseable :/
arm stable
alpha/ia64/sh/sparc stable
