IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
For patches pushed upstream we want builds run on master branch, but
don't want them run on the -maint branches, as we are not keeping the
.travis.yml file on stable branches updated wrt latest needs of travis
CI platforms.
We can't just whitelist 'master' though, because that will prevent
developers triggering their own private travis builds. So we just
blacklist *-maint, since developers will typically use named feature
branches for any work.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The 'brew upgrade' command is pulling in the python2 package which
promptly fails due to clashing symlinks installed by the new python
package (which is python3 based):
==> Pouring python@2-2.7.14_3.sierra.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/2to3-2
Target /usr/local/bin/2to3-2
is a symlink belonging to python. You can unlink it:
brew unlink python
To force the link and overwrite all conflicting files:
brew link --overwrite python@2
To list all files that would be deleted:
brew link --overwrite --dry-run python@2
By running 'brew unlink python' we can get rid of the python3 links that
we didn't want in the first place and avoid this error.
This is the working fix for what we previously attempted todo in:
commit c9c9fc90ce
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Mon Mar 5 10:13:12 2018 +0000
travis: force install of python2 into $PATH on macOS
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The list of commands we're running for the before_install task
is rather large. We have it all on one line because we're
wrapping it all in a test against TRAVIS_OS_NAME env variable.
By moving it into the osx matrix entry we can remove the need
for the conditional shell test. This lets us put each command
on a separate line making the steps clear to understand.
Fortunately the 'before_install' task does not have the crazy
behaviour whereby travis ignores errors and runs all commands
regardless, like the 'script' task does. The first command
failing will cause an immediate stop with error status.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Make sure we install the same packages lcitool would install on
the CentOS CI so that we have consistent results. The package
list is current as of libvirt-jenkins-ci commit ad84090b6f96.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The homebrew formula's ignored Python PEP-0394 recommendations and
changed the plain python binary in /usr/local/bin to point to Python 3
instead of Python 2. Python 2 is not even installed into a location that
is in $PATH by default anymore. The homebrew packages print a message
to stderr claiming to provide a way to fix this
[quote]
This formula installs a python2 executable to /usr/local/opt/python@2/bin
If you wish to have this formula's python executable in your PATH then add
the following to ~/.bash_profile:
export PATH="/usr/local/opt/python@2/libexec/bin:$PATH"
[/quote]
When trying to update $PATH are suggested we find out this message is a
lie and /usr/local/opt/python@2 does not even exist, instead Python
seems to end up in /usr/local/Cellar/python@2/2.7.14_1
Rather than hardcoding this version specific directory in our travis
config, we change to run "brew link --force python@2", to make it create
symlinks in /usr/local/bin for the python2 binary.
The original change triggering this problem was
https://github.com/Homebrew/homebrew-core/pull/24604#issue-171653084
There are countless bug reports against homebrew-core that are closed
without fixes, so it seems they are determined to ignore the Python
PEP 0394 recommendations on this.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Enable testing of both the upstart and systemd init script handling.
We test a different one in each scenario. Even though trusty only
cares about upstart, it is fine for us to test rules that install
systemd, since we're not actually running these scripts for real.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We can't use "make distcheck" on macOS because many unit tests fail. We
can still get coverage of some of the things "distcheck" validates, by
running the "install" and "dist" targets. This is particularly useful
because many conditional features are disabled on macOS, and this helps
make sure we can still successfully install & dist when these bits are
disabled.
The default script is getting unreadable since it is all on one long
line. Rather than adding further conditional clauses to it, we make
use of the travis matrix config override for the script.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Running "make distcheck" includes the "make check", and "make dist"
targets. It ensures that we have CLEANFILES and uninstall rules setup
correctly, as well as validating VPATH builds succeed.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The precise distro is marked deprecated in travis and will be dropped
entirely in 2 months time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Installing nfs-common is broken on trusty since build #807https://travis-ci.org/libvirt/libvirt/builds/326705054
It's probably a transient error on Travis' side, so just comment
it out for the time being to allow builds to proceed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Make sure we install the same packages lcitool would install on
the CentOS CI so that we have consistent results. The package
list is current as of libvirt-jenkins-ci commit 3a559ae7bc08.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
gettext, gnutls and libgcrypt are already installed on the
system, so we don't need to request their installation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Installed packages might be outdated by the time the build
runs, so we should update them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Turns out a build job can be stuck waiting for a macOS worker to
become available for a pretty long time: if more than 5 commits
have been pushed in the meantime, the clone will be too shallow
for the worker to find the commit it's supposed to verify, and
the build job will fail.
See https://travis-ci.org/libvirt/libvirt/jobs/277244110 for an
example of the failure described.
This reverts commit 2e975abdc9.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Order them more logically and make sure that stuff that doesn't
need to be modified frequently if at all, such as the notification
settings, are out of the way.
Perform other very minor tweaks as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Since configure automatically picks up as many optional dependencies
as possible, installing more packages allows us to improve our test
coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
The default distribution is apparently ignored if an explicit test
matrix is provided, so we haven't actually been testing the precise
plus gcc combo.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Make parts of the build command OS-dependent instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
The openwsman header files are at fault here, but precise is entirely
unmaintained at this point so the issue will never be fixed.
Better to ignore the error and have coverage over the Hyper-V driver
than disabling it: if code that would trigger the warning will be
added to libvirt, the CentOS CI will catch it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
We don't need 50 commits for our purposes, so might as well save some
bandwidth and possibly some time by making the clone shallower.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
msgmerge(1) and friends are required to build libvirt, so the
corresponding package should be installed in the Travis worker.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Keeping the list of build dependencies sorted alphabetically
makes it way easier to visually scan it for issues.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The HTML pages are currently validated against an XHTML 1.0 DTD.
This makes it impossible to take advantage of features that are
introduced in HTML 5, because they'll fail validation.
There is intentionally no DTD defined for HTML 5, so there's no
alternative to XHTML 1.0 DTD that we could switch to. The only
options are to stick with XHTML 1.0 forever, or drop the DTD
validation, and we pick the latter.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Disclose the content of the 'test-suite.log' file (if available) in
case of failures inside Travis-CI. This is needed to understand what
happened and to provide hints about the proper fix (if applicable).
This travis configuration tests libvirt builds on 5 platforms that we don't
exercise in the CentOS CI system.
- Ubuntu Trusty with GCC
- Ubuntu Trusty with CLang
- Ubuntu Precise with GCC
- Ubuntu Precise with CLang
- OS-X with CLang
NB, syntax-check fails on OS-X with errors like:
/bin/sh: /usr/bin/grep: Argument list too long
Presumably their grep impl isn't as good as the GNU one, so this test
config skips syntax-check on OS-X for now.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
