Package Details: ttf-twemoji 15.1.0-1

Git Clone URL: (read-only, click to copy)
Package Base: ttf-twemoji
Description: Truetype builds of Twemoji; Twitter Color Emoji for everyone.
Upstream URL:
Keywords: color emoji font truetype-emoji ttf twemoji twemoji-color-font
Licenses: Apache-2.0, CC-BY-4.0
Provides: emoji-font, twemoji-color-font
Submitter: morealaz
Maintainer: JoeBlakeB
Last Packager: JoeBlakeB
Votes: 77
Popularity: 2.01
First Submitted: 2020-02-27 07:29 (UTC)
Last Updated: 2024-03-28 14:58 (UTC)

Dependencies (0)

Required by (9)

Sources (4)

Latest Comments

1 2 3 4 Next › Last »

Hanabishi commented on 2024-01-30 10:40 (UTC) (edited on 2024-01-30 10:42 (UTC) by Hanabishi)

Yes, that was the question. Because we have

Packages that use prebuilt deliverables, when the sources are available, must use the -bin suffix.

Although, fonts don't really fall under the "binary" category. They definitely can't harm as much as executables.

So if the build process is really as long as you say, I guess it is indeed not worth it.

whynothugo commented on 2024-01-30 10:26 (UTC)

Hanabishi: Upstream doesn't provide a any pre-built ttf file. When packaging this for Alpine, Alpine devs preferred to download a ttf file (rather than built it from source just for their package). The TTFs that I publish are meant to file that role for downstream: pre-built font files ready to use by distributions. My expectation was that if any improvements could be made or if it was ever out of date, others would contribute. Upstream still isn't publishing TTF files. See:

As for building from source for the AUR package: builds take about an hour. There's little point in building from source; most people just want the font file. In theory, we could have ttf-twemoji and ttf-twemoji-bin, but I don't think that the effort makes sense.

Hanabishi commented on 2024-01-30 08:39 (UTC)

Is there a reason not to build from the source directly in PKGBUILD?

JoeBlakeB commented on 2024-01-17 22:49 (UTC)

@Coelacanthus oh I see, I have changed the license value to be just one string.

As for MIT vs Apache, @Porous3247 is correct that the MIT license covers only the twemoji scripts, which we don't use, so are not needed here. I will also keep the Apache 2.0 license as my build system and @whynothugo's SourceHut build system (which mine is based of) both use googles noto emoji build system from, which has the license.

Porous3247 commented on 2024-01-17 17:40 (UTC) (edited on 2024-01-17 17:41 (UTC) by Porous3247)

@Coelancanthus I'm the one who suggested a PKGBUILD update that included the license change when the maintainer was a bit inactive. The Apache 2.0 license was originally included to represent @whynothugo 's SourceHut build system, but since the maintainer decided to switch away from the build system, I guess the Apache license can be removed.

The MIT license shouldn't be included as it covers the twemoji library API, but not the graphics. It looks like the workflow included in just simply copies the graphics but does not ever use the library component. Even if the build system did, the license wouldn't propagate to JoeBlakeB/ttf-twemoji-aur

Coelacanthus commented on 2024-01-17 15:20 (UTC)

@JoeBlakeB Other things are fine. But according to RFC 16, using one string license=('Apache-2.0 AND CC-BY-SA-4.0') rather than an array. You can see the example in RFC16.

But when I look back at the of twemoji project. It may be 'MIT AND CC-BY-SA-4.0', not Apache-2.0

JoeBlakeB commented on 2024-01-17 13:25 (UTC) (edited on 2024-01-17 13:36 (UTC) by JoeBlakeB)

@whynothugo There wasn't anything wrong with it for me, but your repo wasn't updated to 15.0.3, so I felt like it would be better for me to build it myself. I only went with GitHub because it is what I was familiar with, and hadn't used sourcehut before. Also, going with GitHub meant I wouldn't need a separate server for the ttf files to be uploaded to, they could just stay on GitHub, again for convince.

whynothugo commented on 2024-01-17 11:03 (UTC)

@JoeBlakeB Was there anything wrong with the existing build system? It's kinda weird to port a perfectly working build onto MS's proprietary platform.

JoeBlakeB commented on 2024-01-16 16:57 (UTC)

@Coelacanthus sure, I have changed the licenses in the PKGBUILD, but I assume everything else is fine?

Coelacanthus commented on 2024-01-16 16:11 (UTC)

Please follow RFC16 use 'CC-BY-4.0 AND Apache-2.0'