Closed Bug 968375 Opened 8 years ago Closed 8 years ago

Add msttcorefonts package to Servo buildbots


(Infrastructure & Operations Graveyard :: CIDuty, task)

Not set


(Not tracked)



(Reporter: larsberg, Assigned: jhopkins)



(2 files)

Servo requires the msttcorefonts in order to render some web pages. Please add that package to the Linux image. Thanks!
It looks like we'll need to build a special package for this, based on Once that's done can be modified to install it at the start of the build process.

I'm trying to find someone to look at this.
Ben, it would be really nice to get this addressed.
Flags: needinfo?(bhearsum)
Assignee: nobody → jhopkins
Component: General Automation → Platform Support
Flags: needinfo?(bhearsum)
QA Contact: catlee → coop
Built packages are at:

Need to test, copy to puppetagain Yum repo, and update Servo build slave configs in puppet.
Unresolved install-time dependency: /usr/sbin/chkfontpath
This forum posts suggests an easier alternative:
John, is this waiting on anything from our side?
Flags: needinfo?(jhopkins)
Josh: no, it is not. I should be able to resume work on this next week.
Flags: needinfo?(jhopkins)
Updated package uploaded to

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 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
> + 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.
Attachment #8393307 - Flags: review?(dustin) → review+
I've removed the binary RPM from my 'people' account.  Currently weighing the options you presented.
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)
[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 on attachment 8393307 [details] [diff] [review]
[puppet] update install/uninstall mechanics, dependencies, mirror list
Attachment #8393307 - Flags: checked-in+
Closed: 8 years ago
Resolution: --- → WONTFIX
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.
Flags: needinfo?(bhearsum)
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.
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.
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.
Flags: needinfo?(bhearsum)
What is the final decision here?  Do we need to get together and have a conversation?
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.