Adding a C.UTF-8 locale to our glibc packages
by Mike FABIAN
This patch adds a C.UTF-8 locale as a folder /usr/lib/locale/C.utf8/
to our glibc packages.
This way, the locale is sort of “unremovable” because it is not
affected by the --install-langs option of build-locale-archive.
build-locale-archive completely ignores folders in /usr/lib/locale/
which do not have a “_” in their name.
This is similar to how Debian did it.
I added the LC_* sections which are missing in the Debian source
though because when sections are missing, localedef prints a warning
and I don’t want to use the “-c” option to force the output in spite
of the warnings.
This locale is very close in behaviour to C/POSIX but LC_CTYPE is just
copying from glibc/localedata/locales/i18n (which we have just updated
for Unicode 8.0.0).
So this C.UTF-8 gives us a locale which is very much like the C locale
but uses UTF-8 encoding and tools like "ls" will display all printable
characters from Unicode instead of displaying question marks for
everything non-ASCII.
Sorting (LC_COLLATE) is done strictly via Unicode code point order which
gives the same sorting for the ASCII range as the traditional C locale.
Debian does this like this:
LC_COLLATE
order_start forward
<U0000>
<U0001>
all code points listed individually leaving out the unassigned ranges
<U10FFFE>
<U10FFFF>
UNDEFINED
order_end
END LC_COLLATE
(more than 300000 lines of code points listed).
I used this instead:
LC_COLLATE
order_start forward
<U0000>
..
<UFFFF>
<U10000>
..
<U1FFFF>
<U20000>
..
<U2FFFF>
<UE0000>
..
<UEFFFF>
<UF0000>
..
<UFFFFF>
<U100000>
..
<U10FFFF>
UNDEFINED
order_end
END LC_COLLATE
Which makes the source much shorter and more readable, the result
in the binary is the same, the size of the binary is the same as well,
the complete binary locale needs about 1.8M almost all because
of LC_COLLATE (same on Debian).
Not skipping the ranges currently not assigned in Unicode would make
the locale about 6.5M big. This seems theoretically better to me
but it has probably little benefit sorting unassigned code points
by code point order as well.
Actually I think this should be enough:
LC_COLLATE
order_start forward
UNDEFINED
order_end
END LC_COLLATE
because of:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
opengroup> The symbol UNDEFINED shall be interpreted as including all coded
opengroup> character set values not specified explicitly or via the ellipsis
opengroup> symbol. Such characters shall be inserted in the character collation
opengroup> order at the point indicated by the symbol, and in ascending order
opengroup> according to their coded character set values. If no UNDEFINED symbol is
opengroup> specified, and the current coded character set contains characters not
opengroup> specified in this section, the utility shall issue a warning message and
opengroup> place such characters at the end of the character collation order.
But unfortunately it does not work like that in glibc, which is probably
a bug.
I tried to look at the code to find out why UNDEFINED does not work as
specified in the standard but could not figure it out yet.
(UNDEFINED currently does not work at all as specified, most locale
sources have UNDEFINED somewhere, but the characters not specified
explicitly do not get inserted where UNDEFINED is but instead right at
the top (before all other charcters).
--
Mike FABIAN <mfabian(a)redhat.com>
☏ Office: +49-69-365051027, internal 8875027
睡眠不足はいい仕事の敵だ。
8 years, 1 month
Some --with/--without tweaks
by DJ Delorie
Some minor tweaks to Carlos's patch...
1. Require C++ only when the with/without options call for it
2. When --without docs, make sure there are no docs left in the
install tree to prevent generating RPMs.
Tested all 16 permutations of bootstrap/docs/testsuite/werror, 75% of
the cases failed to produce RPMs without this tweak, 100% produce RPMs
with this tweak.
--- glibc.spec.before 2015-10-26 23:52:05.809000000 -0400
+++ glibc.spec 2015-10-28 16:41:28.879000000 -0400
@@ -1,6 +1,6 @@
%define glibcsrcdir glibc-2.22-193-g315267a
%define glibcversion 2.22.90
-%define glibcrelease 6%{?dist}
+%define glibcrelease 8%{?dist}
# Pre-release tarballs are pulled in from git using a command that is
# effectively:
#
@@ -389,10 +389,14 @@
BuildRequires: rpm >= 4.2-0.56
%endif
+%if %{without boostrap}
+%if %{with testsuite}
# The testsuite builds static C++ binaries that require a C++ compiler
# and static C++ runtime from libstdc++-static.
BuildRequires: gcc-c++
BuildRequires: libstdc++-static
+%endif
+%endif
# Filter out all GLIBC_PRIVATE symbols since they are internal to
# the package and should not be examined by any other tool.
@@ -1017,6 +1021,10 @@
# Compress all of the info files.
gzip -9nvf $RPM_BUILD_ROOT%{_infodir}/libc*
+
+%else
+rm -f $RPM_BUILD_ROOT%{_infodir}/dir
+rm -f $RPM_BUILD_ROOT%{_infodir}/libc.info*
%endif
##############################################################################
@@ -1214,9 +1222,7 @@
# the core glibc package.
sed -i -e '\|%{_libdir}/lib.*_p.a|d' \
-e '\|%{_prefix}/include|d' \
-%if %{with docs}
-e '\|%{_infodir}|d' \
-%endif
rpm.filelist
# Put some static files into the devel package.
@@ -1851,6 +1857,10 @@
%endif
%changelog
+* Wed Oct 28 2015 DJ Delorie <dj#redhat.com> - 2.22.90-8
+- Require gcc-c++ only when needed
+- Fix --without docs to not leave info files
+
* Wed Sep 16 2015 Mike FABIAN <mfabian(a)redhat.com> - 2.22.90-7
- Add the C.UTF-8 locale (#902094).
8 years, 5 months
Backporting security/critical bug fixes
by Florian Weimer
Should we put patches which have been backported upstream in all active
Fedora releases (unless they affect non-Fedora releases or are clearly
minor)?
Florian
8 years, 5 months