[lfs-dev] glibc-2.23

DJ Lucas dj at linuxfromscratch.org
Sat Feb 20 20:24:19 PST 2016

On 2/19/2016 8:04 PM, Ken Moffat wrote:
> On Fri, Feb 19, 2016 at 06:51:43PM -0600, DJ Lucas wrote:
>> On 2/19/2016 3:18 PM, Bruce Dubbs wrote:
>>> I've built the new glibc in my sandbox and will start doing a -rc2 when
>>> my full build completes in the next hour or so.
>>> I did look at the test failures:
>>> XPASS: elf/tst-protected1a
>>> XPASS: elf/tst-protected1b
>>> FAIL: posix/tst-getaddrinfo4
>>> FAIL: posix/tst-getaddrinfo5
>> None of the stuff from the tarball in 418 has been added. Next release.
> A shame - I gave up when I realised the tarball only built the tests.
> It looks as if understanding how to invoke new glibc tests is way
> beyond my comprehension.

I didn't spend any time on it. I'll take a peek later on, but right now, 
I think it's a fairly safe assumption that these new test failures are 
directly related to the new code and can be safely ignored.

>>> I've updated the text to add posix/tst-getaddrinfo5 to the list of known
>>> failures.  When I look at the text we have now, I also see:
>>> * The rt/tst-cputimer1 and rt/tst-cpuclock2 tests have been known to
>>> fail. The reason is not completely understood, but indications are that
>>> minor timing issues can trigger these failures.
>> I think I had still seen one of the mentioned tests when building on single
>> processor in KVM, but don't recall which. I'll get a build on KVM before
>> release day.
> That is good to hear.

Yeah, I should have pretty good coverage for us, but unfortunately, I'm 
just not yet ready to migrate those hosts yet. They will be done 
probably halfway through next release cycle. I absolutely have to 
package them, too important for me not to do so. I use QLX, virtio, and 
utilize both connection types, also have a windows 10 guest working with 
the RH virtio drivers too that I can drag in for fun. :-)

OT: virtio obviously works well with Linux guests, but runs amazingly 
well with Windows guests as well if needed. That particular Windows 10 
load is faster virtualized than the factory load on original hardware. 
Now, keep in mind that's not exactly a 1:1 comparison, it's a 
convertible (no vendor bloatware installed, no tablet drivers, 
enterprise vs pro), but I was pretty impressed none the less. I get to 
both desktops in around 8-10 seconds from power on (the variable is me 
typing at the GDM login). I did have to disable the startup health check 
in the guest Windows 10 VM as it results in a SMART error for the virtio 
HDD! My poor helpdesk folks didn't like the repeated bogus support 
tickets. :-)


More information about the lfs-dev mailing list