travis CI

[William Roberts]

I see a travis.yml file, recently modified by Nicolas, but I failed to
find the Travis CI instance on travis.org, where is it?

We should likely have it running on commits to the repo and PRs so we
can have some independent way of verifying that our run of the tests
was compromised by some env variation or mistake.

Thoughts?

Bill

[Stephen Smalley]

Post by William Roberts
I see a travis.yml file, recently modified by Nicolas, but I failed to
find the Travis CI instance on travis.org, where is it?
We should likely have it running on commits to the repo and PRs so we
can have some independent way of verifying that our run of the tests
was compromised by some env variation or mistake.
Thoughts?

To date he has just run it on his own fork. Not opposed to enabling
it, just haven't looked into that...

[William Roberts]

Post by Stephen Smalley

Post by William Roberts
I see a travis.yml file, recently modified by Nicolas, but I failed to
find the Travis CI instance on travis.org, where is it?
We should likely have it running on commits to the repo and PRs so we
can have some independent way of verifying that our run of the tests
was compromised by some env variation or mistake.
Thoughts?

To date he has just run it on his own fork. Not opposed to enabling
it, just haven't looked into that...

I have done it for my some of my projects, Ill go ahead and set this up.

[Nicolas Iooss]

On Fri, Oct 13, 2017 at 1:50 AM, William Roberts

Post by William Roberts

Post by Stephen Smalley

Post by William Roberts
I see a travis.yml file, recently modified by Nicolas, but I failed to
find the Travis CI instance on travis.org, where is it?
We should likely have it running on commits to the repo and PRs so we
can have some independent way of verifying that our run of the tests
was compromised by some env variation or mistake.
Thoughts?

To date he has just run it on his own fork. Not opposed to enabling
it, just haven't looked into that...

I have done it for my some of my projects, Ill go ahead and set this up.

I configured Travis-CI to test the branches in my Github repository a
little more than one year ago, after several build configurations got
broken (clang on Linux for example). I later added more features to it
(for example warning about missing .gitignore entries, testing several
Ruby and Python versions, etc), before I upstreamed my .travis.yml
file (a few months ago). When I did it, my main motivation was to
simplify the job of anyone who would want to configure a CI system on
the project (the building rules and dependencies should be quite
similar). Using a continuous integration system is useful to prevent
simple regression issues which would otherwise only be detected when
someone running a specific configuration tries to build the project.

Before asking to enable Travis-CI on the main SELinux repository, I
wanted to make sure it was stable/reliable enough. To do this, I
created a branch named "travis-upstream" in my repository, which
tracked the master branch of the main repository. All went well for
quite some time, until Travis-CI modified this summer their
environments, introducing some incompatibilities with projects which
use several programming languages. Thankfully these changes have been
documented in Travis-CI's blog and I updated the config file to fix
the builds with commits b1ea8120832d ("Travis-CI: use sugulite
environment") and 6d9258e5a05f ("Travis-CI: fix configuration after
September's update"). As Travis-CI does not seem to want to support
multi-language projects (cf.
https://github.com/travis-ci/travis-ci/issues/4090 for example), more
breaking changes could be introduced as the provided environment are
upgraded. Nevertheless I expect that such changes are quite easily
fixable.

In short, using a CI platform is useful and Travis-CI is a free one
which makes it possible to test several build configurations (I also
tried Circle-CI, which did not provide a similar feature) and
maintaining a working configuration does not require much effort.
Moreover when a Travis-CI job fails, the log contains the console
output which usually is very clear about what has gone wrong.
Travis-CI now also provides Docker images which help reproducing
issues and understanding their cause without needing to submit a new
job.

If you want to set this platform up for SELinux userspace project,
please go ahead :)

Cheers,
Nicolas

[William Roberts]

Post by Nicolas Iooss
On Fri, Oct 13, 2017 at 1:50 AM, William Roberts

Post by William Roberts

Post by Stephen Smalley

Post by William Roberts
I see a travis.yml file, recently modified by Nicolas, but I failed to
find the Travis CI instance on travis.org, where is it?
We should likely have it running on commits to the repo and PRs so we
can have some independent way of verifying that our run of the tests
was compromised by some env variation or mistake.
Thoughts?

To date he has just run it on his own fork. Not opposed to enabling
it, just haven't looked into that...

I have done it for my some of my projects, Ill go ahead and set this up.

I configured Travis-CI to test the branches in my Github repository a
little more than one year ago, after several build configurations got
broken (clang on Linux for example). I later added more features to it
(for example warning about missing .gitignore entries, testing several
Ruby and Python versions, etc), before I upstreamed my .travis.yml
file (a few months ago). When I did it, my main motivation was to
simplify the job of anyone who would want to configure a CI system on
the project (the building rules and dependencies should be quite
similar). Using a continuous integration system is useful to prevent
simple regression issues which would otherwise only be detected when
someone running a specific configuration tries to build the project.
Before asking to enable Travis-CI on the main SELinux repository, I
wanted to make sure it was stable/reliable enough. To do this, I
created a branch named "travis-upstream" in my repository, which
tracked the master branch of the main repository. All went well for
quite some time, until Travis-CI modified this summer their
environments, introducing some incompatibilities with projects which
use several programming languages. Thankfully these changes have been
documented in Travis-CI's blog and I updated the config file to fix
the builds with commits b1ea8120832d ("Travis-CI: use sugulite
environment") and 6d9258e5a05f ("Travis-CI: fix configuration after
September's update"). As Travis-CI does not seem to want to support
multi-language projects (cf.
https://github.com/travis-ci/travis-ci/issues/4090 for example), more
breaking changes could be introduced as the provided environment are
upgraded. Nevertheless I expect that such changes are quite easily
fixable.
In short, using a CI platform is useful and Travis-CI is a free one
which makes it possible to test several build configurations (I also
tried Circle-CI, which did not provide a similar feature) and
maintaining a working configuration does not require much effort.
Moreover when a Travis-CI job fails, the log contains the console
output which usually is very clear about what has gone wrong.
Travis-CI now also provides Docker images which help reproducing
issues and understanding their cause without needing to submit a new
job.
If you want to set this platform up for SELinux userspace project,
please go ahead :)
Cheers,
Nicolas

I tried to turn it on in travis, but got the message:

This is not an active repository

You don't have sufficient rights to enable this repo on Travis.
Please contact the admin to enable it or to receive admin rights yourself.

Stephen maybe you can do this, or grant me the permissions?

You should be able to go here:
https://travis-ci.org

And login, and then in your organization for selinux flip the switch
for travis. Once it's on, and working, we can add the badge to the README
file for build status.

[Stephen Smalley]

Post by William Roberts

Post by Nicolas Iooss
On Fri, Oct 13, 2017 at 1:50 AM, William Roberts

Post by William Roberts

Post by William Roberts
I see a travis.yml file, recently modified by Nicolas, but I
failed
to
find the Travis CI instance on travis.org, where is it?
We should likely have it running on commits to the repo and PRs so we
can have some independent way of verifying that our run of the tests
was compromised by some env variation or mistake.
Thoughts?

To date he has just run it on his own fork.  Not opposed to
enabling
it, just haven't looked into that...

I have done it for my some of my projects, Ill go ahead and set this up.

I configured Travis-CI to test the branches in my Github repository a
little more than one year ago, after several build configurations got
broken (clang on Linux for example). I later added more features to it
(for example warning about missing .gitignore entries, testing several
Ruby and Python versions, etc), before I upstreamed my .travis.yml
file (a few months ago). When I did it, my main motivation was to
simplify the job of anyone who would want to configure a CI system on
the project (the building rules and dependencies should be quite
similar). Using a continuous integration system is useful to
prevent
simple regression issues which would otherwise only be detected when
someone running a specific configuration tries to build the
project.
Before asking to enable Travis-CI on the main SELinux repository, I
wanted to make sure it was stable/reliable enough. To do this, I
created a branch named "travis-upstream" in my repository, which
tracked the master branch of the main repository. All went well for
quite some time, until Travis-CI modified this summer their
environments, introducing some incompatibilities with projects which
use several programming languages. Thankfully these changes have been
documented in Travis-CI's blog and I updated the config file to fix
the builds with commits b1ea8120832d ("Travis-CI: use sugulite
environment") and 6d9258e5a05f ("Travis-CI: fix configuration after
September's update"). As Travis-CI does not seem to want to support
multi-language projects (cf.
https://github.com/travis-ci/travis-ci/issues/4090 for example), more
breaking changes could be introduced as the provided environment are
upgraded. Nevertheless I expect that such changes are quite easily
fixable.
In short, using a CI platform is useful and Travis-CI is a free one
which makes it possible to test several build configurations (I also
tried Circle-CI, which did not provide a similar feature) and
maintaining a working configuration does not require much effort.
Moreover when a Travis-CI job fails, the log contains the console
output which usually is very clear about what has gone wrong.
Travis-CI now also provides Docker images which help reproducing
issues and understanding their cause without needing to submit a new
job.
If you want to set this platform up for SELinux userspace project,
please go ahead :)
Cheers,
Nicolas

This is not an active repository
You don't have sufficient rights to enable this repo on Travis.
Please contact the admin to enable it or to receive admin rights yourself.
Stephen maybe you can do this, or grant me the permissions?
https://travis-ci.org
And login, and then in your organization for selinux flip the switch
for travis. Once it's on, and working, we can add the badge to the README
file for build status.

Enabled now for the selinux repo.

[William Roberts]

Post by Stephen Smalley

Post by William Roberts

Post by Nicolas Iooss
On Fri, Oct 13, 2017 at 1:50 AM, William Roberts

Post by William Roberts

Post by Stephen Smalley

Post by William Roberts
I see a travis.yml file, recently modified by Nicolas, but I
failed
to
find the Travis CI instance on travis.org, where is it?
We should likely have it running on commits to the repo and PRs so we
can have some independent way of verifying that our run of the tests
was compromised by some env variation or mistake.
Thoughts?

To date he has just run it on his own fork. Not opposed to enabling
it, just haven't looked into that...

I have done it for my some of my projects, Ill go ahead and set this up.

I configured Travis-CI to test the branches in my Github repository a
little more than one year ago, after several build configurations got
broken (clang on Linux for example). I later added more features to it
(for example warning about missing .gitignore entries, testing several
Ruby and Python versions, etc), before I upstreamed my .travis.yml
file (a few months ago). When I did it, my main motivation was to
simplify the job of anyone who would want to configure a CI system on
the project (the building rules and dependencies should be quite
similar). Using a continuous integration system is useful to prevent
simple regression issues which would otherwise only be detected when
someone running a specific configuration tries to build the
project.
Before asking to enable Travis-CI on the main SELinux repository, I
wanted to make sure it was stable/reliable enough. To do this, I
created a branch named "travis-upstream" in my repository, which
tracked the master branch of the main repository. All went well for
quite some time, until Travis-CI modified this summer their
environments, introducing some incompatibilities with projects which
use several programming languages. Thankfully these changes have been
documented in Travis-CI's blog and I updated the config file to fix
the builds with commits b1ea8120832d ("Travis-CI: use sugulite
environment") and 6d9258e5a05f ("Travis-CI: fix configuration after
September's update"). As Travis-CI does not seem to want to support
multi-language projects (cf.
https://github.com/travis-ci/travis-ci/issues/4090 for example), more
breaking changes could be introduced as the provided environment are
upgraded. Nevertheless I expect that such changes are quite easily
fixable.
In short, using a CI platform is useful and Travis-CI is a free one
which makes it possible to test several build configurations (I also
tried Circle-CI, which did not provide a similar feature) and
maintaining a working configuration does not require much effort.
Moreover when a Travis-CI job fails, the log contains the console
output which usually is very clear about what has gone wrong.
Travis-CI now also provides Docker images which help reproducing
issues and understanding their cause without needing to submit a new
job.
If you want to set this platform up for SELinux userspace project,
please go ahead :)
Cheers,
Nicolas

This is not an active repository
You don't have sufficient rights to enable this repo on Travis.
Please contact the admin to enable it or to receive admin rights yourself.
Stephen maybe you can do this, or grant me the permissions?
https://travis-ci.org
And login, and then in your organization for selinux flip the switch
for travis. Once it's on, and working, we can add the badge to the README
file for build status.

Enabled now for the selinux repo.

FYI this is up and running thanks to Nicolas's .travis.yml.

You can see it verifying this PR
https://github.com/SELinuxProject/selinux/pull/66

I've submitted that patch to the mailing list as well.

[Stephen Smalley]

Post by William Roberts

Post by Stephen Smalley

Post by William Roberts
.org

Post by Nicolas Iooss
On Fri, Oct 13, 2017 at 1:50 AM, William Roberts

Post by William Roberts
sa.g

Post by William Roberts
I see a travis.yml file, recently modified by Nicolas, but I
failed
to
find the Travis CI instance on travis.org, where is it?
We should likely have it running on commits to the repo
and
PRs so we
can have some independent way of verifying that our run
of
the tests
was compromised by some env variation or mistake.
Thoughts?

To date he has just run it on his own fork.  Not opposed to
enabling
it, just haven't looked into that...

I have done it for my some of my projects, Ill go ahead and
set
this up.

I configured Travis-CI to test the branches in my Github
repository
a
little more than one year ago, after several build
configurations
got
broken (clang on Linux for example). I later added more
features to
it
(for example warning about missing .gitignore entries, testing several
Ruby and Python versions, etc), before I upstreamed my
.travis.yml
file (a few months ago). When I did it, my main motivation was to
simplify the job of anyone who would want to configure a CI
system
on
the project (the building rules and dependencies should be quite
similar). Using a continuous integration system is useful to prevent
simple regression issues which would otherwise only be detected when
someone running a specific configuration tries to build the project.
Before asking to enable Travis-CI on the main SELinux
repository, I
wanted to make sure it was stable/reliable enough. To do this, I
created a branch named "travis-upstream" in my repository, which
tracked the master branch of the main repository. All went well for
quite some time, until Travis-CI modified this summer their
environments, introducing some incompatibilities with projects which
use several programming languages. Thankfully these changes
have
been
documented in Travis-CI's blog and I updated the config file to fix
the builds with commits b1ea8120832d ("Travis-CI: use sugulite
environment") and 6d9258e5a05f ("Travis-CI: fix configuration after
September's update"). As Travis-CI does not seem to want to support
multi-language projects (cf.
https://github.com/travis-ci/travis-ci/issues/4090 for
example),
more
breaking changes could be introduced as the provided
environment
are
upgraded. Nevertheless I expect that such changes are quite easily
fixable.
In short, using a CI platform is useful and Travis-CI is a free one
which makes it possible to test several build configurations (I also
tried Circle-CI, which did not provide a similar feature) and
maintaining a working configuration does not require much effort.
Moreover when a Travis-CI job fails, the log contains the console
output which usually is very clear about what has gone wrong.
Travis-CI now also provides Docker images which help
reproducing
issues and understanding their cause without needing to submit
a
new
job.
If you want to set this platform up for SELinux userspace project,
please go ahead :)
Cheers,
Nicolas

This is not an active repository
You don't have sufficient rights to enable this repo on Travis.
Please contact the admin to enable it or to receive admin rights yourself.
Stephen maybe you can do this, or grant me the permissions?
https://travis-ci.org
And login, and then in your organization for selinux flip the switch
for travis. Once it's on, and working, we can add the badge to
the
README
file for build status.

Enabled now for the selinux repo.

FYI this is up and running thanks to Nicolas's .travis.yml.
You can see it verifying this PR
https://github.com/SELinuxProject/selinux/pull/66
I've submitted that patch to the mailing list as well.

Our .travis.yml seems to yield unstable results,
https://travis-ci.org/SELinuxProject/selinux/jobs/292128434

Don't know if it would help to instead download a refpolicy release and
extract it, or if this is just transient.

[William Roberts]

Error 52, which if it lines up with what I am reading is CURLE_GOT_NOTHING
https://curl.haxx.se/libcurl/c/libcurl-errors.html

That url/command combo seems valid, likely a transient issue with github.

Post by Stephen Smalley

Post by William Roberts

Post by Stephen Smalley

Post by William Roberts
.org

Post by Nicolas Iooss
On Fri, Oct 13, 2017 at 1:50 AM, William Roberts

Post by William Roberts
sa.g

Post by Stephen Smalley

Post by William Roberts
I see a travis.yml file, recently modified by Nicolas, but I
failed
to
find the Travis CI instance on travis.org, where is it?
We should likely have it running on commits to the repo
and
PRs so we
can have some independent way of verifying that our run
of
the tests
was compromised by some env variation or mistake.
Thoughts?

To date he has just run it on his own fork. Not opposed to enabling
it, just haven't looked into that...

I have done it for my some of my projects, Ill go ahead and
set
this up.

I configured Travis-CI to test the branches in my Github
repository
a
little more than one year ago, after several build
configurations
got
broken (clang on Linux for example). I later added more
features to
it
(for example warning about missing .gitignore entries, testing several
Ruby and Python versions, etc), before I upstreamed my
.travis.yml
file (a few months ago). When I did it, my main motivation was to
simplify the job of anyone who would want to configure a CI
system
on
the project (the building rules and dependencies should be quite
similar). Using a continuous integration system is useful to prevent
simple regression issues which would otherwise only be detected when
someone running a specific configuration tries to build the project.
Before asking to enable Travis-CI on the main SELinux
repository, I
wanted to make sure it was stable/reliable enough. To do this, I
created a branch named "travis-upstream" in my repository, which
tracked the master branch of the main repository. All went well for
quite some time, until Travis-CI modified this summer their
environments, introducing some incompatibilities with projects which
use several programming languages. Thankfully these changes
have
been
documented in Travis-CI's blog and I updated the config file to fix
the builds with commits b1ea8120832d ("Travis-CI: use sugulite
environment") and 6d9258e5a05f ("Travis-CI: fix configuration after
September's update"). As Travis-CI does not seem to want to support
multi-language projects (cf.
https://github.com/travis-ci/travis-ci/issues/4090 for
example),
more
breaking changes could be introduced as the provided
environment
are
upgraded. Nevertheless I expect that such changes are quite easily
fixable.
In short, using a CI platform is useful and Travis-CI is a free one
which makes it possible to test several build configurations (I also
tried Circle-CI, which did not provide a similar feature) and
maintaining a working configuration does not require much effort.
Moreover when a Travis-CI job fails, the log contains the console
output which usually is very clear about what has gone wrong.
Travis-CI now also provides Docker images which help
reproducing
issues and understanding their cause without needing to submit
a
new
job.
If you want to set this platform up for SELinux userspace project,
please go ahead :)
Cheers,
Nicolas

This is not an active repository
You don't have sufficient rights to enable this repo on Travis.
Please contact the admin to enable it or to receive admin rights yourself.
Stephen maybe you can do this, or grant me the permissions?
https://travis-ci.org
And login, and then in your organization for selinux flip the switch
for travis. Once it's on, and working, we can add the badge to
the
README
file for build status.

Enabled now for the selinux repo.

FYI this is up and running thanks to Nicolas's .travis.yml.
You can see it verifying this PR
https://github.com/SELinuxProject/selinux/pull/66
I've submitted that patch to the mailing list as well.

Our .travis.yml seems to yield unstable results,
https://travis-ci.org/SELinuxProject/selinux/jobs/292128434
Don't know if it would help to instead download a refpolicy release and
extract it, or if this is just transient.

[Stephen Smalley]

Post by William Roberts
Error 52, which if it lines up with what I am reading is
CURLE_GOT_NOTHING
https://curl.haxx.se/libcurl/c/libcurl-errors.html
That url/command combo seems valid, likely a transient issue with github.

I restarted the job, and it failed again in the same way (but on
different cases). Then I restarted it a third time, and this time it
ran to completion. This seems problematic; we likely need to
reconsider any use of curl from the travis.yml file.

Post by William Roberts

Post by Stephen Smalley

Post by William Roberts
gov>

Post by Stephen Smalley

On Sun, Oct 15, 2017 at 5:10 AM, Nicolas Iooss <nicolas.iooss
@m4x
.org

Post by Nicolas Iooss
On Fri, Oct 13, 2017 at 1:50 AM, William Roberts

Post by William Roberts
ho.n
sa.g

Post by William Roberts
I see a travis.yml file, recently modified by
Nicolas,
but I
failed
to
find the Travis CI instance on travis.org, where is it?
We should likely have it running on commits to the repo
and
PRs so we
can have some independent way of verifying that our run
of
the tests
was compromised by some env variation or mistake.
Thoughts?

To date he has just run it on his own fork.  Not opposed to
enabling
it, just haven't looked into that...

I have done it for my some of my projects, Ill go ahead and
set
this up.

I configured Travis-CI to test the branches in my Github
repository
a
little more than one year ago, after several build
configurations
got
broken (clang on Linux for example). I later added more
features to
it
(for example warning about missing .gitignore entries,
testing
several
Ruby and Python versions, etc), before I upstreamed my .travis.yml
file (a few months ago). When I did it, my main motivation
was
to
simplify the job of anyone who would want to configure a CI
system
on
the project (the building rules and dependencies should be quite
similar). Using a continuous integration system is useful to
prevent
simple regression issues which would otherwise only be
detected
when
someone running a specific configuration tries to build the project.
Before asking to enable Travis-CI on the main SELinux repository, I
wanted to make sure it was stable/reliable enough. To do
this,
I
created a branch named "travis-upstream" in my repository, which
tracked the master branch of the main repository. All went
well
for
quite some time, until Travis-CI modified this summer their
environments, introducing some incompatibilities with
projects
which
use several programming languages. Thankfully these changes
have
been
documented in Travis-CI's blog and I updated the config
file to
fix
the builds with commits b1ea8120832d ("Travis-CI: use sugulite
environment") and 6d9258e5a05f ("Travis-CI: fix
configuration
after
September's update"). As Travis-CI does not seem to want to support
multi-language projects (cf.
https://github.com/travis-ci/travis-ci/issues/4090 for
example),
more
breaking changes could be introduced as the provided
environment
are
upgraded. Nevertheless I expect that such changes are quite easily
fixable.
In short, using a CI platform is useful and Travis-CI is a
free
one
which makes it possible to test several build
configurations (I
also
tried Circle-CI, which did not provide a similar feature) and
maintaining a working configuration does not require much effort.
Moreover when a Travis-CI job fails, the log contains the console
output which usually is very clear about what has gone wrong.
Travis-CI now also provides Docker images which help
reproducing
issues and understanding their cause without needing to submit
a
new
job.
If you want to set this platform up for SELinux userspace project,
please go ahead :)
Cheers,
Nicolas

This is not an active repository
You don't have sufficient rights to enable this repo on Travis.
Please contact the admin to enable it or to receive admin
rights
yourself.
Stephen maybe you can do this, or grant me the permissions?
https://travis-ci.org
And login, and then in your organization for selinux flip the switch
for travis. Once it's on, and working, we can add the badge to
the
README
file for build status.

Enabled now for the selinux repo.

FYI this is up and running thanks to Nicolas's .travis.yml.
You can see it verifying this PR
https://github.com/SELinuxProject/selinux/pull/66
I've submitted that patch to the mailing list as well.

Our .travis.yml seems to yield unstable results,
https://travis-ci.org/SELinuxProject/selinux/jobs/292128434
Don't know if it would help to instead download a refpolicy release and
extract it, or if this is just transient.

[Nicolas Iooss]

On Tue, Oct 24, 2017 at 10:20 PM, William Roberts

Post by Stephen Smalley

Post by William Roberts
Error 52, which if it lines up with what I am reading is
CURLE_GOT_NOTHING
https://curl.haxx.se/libcurl/c/libcurl-errors.html
That url/command combo seems valid, likely a transient issue with github.

I restarted the job, and it failed again in the same way (but on
different cases). Then I restarted it a third time, and this time it
ran to completion. This seems problematic; we likely need to
reconsider any use of curl from the travis.yml file.
Weird. I wget things from sourceforge all the time. The only time I have
issues is when sourceforge is down.

[[...]]

Post by Stephen Smalley

Post by William Roberts

Post by Stephen Smalley
Our .travis.yml seems to yield unstable results,
https://travis-ci.org/SELinuxProject/selinux/jobs/292128434
Don't know if it would help to instead download a refpolicy release and
extract it, or if this is just transient.

It looks like transient networking issues between Travis-CI and
Github. A possible fix would consists in using the Ubuntu package
which provides refpolicy files: selinux-policy-dev. This however
introduces the drawback that the package pulls in Ubuntu's version of
checkpolicy, policycoreutils, libsepol... which may introduce
incorrect test success if they happen to be used instead of the
programs from the tested build. So I am not convinced by this.

I am wondering whether using curl's --retry option would help to work
around the networking issues which occurred. I am testing this in my
"curl-retry" branch on Github [1] and will submit a patch if you think
this may work.

Nicolas

[1] https://github.com/fishilico/selinux/commits/curl-retry

[Stephen Smalley]

Post by Nicolas Iooss
On Tue, Oct 24, 2017 at 10:20 PM, William Roberts

Post by Stephen Smalley

Post by William Roberts
Error 52, which if it lines up with what I am reading is
CURLE_GOT_NOTHING
https://curl.haxx.se/libcurl/c/libcurl-errors.html
That url/command combo seems valid, likely a transient issue with github.

I restarted the job, and it failed again in the same way (but on
different cases).  Then I restarted it a third time, and this time
it
ran to completion.  This seems problematic; we likely need to
reconsider any use of curl from the travis.yml file.
Weird. I wget things from sourceforge all the time. The only time I have
issues is when sourceforge is down.

Post by William Roberts
ov>

[[...]]

Post by Stephen Smalley

Post by William Roberts

Post by Stephen Smalley
Our .travis.yml seems to yield unstable results,
https://travis-ci.org/SELinuxProject/selinux/jobs/292128434
Don't know if it would help to instead download a refpolicy
release
and
extract it, or if this is just transient.

It looks like transient networking issues between Travis-CI and
Github. A possible fix would consists in using the Ubuntu package
which provides refpolicy files: selinux-policy-dev. This however
introduces the drawback that the package pulls in Ubuntu's version of
checkpolicy, policycoreutils, libsepol... which may introduce
incorrect test success if they happen to be used instead of the
programs from the tested build. So I am not convinced by this.
I am wondering whether using curl's --retry option would help to work
around the networking issues which occurred. I am testing this in my
"curl-retry" branch on Github [1] and will submit a patch if you think
this may work.

Sounds reasonable to me as a quick fix. Another alternative would be
to include a copy of these files in the selinux repo itself to remove
external dependencies, although that doesn't help with python.

A separate issue with the current travis-ci testing is that it doesn't
exercise any of the python component tests. On the one hand, it could
be argued that is a bug in the python/Makefile in not propagating down
make test to the sudirs, but only some of those tests can be run as
non-root. One of the audit2allow tests presently is invoked via sudo
(probably could be changed though to pass -o to sepolgen-ifgen to avoid
requiring root), and the semanage tests operate on the system policy
store and thus require root (possibly could be redirected to an
alternate root, but doesn't look like semanage provides such an option,
unlike semodule -p). We have this strange inconsistency with the
current tests where some of them can only be run as non-root and others
can only be run as root; likely should be fixed in the tests
themselves.

Post by Nicolas Iooss
Nicolas
[1] https://github.com/fishilico/selinux/commits/curl-retry