On 12/01/2018 05:50 PM, Ken Moffat via blfs-support wrote:
On Sat, Dec 01, 2018 at 10:23:11PM +0000, Ken Moffat via blfs-support wrote:
On Sat, Dec 01, 2018 at 08:00:20PM +0000, Ken Moffat via blfs-support wrote:
Concentrating now on trying to update glibc (one CVE, one "assert
on invocation rather than segfault on exit", one "regression -
slowness in string operations - in certain haswells" which might
affect mine : the change implies new firmware might make the fix
irrelevant, but the problem was seen even in fedora.
Still testing (only having 4GB for /tmp, and filling that up with
past builds and DESTDIRs, blew out my first attempt), but I've
dusted off my "upgrade glibc" script in the hope this will work.
I am interested in that script. I'm always quite reluctant to update
glibc. To me it is the heart of the system. I am comfortable with live
updates with any other package.
I build a new system if I think a new glibc is needed.
Can you post your script?
Dropped the "assert on invocation" patch - its test fails when
applied to 2.28 (specifically, all 5 parts of the test expect a
value of -6 but get a value of 6). Passes in glibc-master, so it
must depend on something else there. But master is where the
pythonization of glibc is taking place, so I'm not looking at
previous changes there, I suspect the early stages of using python
might break things in LFS.
I do not want to patch glibc in the lfs-dev book. It will automatically
be incorporated in the next glibc release which is scheduled before we
release the next version of LFS.
If anyone is running a production system based on our -dev books, then I
question that decision.
Is grumpiness contagious ?
Sometimes, but not this time.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
