here's an example - https://travis-ci.org/softprops/bin-test/jobs/192443776

error: failed to run custom build command for `openssl v0.7.14`
process didn't exit successfully: `/target/debug/build/openssl-5464f8f6e728c35a/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-unknown-linux-musl")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-unknown-linux-musl")
debug=true opt-level=0
HOST = Some("x86_64-unknown-linux-gnu")
TARGET = Some("x86_64-unknown-linux-musl")
TARGET = Some("x86_64-unknown-linux-musl")
HOST = Some("x86_64-unknown-linux-gnu")
CC_x86_64-unknown-linux-musl = None
CC_x86_64_unknown_linux_musl = None
TARGET_CC = None
CC = None
HOST = Some("x86_64-unknown-linux-gnu")
CROSS_COMPILE = None
TARGET = Some("x86_64-unknown-linux-musl")
HOST = Some("x86_64-unknown-linux-gnu")
CFLAGS_x86_64-unknown-linux-musl = None
CFLAGS_x86_64_unknown_linux_musl = None
TARGET_CFLAGS = None
CFLAGS = None
running: "musl-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-static" "-o" "/target/x86_64-unknown-linux-musl/debug/build/openssl-5464f8f6e728c35a/out/src/c_helpers.o" "-c" "src/c_helpers.c"
cargo:warning=src/c_helpers.c:1:25: fatal error: openssl/ssl.h: No such file or directory
cargo:warning=compilation terminated.
ExitStatus(ExitStatus(256))
command did not execute successfully, got: exit code: 1
--- stderr
thread 'main' panicked at 'explicit panic', /cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.41/src/lib.rs:1018
note: Run with `RUST_BACKTRACE=1` for a backtrace.```

I'm switching a small project of mine over to trust. Builds on Travis are failing when they didn't previously. I'm getting SSL errors when testing the crate with TARGET=*-unknown-linux-* on Travis. darwin is fine, and the tests don't run on BSD or Windows. Testing locally on debian and arch linux also works.

It looks like reqwest can't find certificates:

Error { kind: Io(Error { repr: Custom(Custom { kind: Other, error: Ssl(ErrorStack([Error { code: 336134278, library: \"SSL routines\", function: \"ssl3_get_server_certificate\", reason: \"certificate verify failed\", file: \"s3_clnt.c\", line: 1264 }])) }) }), url: Some(\"https://inspirehep.net/search?of=hx&p=Higgs%3A2014aqa\")

Example log on Travis Line where the panic happens

This looks like a related issue: https://github.com/japaric/trust/issues/55 . It's not exactly same though; everything seems to build but there is an error during tests.

Thanks for this project!

Heatseeker has a build script that collects some build-time metadata and writes a version.rs file. After migrating to trust, Travis builds (except for builds targeting Darwin) are failing with the following error:

error: failed to run custom build command for `heatseeker v1.5.0 (file:///project)`
process didn't exit successfully: `/target/debug/build/heatseeker-77dc6031b5733332/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 30, message: "Read-only file system" } }', ../src/libcore/result.rs:837

The custom build command never caused any problems before, and somehow it's still not causing problems for Darwin builds. I'm not sure if the problem is in the trust template, my adaptation of it, or Travis itself.

This is a followup to #48.

It seems nothing is using sudo in trust, removing this line will default to sudo: false. This means, trust will run on Travis container infrastructure, which has faster boots and probably faster builds.

My testing showed that my repos run fine without sudo. I furthermore verified:

• The docker service is brought up, even without sudo: enabled, so we are good there.
• sudo apt-get no longer works since there is no sudo. But apt packages can be installed using the apt addon. (Example how this looks).

This is done to prevent a default build from spawning, (it looks weird, its better to have the build as part of the matrix.) Also the default is to run on stable anyways so its even more silly.

Since https://github.com/travis-ci/travis-ci/issues/7510 Travis now uses rustup.rs to install rust. This change will stop trust from installing rust a second time the exact same way that Travis does.

Using cross with build scripts breaks sometimes, see https://github.com/japaric/cross/issues/39 . By cleaning first, we ensure we don't fail because of reusing build-scripts.

Fixes #60 .

travis-ci.com is now the default for opensource projects. However their commandline tool still needs the --pro flag to encrypt the github token correctly.

I described the reason for this extra flag in more detail in my issue: #104

Fixes #130 Supersedes #124

Synopsis

Explained here: https://github.com/japaric/trust/issues/130#issuecomment-1315085924

Solution

Parse latest Git tag name from JSON returned by https://api.github.com/repos/$git/releases/latest.

Compiling memchr v2.3.3 Compiling lazy_static v1.4.0 Compiling regex-syntax v0.6.18 Compiling libc v0.2.71 Compiling autocfg v1.0.0 Compiling proc-macro-hack v0.5.16 Compiling cpython v0.5.0 Compiling thread_local v1.0.1 Compiling num-traits v0.2.12 Compiling paste-impl v0.1.17 Compiling paste v0.1.17 Compiling aho-corasick v0.7.10 Compiling regex v1.3.9 Compiling python3-sys v0.5.0 error: failed to run custom build command for python3-sys v0.5.0

Caused by: process didn't exit successfully: /target/debug/build/python3-sys-ed1507cd27247b52/build-script-build (exit code: 101) --- stderr thread 'main' panicked at 'called Result::unwrap() on an Err value: "No python interpreter found of version 3.*"', /cargo/registry/src/github.com-1ecc6299db9ec823/python3-sys-0.5.0/build.rs:450:35

Hi there. I wonder if you might be able to help me?

I've noticed the following failure on Travis Linux builds when trying to install the binary release:

$  curl -LSfs https://japaric.github.io/trust/install.sh | \
>     sh -s -- --git japaric/cross

install.sh: GitHub repository: https://github.com/japaric/cross
install.sh: Crate: cross
install.sh: Tag: latest (latest)
install.sh: Target: x86_64-unknown-linux-gnu
install.sh: Installing to: /home/travis/.cargo/bin

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

It looks to me like the install.sh script might be incompatible with the latest tag of cross because specifying the previous tag works:

$ curl -LSfs https://japaric.github.io/trust/install.sh | \
>         sh -s -- \
>          --git japaric/cross \
>            --tag v0.1.16
install.sh: GitHub repository: https://github.com/japaric/cross
install.sh: Crate: cross
install.sh: Tag: v0.1.16
install.sh: Target: x86_64-unknown-linux-gnu
install.sh: Installing to: /home/travis/.cargo/bin

We also target mac OS and it looks like it has a similar issue:

$ curl -LSfs https://japaric.github.io/trust/install.sh | \
    sh -s -- --git japaric/cross

install.sh: GitHub repository: https://github.com/japaric/cross
install.sh: Crate: cross
install.sh: Tag: latest (latest)
install.sh: Target: x86_64-apple-darwin
install.sh: Installing to: /Users/dean/.cargo/bin

tar: Unrecognized archive format
tar: Error exit delayed from previous errors.

Do you have any ideas what the problem might be here? I'm afraid I'm a bit of a Rust newbie so I must admit I'm not sure what to look for here. Let me know if I can get anything else to help with this, or if I should actually report this on this Cross project?

Thanks very much, Dean

Hi, I noticed this is using Trusty, which went out of support in April 2019. See .travis.yml line 4: https://github.com/japaric/trust/blob/master/.travis.yml#L4

Would there be any issues with using a newer Ubuntu version? Thanks!