Red Hat Bugzilla – Bug 1258542
Review Request: hack-fonts - A typeface designed for source code
Last modified: 2017-10-20 12:21:08 EDT
Spec URL: https://heliocastro.fedorapeople.org/hack-fonts.spec
SRPM URL: https://heliocastro.fedorapeople.org/hack-fonts-2.010-1.fc22.src.rpm
Description: A typeface designed for source code
Fedora Account System Username: heliocastro
From the policy: "Fonts SHOULD be built from source whenever upstream provides them in a source format" - upstream does appear to provide source here.
They have the source, but no instructions how to build it whatsoever.
I just followed the same process used on Overpass Red Hat font, which has the source available, but same way, only the type faces are included.
NEW version released.
(In reply to Helio Chissini de Castro from comment #2)
> They have the source, but no instructions how to build it whatsoever.
> I just followed the same process used on Overpass Red Hat font, which has
> the source available, but same way, only the type faces are included.
This is ridiculous, the fonts are derived from DejaVu, and DejaVu build is completely scripted. The project just need to fork the build scripts like it forked everything else, and decide on a naming policy
I really hope to see this package in the main repo soon :)
Where are we in this review? Upstream is excited to get Hack into Fedora.
Updated SPEC and SRPM
Copr repo updated as well
Any further update on this?
Package request has been denied with the reason: Review not approved.
I will do review since I want this font already. Expect a review for tomorrow.
I'll just take this over if nobody is doing this, will ask for a review.
This was strangely forgotten.
Before we can even move to package this, does anyone know how this is built? I've opened a ticket on upstream's github, Debian has this packaged but I don't see them doing any source builds of the fonts.
I need some clarification on our policy for this. Given Debian is even more severe for requiring sources, maybe Fedora should follow Debian's guide on this?
Debian is using same approach as me, using the precompiled ttf/otf
The only thing is that we're deploying only ttf and debian both ones.
And i personally don't know if worth pack the web fonts.
Well, if it's acceptable to Debian surely this should be acceptable to Fedora, if not something seems wrong with our policy...
Debian is not inevitably 'freer' than Fedora. Our requirements are more strict in some ways. Just because Debian doesn't (and, AFAICT, never has) required fonts to be compiled from source doesn't mean we're wrong in requiring this.
Upstream bug regarding building this font from source: https://github.com/chrissimpkins/Hack/issues/227
I am in contact with upstream, they are looking at improving our ability to build the fonts from scratch. More on this when they get back to me.
The Hack license is now acceptable for Fedora:
Also, FWIW I could really use the web fonts for Bodhi (which is why I wanted to package Hack) so I would appreciate if you could include a subpackage with those files.
I'm willing to review this package if nobody else has a "claim" on reviewing it.
After reading the scrollback it does sound like Shawn is lined up to do the review so I'll defer, but I'm happy to be a standin. I'll memorize my lines.
My interpretation of the packaging rules is that SHOULD != MUST when it comes to building the font from source. The font guidelines do use the word "MUST" in other places so I take that to mean that this shouldn't block the package from getting into Fedora. It's obviously better if we build the font from source, but since there isn't a clear way to do that provided by upstream I don't think we have to wait for https://github.com/chrissimpkins/Hack/issues/227 to be solved to get this into Fedora. I would recommend allowing the package in with the OTF files (and hopefully web files for me ☺) and then filing a BZ to build from source if possible later.
Well, there's still the *general* packaging guidelines to consider. I don't think the font guidelines supersede those, in fact the section on packaging from source specifically references back to them. And they're quite specific about when you get an exception from the requirement to build from source.
I've poked Chris on twitter, you can certainly help with packaging, it's always good to have co-maintainers.
Adam, fair enough.
Shawn, if you don't want to deal with the web files I'd be happy to handle that part as a co-maintainer.
Here is the tool can use to build the fonts
We will need this packaged too as a dependency for building, if we want to build them now.
Any news here?
I should have something soon, i'll put up a .spec for review this week.
So I see this is still pending and I'm not completely sure why.
I understand that there's a desire to have these built from source, which requires some additional dependencies. However, fonts are considered by Fedora to be "content" and are explicitly listed as content: https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content
The font-specific packaging guidelines mention that they should be compiled from source because most of the time they are buildable with free, packaged software and the existence of bytecode hinting engines does get close to the line of what might start looking like something which isn't content. However, it's just a "should", and lack of software needed to build it is a pretty good reason to violate one of those.
If anything I'd hope that the hack fonts could be imported now while work is ongoing to package the dependencies. In the future this package could switch over to building from source.
If the guidelines on this are confusing then I will be happy to work to get them changed to be less confusing.
Upstream is changing how fonts are built now, which means we can use Open Source tools to build them. I'm waiting for them to finish some of those bits which are im progress right now.
This is currently blocked from our other dependencies needed for python-fontmake and its sub-dependencies...
Upstream is appreciative in our efforts to get things packaged up.
3.00 is released, but we're still blocked here...