Having an odd issue where Travis fails to build with the error:

Cross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override

Even though I have it specified as a global environment variable in the file:

env:
  global:
    - CRATE_NAME=tv-renamer
    - GTK=3.18
    - PKG_CONFIG_ALLOW_CROSS=1
    - LD_LIBRARY_PATH="$HOME/local/lib/"
    - PKG_CONFIG_PATH="$HOME/local/lib/pkgconfig"

Any ideas on how to get this working?

Probably hard. There's no Travis support for this AFAIK.

Or at least it seems that if you are using homu with only the auto, try and TAG branches enabled the cache is not shared between deploys or different pull requests. It seems that travis only shares caches if the cache originates from a "push builds" but the default homu model only makes use of "pull request builds"

Hey, so I wonder: Is it possible to use external libraries with this project? How?

Thanks! This project seems very cool, and I can't wait to finally be able to cross compile my project lol.

Since a lot of people will be adapting the skeletons here, it might be nice to have a special exemption that allows them to license it under whatever license they choose. This makes the licensing story very clear.

The flex / bison projects do this for their skeleton:

• https://www.gnu.org/software/bison/manual/html_node/Conditions.html
• http://git.savannah.gnu.org/cgit/bison.git/tree/data/bison.m4#n50

The latest nightly doesn't work with trust anymore. It could be related to the switch to xz, but it could also be something else. Here's the failed build: https://travis-ci.org/CryZe/livesplit-core/jobs/241630754#L298

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 just setup trust. However, I am running into a problem:

+curl -LSfs https://japaric.github.io/trust/install.sh
install.sh: GitHub repository: https://github.com/japaric/cross
install.sh: Crate: cross
install.sh: Tag: v0.1.10
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

Not sure why this happens. The complete log can be found here:
https://travis-ci.org/manuels/bulletinboard-dht/jobs/218182794

From an initial look the only difference between trust and rust-everywhere is the use of cross, and maybe one or two additional architecture. The advantages should listed in the README.

I don't like writing an issue here and bore you but I spend the whole day with 22 releases and everyone failed. I simply don't know what to do at this point.

What I did

1. copy the trust files in my repository https://github.com/flofriday/thumbcloud
2. changing some build options
3. create the appveyor encrypted key with my github token -> and appveyor works perfectly which means my github token must work
4. create the travis encrypted key with travis encrypt bd2XXXXXXX46f -> travis fails everytime at deployment with GET https://api.github.com/user: 401 - Bad credentials https://travis-ci.com/flofriday/thumbcloud/jobs/128447592

I also tried:

• travis encrypt bd2XXXXXXX46f -r flofriday/thumbcloud
• travis encrypt -r flofriday/thumbcloud -org like recommended here: travis-ci/travis-ci#8128 which gives a prompt to enter the key, however exiting with CTRL - D didn't worked on my windows machine
• Inserting the key with and without "
• travis encrypt bd2XXXXXXX46f --add
• travis encrypt bd2XXXXXXX46f --add deploy.api_key

Right now the MAJJOR.MINOR.PATCH version of cross is hard coded in ci/install.sh. Let's change it so we always install the latest MAJOR.MINOR.* version instead; that way most users won't have to update that number so often. This is going to mainly involve teaching the install.sh script to accept MAJOR.MINOR as a valid --tag.

It'd be nice to also have the crate pushed to crates.io, on tagged commits, after tests passed.

Seems rather easy to implement: https://github.com/tomaka/glutin/blob/a974631197da6da9d9a91b00b4bfc75345608e51/.travis.yml#L31

trust builds are failing now that the gcc crate has been renamed to cc

use the openwrt toolchain

Why are tests on FreeBSD disabled? I noticed that they fail when enabled, but I figured I would ask here before digging too deep into why.

If they can't be enabled, it might be worth noting why somewhere.

Thanks!

Example

If ($Env:TARGET -eq 'x86_64-pc-windows-gnu') {
  $Env:PATH += ';C:\msys64\mingw64\bin'
} ElseIf ($Env:TARGET -eq 'i686-pc-windows-gnu') {
  $Env:PATH += ';C:\msys64\mingw32\bin'
}
curl -sSf -o rustup-init.exe https://win.rustup.rs/
'curl' is not recognized as an internal or external command,
operable program or batch file.
Command exited with code 1

output for cobalt.rs

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.

I'm building my package inside a manylinux1 container (CentOS 5), so that the dylibs can be used in Python wheels. This used to work perfectly, but the change to cross and its dependence on sort --sort-version is difficult to fix; I can't even upgrade to the latest coreutils, because CentOS 5 doesn't support the .xz format that's used after coreutils version 8.13

I know gsort can be installed using homebrew on MacOS, but I wonder if there's a simple way to fix this…

Quoting from https://twitter.com/Sunjay03/status/997336553528610816:

If you use a rust-toolchain file in your @rustlang project, make sure you delete it when you run CI. If you don't, you'll always build on a single version of Rust and your tests will keep passing even if they shouldn't b/c you aren't testing what you expect

Summary of the thread at this time:

• Suggestion: CI should fail if the file is present
• Suggestion: CI should auto-delete the file
• Concern: pinned versions in two locations in your VCS (in rust-toolchain, in .travis.yml)
• Suggestion: CI should run cargo +nightly build, overriding the pin from rust-toolchain
• Note: If only building one supported version (e.g internal company code) it's how the version is defined (i.e CI shouldn't always delete it)

/cc @sunjay, @Manishearth, @llogiq, @anp

First of: Thanks for this great work. It makes it soo much faster to setup cross compiled and general auto-publishing with Rust! Thanks so much.

Coming to the problem. Some of our dependencies, somewhere deeper down depend on the backtrace and that doesn't compile in the travis setup :( . I've already tried installing other libc6 bindings but I can't find any way to fix this.

   Compiling backtrace v0.3.0

Build failed, waiting for other jobs to finish...

error: failed to run custom build command for `backtrace v0.3.0`

process didn't exit successfully: `/target/release/build/backtrace-e882241ff52c7727/build-script-build` (exit code: 1)

--- stderr

/target/release/build/backtrace-e882241ff52c7727/build-script-build: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.18' not found (required by /target/release/build/backtrace-e882241ff52c7727/build-script-build)

Full Travis log and the Travis config file used to come to this. I appreciate any input/hints/ideas!

Build on travis failed with the error of docker: Error parsing reference: "japaric/--release:v0.1.10" is not a valid repository/tag in linux.

Since you download rust as part of the build script, it would be useful to use language: generic for the travis.yml

build log

/usr/local/lib/gcc/x86_64-unknown-netbsd/5.3.0/../../../../x86_64-unknown-netbsd/bin/ld: /rust/lib/rustlib/x86_64-unknown-netbsd/lib/libstd-075ab6f2359a82f1.rlib(std-075ab6f2359a82f1.std0.rcgu.o): undefined reference to symbol 'execvp'
          /usr/local/x86_64-unknown-netbsd/lib/libc.so.12: error adding symbols: DSO missing from command line
          collect2: error: ld returned 1 exit status

I more or less constantly (but randomly) hit the following issue with AppVeyor on nightly: rust-lang/rustup#346

On nightly the checksum check fails with:

rustup-init.exe -y --default-host %TARGET% --default-toolchain %RUST_VERSION%
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: update not yet available, sorry! try again later
error: checksum failed, expected: '63c2dd25afc95dcfb4d14dedb6134137bd350df2efde824ca9ac60da16cff216', calculated: 'aaa5fc97776fdbf2fc4aa635f405fd32fb91262b667a1b434f7ad30ca51978ca'
Command exited with code 1

This is of course not to be blamed on trust. But I was thinking that if it's not just me having this issue it might be nice to fix it in trust anyway. If I'm the only one with these problems then ignore this issue.

I made this change to appveyor.yml and that seems to solve the problem. It is not elegant, but it works. Replace the rustup-init part with this:

- ps: >-
      If ($Env:RUST_VERSION -eq 'nightly') {
        Start-FileDownload "https://static.rust-lang.org/dist/rust-${env:RUST_VERSION}-${env:TARGET}.exe"
        cmd /c rust-%RUST_VERSION%-%TARGET%.exe /VERYSILENT /NORESTART /DIR="C:\Program Files (x86)\Rust"
        $Env:PATH += ';C:\Program Files (x86)\Rust\bin'
      } Else {
        cmd /c curl -sSf -o rustup-init.exe https://win.rustup.rs/
        cmd /c rustup-init.exe -y --default-host %TARGET% --default-toolchain %RUST_VERSION%
        $Env:PATH += ';C:\Users\appveyor\.cargo\bin'
      }

It does have the problem that cmd /c rustup-init.exe -y ... will output lots of ugly red output during the build, but it does not fail at least. Any idea how to silence that?

The reason for staying with rustup at all for non-nightly builds is that you can't download the latest stable release form the static.rust-lang.org server without manually specifying the version number you want.

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: #55 . It's not exactly same though; everything seems to build but there is an error during tests.

Thanks for this project!

Would be nice to be able to build .debs in addition to binaries

This part of appveyor.yml is not easy to understand for someone not very familiar with Appveyor:

# disable automatic builds
build: false

It sounds like it turns off automatically building new commits to the project. Which it doesn't.

If the following comment is correct I would say it describes the setting in a clearer way:

# We build in the test stage, so disable Appveyor's build stage.
build: false

Is it possible to cache the docker images used by cross or at least their internal cargo caches?
That way future builds would be much faster I guess.

Here is the link of CircleCI.

Thanks for this wonderful repo.

Only one thing that I noticed is the lack of clang that actually breaks all my builds.

Libclang is used by bindgen.

Now it is late, but I guess it is a simple as adding,
apt-get install llvm-3.9-dev libclang-3.9-dev clang-3.9
to the install script.

Before to go ahead and provide a PR I would like to know the maintainers opinion.

Cheers,

See line 10 of this build job

I think this may be caused by powershell somehow because I don't recall ever running into a problem like this one with Travis or pre-powershell AppVeyor configs.

It would be nice to support uploading coverage to coveralls and other services.

AppVeyor announced Linux support: https://www.appveyor.com/blog/2018/03/06/appveyor-for-linux/

I have no specific requests (or agenda) - just interested in what that means for this project.

Need to mount some stuff

The build and deploy still works, but I get this message near the end. I'm not familiar with Powershell so I'm not really sure what's going on.

Remove-Item : The method or operation is not implemented.
At C:\projects\eson\ci\before_deploy.ps1:22 char:1
+ Remove-Item $STAGE
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Remove-Item], NotImplementedException
    + FullyQualifiedErrorId : System.NotImplementedException,Microsoft.PowerShell.Commands.RemoveItemCommand

This is the first Travis build that started failing with the following error:

$ bash ci/install.sh
++dirname ci/install.sh
+. ci/utils.sh
+main
+install_c_toolchain
+case $TARGET in
+install_rustup
+sh /home/travis/rust/lib/rustlib/uninstall.sh
sh: 0: Can't open /home/travis/rust/lib/rustlib/uninstall.sh
The command "bash ci/install.sh" failed and exited with 127 during .
Your build has been stopped.

Any ideas what this could be caused by? I didn't edit any CI files in that commit.
Thank you in advance.

My project rustboy uses rust_minifb which links against X11 libs, as seen in a failed build. I tried adding libx11-dev to ci/install.sh but that didn't work either. What's the best strategy to include the headers I want for my travis build? Cheers!

I am probably doing something wrong somewhere...

I followed the instruction in .travis.yml to create the GH_TOKEN but my builds fail with 401:
https://travis-ci.org/fenollp/minrs/builds/191088904

Am I doing too many requests? Should I use repo instead of public_repo?

Thanks

Both the Travis-CI and AppVeyor configs pass --target $TARGET/--target %TARGET% flags to cargo when building and testing. Why is this? Would it make any difference if they were removed?
At least for AppVeyor the host in the %TARGET% variable has already been configured as the default in:

- rustup-init.exe -y --default-host %TARGET% --default-toolchain %RUST_VERSION%

The reason I ask is because of this bug: rust-lang/cargo#4254
Which stops me from using the serde features = ["derive"] trick on stable Rust on Windows. So I'm thinking to remove --target from my appveyor.yml. It seems to work, just want to check if there are any factors I miss.

Suddenly tokei no longer builds on CI, it just fails with ``"rustup" "target" "list" failed with exit code: Some(1).

https://travis-ci.org/Aaronepower/tokei