-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with setting up the msttfonts on linux #186
Comments
How can I tell if the fonts are properly installed? I checked it out in a Vagrant VM and it seems to work OK: the fonts are getting downloaded and placed into /usr/share/fonts/truetype/msttcorefonts, and it looks like the debconf selection is getting set properly. |
When it fails nothing is created in /usr/share/fonts/truetype but no errors are reported and the debconf selections are all fine. You can look at the salt log in AWS boot or on the build machines for its details, but not much is reported there other than it successfully installed the package. |
Hmm, interesting. I think looking at the logs will be important to figure this one out, but I don't want to just put them in a Gist or Pastebin. Would you be comfortable giving me SSH access to these machines? Also, which machines (hostnames) had this problem? |
Sure! I'd be happy to give you access to ssh in. You can open a PR like #184 to try it out. IIRC, it happened to our EC2 "linux2" builder. I can give you that IP after we have your ssh key installed. Alternatively, I can also log in there and retrieve any logs that you need. |
Also, if it matters, I've noticed that if I
|
This changes our workaround to be more verbose with no-op states but more robust in the case of pkrepo failures: the directory will not be cleaned until after all of the pkgrepo states complete succesfully. This also cleans up the MS TTF core fonts, and should help with servo#186.
Standardize pkgrepo usage This changes our workaround to be more verbose with no-op states but more robust in the case of pkrepo failures: the directory will not be cleaned until after all of the pkgrepo states complete succesfully. This also cleans up the MS TTF core fonts, and should help with #186. Note that it appears the Vagrant `ubuntu/trusty64` image that we use already has the `multiverse` repository enabled, which might be why I can't reproduce #186 inside Vagrant; it may be worth spinning up a temporary EC2 instance to test this out (probably in masterless/local mode instead of having it connect to `servo-master`). <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/250) <!-- Reviewable:end -->
@larsbergstrom @edunham Did you run into this when setting up the new cross builders? Also, do you know if that was before or after #250 landed? If you didn't hit any problems this time, I think we can close this issue for now. |
Confirmed that both of the cross builders provisioned with correctly-installed fonts. Thanks! |
We moved EC2 builders this past week, and had problems with the MS TT fonts installer again. The relevant install lines appear to be here:
https://github.com/servo/saltfs/blob/master/servo-dependencies.sls#L10-L19
What seems to have happened (from looking at the failing machine) is that the mscorefonts-eula was set to
False
rather than true before the installation of the package happened, and so the package was showing as installed but none of the fonts were available. I had to reset the eula flag then forcibly uninstall/reinstall the fonts.Any ideas? CC: @metajack @aneeshusa @edunham
The text was updated successfully, but these errors were encountered: