Why stable downgrade, from kernel-4.4.6 to 4.1.15

[gordonp]

I sync'd, went to update world..... WHOA! What is going on - I'm running the "stable" desktop kernel, with desktop/Gnome/systemd profile, which up until a short while ago was kernel-4.4.6

Suddenly, portage wants me to downgrade to 4.1.15.

This just doesn't smell right.... anyone have any insight as to what's going on?

TIA!

[Tony0945]

According to this page: https://packages.gentoo.org/packages/sy ... oo-sources

sys-kernel/gentoo-sources: Remove old, unsupported versions.
Mike Pagano, Sat, 20 Aug 2016 13:02, commit 6a950de9
gentoo-sources-4.4.6.ebuild, gentoo-sources-4.6.3.ebuild, gentoo-sources-4.6.4.ebuild, gentoo-sources-4.6.5.ebuild, gentoo-sources-4.6.6-r1.ebuild, gentoo-sources-4.6.6.ebuild, gentoo-sources-4.6.7.ebuild

Some devs are very quick to drop packages. Sometimes they even drop the only stable package.

Thanks for the heads-up. I'll move 4.4.6 to local overlay before syncing.

EDIT:
Looks like I was too late to save the patches and sources. Maybe I have them on another machine.

Why did he drop stable 4.4.6 as "old and unsupported" but keep unstable 3.4.112 ?

[ian.au]

According to this page: https://packages.gentoo.org/packages/sy ... oo-sources

sys-kernel/gentoo-sources: Remove old, unsupported versions.
Mike Pagano, Sat, 20 Aug 2016 13:02, commit 6a950de9
gentoo-sources-4.4.6.ebuild, gentoo-sources-4.6.3.ebuild, gentoo-sources-4.6.4.ebuild, gentoo-sources-4.6.5.ebuild, gentoo-sources-4.6.6-r1.ebuild, gentoo-sources-4.6.6.ebuild, gentoo-sources-4.6.7.ebuild

Some devs are very quick to drop packages. Sometimes they even drop the only stable package.

Thanks for the heads-up. I'll move 4.4.6 to local overlay before syncing.

++ Thanks also, I'll put off syncing for a couple of days. It's a PITA when this happens.

[asturm]

I don't quite see why it matters. Add the version you want to keep to the world file so depclean won't remove it, work done. You don't need your kernel in tree to use it.

[dantrell]

I don't quite see why it matters. Add the version you want to keep to the world file so depclean won't remove it, work done. You don't need your kernel in tree to use it.

That's not how it works.

If the related packages were already installed, they don't need to be in the tree to be used, however, at that point you will not be able to reinstall those packages and eclean (on the default settings) will delete any related binaries.

Let's be frank, the issue with stabilizing kernel release versions in a timely manner aside, they were overzealous in selecting the versions they choose to remove. If it's listed in the overview of the Linux Kernel site, it's should be in portage. Anything marked as EOL is a notification until it actually disappears from the overview (and if memory serves, some versions marked as EOL have had that status reverted when a qualified maintainer stepped up).

Also, while the Linux Kernel itself encourages you to move to the latest stable line, that's not always immediately possible depending on your hardware (or other) needs. For instance, anyone using the NVIDIA drivers, the Broadcom STA Wireless drivers or ZFS still require the 4.6.x line.

If you don't see the point, then I don't think this matter is very relevant to you and what you are saying isn't really helpful.

To those it does impact, you can comment on Gentoo bug #591758 but ultimately, you will probably want to utilize a local overlay (which after more than a decade of Gentoo, I can say is a must).

P.S. For the record, the latest stable 4.6 release is 4.6.7 so if you require this line, use that version. You can find that ebuild here.

Edit: s/depclean/eclean/

[ian.au]

I don't quite see why it matters. Add the version you want to keep to the world file so depclean won't remove it, work done. You don't need your kernel in tree to use it.

Because it's sloppy? And because some old installs with 32mb /boot sectors can only hold 2 kernels?

[asturm]

@dantrell: Then someone should step up and help with kernel maintenance. First thing would be backporting CVE-2016-5696 which concerns <4.7 kernels and is probably the reason why any previous kernel version that is EOL was removed. As it is now there seems to be no room for backporting extra patches to EOL'd kernels.

Admittedly I'm in the fine position to not use any binary blobs. But I've been affected by kernel bugs in the past that had me drop back to an older, but LTS maintained kernel version for a long time (you hear me, 3.4.105). That's what you do...

If the related packages were already installed, they don't need to be in the tree to be used, however, at that point you will not be able to reinstall those packages and depclean (on the default settings) will delete any related binaries.

--depclean does not remove kernel binaries you compiled, only the sources. And other packages that need kernel sources around for build do just need these sources pointed at by your linux symlink and can use them as long as you do not --depclean them.

And because some old installs with 32mb /boot sectors can only hold 2 kernels?

What's /boot got to do with it? Nothing.

[dantrell]

--depclean does not remove kernel binaries you compiled, only the sources. And other packages that need kernel sources around for build do just need these sources pointed at by your linux symlink and can use them as long as you do not --depclean them.

I meant the binary packages in PKGDIR if you have FEATURES="buildpkg" enabled.

By default, eclean will only protect distfiles and binary packages that have a corresponding ebuild available.

Edit: s/depclean/eclean/

[asturm]

I meant the binary packages in PKGDIR if you have FEATURES="buildpkg" enabled.

By default, depclean will only protect distfiles and binary packages that have a corresponding ebuild available.

Availability of ebuild has nothing to do with it:

Code: Select all

#  equery l -iop gentoo-sources
 * Searching for gentoo-sources ...
[I--] [??] sys-kernel/gentoo-sources-4.6.7:4.6.7
[IP-] [ ~] sys-kernel/gentoo-sources-4.7.2:4.7.2

Code: Select all

# emerge --noreplace =gentoo-sources-4.6.7
Calculating dependencies... done!
>>> Recording sys-kernel/gentoo-sources:4.6.7 in "world" favorites file...
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

Code: Select all

# emerge -cp gentoo-sources

Calculating dependencies... done!
>>> Calculating removal order...

>>> These are the packages that would be unmerged:

 sys-kernel/gentoo-sources
    selected: 4.7.2 
   protected: none 
     omitted: 4.6.7 

All selected packages: =sys-kernel/gentoo-sources-4.7.2

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

Distfiles/Binary packages are cleaned by eclean, not --depclean? And last time I checked, they are kept for installed packages even if they are unavailable.

[tberger2]

https://sources.gentoo.org/cgi-bin/view ... ideattic=0

[dantrell]

Distfiles/Binary packages are cleaned by eclean, not --depclean? And last time I checked, they are kept for installed packages even if they are unavailable.

I was thinking of eclean the whole time. I'd strikethrough the text but apparently that bbcode isn't available.

My point stands though: there are reasons why it matters (to others, if not yourself).

That's all I have to say about that.

[ian.au]

And because some old installs with 32mb /boot sectors can only hold 2 kernels?

What's /boot got to do with it? Nothing.

Because for me, managing those systems it determines my procedure for adding / removing sources from world - which I usually do remotely --depcleaning the old after a successful build of the new.
Yes, it's easy enough to work around, I just don't think it should be necessary to.

Is it really so hard to stabilize a newer kernel before retiring the current one?

[asturm]

Distfiles/Binary packages are cleaned by eclean, not --depclean? And last time I checked, they are kept for installed packages even if they are unavailable.

I was thinking of eclean the whole time. I'd strikethrough the text but apparently that bbcode isn't available.

Not for nitpicking, but just for completeness if others are following the discussion:

Code: Select all

# eclean -d distfiles
 * Building file list for distfiles cleaning...

   The following unavailable installed packages were found
             sys-kernel/gentoo-sources-4.6.7

Code: Select all

# ls -1 /var/lib/portage/distfiles/gen*-4.6*
/var/lib/portage/distfiles/genpatches-4.6-9.base.tar.xz
/var/lib/portage/distfiles/genpatches-4.6-9.extras.tar.xz
/var/lib/portage/distfiles/gentoo-headers-4.6-1.tar.xz
/var/lib/portage/distfiles/gentoo-headers-base-4.6.tar.xz

So there's no reason to be afraid of losing distfiles either. I'm on the same side, btw, because it turns out 4.7.2 is just one of those kernels that introduce a surprise kernel panic on my aging system. So i can't use it right now.

And @ian.au, there's no reason to take *any* action in /boot just because your current kernel is leaving tree. It is entirely your own decision when you switch. To me this is very similar to the recent discussion about whether it would be better for Gentoo to take on a different approach for [replacing, not installing side-by-side] new kernel sources [or keep the one in use - just, which one exactly?]. Which in the end came down to no, this is one area where you do the manual work, kernel sources handling is simply different to other packages in the tree.

Is it really so hard to stabilize a newer kernel before retiring the current one?

Apparently it is hard to stabilise anything at this point. But what does a stable kernel mean, anyway, for your Gentoo system? It is not like any other package in tree, it is impossible for arch teams to test even a tiny part of all hardware that is supported, so whatever gets stabilised just didn't have too many bugs reported in bugzilla. And when that happens, it is actually already obsolete by at least several upstream releases that are much more recommended for use. Two years of stable kernels didn't work for my particular corner case, I wouldn't have dared trying to argue to block stabilisation because of that.

[Tony0945]

P.S. For the record, the latest stable 4.6 release is 4.6.7 so if you require this line, use that version. You can find that ebuild here.
Edit: s/depclean/eclean/

According to https://packages.gentoo.org/packages/sy ... oo-sources, the latest gentoo stable is now 4.1.15-r1, not 4.6.7 which is not available. You are perhaps talking about vanilla-sources. (EDIT: I see there was a link, my screen has poor contrast. However, the ebuild is not the problem, the distfile and patches are the problem.)

It does matter to keep the sources around if you need to change a configuration option or emerge a later version of an out of kernel driver like r8168.

I understand the reasons for removing old versions. I'm wondering why the latest stable was removed (a mistake? a bug?). My big gripe was the lack of notice. I sync daily, yet I find out about this on Sunday morning from another user posting a question on the forum.

Gentoo devs used to give 30 day notices of removal and when you logged in at the forum, you saw the notices immediately.

[asturm]

30 day notices are for removal of an entire package, not a single version.

It does matter to keep the sources around if you need to change a configuration option or emerge a later version of an out of kernel driver like r8168.

You are completely in control of that, if you read my posts.

[Caleb9]

4.4.6 is back as stable

[ian.au]

Is it really so hard to stabilize a newer kernel before retiring the current one?

Apparently it is hard to stabilise anything at this point. But what does a stable kernel mean, anyway, for your Gentoo system? It is not like any other package in tree, it is impossible for arch teams to test even a tiny part of all hardware that is supported, so whatever gets stabilised just didn't have too many bugs reported in bugzilla. And when that happens, it is actually already obsolete by at least several upstream releases that are much more recommended for use. Two years of stable kernels didn't work for my particular corner case, I wouldn't have dared trying to argue to block stabilisation because of that.

Well I wasn't suggesting blocking stabilisation, quite the contrary, but I take your point.

Upstream were indicating LTS for 4.4.6 back when it was stabilised. Clearly they've had some issues, and moved LTS to 4.4.19 on 4.4.x, then I see the tree has moved back to 4.1.15-r1 yet upstream LTS on 4.1.x is currently 4.1.30. So to me that's all a bit of a pig's breakfast.

Anyway, I'll follow upstream and fix on 4.4.19. I prefer to follow stable here, just to cut down on shooting out corner-cases and staying reasonably current. I don't need cutting-edge, but I have some ARM devices which benefit from the 4.4.x branch, so the drop to stable (as far as the tree is concerned) isn't an option this time. I don't wan't to stay on a superceded source.

[Bigun]

4.4.6 is back as stable

Or be patient... that's another option.

[dantrell]

Not for nitpicking, but just for completeness if others are following the discussion:

Code: Select all

# eclean -d distfiles
 * Building file list for distfiles cleaning...

   The following unavailable installed packages were found
             sys-kernel/gentoo-sources-4.6.7

Code: Select all

# ls -1 /var/lib/portage/distfiles/gen*-4.6*
/var/lib/portage/distfiles/genpatches-4.6-9.base.tar.xz
/var/lib/portage/distfiles/genpatches-4.6-9.extras.tar.xz
/var/lib/portage/distfiles/gentoo-headers-4.6-1.tar.xz
/var/lib/portage/distfiles/gentoo-headers-base-4.6.tar.xz

So there's no reason to be afraid of losing distfiles either. I'm on the same side, btw, because it turns out 4.7.2 is just one of those kernels that introduce a surprise kernel panic on my aging system. So i can't use it right now.

You are nitpicking but that's fine.

I wasn't talking about eclean distfiles because the results are not always immediately obvious since there is often multiple corresponding ebuilds for a particular distfile. In this case, it's:

• aufs-sources-4.6.x
• hardened-sources-4.6.x

So naturally, the related distfiles wouldn't be removed just yet. However, with eclean packages the binary packages (i.e. PKGDIR) would immediately be removed because it corresponds directly to the removed ebuild.

For reinstallation purposes, having the distfiles don't matter if the ebuild isn't present. You also can't reinstall the package directly through a stored binary package because it would have been removed as well. Basically it blocks reinstallations and new installations which is what I was initially trying to say.

Is it really so hard to stabilize a newer kernel before retiring the current one?

Apparently it is hard to stabilise anything at this point. But what does a stable kernel mean, anyway, for your Gentoo system? It is not like any other package in tree, it is impossible for arch teams to test even a tiny part of all hardware that is supported, so whatever gets stabilised just didn't have too many bugs reported in bugzilla. And when that happens, it is actually already obsolete by at least several upstream releases that are much more recommended for use. Two years of stable kernels didn't work for my particular corner case, I wouldn't have dared trying to argue to block stabilisation because of that.

Others have been mentioning stabilization and they have a point. However, that's a more widespread issue with deeper roots and less of a priority than actually having the ebuilds available in the first place.

My argument is against the removal of ebuilds, for good reason.

P.S. For the record, the latest stable 4.6 release is 4.6.7 so if you require this line, use that version. You can find that ebuild here.
Edit: s/depclean/eclean/

According to https://packages.gentoo.org/packages/sy ... oo-sources, the latest gentoo stable is now 4.1.15-r1, not 4.6.7 which is not available. You are perhaps talking about vanilla-sources. (EDIT: I see there was a link, my screen has poor contrast. However, the ebuild is not the problem, the distfile and patches are the problem.)

For me, the removal of the ebuild is the issue.

You are thinking of something else. Your packages will not be uninstalled if the ebuilds are removed so the installed kernel sources will remain. This is what genstorm was initially explaining but I wasn't disputing that.

4.4.6 is back as stable

Or be patient... that's another option.

I'm sure this had more to do with the activity on Gentoo bug #591758 than patience.

That said, restoring the 4.6 line is a good first step but the 4.6.7 release version should have been stablized instead. It contains quite a few fixes and it's not impacted by CVE-2016-5696 as the related patch for the 4.7 line was backported. You can verify this by checking the ChangeLog.

Someone should probably request immediate restoration and stabilization of 4.6.7 with the fix for that CVE being backported as the reason, as well as mention the build failures for NVIDIA drivers, Broadcom STA drivers and ZFS on the 4.7 line.

Edit: So as it turns out, I just noticed that it was 4.4.6 which was restored. I had that swapped with the 4.6 line (simple enough of a mistake to make).

It looks like stabilization (as it pertains to Gentoo) is more of an issue than I thought. 4.4.6 is quite a few releases behind 4.4.19 and if anything, 4.4.18 should be in stable right now while 4.4.19 is marked as ~.

4.6.6 (stable) and 4.6.7 (~), which I wanted restored are still missing but granted, Gentoo bug #591758 wasn't about that.

Given my past experience with Gentoo developers, I think I will just maintain my local overlays and go about my way.

[asturm]

I wasn't talking about eclean distfiles because the results are not always immediately obvious since there is often multiple corresponding ebuilds for a particular distfile. In this case, it's:

• aufs-sources-4.6.x
• hardened-sources-4.6.x

So naturally, the related distfiles wouldn't be removed just yet. However, with eclean packages the binary packages (i.e. PKGDIR) would immediately be removed because it corresponds directly to the removed ebuild.

...but why would you make binary packages out of kernel *sources*?

[dantrell]

I wasn't talking about eclean distfiles because the results are not always immediately obvious since there is often multiple corresponding ebuilds for a particular distfile. In this case, it's:

• aufs-sources-4.6.x
• hardened-sources-4.6.x

So naturally, the related distfiles wouldn't be removed just yet. However, with eclean packages the binary packages (i.e. PKGDIR) would immediately be removed because it corresponds directly to the removed ebuild.

...but why would you make binary packages out of kernel *sources*?

Consistency. Ease of deployment. Other reasons which don't apply to me but might to someone else.

It you can't think of one, then maybe it's not relevant to your interests. Or perhaps... you want company under that bridge?

[asturm]

Nah, certainly not :p I am distributing binary packages myself, locally, but kernel sources are always kept as distfiles, because that's what they are. Basically, one might as well distribute them out-of-tree. However, I have often thought about how nice it would be to distribute the actual kernel binaries to the weaker machines as well over regular emerge. Which would need quite some changes...