coreutils currently configures `ls` to use 256 colours rather than 16.
This is a downstream Fedora change which means that `ls` doesn't
follow the colour palette that's configured in the terminal.
We are therefore planning on removing the downstream customisation, so
that `ls` uses the 16 colour palette, which the user is able to
control through the app. This will make `ls` consistent with other
commands. It will also mean that improvements to the default colour
palette will be seen in ls.
If anyone knows of any issues with this, please comment on the issue:
this is more of a head's up than a bug per se (well, I'm actually not
sure if it's a bug, is it?), but I've had a package fail to build due to
LTO and neon optimisations:
Basically what they do is compile different .a with different level of
optimisations as required, and then link them into the final program
without any optim flag and intend to have it just use the optimised
functions as is.
Without LTO, this just embeds the code so the rest of the program was
built naively and it used to work, but with LTO the compiler tries to
use neon optimisations at some point apparently and the link fails :
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/arm_neon.h:10426:22: fatal error: You must enable NEON instructions (e.g. ‘-mfloat-abi=softfp’ ‘-mfpu=neon’) to use these intrinsics.
The "fix" here is simple and upstream is reactive so I'll just resubmit
the package with -mfpu=neon appended to linker args as well, but this
might come bite other projects as well.
I don't think gcc can intuite this so it's probably not a bug though
(hence I'm not planning on opening a bug), but it is a regression of
Anyway I hope this mail can save others a few minutes of research :)
Sometimes you need to get into the build directory, in my case for
OpenColorIO I use help2man to generate some of the man pages.
I had to rely on the power of Google/Gmail to find Neal's response to one
of my earlier emails to find the answer again...
But that begs the question, now that we have updated %cmake, and new
%cmake_build & %cmake_install, why is it %_vpath_builddir and not
Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
To convert UTC to your local time, take a look at
date -d '2020-08-05 14:00 UTC'
Links to all issues to be discussed can be found at:
= Discussed and Voted in the Ticket =
F33 Self-Contained Change: .NET Core on Aarch64
APPROVED (+7, 0, -0)
F33 Self-Contained Change: Stratis 2.1.0
APPROVED (+9, 0, -0)
= Followups =
#topic #2440 F33 System-Wide Change: Patches in Forge macros - Auto
macros - Detached rpm changelogs
= New business =
No tickets older than 7 days are waiting for input or are tagged with
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
真実はいつも一つ！/ Always, there's only one truth!