Intent to relicense fontpackages
by Nicolas Mailhot
Hi all,
Just FYI, I intend to relicense fontpackages from LGPL3+ to GPL3+, to
make sharing parts with go-macros easier.
Since fontpackages only contains templates and scripts and is not linked
anywhere there is no practical difference.
If you see a problem with this change, or have contributed to
fontpackages to the past and do not like this change, please say so now.
Regards,
--
Nicolas Mailhot
5 years, 1 month
Re: [Fontconfig] fontconfig priority management
by Nicolas Mailhot
Le mardi 16 octobre 2018 à 22:03 -0400, Jerry Casiano a écrit :
Hi,
> A link to the previous discussion? which gives this some context would
> be appreciated.
I pretty much quoted Akira's initial message entirely ;). Since we've
both been at it for a long time, some things are not overly detailed and
just alluded at minimally.
Regards,
--
Nicolas Mailhot
5 years, 1 month
fontconfig priority management
by Akira TAGOH
Hi,
The priority number of fontconfig config files in packages is
hardcoded at this moment. this requires huge works to update,
particularly when changing default fonts say (even though it won't so
often happens but still when fixing config files and updating for huge
packages etc). so I'm pondering to manage the priority in centralized
package and determine it at runtime, allowing users to have own
ordering.
I don't have any implementations for this but just to share an idea with you.
Please let me know if you have any concerns on it.
--
Akira TAGOH
5 years, 1 month
Re: [Fontconfig] fontconfig priority management
by Akira TAGOH
What Nicolas quoted is everything and the packaging policy in Fedora
is somewhat relevant to this though, other distros or individual may
more or less has own fontconfig config per fonts perhaps. the idea is
to reduce the cost of managing those files and the priority things.
this would allows users to have the convenient way to have config
files without understanding complicated syntax and to manage their own
default fonts easily.
On Wed, Oct 17, 2018 at 11:03 AM Jerry Casiano <jerrycasiano(a)gmail.com> wrote:
>
> A link to the previous discussion? which gives this some context would be appreciated.
>
>
>
> On Tue, Oct 16, 2018, 5:41 PM Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
>>
>> Hi Akira,
>>
>> > The priority number of fontconfig config files in packages is
>> > hardcoded at this moment. this requires huge works to update,
>> > particularly when changing default fonts say (even though it won't so
>> > often happens but still when fixing config files and updating for huge
>> > packages etc). so I'm pondering to manage the priority in centralized
>> > package and determine it at runtime, allowing users to have own
>> > ordering.
>> >
>> > I don't have any implementations for this but just to share an idea
>> > with you.
>>
>> It’s great you’re looking at improving things! fontconfig has served us
>> well all those years. But there are really a lot more free and open
>> fonts nowadays than when fontconfig config syntax and file layout was
>> defined (which is wonderful!). So things are cracking a bit at the
>> seams, and not only on your side.
>>
>> If I may give my opinion (CC-ing the fontconfig ML since I don't think
>> any of this is Fedora-specific). Probably more than what you asked, but
>> such is life ;)
>>
>> 1. fontconfig config syntax is too low level for the everyday needs of
>> 2018. It was great when fonts on freedesktop systems were a small known
>> pile of semi-broken files squirrelled away by xorg and texlive, it’s not
>> so great to manage today’s huge numbers of standardized opentype files.
>> The current syntax allows writing excruciately precise and accurate
>> rules, except no human has the time to define those rules for every
>> possible font file we deploy, so we get to write precisely things we are
>> not so sure about.
>>
>> 2. so, this precise syntax should be kept to manage special cases, and
>> something simpler and higher level should be introduced, with more
>> things delegated to the fontconfig engine (like priorizing, as you
>> rightly noted). Something like, process special precise rule in low-
>> level fontconfig syntax first, then mass-process simplified high-level
>> syntax.
>>
>> 3. the first higher level object should be a set-of-rules object, so
>> ordering can be managed independently of file layout (basically you
>> would order sets, regardless if the sets are each in their own file or
>> share a single file, and regardless of the naming of those files. So
>> stop shuffling and renaming files around to order things.
>>
>> 4. set ordering would be undefined and left to fontconfig by default,
>> with one explicit human-maintained per-generic sets-that-must-go-
>> first ordered list, and another per-generic sets-that-must-go-last list.
>> And optional per-script overrides for those lists. Everything in between
>> we don’t have the time and energy to order manually (and there’s no need
>> to).
>>
>> 5. Of course, one copy of the lists in /usr/share/fontconfig for the
>> system integrator, with an override in /etc for the sysadmin, and
>> another override in .config for each user
>>
>> 6. IMHO to keep things manageable you should have one set = one font
>> family (in the WWS sense, ie do not create as many sets as there are
>> font family name variations, do not create separate sets for acmefont
>> armenian and acmefont greek). We can extend font family definition to
>> more things than just WWS when apps learn to manage more facets than
>> just WWS for one font family, but at this point of time just doing WWS
>> is taxing for the average app. Things like caption fonts, math fonts,
>> etc should probably be merged with the WWS stuff eventually once we have
>> more experience on handling those transparently in apps.
>>
>> 7. that does force fontconfig to manage high-level simplified and
>> unified font family naming, instead of hoping font files will come with
>> clean consistent naming (they don't and they won't, stop hoping for it,
>> stop relying on fontconfig config writers to fix it, stop inflicting on
>> users long lists of non-merged font names and expect them to jungle with
>> the result, managing technical splits in font families is fontconfig's
>> job not the user job, the user should only have to specify the design
>> and the style he wants).
>>
>> 8. if there are several set definitions for the same font family at the
>> same level of config (system integrator, sysadmin or user) just merge
>> them transparently with undefined ordering rules when merging
>>
>> 9. if one set exists in several level, allow the override levels
>> (sysadmin and user) to define in their set if they want it merged with
>> lower levels or if they want it to replace the lower level definitions
>>
>> 10. The typical set should probably just define:
>> * the generic the font family belongs to (what generic should be used
>> to complete the font family, and what generic should ne constructed from
>> the font family)
>> * the list of known font families with similar design or metrics (so
>> substitute this font family to those other font families if they are
>> absent or lacking coverage, and conversely use those other font families
>> to complete the font family if it lacks coverage). I really don’t think
>> there is much benefit in ordering those manually. If there is some
>> benefit, ordering should be an explicit attribute of the list, not the
>> default.
>>
>> 11. Eventually, the set could also contain
>> * an explicit list of internal hidden font families to map to this set
>> (ie hide those font families from font lists, present only the unified
>> clean name, manage internally in fontconfig which font file to use
>> depending on what needs to be rendered)
>> * the same thing, with also a face mapping, if face needs correction
>> too
>> * an explicit "use this internal font family for this script" to manage
>> situations when there are regional variations on how to render an
>> unicode codepoint
>>
>> 12. though I do hope opentype tables in shipped fonts get complete
>> enough over time, and fontconfig gets smart enough over time, that all
>> those mappings and overrides won’t need manual declaration long term.
>> * IMHO fontconfig should map automatically by default everything
>> defined in the WWS whitepaper,
>> * and probably all the per-script/region/language common name
>> variations
>>
>> 13. and since people will rightfully object that naming heuristics are
>> not reliable and fail in some cases
>> * allow defining a set with a property that basically says "do not
>> merge me, I’m different"
>> * make merging the default, and not-merging an explicit exception
>>
>> With just that you should be able to handle 90% of what people need to
>> declare to fontconfig today (handwaves). And have something easy to
>> order at system, sysadmin or user level. The 10% of very specific and
>> complex configuration that does not fit in this simplified model, can be
>> handled with the current syntax. It’s small enough in volume that I
>> doubt its causes you lots of management problems.
>>
>> Best regards,
>>
>> --
>> Nicolas Mailhot
>>
>> _______________________________________________
>> Fontconfig mailing list
>> Fontconfig(a)lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/fontconfig
--
Akira TAGOH
5 years, 1 month
Fonts packaging macros rework early peek
by Nicolas Mailhot
Hi,
To all that may concern (mainly, packagers of things that include font
files).
I’m currently reworking the font automation I created for Fedora 10
years ago. You can get an early peek at the result here:
https://copr.fedorainfracloud.org/coprs/nim/fontpackages-2/
The main objectives of the rework are:
* make it easier to use
* generate appstream files automatically, and validate the result
* you can of course handcraft your own appstream file, or use the
one shipped by your upstream, if that thing actually exists
* remove more boilerplate code in the specs
* move to a more declarative syntax
* it is slightly more verbose but you don't need to remember magic
macro flags, just to cut and paste a block of variables and fill in
their values
* remove historical implementation quirks
* enforce Fedora naming guidelines some more at the macro level, since
reading those is too much work for some packagers
* completely cut the relationship between font subpackages and the srpm
they’re generated from, so any Fedora package that includes fonts can
use those without side effects on the rest of the spec
* move to generic macro naming, that can be templated away by rpm in
the future
So, it's a technical implementation rework, without any change in the
packaging principles that exist in current guidelines.
At this stage I'm pretty sure the way macros will be used in specs is
stabilized, so you can take a look at the specs in copr and comment if
there are things you'd like to be done differently.
The declaration order is not too intuitive, mostly because it differs
from Fedora habits, but each change was driven by rpmbuild, copr or mock
requirements, so don't order things back unless you want to discover the
hard way why it needs to be like that.
Finally, I do realise the proposal, if accepted, will mean rewriting
part of existing font specs at one point, which no one wants to do, but:
1. it's less work than writing appstream files and the associated spec
code manually (do *you* validate your appstream files correctly today in
your specs?),
2. it mostly involves removing spec lines → less lines for packagers to
maintain in the future
2. I did this work for my own font packages, and there are lots of them,
so believe me I tried to make it as simple as possible, starting for
myself
4. I don't think some spec churn every 10 years is too much to ask
The remaining todo is mainly to clean up the layout of the macro package
itself, write templates, and do some guidelining (and bug fixing, if
needed).
If you want to rebuild any of the packages or specs on you system you
need the redhat-rpm-config and rpm version in copr, as the font macros
depend on their changes. Those changes are currently being integrated in
rawhide for other reasons, and a backport to stable is also on the
agenda.
You’ll see in the copr some badly needed updates to some important
Fedora font packages (dejavu, stix, droid, etc). I officially suck at
updates. I'm reworking things to help me suck less. Also, I took the
opportunity to package some font families that should have been packaged
quite a long time ago (not necessarily by myself). All this will hit
rawhide and reviews once the macro work is done.
Regards,
--
Nicolas Mailhot
5 years, 1 month
[RFC] Default rpm macro packaging layout and conventions
by Nicolas Mailhot
Hi,
I'd like Fedora and FPC in general to agree to a general layout for
macros and their associated material like templates, so the next step
can focus on the actual macros and their documentation, and not on how
the result is shipped to users.
https://pagure.io/packaging-committee/issue/813
The reason being I'm currently wrapping up three sets of rpm macros for
Fedora⁰. The coding and first-pass testing for each macro set is mostly
done, the next step is packaging, documenting, and guideline-ing.
I'd like to do the documenting and guideline-ing for each macro set via
standard templates. Wiki (or the new docs site) is a huge time sink to
write and update, and most packagers do not read the result, so it's
mostly a waste of time. OTOH templates are operational and do work. Thus
with hindsight, a short paragraph in guidelines that points to a package
of templates, works loads better than a wall of wiki text
Here is how I understand today's Fedora best practices. To my knowledge,
they are mostly unwritten packager lore. (obviously stuff in
redhat-rpm-config is a special case)
%<--
A. A single project hosts macros, templates, readmes, so everything is
kept in sync
B. For macros that process <foo> material, the project is named
<foo>-macros or <foo>packages (which one does FPC prefer?)
C. The project SHOULD be hosted on Fedora infra, or a cross-distro
hosting site
(ie pagure.io, even if I find it severely limitating from a forge
POW)
D. The result is packaged as a <foo>-macros or <foo>packages srpm
(whichever FPC chose in B)
E. The srpm CAN BuildRequire anything (though usually it will be
composed of macros, docs, scripts, that do not need much building,
anything binary is likely to end up in its own package that is then
BuildRequired)
F. This srpm generates the following subpackages (using -n, otherwise
you end up with very awkward package names)
F.1 A package named <foo>-srpm-macros, sufficient to create <foo> srpms:
* this package MUST be in the default build root (buildsys group)
* it MUST NOT require anything: we want builds to be fast and
efficient, and package ecosystems not to pollute the builds of other
package ecosystem
* it MUST define a pivot macro expected to be present in every <foo>
spec
* this macro SHOULD generate a BuildRequires on <foo>-rpm-macros
* this package MUST define every other macro or constant needed by
rpmbuild to assemble <foo> srpms (mostly, anything dealing with <foo>
sources or the SRPM name)
F.2 A package named <foo>-rpm-macros, sufficient for the build stage of
<foo> packages
* this package MUST NOT assume it can be in the default build root
* it CAN and SHOULD Require anything typically needed to build <foo>
packages. Require restrictions are for <foo>-srpm-macros, not
<foo>-rpm-macros
* anything used in %prep, %build, %install, %check, or to compute
<foo>-style deps
* for example: for Go packages, the Golang compiler, for fonts
packages, fontconfig
* it MUST provide the associated macros and constants (typically the
constant defining standard filesystem locations for <foo> stuff)
* it MUST require <foo>-filesystem
* it SHOULD NOT be necessary to install <foo> packages once built, not
be depended on by those packages
F.3 A package named <foo>-filesystem
* this package MUST materialize and own the filesystem locations
defined in <foo>-rpm-macros
* this package MUST NOT require anything except other filesystem-style
packages
* this way it can be depended on by <foo> packages without pulling in
all the build infra of <foo>-rpm-macros
F.4 A package named <foo>packages-devel ? <foo>-macros-devel ?
<foo>packages-templates ? <foo>-macro-templates ? What is the FPC
preference?
* this package SHOULD depend on rpmdevtools
* this package SHOULD provide at least one template in
%{_sysconfdir}/rpmdevtools/ showing how <foo> macros are supposed to be
used
* this package SHOULD contain every other additionnal documentation
file, necessary to understand those templates
* this package SHOULD NOT be necessary to install <foo> packages once
built, not be depended on by those packages
F.5 A package named <foo>packages-tools ? <foo>-macros-tools ? What is
the FPC preference?
* holds anything not strictly necessary to run the macros or understand
the templates, but can be useful to some packages, typically convenience
scripts
%<--
Did I get this right or did i forget something important?
Regards,
⁰
1. "forge macros" v2 (v1 was merged in redhat-rpm-config 9 months ago)
macros to map <url,version,tag,commit,branch> metadata to classical rpm
Source, URL, %setup, %dist, etc verbs, when a project is hosted on
Gitlab, GitHub, etc (*not* Pagure because Pagure is missing needed
functionality). There are hundreds if not thousands of packages in the
distro that can make use of this.
v2 adds the ability to process multiple archives in a single source
rpm.¹
2 "go macros" v2 (v1 was merged in go-compilers and go-srpm macros about
the same time as the forge macros)
automation for packaging software written in the Go language (Go
language). Go is getting huge nowadays, it's the language in which
kubernetes, docker, and a lot of cloud infra software is being written
today. This is really why I'm doing all this, the forge macros are just
a spinoff of generic non-Go-specific functionality that Go macros need.
v2 add the ability to process multiple archives in a single source rpm,
and Go BuildRequires automation (one of the huge missing bits in the
v1)²
3 font macros v2 (v1 + associated guidelines were written by myself
around a decade ago)
Another spinoff of 1. and 2. Mostly because golang-x-image is the
upstream of the Go fonts, which has caused me to revisit the subject.
With the framework code written for 1., ten years of hindsight,
experience, and rpm improvements, I can and did write macros that remove
known problems in the current set, add missing functionalities like
appstream handling, and are generally more convenient to use (took me
about a week-end of hacking)³
¹ A first version has already been completed and merged in
redhat-rpm-config 9 months ago. Thanks to everyone involved.
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/7c4cd330850ee228ca...
It worked and still works fine, you can use it today in your packages,
but it has a huge limitation: it assumes you only need to process a
single source archive in the specfile. People rightly pointed out in the
review that, while it's the general and preferred case, some packages do
need to mix source archives (esp. on EL given the hard constrains EL has
on not touching existing package layout).
Therefore I've prepared a new version that *can* process multiple
sources. It's backwards-compatible, multi-source is achieved via new
flags, in the absence of those flags it will assume a single source like
the current merged code does.
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35
It adds a huge level of complexity macro-side, rpm does not really
provide the framework to do this kind of multiplexing, the framework had
to be coded from scratch in lua macro code. However, the framework has
been coded now, it's generic, and rightly belongs in a generic package
like redhat-rpm-config
² Currently in the final stages of technical testing before I document
it and send a PR
https://github.com/nim-nim/go-macros/commits/dev
³ Currently past the technical testing, need to document it, send myself
a PR, send the result to FPC and the Fonts SIG to switch existing
packaging guidelines
--
Nicolas Mailhot
5 years, 1 month
Inconsolata no longer available in terminal after F29 beta upgrade?
by Matthew Miller
My terminal font of choice is Inconsolata, packaged as
levien-inconsolata-fonts. After my F29 beta upgrade, everything is smooth,
but I noticed that my terminal windows default to some other font, and when
I go to the preferences, Inconsolata is not listed as an option.
Did something change in the font or its packaging, or is this a GNOME
Terminal bug?
Please help, as I am using Source Code Pro as an alternative in the
meantime, and I'm not sure I can handle this. :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5 years, 1 month
