F36 Change: Default To Noto Fonts (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts
== Summary ==
Changing the default fonts for various languages to Noto Fonts as much
as possible, to make consistency on the text rendering.
== Owner ==
* Name: [[User:Tagoh|Akira TAGOH]]
* Email: <tagoh(a)redhat.com>
== Detailed Description ==
For a long time we have used DejaVu fonts as the default font for
European and other language scripts. On the other hand some language
scripts are not covered by DejaVu and hence have other default fonts.
(A few languages like Chinese, Japanese and Korean, as well as
Gurmukhi, Sinhala, and emoji are already using Noto fonts by default
for some time.) This situation leads to inconsistencies in text
rendering on applications and desktops, particularly when mixing
different character sets. Further Noto fonts bring some further
advantages: the fonts are generally higher quality and support
variable fonts for most scripts, making them more compact.
This change aims to provide better experience and consistent text
rendering across more languages by replacing DejaVu with Noto as the
general system default set of fonts.
The following packages will be installed by default to replace
DejaVu's coverage:
* google-noto-sans-vf-fonts
* google-noto-serif-vf-fonts
* google-noto-sans-mono-vf-fonts
* google-noto-sans-arabic-vf-fonts
* google-noto-sans-cherokee-vf-fonts
* google-noto-sans-thaana-vf-fonts
* google-noto-sans-hebrew-vf-fonts
* google-noto-rashi-hebrew-vf-fonts
* google-noto-sans-math-vf-fonts
* google-noto-sans-armenian-vf-fonts
* google-noto-serif-armenian-vf-fonts
* google-noto-sans-canadian-aboriginal-vf-fonts
* google-noto-sans-georgian-vf-fonts
* google-noto-serif-georgian-vf-fonts
* google-noto-sans-lao-vf-fonts
* google-noto-serif-lao-vf-fonts
* google-noto-serif-gurmukhi-vf-fonts
* google-noto-serif-sinhala-vf-fonts
And you can check
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to
see what languages will be affected by this change.
== Benefit to Fedora ==
We would get better text rendering on applications and desktops. Also
this change should save about 6MB on the fresh install.
<pre>
$ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts
| awk 'BEGIN{a=0}{a+=$5}END{print a}'
10789272</pre>
<pre>
$ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts
google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts
google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts
google-noto
-sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts
google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f
onts google-noto-serif-armenian-vf-fonts
google-noto-sans-canadian-aboriginal-vf-fonts
google-noto-sans-georgian-vf-f
onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts
google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts
google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print
a}'
4753340
</pre>
== Scope ==
* Proposal owners:
** Update google-noto-fonts and dejavu-fonts to change the priority
for fontconfig config.
** Update langpacks to update the dependency.
** Update comps to make Noto fonts default.
** Update lorax templates related to DejaVu.
** Update fontconfig to change the order of fonts in the builtin config.
* Other developers:
** Packagers who owns packages implicitly expects DejaVu is installed
by default will needs to update the dependency for them.
* Release engineering: [https://pagure.io/releng/issue/10492 #10492]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The migration will be done by updating langpacks. after upgrading and
rebooting, the default font will be Noto instead of DejaVu.
Since this change aims to switch non-variable fonts to variable fonts,
it may not works with legacy applications as expected such as missing
some variants. in that case, you can install non-variable fonts
packages. the package name will be similar and simply drop `-vf` from
the variable fonts packages.
== How To Test ==
* This change can be simply tested by `fc-match` command like
`fc-match sans:lang=<your langauge>`, `fc-match serif:lang=<your
language>` and `fc-match monospace:lang=<your language>`. You can
check the expected result from
[https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table].
* Test the text rendering in your favorite application, which use the
system default font.
== User Experience ==
Users will see the default font is changed to Noto by this change
except for some languages which has much better quality of fonts.
== Dependencies ==
Only dejavu-fonts, langpacks, and fontconfig are required to update.
Other packages which explicitly has a dependency to dejavu-fonts are
basicaly optional to update.
== Contingency Plan ==
* Contingency mechanism: Revert the relevant packages updated.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None.
== Release Notes ==
The default fonts for most languages will be Google Noto fonts instead
of DejaVu, to keep consistency on the text rendering and to provide
better quality among languages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 months
Plan / proposal: enable openQA update testing and potentially
gating on Rawhide updates
by Adam Williamson
Hi folks!
We've had openQA testing of updates for stable and branched releases,
and gating based on those tests, enabled for a while now. I believe
this is going quite well, and I think we addressed the issues reported
when we first enabled gating - Bodhi's gating status updates work more
smoothly now, and openQA respects Bodhi's "re-run tests" button so
failed tests can be re-triggered.
A few weeks ago, I enabled testing of Rawhide updates in the openQA
lab/stg instance. This was to see how smoothly the tests run, how often
we run into unexpected failures or problems, and whether the hardware
resources we have are sufficient for the extra load.
So far this has been going more smoothly than I anticipated, if
anything. The workers seem to keep up with the test load, even though
one out of three worker systems for the stg instance is currently out
of commission (we're using it to investigate a bug). We do get
occasional failures which seem to be related to Rawhide kernel slowness
(e.g. operations timing out that usually don't otherwise time out), but
on the whole, the level of false failures is (I would say) acceptably
low, enough that my current regime of checking the test results daily
and restarting failed ones that don't seem to indicate a real bug
should be sufficient.
So, I'd like to propose that we enable Rawhide update testing on the
production openQA instance also. This would cause results to appear on
the Automated Tests tab in Bodhi, but they would be only informational
(and unless the update was gated by a CI test, or somehow otherwise
configured not to be pushed automatically, updates would continue to be
pushed 'stable' almost immediately on creation, regardless of the
openQA results).
More significantly, I'd also propose that we turn on gating on openQA
results for Rawhide updates. This would mean Rawhide updates would be
held from going 'stable' (and included in the next compose) until the
gating openQA tests had run and passed. We may want to do this a bit
after turning on the tests; perhaps Fedora 37 branch point would be a
natural time to do it.
Currently this would usually mean a wait from update submission to
'stable push' (which really means that the build goes into the
buildroot, and will go into the next Rawhide compose when it happens)
of somewhere between 45 minutes and a couple of hours. It would also
mean that if Rawhide updates for inter-dependent packages are not
correctly grouped, the dependent update(s) will fail testing and be
gated until the update they depend on has passed testing and been
pushed. The tests for the dependent update(s) would then need to be re-
run, either by someone hitting the button in Bodhi or an openQA admin
noticing and restarting them, before the dependent update(s) could be
pushed.
In the worst case, if updated packages A and B both need the other to
work correctly but the updates are submitted separately, both updates
may fail tests and be blocked. This could only be resolved by waiving
the failures, or replacing the separate updates with an update
containing both packages.
All of those considerations are already true for stable and branched
releases, but people are probably more used to grouping updates for
stable and branched than doing it for Rawhide, and the typical flow of
going from a build to an update provides more opportunity to create
grouped updates for branched/stable. For Rawhide the easiest way to do
it if you need to do it is to do the builds in a side tag and use
Bodhi's ability to create updates from a side tag.
As with branched/stable, only critical path updates would have the
tests run and be gated on the results. Non-critpath updates would be
unaffected. (There's a small allowlist of non-critpath packages for
which the tests are also run, but they are not currently gated on the
results).
I think doing this could really help us keep Rawhide solid and avoid
introducing major compose-breaking bugs, at minimal cost. But it's a
significant change and I wanted to see what folks think. In particular,
if you find the existing gating of updates for stable/branched releases
to cause problems in any way, I'd love to hear about it.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
3 months, 2 weeks
RISC-V -- are we ready for more, and what do we need to do it?
by Matthew Miller
Hi all! I just got back from Open Source Summit, several of the talks I
found interesting were on RISC-V -- a high-level one about the
organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official
Fedora arch. As I understand it, the major infrastructure blocker is simply
that there isn't server-class hardware (let alone hardware that will build
fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
as builders, could we build fast enough under QEMU emulation to work? We
have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of
the distro which don't build yet? Is there a big enough risc-v team to
respond to arch-specific build failures? And, do we have enough people to do
QA around release time?
* see http://fedora.riscv.rocks/koji/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3 months, 2 weeks
Self Introduction: Andreas Vögele
by Andreas Vögele
Hello Fedora developers,
I'm Andreas from Stuttgart in Germany. I'm a system administrator and
software developer, who moved his computers to Fedora about a year ago.
I've written a handful of Perl modules that I package at the Open Build
Service and Copr. I'd like to maintain some of these modules directly in
Fedora. In the past, I maintained ports of other software at
SlackBuilds.org and OpenBSD. Occasionally, I contribute patches to free
software projects. I enjoy programming in C, Perl and recently Kotlin.
Kind regards,
Andreas
3 months, 3 weeks
Conflicting build-ids in nekovm and haxe
by Andy Li
Hi list,
Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901
Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages contains "/usr/lib/.build-id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c".
The nekovm one is a symlink to "/usr/bin/neko". The haxe one to "/usr/bin/haxelib".
Both the neko and haxelib binaries are built with libneko, with a nearly identical main.c with the only difference of the present of neko bytecode embedded as a byte array (neko: the byte array is null; haxelib: the byte array is the haxelib neko bytecode).
I'm not sure how to resolve it.
Please advice.
Best regards,
Andy
4 months, 3 weeks
can't install package pipewire-jack-audio-connection-kit
by Martin Gansser
Hi,
when trying to install pipewire-jack-audio-connection-kit i get this error message:
# dnf -y install pipewire-jack-audio-connection-kit
Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020.
Error:
Problem: problem with installed package jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- conflicting requests
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
- package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
How can i fix this ?
Regards
Martin
6 months, 3 weeks
Planning to start unifying native and mingw packages
by Sandro Mani
Hi
Following recent discussions and to reduce the maintenance burden, I'm
planning to start merging native and mingw packages. Initially, I'll be
looking at these packages where I maintain both variants:
eigen3 mingw-eigen3
enchant2 mingw-enchant2
freeimage mingw-freeimage
gdal mingw-gdal
GeographicLib mingw-GeographicLib
geos mingw-geos
giflib mingw-giflib
gtkspell3 mingw-gtkspell3
gtkspellmm30 mingw-gtkspellmm30
jxrlib mingw-jxrlib
leptonica mingw-leptonica
libgeotiff mingw-libgeotiff
libimagequant mingw-libimagequant
libkml mingw-libkml
librttopo mingw-librttopo
libspatialite mingw-libspatialite
libwebp mingw-libwebp
openjpeg2 mingw-openjpeg2
OpenSceneGraph mingw-OpenSceneGraph
osgearth mingw-osgearth
podofo mingw-podofo
proj mingw-proj
python-pillow mingw-python-pillow
qtspell mingw-qtspell
shapelib mingw-shapelib
svg2svgt mingw-svg2svgt
tesseract mingw-tesseract
uriparser mingw-uriparser
I'm performing test builds here [1]. Once I've got them all building
there, if there are no objections, I plan to push to F37 and retire all
the corresponding mingw repos.
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/
6 months, 3 weeks
F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Create a corresponding macro for each compiler flag in the
redhat-rpm-config macro file and create "extra flag" macros to make it
easier for packages to add and remove compiler flags.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
The macros file in the redhat-rpm-config package contains a list of
default compiler flags for packages to use when compiling C, C++, and
Fortran packages. There is currently no standard way to remove or add
to the set of default flags. Most packages use a combination of echo
and sed to remove unwanted flags or add new ones. Some examples:
compiler-rt:
[https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt...
global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)]
julia:
[https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS
//')]
This change will add new macros which will make it easier for packages
to add and remove their own compiler flags. This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these new macros will give packagers
even more fine-grained control over the options.
The proposed macros for adding new flags are:
%_pkg_extra_cflags
%_pkg_extra_cxxflags
%_pkg_extra_fflags
%_pkg_extra_ldflags
These will be added to %{build_cflags}, %{build_cxxflags},
%{build_fflags}, and %{build_ldflags} respectively to allow packges to
add their own flags to the default list: e.g.
%build_cflags %{optflags} %{_pkg_extra_cflags}
The proposed new macros to represent existing flags are:
%_flag_fstack_protector_strong -fstack-protector-strong
%_flag_z_now -Wl,-z,now
%_flag_z_defs -Wl,-z,defs
%_flag_flto_auto -flto=auto
%_flag_ffat_lto_objects -ffat-lto-objects
%_flag_o -O2
%_flag_f_exceptions -fexceptions
%_flag_g -g
%_flag_grecord_gcc_switches -grecord-gcc-switches
%_flag_pipe -pipe
%_flag_wall -Wall
%_flag_werror_format_security -Werror=format-security
%_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2
%_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS
%_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables
%_flag_fstack_clash_protection -fstack-clash-protection
%_flag_fcf_protection -fcf-protection
%_flag_mbranch_protection_standard -mbranch-protection=standard
With these new macros, the examples from above could be re-written as:
compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
julia: %global _flag_glibcxx_assertions %{nil}
For more details see the
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9...
Prototype Implementation].
In addition to adding these new macros, the packaging guidelines will
be updated to require that all new flags added to redhat-rpm-config
have their own RPM macro.
== Benefit to Fedora ==
* It will provide a standard way to disable existing compiler flags or
enable new ones that is more simple and robust than the existing echo
+ sed solution.
* It will make it easier to determine which packages disable or add
compiler flags by doing a simple grep of the spec files.
* It will make it easier for toolchain developers to experiment with
adding new flags to the distribution as this can be done with a simple
macro definition instead of patching redhat-rpm-config.
== Scope ==
* Proposal owners:
** Proposal owners will update the redhat-rpm-config package and add
the new macros.
** Proposal owners will test the changes to ensure that the correct
flags are still being used.
* Other developers:
** Other developers may, but are not required to, update their
packages to use the new macros.
* Release engineering: [https://pagure.io/releng/issues/10819 #10819]
* Policies and guidelines:
** The Fedora packaging policy will be updated to require that new
flags added to redhat-rpm-config come with their own RPM macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
None.
== How To Test ==
* This can be tested by inspecting the value of the %{build_cflags},
%{build_cxxflags}, %{build_fflags}, and %{build_ldflags} and ensuring
they are the same before and after the change.
* This can be tested by modifying some of the new macros in a spec
file and ensuring that the changes appear in the appropriate macro
mentioned above.
== User Experience ==
This is a change for developers and will have no impact to the user experience.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Change owner
will revert the update to redhat-rpm-config.
* Contingency deadline: Mass Rebuild
* Blocks release? N/A (not a System Wide Change), No
== Documentation ==
None.
== Release Notes ==
None.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
7 months, 3 weeks
