Alternative option for solving Fedora i686 vs geode problems

Peter Robinson pbrobinson at
Tue Jun 8 07:17:58 EDT 2010

On Tue, Jun 8, 2010 at 5:31 AM, John Gilmore <gnu at> wrote:
>> 2) FESCo (Fedora Engineering Steering Committee) is dealing with the
>> issue upstream [1][2] in Fedora with the view of getting it fixed
>> upstream for F-14 or at the very least clarified. It was agreed in
>> F-12 that the Geode LX would be supported and that decision wasn't
>> discussed otherwise. Please add to the conversation on the ticket or
>> the list. It might be worth seeing the outcome of this before we go
>> and reinvent the wheel again.
>> Peter
>> [1]
>> (but thread goes back to April)
>> [2]
> It's nice to know we have the attention of the right folks.  But there's
> some useful info we could give them for tomorrow's FESCo meeting.

You can attend. Its an open IRC meeting [1]. It might be worthwhile
showing up as you can probably give more constructive details.

> Do we know which i386/i686 packages in F13 actually contain NOPL
> instructions?  Apparently, glibc does contain them, due to the report
> here from the beta:
> If fixing F13 would only require rebuilding five, ten, or twenty
> packages, then fixing it in the F13 repos (for everybody, not just for
> OLPC) is totally doable.  If it requires a total rebuild, then the fix
> could only occur in the next Fedora release.

Reading below it looks like it just needs one.

> This message suggested that the NOPL instruction doesn't appear in any
> of the coreutils programs:
> To figure this out, I downloaded and booted the F13 "i686" LiveCD and
> did this:
>  for x in {,/usr}{/bin,/sbin,/lib}/* ; do
>    echo $x
>    objdump -d $x | grep nopl
>  done
> It shows nopl's in:


> There are no nopl's anywhere under /lib/modules.  objdump couldn't
> examine the mashed kernel image in /boot, but I bet it's free or
> almost free of nopl's.
> Virtually all of these files are generated from the libc sources
> (except two executables statically-linked with libc).  In short, this
> is almost exclusively a glibc problem.  It's probably just a bug
> introduced into the glibc configuration or makefile in F13.

Or in the new major 2.12 version of glibc shipped with Fedora? Well
its not hard to rebuild a scratch build of glibc in Fedora build
systems. Is it possible for someone to workout what changes we should
try and test? If someone can work it out I'll quite happily push
scratch builds through the build system if no one else can to allow
testing and verification of the problem. Changes to the way it was
built during F-13 can be found in the rpm cvs [2] if you want to be
able to compare changes.

> Fedora Bug 579838 should be reopened -- it was inappropriately closed
> by Andreas Schwab on 2010-04-07.  (Jakub's comment wasn't pretty, but
> he didn't close the bug - Andreas did.  But closing bugs
> inappropriately to make your bug stats look good is rampant in every
> development org - e.g. I regularly complain to Ubuntu about this.)
> This is not a dead issue for F13, and we should seek solutions within
> F13 as well as outside it.

Feel free to reopen it, if you can't let me know and I will.

> Oddly, F13 offers release CDs and DVDs only for "i386" (and x86-64),
> but offers live CDs only for "i686" (and x86-64).  It is completely
> unclear from the documentation (which suggests using these
> interchangeably) whether the "i386" DVD is really compiled for i686 or
> i386.  See:

It is i686, I'll file a bug to get it verified on the site. Thanks.

>    (hover over the "Download Now" buttons to see which ISO image each
>     one offers.)
>        John


More information about the Devel mailing list