Should Travis use "make distcheck"?

I just noticed that we had broken "make dist" on master, because one of the jenkins builders wasn't passing. I fixed it with 197d1992dba2fe.

Should our Travis builds be reconfigured to use "make distcheck" instead of "make all && make check"? It takes only a little bit longer, but it would help us be sure that we weren't running into any issues like the one above, or #25732 (moved).

Instead of passing things to "configure" directly in this case, we would need to use the DISTCHECK_CONFIGURE_FLAGS flag to set the configuration options that distcheck would use.

changed milestone to %Tor: 0.3.4.x-final

added 034-roadmap-subtask component::core tor/tor milestone::Tor: 0.3.4.x-final owner::nickm parent::25550 priority::medium resolution::implemented reviewer::isis severity::normal status::closed tor-ci type::defect labels

Trac:
Keywords: 034-roadmap-master, 034-included-20180328, 034-triage-20180328 deleted, 034-roadmap-subtask added

Trac:
Status: new to accepted
Owner: N/A to nickm

I have a patch here in a branch called travis_distcheck_029.

We should also make sure that the distributed bundles work with Rust, and I have a branch for that as travis_distcheck_031. However, we shouldn't merge that branch into 0.3.1: "make distcheck" doesn't work with Rust until 0.3.3! I have merged that branch forward as travis_distcheck_033.

Trac:
Status: accepted to needs_review

Trac:
Cc: N/A to isis, catalyst

I'm sorry, I noticed the Rust breakage with 0.3.1 and 0.3.2 because I build .debs for my Qubes sys-tor VM, but I never said anything because I don't (want to) understand enough!^Wmore about Debian or its packaging system(s) and didn't really want to get into it. In retrospect, I probably should have filed a ticket.

This patch LGTM!

Maybe we want to have conversations at some point about what Jenkins' function/purpose is (I thought it existed specifically to test packaging and more diverse architectures and platforms like arm and win32), and who maintains our Debian stuff (we seem to do a lot of bending over backwards specifically for Debian when there's also other good distros whom we completely ignore)? If so, maybe we should schedule these conversations for the Seattle 2018 network-team meeting?

Trac:
Reviewer: N/A to isis
Status: needs_review to merge_ready

Replying to isis:

I'm sorry, I noticed the Rust breakage with 0.3.1 and 0.3.2 because I build .debs for my Qubes sys-tor VM, but I never said anything because I don't (want to) understand enough!^Wmore about Debian or its packaging system(s) and didn't really want to get into it. In retrospect, I probably should have filed a ticket.

This patch LGTM!

Great! I'll plan to merge it once the team has had a chance to discuss the issue below. Let's either do it at monday meeting, or schedule a time then to do it later.

Maybe we want to have conversations at some point about what Jenkins' function/purpose is (I thought it existed specifically to test packaging and more diverse architectures and platforms like arm and win32),

From my point of view, it's okay if we rely on Jenkins to test packaging and diverse architectures, but only if we are looking at it and fixing the issues. On the other hand, if we don't treat bugs found by Jenkins failures as "must fix", then I think we need to take more patches like this that add more configurations to Travis.

I'm fine with either route: either checking Jenkins more frequently, or expanding the scope of what we do with Travis.

Merged both branches; now travis should distcheck for us

Trac:
Resolution: N/A to implemented
Status: merge_ready to closed

closed

mentioned in issue #25936 (moved)

moved to tpo/core/tor#25814 (closed)

mentioned in issue tpo/core/tor#25936 (closed)