Skip to content
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

Closed
larsbergstrom opened this issue Jan 4, 2016 · 7 comments
Closed

Problems with setting up the msttfonts on linux #186

larsbergstrom opened this issue Jan 4, 2016 · 7 comments

Comments

@larsbergstrom
Copy link
Contributor

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

@aneeshusa
Copy link
Contributor

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.

@metajack
Copy link
Contributor

metajack commented Jan 6, 2016

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.

@aneeshusa
Copy link
Contributor

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?

@larsbergstrom
Copy link
Contributor Author

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.

@larsbergstrom
Copy link
Contributor Author

Also, if it matters, I've noticed that if I highstate that box, I sometimes get:

----------
          ID: FIX enable multiverse
    Function: pkgrepo.absent
        Name: deb http://archive.ubuntu.com/ubuntu trusty multiverse
      Result: True
     Comment: Removed package repo deb http://archive.ubuntu.com/ubuntu trusty multiverse
     Started: 13:09:30.857022
    Duration: 6125.226 ms
     Changes:   
              ----------
              repo:
                  deb http://archive.ubuntu.com/ubuntu trusty multiverse
----------
          ID: enable multiverse
    Function: pkgrepo.managed
        Name: deb http://archive.ubuntu.com/ubuntu trusty multiverse
      Result: True
     Comment: Configured package repo 'deb http://archive.ubuntu.com/ubuntu trusty multiverse'
     Started: 13:09:36.982359
    Duration: 2987.726 ms
     Changes:   
              ----------
              repo:
                  deb http://archive.ubuntu.com/ubuntu trusty multiverse
----------

aneeshusa added a commit to aneeshusa/servo-saltfs that referenced this issue Mar 14, 2016
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.
bors-servo pushed a commit that referenced this issue Mar 22, 2016
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 -->
@aneeshusa
Copy link
Contributor

@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.

@larsbergstrom
Copy link
Contributor Author

Confirmed that both of the cross builders provisioned with correctly-installed fonts. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants