968375 - Add msttcorefonts package to Servo buildbots

Status: RESOLVED WONTFIX

(Infrastructure & Operations Graveyard :: CIDuty, task)

Description

[Lars Bergstrom (:larsberg)]

Servo requires the msttcorefonts in order to render some web pages. Please add that package to the Linux image. Thanks!

Comment 1

[[e-mail] (:bhearsum)]

It looks like we'll need to build a special package for this, based on http://go2linux.garron.me/msttcorefonts-true-type-fonts-on-linux. Once that's done https://github.com/mozilla/servo/blob/master/bld/linux.py can be modified to install it at the start of the build process.

I'm trying to find someone to look at this.

Comment 2

[Josh Matthews [:jdm]]

Ben, it would be really nice to get this addressed.

Comment 3

[John Hopkins (:jhopkins)]

Attachment: [puppet] msttcorefonts spec file from http://corefonts.sourceforge.net/msttcorefonts-2.0-1.spec

Comment 4

[John Hopkins (:jhopkins)]

Built packages are at: http://people.mozilla.org/~jhopkins/bug968375/

Need to test, copy to puppetagain Yum repo, and update Servo build slave configs in puppet.

Comment 5

[John Hopkins (:jhopkins)]

Unresolved install-time dependency: /usr/sbin/chkfontpath

Comment 6

[John Hopkins (:jhopkins)]

This forum posts suggests an easier alternative:

 http://www.spinics.net/linux/fedora/fedora-users/msg423966.html

Comment 7

[Josh Matthews [:jdm]]

John, is this waiting on anything from our side?

Comment 8

[John Hopkins (:jhopkins)]

Josh: no, it is not. I should be able to resume work on this next week.

Comment 9

[John Hopkins (:jhopkins)]

Updated package uploaded to http://people.mozilla.org/~jhopkins/bug968375/

I tested this in a mock and non-mock environment and `fc-list` (from the fontconfig package) shows the list of installed fonts.  The list is also updated properly when the msttcorefonts package is removed.

Should be able to get this deployed tomorrow (Wednesday).

Comment 10

[John Hopkins (:jhopkins)]

Attachment: [puppet] update install/uninstall mechanics, dependencies, mirror list

original spec file is in attachment 8382276 [details] [diff] [review], for reference

Comment 11

[Dustin J. Mitchell [:dustin] (he/him)]

Comment on attachment 8393307 [details] [diff] [review]
[puppet] update install/uninstall mechanics, dependencies, mirror list

Review of attachment 8393307 [details] [diff] [review]:
-----------------------------------------------------------------

Aside from the concerns below, I don't actually have a problem with the patch itself -- landing it wouldn't, as far as I can tell, be a problem from a licensing perspective.

As a side note, you should probably remove the RPMs from people.m.o too.

::: modules/packages/manifests/mozilla/msttcorefonts.spec
@@ +29,5 @@
> +The TrueType core fonts for the web that was once available from
> +http://www.microsoft.com/typography/fontpack/. The src rpm is cleverly
> +constructed so that the actual fonts are downloaded from Sourceforge's site
> +at build time. Therefore this package technically does not 'redistribute'
> +the fonts, it just makes it easy to install them on a linux system.

This seems kinda sketchy.  I very much doubt it would matter in a court of law whether the fonts are downloaded by rpmbuild or by the script in the .spec, and it doesn't seem like any great advantage to be able to distribute the src rpm if you can't distribute the binary RPM.  On a technical basis, a spec file that goes out and downloads stuff on its own is pretty unusual.

Even if this legal dodge *is* legit, then it means we can't put the binary RPM on any public server.

So I think you'll have two options here:

 1. Set up a new, perhaps servo-specific, private yum repository (under /data/repos/private/yum/, so it's not publicly visible) and put the RPM there; or

 2. Take this whole issue out of puppetagain, and let servo handle the licensing issues, either installing the RPM from a private URL or by running a private yum repo.

Either one is fine with me.  I only suggest #2 because this RPM isn't actually installed by PuppetAgain, and it can't go in any existing PuppetAgain yum repository, so it seems like involving PuppetAgain at all is unnecessary.

Comment 12

[John Hopkins (:jhopkins)]

I've removed the binary RPM from my 'people' account.  Currently weighing the options you presented.

Comment 13

[Lars Bergstrom (:larsberg)]

Hrm, I don't want to get you in legal trouble or eat up too much more of your time - we already appreciate how much you've put into this!

Maybe the "right thing" for Servo to do here is:

* Remove our hard dependency on the presence of those fonts at startup
* Ensure all of our ref tests only use fonts we can safely install license-free (e.g., Ahem)

Comment 14

[John Hopkins (:jhopkins)]

[10:01am] jhopkins: larsberg: any drawback to using alternative fonts? (re: bug 968375)
[10:03am] larsberg: jhopkins: there are no drawbacks I'm aware of to doing that, other than just the need for somebody to sit down and clean up the way we use fontconfig - which we have to do anyway because I think 1/2 of our Android load time is spent walking over the device fonts and their metrics 
[10:05am] jhopkins: larsberg: i will land the .spec file in case it is needed in the future and we'll go with the freely available fonts as the plan of record.  ok?
[10:06am] larsberg: jhopkins: That sounds great [...]

Comment 15

[John Hopkins (:jhopkins)]

Comment on attachment 8393307 [details] [diff] [review]
[puppet] update install/uninstall mechanics, dependencies, mirror list

https://hg.mozilla.org/build/puppet/rev/b5410c664d43

Comment 16

[Jack Moffitt [:jack]]

This is a little disappointing. bhearsum and I discussed this issue before any of this work began, and I was told this was fine and releng had dealt with similar issues before.

Also, considering the "it won't matter in a court of law" argument you propose, I find it hard to reconcile that with Mozilla's stated strategy for avoiding H.264 royalties by downloading OpenH264 binary plugins from Cisco on demand.

Does releng not have a private yum repo that can be used for this? I'm not sure why a servo specific one would be needed.

Comment 17

[Dustin J. Mitchell [:dustin] (he/him)]

Well, IANAL so I won't debate the legal questions - I hope we can agree it's not a decision that NAL people should be making without advice from AL.

We don't have a private yum repo now, but setting one up is an option (option number 1, in fact).  We *have* set up similar things (but not yum repos) for vmware tools and some Apple packages like XCode, so there's certainly precedent.

However, from the comments above it seems that using restricted fonts is not necessary, and that avoiding them has other benefits.

Comment 18

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Dropping our dependency on those fonts is definitely the long term plan, but right now, not having those fonts installed on the Linux slaves means we can't do any automated testing on Linux. Waiting on the code changes is a possibility, but I'd personally prefer having the test coverage even before that happens.

Comment 19

[[e-mail] (:bhearsum)]

So, I had it in my head that we already had private yum repositories. Clearly I was wrong about that - sorry.

I haven't been plugged into this bug since John picked it up, but it seems like we need to clear up whether or not we actually need this? You and Lars appear to be saying different things. If we need them, we need them, and it sounds like we have a plan for that.

Comment 20

[John Hopkins (:jhopkins)]

What is the final decision here?  Do we need to get together and have a conversation?