Chandan Singh authored Feb 13, 2019 and Chandan Singh committed Feb 15, 2019

This script leverages the recently added format strings
(`%{build-deps}`, `%{runtime-deps}`) to `bst show` to print a graph in
DOT format. This requires users to have the `graphviz` python package
installed.

Additionally, users can also render the graph using the `--format`
option if they have the `graphviz` command line tool installed.

contrib/bst-graph: Add script to print graph in DOT format

Closes #705

See merge request !1148

Rather than constantly using regular expressions and retrieval from YAML
nodes, pre-parse expansion strings into a list representation cached
for reuse, and then expand them as simple string concatenation.

Signed-off-by: Daniel Silverstone <daniel.silverstone@codethink.co.uk>

Variables: Rework how expansion strings work

See merge request !1152

Angelos Evripiotis authored Feb 14, 2019 and Angelos Evripiotis committed Feb 15, 2019

Change the default value of mtime when doing export_to_tar() from `0` to
`_utils._magic_timestamp`. This avoids problems in other software, which
assume that an mtime of `0` means the file does not exist.

There is more than one example where files with an mtime of zero are
treated as non-existant by other software. e.g. [ninja][1] and [Template
Toolkit][2].

The OSTree project also [express an intention][3] to move from an mtime
of 0 to an mtime of 1:

> For this reason, OSTree acts as though all timestamps are set to
> time_t 0, so that comparisons will be considered up-to-date. Note that
> for a few releases, OSTree used 1 to fix warnings such as GNU Tar
> emitting "implausibly old time stamp" with 0; however, until we have a
> mechanism to transition cleanly to 1, for compatibilty OSTree is
> reverted to use zero again.

From the comments on export_to_tar(), the motivation for having an mtime
of 0 was to have reproducible results, rather than it specifically being
the value 0.

Additionally, the reproducible builds project has a [page on
archives][4]; it mentions the benefits of setting all the files to have
the same mtime, or clamping the mtime. It makes no mention of a
motivation for the mtime to be specifically 0.

Fixes #914

[1]: https://github.com/ninja-build/ninja/issues/1120
[2]: https://github.com/abw/Template2/blob/8d7d37200af436f1ad43628278d3caad257c8e27/lib/Template/Provider.pm#L635
[3]: https://ostree.readthedocs.io/en/latest/manual/repo/
[4]: https://reproducible-builds.org/docs/archives/

storage.Directory.export_to_tar: default mtime=utils._magic_timestamp

Closes #914

See merge request !1149

Use sets when checking for existence of an element

See merge request !1154

Angelos Evripiotis authored Feb 05, 2019 and Angelos Evripiotis committed Feb 15, 2019

Remove the need for the 'really-workspace-close-project-inaccessible'
config option, as well as the option itself.

As agreed on the mailing list [1], all the 'are you sure?' prompts on
workspace reset and close were removed. While that discussion was going
on, this new prompt and option was added. At the 2019 BuildStream
Gathering, it was verbally agreed between myself and Tristan VB that we
would also remove this instance.

It was also agreed that we should have a notice to let the user know
what they'd done, this was already in place if interactive. Moved it to
be unconditional so that there's no difference in non-interactive
behaviour. Made it output to stderr, as it's diagnostic meant for the
user. Made it the last thing echo'd so it's next to the prompt - it's
very relevant to what they type next. Added a test to make sure the text
makes it to stderr in the appropriate case, and not in an inappropriate
one.

This is the last instance of any prompt configuration, so BuildStream
can also forget all of that machinery.

[1] https://mail.gnome.org/archives/buildstream-list/2018-December/msg00111.html

userconfig: rm really-workspace-close-project-inaccessible

Closes #726 and #744

See merge request !1130

See buildstream-docker-images#26
for detailed discussion around this.

`buildstream/buildstream-fedora` is now considered deprecated. Switch to
`buildstream/buildstream` image. This image also offers more tags that
will provide users more flexibility.

Now that the `buildstream/buildstream` image has 9 variants, let's make
it easier to choose the desired tag, using a command-line option.

This is otherwise possible by specifying the full image name `image:tag`
using the `-i` option. But, this will make it easier to specify just the
tag using `-j`.

The following two invocations of `bst-here` are now equivalent:

    bst-here -i buildstream/buildstream:dev
    bst-here -j dev

contrib/bst-here: Allow users to specify image variant

See merge request !1153

[ci skip]

README.rst: Add table with distros with packaged buildstream

See merge request !1143

The directory needs to be serialized after the Digest for the
subdirectory `caller` has been updated.