The culprit is probably this line:

https://github.com/adrelanos/qubes-template-whonix/blob/4233ccab24e8f0ae4da22a66b20bb2789da1a886/whonix-gateway/04_install_qubes_post.sh#L39

I forget to set that to jessie since the builds created for Whonix 13 was blessed stable.

If you want just a debug build... If you can set this environment variable (not well tested)...

export whonix_repository_suite="jessie"

Or edit/commit to qubes-template-whonix/whonix-gateway/04_install_qubes_post.sh.

For a new testing or even stable release, I need to finish the updated qubes-whonix package that I am working on at the moment.

In T527#9583, @Patrick wrote:

For a new testing or even stable release, I need to finish the updated qubes-whonix package that I am working on at the moment.

Ok, so I think for Qubes R3.2-rc2 I'll use whonix templates from rc1. Is it ok?

Yes. (Whonixl legacy bind-directories should be disabled thanks to the
qubes-core-agent-linux upgrade and bind-dirs.sh should work fine.)

In T527#9601, @marmarek wrote:

In T527#9583, @Patrick wrote:

For a new testing or even stable release, I need to finish the updated qubes-whonix package that I am working on at the moment.

Ok, so I think for Qubes R3.2-rc2 I'll use whonix templates from rc1. Is it ok?

In T527#9602, @Patrick wrote:

Yes. (Whonixl legacy bind-directories should be disabled thanks to the
qubes-core-agent-linux upgrade and bind-dirs.sh should work fine.)

On a second thought that would not work. If you use templates from R3.3-rc1 those still and these get upgrades to newer qubes-core-agent, these would be missing the bind-directories legacy function that is not yet in Whonix stable repository. whonix-setup-wizard would rerun, lost Tor config, new Tor entry guards... Perhaps a compromise we can make.

What would work better would be a rebuild of Whonix 13 from Whonix stable repository with Qubes R3.2-rc2. These would get started with bind-dirs.sh from the first boot.

R3.2-rc2 is already released...
But - the whole thing applied only to workstation template - gateway build was ok and new one is included there - I've just checked and it has legacy function in /usr/lib/qubes-bind-dirs.d/41_qubes-whonix.conf.

BTW I think it worth adding template builds for automatic testing via travis-ci. It's super easy - take a look at Debian one:
https://github.com/QubesOS/qubes-builder-debian/blob/master/.travis.yml

What repository would be good for it? qubes-template-whonix?

In T527#9607, @marmarek wrote:

R3.2-rc2 is already released...
But - the whole thing applied only to workstation template - gateway build was ok and new one is included there - I've just checked and it has legacy function in /usr/lib/qubes-bind-dirs.d/41_qubes-whonix.conf.

I wonder where /usr/lib/qubes-bind-dirs.d/41_qubes-whonix.conf comes from. I haven't added it to the stable repository.

BTW I think it worth adding template builds for automatic testing via travis-ci.

That would be awesome!

It's super easy - take a look at Debian one:
https://github.com/QubesOS/qubes-builder-debian/blob/master/.travis.yml

What repository would be good for it? qubes-template-whonix?

Yes.

In T527#9609, @Patrick wrote:

In T527#9607, @marmarek wrote:

R3.2-rc2 is already released...
But - the whole thing applied only to workstation template - gateway build was ok and new one is included there - I've just checked and it has legacy function in /usr/lib/qubes-bind-dirs.d/41_qubes-whonix.conf.

I wonder where /usr/lib/qubes-bind-dirs.d/41_qubes-whonix.conf comes from. I haven't added it to the stable repository.

Probably because of the line you've mentioned earlier the build used development repository...

Ah. Sure. However, an image build from the Whonix developers repository should not make it into any testing or even stable releases. That repo is very unstable where I do experiments that could break anything.

Hmm, this is all strange. As you can see in the build log, I've build from https://github.com/marmarek/qubes-template-whonix, master branch. And there I see WHONIX_APT_REPOSITORY_OPTS ?= stable
Is this setting ignored?

Added .travis.yml:

https://github.com/adrelanos/qubes-template-whonix/blob/master/.travis.yml

sudo ln -s sid /usr/share/debootstrap/scripts/stretch is failing. Log:

https://api.travis-ci.org/jobs/148761324/log.txt?deansi=true

Any idea? Is it even needed? I try without. (Without is also better for more consistent results.)

Package anon-workstation-packages-recommended is not configured yet.

This is likely just be a symptom. [I also would have wondered what could have broken dependencies.] The build breaks on purpose. "Failing closed." The culprit is:

Failed to download: https://dist.torproject.org/torbrowser/5.5.5/sha256sums.txt.asc

I think we discussed this before, if so, you likely remember. Anyhow, I described that failing closed mechanism when TBB download fails during build here:
https://www.whonix.org/wiki/Tor_Browser#Qubes_specific

qubes-template-whonix has been changed to whonix_repository_suite="jessie-proposed-updates" for now.

Even if I haven't learned how to build Qubes R3.2 myself yet (https://groups.google.com/forum/#!topic/qubes-devel/W917Ur9XBVI), chances are good, that you are already able to build Qubes R3.2 Whonix 13.

Whonix jessie-proposed-updates repository contains both a newer version of tb-updater (maintenance update with up to date version number) as well as an updated qubes-whonix package (fixes from T528).

Another Travis CI issue.

Makefile:45: *** Building template whonix-gateway not supported by any of configured plugins. Stop.

https://s3.amazonaws.com/archive.travis-ci.org/jobs/148762157/log.txt

(Using a minimal TravisCI config for now until these issues are sorted out until all variations get added.)

~3 years ago I had TravisCI builds somewhat working. --target root and package builds only. No vm image builds back then due to various TravisCI limitations. At one point I gave up on TravisCI, because there was too much effort and to keep it running and too much if Debian or Ubuntu code. Perhaps things have improved now. Hopefully! Generally, CI is very cool, but a Debian based CI platform is desirable.

In T527#9673, @Patrick wrote:

Added .travis.yml:

https://github.com/adrelanos/qubes-template-whonix/blob/master/.travis.yml

sudo ln -s sid /usr/share/debootstrap/scripts/stretch is failing. Log:

https://api.travis-ci.org/jobs/148761324/log.txt?deansi=true

Any idea? Is it even needed? I try without. (Without is also better for more consistent results.)

It needs to be done after installing debootstrap.

Also, dist: jessie is not supported, only precise and trusty - and we need trusty to have less ancient tools (for example make is too old in precise).

Makefile:45: *** Building template whonix-gateway not supported by any of configured plugins. Stop.

You need to enable template-whonix builder plugin (in addition to builder-debian). Simply place BUILDER_PLUGINS="template-whonix builder-debian" in env.

Using that now.

Yet BUILDER_PLUGINS is missing it.

BUILDER_PLUGINS:

     builder-fedora, builder-debian, mgmt-salt,

Hence, build still failing.

Makefile:45: *** Building template whonix-gateway not supported by any of configured plugins. Stop.

log:
https://s3.amazonaws.com/archive.travis-ci.org/jobs/148863490/log.txt

In T527#9675, @Patrick wrote:

Package anon-workstation-packages-recommended is not configured yet.

This is likely just be a symptom. [I also would have wondered what could have broken dependencies.] The build breaks on purpose. "Failing closed." The culprit is:

Failed to download: https://dist.torproject.org/torbrowser/5.5.5/sha256sums.txt.asc

Ah, haven't found this before. Anyway this was the fourth build in row which failed with the same message...

I think we discussed this before, if so, you likely remember. Anyhow, I described that failing closed mechanism when TBB download fails during build here:
https://www.whonix.org/wiki/Tor_Browser#Qubes_specific

qubes-template-whonix has been changed to whonix_repository_suite="jessie-proposed-updates" for now.

Even if I haven't learned how to build Qubes R3.2 myself yet (https://groups.google.com/forum/#!topic/qubes-devel/W917Ur9XBVI), chances are good, that you are already able to build Qubes R3.2 Whonix 13.

Whonix jessie-proposed-updates repository contains both a newer version of tb-updater (maintenance update with up to date version number) as well as an updated qubes-whonix package (fixes from T528).

Ok, will try.

In T527#9680, @Patrick wrote:

Using that now.

Yet BUILDER_PLUGINS is missing it.

BUILDER_PLUGINS:

     builder-fedora, builder-debian, mgmt-salt,

Hence, build still failing.

Makefile:45: *** Building template whonix-gateway not supported by any of configured plugins. Stop.

log:
https://s3.amazonaws.com/archive.travis-ci.org/jobs/148863490/log.txt

Try again (just retry build from travis UI)- I've fixed builder.conf to allow BUILDER_PLUGINS being overridden from env:
https://github.com/QubesOS/qubes-builder/commit/f4073690e0ecca8cb26f4b6b0c8ad791f40ca38b

Getting closer.

-> Updating sources for template-whonix...

--> Fetching from https://github.com/QubesOS/qubes-template-whonix.git master...

remote: Invalid username or password.

fatal: Authentication failed for 'https://github.com/QubesOS/qubes-template-whonix.git/'

make: *** [template-whonix.get-sources] Error 128

I could probably add a pre-script to add an override.conf that uses Whonix rather than QubesOS as github account name unless you have a better solution in mind.

I have the override file in place.

https://github.com/adrelanos/qubes-template-whonix/blob/master/.travis.yml

But it is ignored. Still failing for the same reason.

How do I make changes to override.conf take effect from command line? (usually I use ./setup, but that gui tool won't work for TravisCI)

log:
https://api.travis-ci.org/jobs/148908578/log.txt?deansi=true

In T527#9688, @Patrick wrote:

I have the override file in place.

https://github.com/adrelanos/qubes-template-whonix/blob/master/.travis.yml

But it is ignored. Still failing for the same reason.

How do I make changes to override.conf take effect from command line? (usually I use ./setup, but that gui tool won't work for TravisCI)

override.conf is only a feature of ./setup - to apply modification some and and still be able to use setup UI. It isn't a standard qubes-builder configuration.

But you can set of those settings using environment. Maybe even export xxx=yyy in before script will work (to avoid very long lines in env section).

That works. Sorting out gpg key import and verification was a bit difficult. And the before_script looks kinda complex now. Non-ideal, but it is building now. Let's see.

The build succeeded, however there was an error at the end.

./create_template_list.sh: line 13: xenstore-read: command not found

log:
https://api.travis-ci.org/jobs/148930967/log.txt?deansi=true

In T527#9691, @Patrick wrote:

The build succeeded, however there was an error at the end.

./create_template_list.sh: line 13: xenstore-read: command not found

Looks to be related to not running inside Qubes. Can be safely ignored.

Half of the builds succeeded. Both gateway and workstation builds succeeded. R3.1 and R3.2 builds succeeded.

Interestingly, only builds using USE_QUBES_REPO_TESTING=1 succeeded. These not using that failed.

https://travis-ci.org/Whonix/qubes-template-whonix

Is this something to worry about or something worth ignoring since fixed in testing?

For 3.1 - yes, this is expected, qubes-core-agent package currently is available only in testing repository (will be in stable in two days) - https://github.com/QubesOS/qubes-issues/issues/2205

For 3.2 - that's strange:

Setting up brltty (5.2~20141018-5) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
./functions.sh: line 68: 28742 Segmentation fault      (core dumped) /usr/sbin/chroot "${INSTALLDIR}" ${1+"$@"}

Where did that happen? I checked all successful logs and found that nowhere.

In the failed one (job #13.5)

Okay, that is very strange indeed. No idea. Perhaps a transient TravisCI issue?

Disabled the failing ones for now. Qubes testing R3.1 and R3.2 are building fine on a rebuild.