I'm using the stable version of the gentoo-sources, and the most recently stable was 4.4.6. However, it was deleted and now the most recently (stable) is the 4.1.15-r1. What's going on? Must we use that version? Thanks. Reproducible: Always
Yes, I recommend upgrading even though they are not marked stable. Kernels these days don't get any request for stabilization and you are at risk with these older kernels. That specific 'stable' kernel is a false sense of security and we do no favors by leaving it in the tree. Which is why no vanilla kernel is ever marked stable. In fact, upstream recommends upgrading with every release they do.
I have the same issue. Please request stabilization of newer version. Your work is awesome. Gentoo linux is the best disto :).
(In reply to Mike Pagano from comment #1) > Yes, I recommend upgrading even though they are not marked stable. > > Kernels these days don't get any request for stabilization and you are at > risk with these older kernels. > > That specific 'stable' kernel is a false sense of security and we do no > favors by leaving it in the tree. > > Which is why no vanilla kernel is ever marked stable. > > In fact, upstream recommends upgrading with every release they do. Although is a good argument, note that upstream kernel is updated frequently, which means I need to compile it every time it happens, and takes some time between installing from Gentoo repos and compile sources. With the stable-marked kernel didn't happen this. I though a stable kernel is quite mature.
Also, latest version of nvidia-drivers fails at build with 4.7.2: ers/nvidia-drivers-370.23/work/kernel/nvidia-drm/.tmp_nv-pci-table.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nv-pci-table.c x86_64-pc-linux-gnu-ld -m elf_x86_64 -r -o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-drv.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-utils.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-crtc.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-encoder.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-connector.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-gem.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-fb.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-modeset.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-mmap.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-fence.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nvidia-drm-linux.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nv-pci-table.o (cat /dev/null; echo kernel//var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia.ko; echo kernel//var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-uvm.ko; echo kernel//var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-modeset.ko; echo kernel//var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm.ko;) > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/modules.order x86_64-pc-linux-gnu-ld -r -o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-interface.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-frontend.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-instance.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-acpi.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-chrdev.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-cray.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-dma.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-gvi.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-i2c.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-mempool.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-mmap.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-p2p.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-pat.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-procfs.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-usermap.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-vm.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-vtophys.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os-interface.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os-mlock.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os-pci.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os-registry.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os-usermap.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-modeset-interface.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-pci-table.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv_uvm_interface.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nvlink_linux.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nvlink_pci.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/ebridge_linux.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/ibmnpu_linux.o x86_64-pc-linux-gnu-ld -r -o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-modeset/nv-modeset-interface.o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-modeset/nvidia-modeset-linux.o make -f /usr/src/linux-4.7.2-gentoo/scripts/Makefile.modpost find /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/.tmp_versions -name '*.mod' | xargs -r grep -h '\.ko$' | sort -u | sed 's/\.ko$/.o/' | scripts/mod/modpost -m -i ./Module.symvers -I /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/Module.symvers -o /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/Module.symvers -S -w -s -T - FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only symbol 'mutex_destroy' make[3]: *** [/usr/src/linux-4.7.2-gentoo/scripts/Makefile.modpost:91: __modpost] Error 1 make[2]: *** [/usr/src/linux-4.7.2-gentoo/Makefile:1461: modules] Error 2 make[2]: Leaving directory '/usr/src/linux-4.7.2-gentoo' make[1]: *** [Makefile:150: sub-make] Error 2 make[1]: se sale del directorio '/usr/src/linux-4.7.2-gentoo' make: *** [Makefile:81: modules] Error 2 * ERROR: x11-drivers/nvidia-drivers-370.23::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=x11-drivers/nvidia-drivers-370.23::gentoo'`, * the complete build log and the output of `emerge -pqv '=x11-drivers/nvidia-drivers-370.23::gentoo'`. * The complete build log is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/environment'. * Working directory: '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel' * S: '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/' >>> Failed to emerge x11-drivers/nvidia-drivers-370.23, Log file: >>> '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/build.log' * Messages for package x11-drivers/nvidia-drivers-370.23: * ERROR: x11-drivers/nvidia-drivers-370.23::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=x11-drivers/nvidia-drivers-370.23::gentoo'`, * the complete build log and the output of `emerge -pqv '=x11-drivers/nvidia-drivers-370.23::gentoo'`. * The complete build log is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/environment'. * Working directory: '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel' * S: '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/' * GNU info directory index is up-to-date.
Also, I found that. nvidia-drivers cannot build with newer kernels due to license. https://twitter.com/Cynede/status/765879300348342272?lang=es
You don't need to have your kernel version in tree at all to be able to use it. In case you need to keep the sources, just make sure they are not depcleaned by recording the version to world file...
Can't we just have a stable 4.6 Kernel, thanks.
The main problem here is that now that 4.4.6 is removed, all stable installs want to downgrade to 4.1, because that is the latest stable kernel. Although I understand to remove 4.4.6, please mark the 4.4.19 stable, which is also in the tree.
(In reply to jorgicio from comment #4) > Also, latest version of nvidia-drivers fails at build with 4.7.2: > > ers/nvidia-drivers-370.23/work/kernel/nvidia-drm/.tmp_nv-pci-table.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nv- > pci-table.c > x86_64-pc-linux-gnu-ld -m elf_x86_64 -r -o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-drv.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-utils.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-crtc.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-encoder.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-connector.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-gem.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-fb.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-modeset.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-mmap.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-fence.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/ > nvidia-drm-linux.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia-drm/nv- > pci-table.o > (cat /dev/null; echo > kernel//var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia. > ko; echo > kernel//var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia- > uvm.ko; echo > kernel//var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia- > modeset.ko; echo > kernel//var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia- > drm.ko;) > > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/modules.order > x86_64-pc-linux-gnu-ld -r -o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > interface.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > frontend.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > instance.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > acpi.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > chrdev.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > cray.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-dma. > o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-gvi. > o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-i2c. > o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > mempool.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > mmap.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-p2p. > o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-pat. > o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > procfs.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > usermap.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-vm. > o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > vtophys.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os- > interface.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os- > mlock.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os-pci. > o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os- > registry.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/os- > usermap.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv- > modeset-interface.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/nv-pci- > table.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/ > nv_uvm_interface.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/ > nvlink_linux.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/ > nvlink_pci.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/ > ebridge_linux.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia/ > ibmnpu_linux.o > x86_64-pc-linux-gnu-ld -r -o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia- > modeset/nv-modeset-interface.o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/nvidia- > modeset/nvidia-modeset-linux.o > make -f /usr/src/linux-4.7.2-gentoo/scripts/Makefile.modpost > find > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/.tmp_versions > -name '*.mod' | xargs -r grep -h '\.ko$' | sort -u | sed 's/\.ko$/.o/' | > scripts/mod/modpost -m -i ./Module.symvers -I > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/Module. > symvers -o > /var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel/Module. > symvers -S -w -s -T - > FATAL: modpost: GPL-incompatible module nvidia-drm.ko uses GPL-only symbol > 'mutex_destroy' > make[3]: *** [/usr/src/linux-4.7.2-gentoo/scripts/Makefile.modpost:91: > __modpost] Error 1 > make[2]: *** [/usr/src/linux-4.7.2-gentoo/Makefile:1461: modules] Error 2 > make[2]: Leaving directory '/usr/src/linux-4.7.2-gentoo' > make[1]: *** [Makefile:150: sub-make] Error 2 > make[1]: se sale del directorio '/usr/src/linux-4.7.2-gentoo' > make: *** [Makefile:81: modules] Error 2 > * ERROR: x11-drivers/nvidia-drivers-370.23::gentoo failed (compile phase): > * emake failed > * > * If you need support, post the output of `emerge --info > '=x11-drivers/nvidia-drivers-370.23::gentoo'`, > * the complete build log and the output of `emerge -pqv > '=x11-drivers/nvidia-drivers-370.23::gentoo'`. > * The complete build log is located at > '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/environment'. > * Working directory: > '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel' > * S: '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/' > > >>> Failed to emerge x11-drivers/nvidia-drivers-370.23, Log file: > > >>> '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/build.log' > > * Messages for package x11-drivers/nvidia-drivers-370.23: > > * ERROR: x11-drivers/nvidia-drivers-370.23::gentoo failed (compile phase): > * emake failed > * > * If you need support, post the output of `emerge --info > '=x11-drivers/nvidia-drivers-370.23::gentoo'`, > * the complete build log and the output of `emerge -pqv > '=x11-drivers/nvidia-drivers-370.23::gentoo'`. > * The complete build log is located at > '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/temp/environment'. > * Working directory: > '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/kernel' > * S: '/var/tmp/portage/x11-drivers/nvidia-drivers-370.23/work/' > > * GNU info directory index is up-to-date. No issues for me with nvidia-370.23 and 4.7.2. Though this is a bit off topic for this bug.
(In reply to Daniel Augustin from comment #8) > The main problem here is that now that 4.4.6 is removed, all stable installs > want to downgrade to 4.1, because that is the latest stable kernel. > > Although I understand to remove 4.4.6, please mark the 4.4.19 stable, which > is also in the tree. I agree with your point here. I think the safest step for our users is to do the same as we do with vanilla and have no kernel marked stable. Anyways, I can't indiscriminately mark kernels stable because I feel like it. :) But, feel free to open a stable request for any version you like.
I dont think put all kernel as unstable is a solution. Let me show the problem. supose i am a new user. i will install gentoo-sources like this.. emerge gentoo-sources --ask the system propose me to unmask a given kernel but this only one. Until this kernel is out of the tree i cant see any problem in my system even though i have an really old kernel. Leave the responsability to know which kernel is safe to use is not what i want in a distribution. So please dont mask all kernels like in vainilla. Because this will lead in problems. anyway, gentoo devs your work is great :)
This change caught me by surprise. Does anyone know if there was a specific reason why 4.4.6 was removed? Judging by the commit message https://gitweb.gentoo.org/repo/gentoo.git/commit/sys-kernel/gentoo-sources?id=6a950de91349f9c1fa1562ea8ce79ec2a61e84f2 it seems like human error to me, since there's no mention of a bug/deliberate revert to an older stable version. Obviously cleaning up stable and then ending up with an older version doesn't make sense. The simple immediate fix could be to just re-add 4.4.6. For the longer term, shouldn't we mark upstream's LTS release, currently 4.4.19, as stable?
Why isn’t the latest stable kernel marked stable when it is released? Why does it need a stabilization request from a user? I can understand that for some semi-obscure packages it is not automatic, but the kernel is quite important.
What meaning is left of stabilisation, when you just auto-declare the latest one stable? ;) It certainly isn't stable for me, unfortunately I get kernel panics. So it is perfectly fine to stay at 4.6.7 per my (your) own decision, and that version leaving tree does not affect this decision at all. Kernel packages handling has always been different to the other packages in tree, since you configure, build and install it manually. Tree removal does not equal kernel image removal in my /boot.
(In reply to Andreas Sturmlechner from comment #14) > What meaning is left of stabilisation, when you just auto-declare the latest > one stable? ;) It certainly isn't stable for me, unfortunately I get kernel > panics. > > So it is perfectly fine to stay at 4.6.7 per my (your) own decision, and > that version leaving tree does not affect this decision at all. > > Kernel packages handling has always been different to the other packages in > tree, since you configure, build and install it manually. Tree removal does > not equal kernel image removal in my /boot. This is exactly right. This is healthy debate and I appreciate the tone and input from everyone. --- Instead of asking why is X.X.X removed, you should ask "What does a stable kernel mean?" This is what is means: An arch tester ran it for a few (hours, days?) and he marked it stable. Secure? Maybe. Sometimes security fixes get into upstream and released without any notice. The stated policy of upstream kernel developers is to always upgrade. Always. We had a policy where I could auto stabilize minor kernel versions if a previous minor version was arch stabilized. But I was publicly attacked by a bug wrangler, so I don't do that anymore. What I do now, is wait for a user's request to stabilize a specific version. They I just add the arch teams and let them do their thing.
As being 4.7.2 the latest stable version upstream, the same status may be applied to the belonging ebuild.
(In reply to Mike Pagano from comment #15) > We had a policy where I could auto stabilize minor kernel versions if a > previous minor version was arch stabilized. But I was publicly attacked by a > bug wrangler, so I don't do that anymore. I think that policy makes a lot of sense, especially for longterm releases. > What I do now, is wait for a user's request to stabilize a specific version. > They I just add the arch teams and let them do their thing. I opened bug 591810 for 4.4.19.
I restored 4.4.6 in the meantime.
(In reply to Diogo Pereira from comment #17) > (In reply to Mike Pagano from comment #15) > > We had a policy where I could auto stabilize minor kernel versions if a > > previous minor version was arch stabilized. But I was publicly attacked by a > > bug wrangler, so I don't do that anymore. > > I think that policy makes a lot of sense, especially for longterm releases. > > > What I do now, is wait for a user's request to stabilize a specific version. > > They I just add the arch teams and let them do their thing. > > I opened bug 591810 for 4.4.19. Yeah I did too. Not everyone did.
(In reply to Diogo Pereira from comment #17) > (In reply to Mike Pagano from comment #15) > > We had a policy where I could auto stabilize minor kernel versions if a > > previous minor version was arch stabilized. But I was publicly attacked by a > > bug wrangler, so I don't do that anymore. > > I think that policy makes a lot of sense, especially for longterm releases. Totally agree with this for the LTS releases. Any chance this policy can be reinstated? (In reply to Mike Pagano from comment #18) > I restored 4.4.6 in the meantime. Thanks for the quick response/fix!
I noticed that with kernel 4.7, sometimes there are some hungs in the system. Gets freeze for a while, specially when I use Firefox.
Shrugs... that's people for you. ;-) Two choices are; 1) Revert back the previous most recent version marked stable, =sys-kernel/gentoo-sources-4.4.6 2) Avoid CVE-2016-5696 or recently reported Gentoo Bug #591624 TCP/IP Injection vulnerability (CVE-2016-5696) (I just previous to this exploit, started using the latest stable version regardless of keywording.) If you use net-firewall/shorewall, you will run into shorewall related "uname -r" failures while trying to start shorewall with the kernel-4.7 series, consequently leading to shorewall failure to start. (An upstream shorewall bug.) It's Summer. It's humid, and there are lots of bugs. I can't wait for Winter!
(In reply to Roger from comment #22) > If you use net-firewall/shorewall, you will run into shorewall related > "uname -r" failures while trying to start shorewall with the kernel-4.7 > series, consequently leading to shorewall failure to start. (An upstream > shorewall bug.) Please file a bug against net-firewall/shorewall. I am running gentoo-sources:4.7 by myself and don't experience such a problem; Also there's nothing on shorewall ml.
(In reply to Mike Pagano from comment #15) > We had a policy where I could auto stabilize minor kernel versions if a > previous minor version was arch stabilized. But I was publicly attacked by a > bug wrangler, so I don't do that anymore. While I can understand that being attacked by a colleague on the project for implementing an agreed policy might lead one to reconsider continuing with that policy, though I wonder whether abandoning the policy was the best outcome for Gentoo and its users. IIRC the reason for the policy being adopted in the first place was that Gentoo had fallen quite far behind when it came to kernels marked as stable, and users that did not keyword the kernel were at risk of some quite problematic security issues. As I understand the situation, we're at risk of that situation arising again. I suspect that a continuation of this discussion is probably something that should be taken off this bug. Judging by this bug there does seem to be a fair amount of support for a restoration of the policy in some form (maybe an "anti-bug" would help avoid the situation the bug wrangler took exception too - a new release becomes available - an "anti-bug" is opened to log opposition to auto-stabilize the new version, if there's none after, say, a week, the new version is marked stable). Thanks for restoring 4.4.6, perhaps an informal pruning policy for LTS kernel versions could be adopted, where the most current release marked as stable (if there is one) is retained, in addition to the one or two most current releases. That way most versions would look similar to the way 3.10 does at the moment, i.e. 3.10.95 (stable), 3.10.101, and 3.10.102. I'm not sure there's a compelling case for retaining more than 2 "unstable" releases (of course, others might disagree). Whatever the outcome, thanks for your continuing efforts the help us Mike.
(In reply to BobbyK from comment #24) > (In reply to Mike Pagano from comment #15) > > We had a policy where I could auto stabilize minor kernel versions if a > > previous minor version was arch stabilized. But I was publicly attacked by a > > bug wrangler, so I don't do that anymore. > > While I can understand that being attacked by a colleague on the project for > implementing an agreed policy might lead one to reconsider continuing with > that policy, though I wonder whether abandoning the policy was the best > outcome for Gentoo and its users. > > IIRC the reason for the policy being adopted in the first place was that > Gentoo had fallen quite far behind when it came to kernels marked as stable, > and users that did not keyword the kernel were at risk of some quite > problematic security issues. As I understand the situation, we're at risk > of that situation arising again. > > I suspect that a continuation of this discussion is probably something that > should be taken off this bug. Judging by this bug there does seem to be a > fair amount of support for a restoration of the policy in some form (maybe > an "anti-bug" would help avoid the situation the bug wrangler took exception > too - a new release becomes available - an "anti-bug" is opened to log > opposition to auto-stabilize the new version, if there's none after, say, a > week, the new version is marked stable). > > Thanks for restoring 4.4.6, perhaps an informal pruning policy for LTS > kernel versions could be adopted, where the most current release marked as > stable (if there is one) is retained, in addition to the one or two most > current releases. That way most versions would look similar to the way 3.10 > does at the moment, i.e. 3.10.95 (stable), 3.10.101, and 3.10.102. I'm not > sure there's a compelling case for retaining more than 2 "unstable" releases > (of course, others might disagree). > > Whatever the outcome, thanks for your continuing efforts the help us Mike. Thanks for the kind words and I don't disagree with anything you've said above. Mike
This comment serves as a closing summary of the resolution. In the case that you want to discuss this further; consider the mailing lists, chat or forums. (In reply to jorgicio from comment #0) > I'm using the stable version of the gentoo-sources, and the most recently > stable was 4.4.6. However, it was deleted and now the most recently (stable) > is the 4.1.15-r1. What's going on? Must we use that version? This bug can be closed as the 4.4.6 removal is reverted, therefore no longer causing the described downgrades. In order to eventually remove 4.4.6, stabilization of 4.4.19 is requested in bug 591810. commit 8c0f6d8eb8e577648f7e3510aad71498a7307d23 Author: Mike Pagano <mpagano@gentoo.org> Date: Sun Aug 21 11:20:04 2016 -0400 sys-kernel/gentoo-sources: Restore latest stable. Package-Manager: portage-2.2.28 RepoMan-Options: --force (In reply to jorgicio from comment #21) > I noticed that with kernel 4.7, sometimes there are some hungs in the > system. Gets freeze for a while, specially when I use Firefox. Can you file a new bug about this and attach clues from dmesg or syslog? Thank you very much in advance
