Re: [lfs-dev] Linux kernel policy
On Tue, Mar 31, 2020 at 11:35:21PM +0100, Ken Moffat via lfs-dev wrote: > > Meanwhile, looking at the commits for 5.6.1-rc1, I don't know if the > fix for intel wifi has even gone upstream yet, but none of the items > for .1 look relevant to that, so perhaps hold off for .2 for those > people who use intel wifi. > That fix went upstream yesterday as part of the networking fixes for 5.7, and is in 5.6.2-rc1, so 5.6.2 should be ok for intel wifi. ĸen -- OMG!!! Ponies!!! -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On 3/31/20 11:13 PM, Kevin Buckley wrote: On Tue, 31 Mar 2020 at 04:06, Bruce Dubbs via lfs-dev wrote: I would like to propose keeping the kernel at the most recent long term support (LTS) version for the book. Users can, of course, use whatever version they want. What do you think? -- Bruee A slightly different take on this to most of the other postings, but would there be any gain, for the LFS Book, in promoting (and documenting) the use of incremental kernel updates? I'm aware that Thomas Trepl does this, even though it's not documented in his Multilib patch. The thinking would be that whilst the LFS Book development line pinned itself at a given revision, the Book would document the process whereby incremental updates were made to the kernel sources and, where any given patch-level of the kernel was thought to have beome significant enough to be needed in a LFS system, ahead of a release, that recommendation to upgrade could be made in the current Book's Errata, as well as the SVN head. Just my thr'pen'th though: probably file under "you distro: your rules", Updating a kernel is just a rebuild and install as in Chapter 8 of the book and then an edit of grub.cfg. Nothing else is really needed. The incremental updates (I assume you mean patches) just is a minor variation that affects download time/disk space. It's really not a big difference from rebuilding the current kernel with different options. Do remember that you should never reinstall the kernel's API headers Section 6.7). glibc depends on that. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On Tue, 31 Mar 2020 at 04:06, Bruce Dubbs via lfs-dev wrote: > > I would like to propose keeping the kernel at the most recent long term > support (LTS) version for the book. Users can, of course, use whatever > version they want. > > What do you think? > >-- Bruee A slightly different take on this to most of the other postings, but would there be any gain, for the LFS Book, in promoting (and documenting) the use of incremental kernel updates? I'm aware that Thomas Trepl does this, even though it's not documented in his Multilib patch. The thinking would be that whilst the LFS Book development line pinned itself at a given revision, the Book would document the process whereby incremental updates were made to the kernel sources and, where any given patch-level of the kernel was thought to have beome significant enough to be needed in a LFS system, ahead of a release, that recommendation to upgrade could be made in the current Book's Errata, as well as the SVN head. Just my thr'pen'th though: probably file under "you distro: your rules", Kevin -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On 2020-03-31 23:35 +0100, Ken Moffat via lfs-dev wrote: > On Tue, Mar 31, 2020 at 11:37:15AM -0500, Bruce Dubbs via lfs-dev wrote: > > On 3/31/20 4:14 AM, Pierre Labastie via lfs-dev wrote: > > > On Tue, 2020-03-31 at 08:52 +0800, Xi Ruoyao via lfs-dev wrote: > > > > On 2020-03-30 15:05 -0500, Bruce Dubbs via lfs-dev wrote: > > > > > > > > For 5.4 LTS, we got 21 releases in this year, and 12 releases since > > > > Feb. 1st. > > > > No significant improvement. LTS meaning continuing maintenance so > > > > we'll still > > > > get one release for each severe bug (even if it's a bug in a strange > > > > server > > > > motherboard). > > > > > > > > I think we can just hold on kernel 5.x.0 for the development book > > > > unless there > > > > is a bug making it unusable. (There is already a note telling the > > > > audience to > > > > use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2. > > > > > > > > > > I'd say that what we have (update the kernel to latest when updating > > > other parts of the book) is not so bad, except we should refrain to > > > update to whatever.0 versions. It's not because the maintainers have > > > done some mistake once (modifying a driver between the last rc and the > > > release IIUC), that they always will do, but we should consider > > > whatever.0 versions are still "development" (not only for kernel > > > actually). Oh I didn't know that. A similar issue is mesa-x.y.0. From [mesa-20.0.0 release note][1]: > Mesa 20.0.0 is a new development release. People who are concerned with > stability and reliability should stick with a previous release or wait for > Mesa 20.0.1. [1]: https://mesa3d.org/relnotes/20.0.0.html And I've noticed some segfaults related to mesa libraries using 20.0.0. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On Tue, Mar 31, 2020 at 11:37:15AM -0500, Bruce Dubbs via lfs-dev wrote: > On 3/31/20 4:14 AM, Pierre Labastie via lfs-dev wrote: > > On Tue, 2020-03-31 at 08:52 +0800, Xi Ruoyao via lfs-dev wrote: > > > On 2020-03-30 15:05 -0500, Bruce Dubbs via lfs-dev wrote: > > > > > > For 5.4 LTS, we got 21 releases in this year, and 12 releases since > > > Feb. 1st. > > > No significant improvement. LTS meaning continuing maintenance so > > > we'll still > > > get one release for each severe bug (even if it's a bug in a strange > > > server > > > motherboard). > > > > > > I think we can just hold on kernel 5.x.0 for the development book > > > unless there > > > is a bug making it unusable. (There is already a note telling the > > > audience to > > > use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2. > > > > > > > I'd say that what we have (update the kernel to latest when updating > > other parts of the book) is not so bad, except we should refrain to > > update to whatever.0 versions. It's not because the maintainers have > > done some mistake once (modifying a driver between the last rc and the > > release IIUC), that they always will do, but we should consider > > whatever.0 versions are still "development" (not only for kernel > > actually). > > > > With this policy, chances are that the first version we include in a > > 5.x series is higher than 5.x.1. > > > > Anyway, since LTS gets updated very often too, there is no much gain in > > using LTS. > > OK. I guess we can go with that. > > -- Bruce > Meanwhile, looking at the commits for 5.6.1-rc1, I don't know if the fix for intel wifi has even gone upstream yet, but none of the items for .1 look relevant to that, so perhaps hold off for .2 for those people who use intel wifi. ĸen -- OMG!!! Ponies!!! -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On 3/31/20 4:14 AM, Pierre Labastie via lfs-dev wrote: On Tue, 2020-03-31 at 08:52 +0800, Xi Ruoyao via lfs-dev wrote: On 2020-03-30 15:05 -0500, Bruce Dubbs via lfs-dev wrote: We have almost always updated the linux kernel to the "mainline" release. We do skip intermediate releases though because of the frequency of releases. For instance, today is the 90th day of the year, but there have been about 34 releases. The first release of the year was 5.4.8. There is a little overlap there because 5.4 is a longterm release. In any case there have been 13 releases for 5.5 since February 1st (14 if you count 5.6). I would like to propose keeping the kernel at the most recent long term support (LTS) version for the book. Users can, of course, use whatever version they want. What do you think? -- Bruee For 5.4 LTS, we got 21 releases in this year, and 12 releases since Feb. 1st. No significant improvement. LTS meaning continuing maintenance so we'll still get one release for each severe bug (even if it's a bug in a strange server motherboard). I think we can just hold on kernel 5.x.0 for the development book unless there is a bug making it unusable. (There is already a note telling the audience to use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2. I'd say that what we have (update the kernel to latest when updating other parts of the book) is not so bad, except we should refrain to update to whatever.0 versions. It's not because the maintainers have done some mistake once (modifying a driver between the last rc and the release IIUC), that they always will do, but we should consider whatever.0 versions are still "development" (not only for kernel actually). With this policy, chances are that the first version we include in a 5.x series is higher than 5.x.1. Anyway, since LTS gets updated very often too, there is no much gain in using LTS. OK. I guess we can go with that. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On Tue, 2020-03-31 at 08:52 +0800, Xi Ruoyao via lfs-dev wrote: > On 2020-03-30 15:05 -0500, Bruce Dubbs via lfs-dev wrote: > > We have almost always updated the linux kernel to the "mainline" > > release. We do skip intermediate releases though because of the > > frequency of releases. > > > > For instance, today is the 90th day of the year, but there have > > been > > about 34 releases. The first release of the year was 5.4.8. There > > is a > > little overlap there because 5.4 is a longterm release. In any > > case > > there have been 13 releases for 5.5 since February 1st (14 if you > > count > > 5.6). > > > > I would like to propose keeping the kernel at the most recent long > > term > > support (LTS) version for the book. Users can, of course, use > > whatever > > version they want. > > > > What do you think? > > > >-- Bruee > > For 5.4 LTS, we got 21 releases in this year, and 12 releases since > Feb. 1st. > No significant improvement. LTS meaning continuing maintenance so > we'll still > get one release for each severe bug (even if it's a bug in a strange > server > motherboard). > > I think we can just hold on kernel 5.x.0 for the development book > unless there > is a bug making it unusable. (There is already a note telling the > audience to > use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2. > I'd say that what we have (update the kernel to latest when updating other parts of the book) is not so bad, except we should refrain to update to whatever.0 versions. It's not because the maintainers have done some mistake once (modifying a driver between the last rc and the release IIUC), that they always will do, but we should consider whatever.0 versions are still "development" (not only for kernel actually). With this policy, chances are that the first version we include in a 5.x series is higher than 5.x.1. Anyway, since LTS gets updated very often too, there is no much gain in using LTS. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On 2020-03-31 08:52 +0800, Xi Ruoyao via lfs-dev wrote: > LTS meaning continuing maintenance so we'll still get one release for each > severe bug (even if it's a bug in a strange server motherboard). s/motherboard/& driver/ I can't type :(. > I think we can just hold on kernel 5.x.0 for the development book unless there > is a bug making it unusable. (There is already a note telling the audience to > use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On 2020-03-30 15:05 -0500, Bruce Dubbs via lfs-dev wrote: > We have almost always updated the linux kernel to the "mainline" > release. We do skip intermediate releases though because of the > frequency of releases. > > For instance, today is the 90th day of the year, but there have been > about 34 releases. The first release of the year was 5.4.8. There is a > little overlap there because 5.4 is a longterm release. In any case > there have been 13 releases for 5.5 since February 1st (14 if you count > 5.6). > > I would like to propose keeping the kernel at the most recent long term > support (LTS) version for the book. Users can, of course, use whatever > version they want. > > What do you think? > >-- Bruee For 5.4 LTS, we got 21 releases in this year, and 12 releases since Feb. 1st. No significant improvement. LTS meaning continuing maintenance so we'll still get one release for each severe bug (even if it's a bug in a strange server motherboard). I think we can just hold on kernel 5.x.0 for the development book unless there is a bug making it unusable. (There is already a note telling the audience to use latest 5.x.y.) And, we should update to latest 5.x.y before 9.2. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On Mon, Mar 30, 2020 at 03:12:41PM -0500, Douglas R. Reno via lfs-dev wrote: > > On 3/30/20 3:05 PM, Bruce Dubbs via lfs-dev wrote: > > We have almost always updated the linux kernel to the "mainline" > > release. We do skip intermediate releases though because of the > > frequency of releases. > > > > For instance, today is the 90th day of the year, but there have been > > about 34 releases. The first release of the year was 5.4.8. There is a > > little overlap there because 5.4 is a longterm release. In any case > > there have been 13 releases for 5.5 since February 1st (14 if you count > > 5.6). > > > > I would like to propose keeping the kernel at the most recent long term > > support (LTS) version for the book. Users can, of course, use whatever > > version they want. > > > > What do you think? > > > > -- Bruee > > I think this is a good idea, especially after the IWLWIFI problems with > Linux-5.6 > (https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Broken-Intel-IWLWIFI) > > However, the current version of the LTS kernel is 5.4.28. Between > 5.4.14-5.4.16, there was a problem with kernel's cryptography implementation > that would cause cryptsetup, bluez, and other applications that rely off the > kerne's crypto implementation to crash. > > I don't recall if we've had to adapt anything to changes in 5.5 or not, I > think that was all 5.2/5.3-related. > > I agree that downgrading to 5.4 might be the best approach for now though. > I have mixed feelins about the current LTS (5.4) kernel. It seems to me that gkh is keeping it a lot closer to Linus's git head than ever used to be the case, perhaps because of all the [PATCH AUTOSEL] mails on lkml which I filter out because at least in the early days a lot of them were just wrong and added to the noise. My impression from picking random point releases of current kernels is that for my machine some are good and others less good - usually the problems get fixed (often by more backports) fairly quickly, but I no longer have confidence in saying that the latest point release should be used. If we do revert to 5.4, we need 5.4 headers and presumably 5.4 iproute2. I'm currently running 5.5.7 on my laptop and most of my current desktops, but 5.6.0-rc5 on one. However, on my server (Athlon 200GE) I'm running 5.4.23 with LFS-9.1. I used to use LTS for my server, but when I got that machine I used 5.3.latest because 4.19 was almost certainly too old to associate its video (Raven Ridge) with amdgpu rather than radeon, and I want a framebuffer for when I use it directly, 80x25 doesn't cut the mustard). Will be updating my desktops to 5.6.0 when time permits, because I don't need IWLWIFI. For my laptop, will only update the kernel when I become aware of a problem, or when I update it to 9.2. And for the one or two machines where I did builds with 5.5 headers I didn't notice any problems in what _I_ build. Hmm, actually the firefox widevine update leading to a problem with 68.5.0 might have been related to the headers, it was unclear if kernel headers or glibc was the cause. ĸen -- When alle is ſayed and all is done, ye must chooſe your faces wisely, for soon enouff ye will be playing with fyre." The Nice and Accurate Prophecies of Agnes Nutter, Prophecy 5004 -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux kernel policy
On 3/30/20 3:05 PM, Bruce Dubbs via lfs-dev wrote: We have almost always updated the linux kernel to the "mainline" release. We do skip intermediate releases though because of the frequency of releases. For instance, today is the 90th day of the year, but there have been about 34 releases. The first release of the year was 5.4.8. There is a little overlap there because 5.4 is a longterm release. In any case there have been 13 releases for 5.5 since February 1st (14 if you count 5.6). I would like to propose keeping the kernel at the most recent long term support (LTS) version for the book. Users can, of course, use whatever version they want. What do you think? -- Bruee I think this is a good idea, especially after the IWLWIFI problems with Linux-5.6 (https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Broken-Intel-IWLWIFI) However, the current version of the LTS kernel is 5.4.28. Between 5.4.14-5.4.16, there was a problem with kernel's cryptography implementation that would cause cryptsetup, bluez, and other applications that rely off the kerne's crypto implementation to crash. I don't recall if we've had to adapt anything to changes in 5.5 or not, I think that was all 5.2/5.3-related. I agree that downgrading to 5.4 might be the best approach for now though. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Linux kernel policy
We have almost always updated the linux kernel to the "mainline" release. We do skip intermediate releases though because of the frequency of releases. For instance, today is the 90th day of the year, but there have been about 34 releases. The first release of the year was 5.4.8. There is a little overlap there because 5.4 is a longterm release. In any case there have been 13 releases for 5.5 since February 1st (14 if you count 5.6). I would like to propose keeping the kernel at the most recent long term support (LTS) version for the book. Users can, of course, use whatever version they want. What do you think? -- Bruee -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
