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

Consistent build failures #148

Closed
causal-agent opened this issue Feb 21, 2016 · 14 comments
Closed

Consistent build failures #148

causal-agent opened this issue Feb 21, 2016 · 14 comments

Comments

@causal-agent
Copy link
Contributor

I'm getting intermittent build failures locally and consistent build failures on Travis CI:

failed to run custom build command for `google-gmail1 v0.1.11+20151214`
Process didn't exit successfully: `/home/travis/build/programble/fresh/target/debug/build/google-gmail1-75b8106a78a393ea/build-script-build` (exit code: 101)
--- stderr
thread '<main>' panicked at 'assertion failed: (self.right != self.left)', /home/travis/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.29.0/src/print/pp.rs:447

https://travis-ci.org/programble/fresh/jobs/110677771

@Byron
Copy link
Owner

Byron commented Feb 21, 2016

To me it looks like an issue with the build script, which essentially runs the serde-precompiler. What do you think I can do to help with it ?

@causal-agent
Copy link
Contributor Author

I haven't checked the versions of the build dependencies. Since this just started happening, it seems like one of them maybe had a patch bump that broke things?

@causal-agent causal-agent changed the title Intermittent build failures Consistent build failures Feb 23, 2016
@reem
Copy link

reem commented Feb 26, 2016

I am seeing this too, anything I can do to help?

@Byron
Copy link
Owner

Byron commented Feb 26, 2016

I believe this is related to dermesser/yup-oauth2#16 , which in turn goes back to serde-deprecated/syntex#33 .
Currently I am just linking up the issues, maybe @erickt will be able to put the pieces together.
Usually, when issues arise in syntex land, I am totally lost.

@causal-agent
Copy link
Contributor Author

Workaround:

[dependencies]
serde = "0.6.0"
serde_json = "0.6.0"

[build-dependencies]
syntex = "=0.28.0"
serde_codegen = "=0.6.13"

Anything later than serde_codegen 0.6.13 is broken.

@softprops
Copy link

Is there a suggested version of this library to use to avoid this issue. I tried the suggestion above and my build still fails with

Process didn't exit successfully: `/source/target/debug/build/google-pubsub1-2ce61d1019a8c245/build-script-build` (exit code: 101)
--- stderr
thread '<main>' panicked at 'assertion failed: (self.right != self.left)', /root/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.30.0/src/print/pp.rs:447

edit:

I'm using the latest for google-pubsub1="0.1"

@Byron
Copy link
Owner

Byron commented Mar 28, 2016

@softprops Something you should be able to do is to just pull this repository, look into the gen/google-pubsub1 directory, and alter the cargo.toml to the workaround posted by @programble . It's quite a theory though because when I tried these numbers, I would get plenty incompatible types within serde_json 0.6.0. Maybe I am missing something though.
It's quite annoying that most of the APIs provided here are currently broken due to this issue, and I am hoping @erickt will have some time to look into the underlying problem at some point. Also I hope to have some more time soon to dig in properly, after all the workaround is supposed to work and I'd love to see it used here as well.

@causal-agent
Copy link
Contributor Author

This is the patch I applied, but I've only actually generated and used google-gmail1 with it:

From 79a8e2c9d36b52e4020bb7851a11b8b0cf42ea04 Mon Sep 17 00:00:00 2001
From: Curtis McEnroe <programble@gmail.com>
Date: Sat, 5 Mar 2016 16:03:40 -0500
Subject: [PATCH] Pin serde_codegen to 0.6.13

---
 src/mako/Cargo.toml.mako | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mako/Cargo.toml.mako b/src/mako/Cargo.toml.mako
index f124f8d..cdd73be 100644
--- a/src/mako/Cargo.toml.mako
+++ b/src/mako/Cargo.toml.mako
@@ -29,16 +29,16 @@ name = "${util.program_name()}"
 hyper = "0.7"
 ## Must match the one hyper uses, otherwise there are duplicate similarly named `Mime` structs
 mime = "0.1.0"
-serde = ">= 0.7.0"
-serde_json = ">= 0.7.0"
+serde = "0.6.0"
+serde_json = "0.6.0"
 yup-oauth2 = ">= 0.5.4"
 % for dep in cargo.get('dependencies', list()):
 ${dep}
 % endfor

 [build-dependencies]
-syntex = { version = ">= 0.23" }
-serde_codegen = { version = ">= 0.6" }
+syntex = "=0.28.0"
+serde_codegen = "=0.6.13"

 % if make.depends_on_suffix is not None:

--
2.7.2

ghost pushed a commit that referenced this issue Apr 10, 2016
Everything newer than the ones we see here will cause
the error described in #148.
@Byron
Copy link
Owner

Byron commented Apr 10, 2016

Thanks @programble , I finally managed to get it to compile as well, and am currently publishing new versions to crates.io.
To me it seems serde is breaking apart, and I admit I don't fully understand what's going on there. For some reason, I had to adjust yup-oauth to use the same serde as google-apis-rs, otherwise it wouldn't compile. Interestingly, yup-oauth2 doesn't build standalone anymore, but does so when used by google-apis-rs.
Another issue I encountered is that hyper::header::[authorization]::Scheme is not implemented for yup-oauth::Scheme when used in google-apis-rs, but seems to have no problem when used within yup-oauth2. Thus I ended up just using the hyper:0.8 Bearer header type as a workaround.

It's quite interesting that serialization/deserialization in Rust still seems to be somewhat difficult to achieve and to keep stable, at least from my experience so far.

In any case, I will keep the issue open as the root cause of this is not yet fixed.

@causal-agent
Copy link
Contributor Author

Good to see new versions released finally!

@softprops
Copy link

Great! I'm going to give this lib a second spin

@Byron
Copy link
Owner

Byron commented May 20, 2016

Please note that for now you can compile with nightly to workaround the syntex problem. I am using a line like this to do that:

make drive3-cli-cargo ARGS=build --no-default-features --features=nightly

Also a new authentication flow was added and set as default, which will make APIs like drive3 and calendar work out of the box.

@Byron
Copy link
Owner

Byron commented May 28, 2016

A PR is on the way to fix this issue on stable as well: serde-deprecated/syntex#47

@Byron
Copy link
Owner

Byron commented Jun 20, 2016

Thanks to the merge upstream this issue is now fixed for google-apis-rs as well. Please run something like make youtube3-cli-cargo ARGS=update to get the latest version of serde.

For completeness, I link the related issue in rust's libsyntax.

@Byron Byron closed this as completed Jun 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants