Re: travis build env switched to xenial

2019-04-13 Thread David Bremner
David Bremner  writes:

> I was feeling a bit annoyed at the idea of patching the notmuch test
> framework so that C99 was used by default [1], so I bumped the travis
> build env to xenial. trusty (the previous config) is EOL in April.
>
> Unfortunately it looks like xenial is also too old to have gmime-3.0, so
> we're still testing against libgmime-2.6.
>

On a related note, I've added the xapian backports ppa (maintained by
xapian upstream) to start testing against Xapian 1.4 by default. There
is some rough plan to remove support for pre-1.4 Xapian, so this is a
step in that direction. So far I didn't see an easy way to do something
similar to update the tested version of GMime

d


___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: travis build env switched to xenial

2019-03-07 Thread Dan Čermák
Brian May  writes:

> David Bremner  writes:
>
>> Those of you about to tell me how much better FreedomAvocadoCI [2] is
>> [2]: Not (yet) a real product/project.
>
> I don't know of any existing solution that actually advocates freedom
> :-(

There is for instance GitLab CI, although their "main" product
(gitlab.com) is proprietary.

A fully open source "forge" (= something like gitlab, github, etc) with
an integrated CI is https://sourcehut.org/. It is currently still in
development but already provides a number of different build
environments:
https://man.sr.ht/builds.sr.ht/compatibility.md

Not sure if it can be triggered by webhooks, but the main developer
(Drew DeVault) is quite responsive, so it probably can be integrated
into notmuch's development environment.

>
> However the following solutions seem to have really good reviews.
>
> * https://buildkite.com/ - need to provide your own machines for agents.
>
> * https://circleci.com/ - uses own cloud providers.
>
> Both these solutions - like Travis - are free for open source.
>
> There is also https://semaphoreci.com/ - it does things a bit
> differently - the workflow is configured through a website. I think I
> prefer circleci.
> -- 
> Brian May 
> https://linuxpenguins.xyz/brian/
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: travis build env switched to xenial

2019-03-06 Thread Carl Worth
On Wed, Mar 06 2019, David Bremner wrote:
> Those of you about to tell me how much better FreedomAvocadoCI [2] is
> than Travis are encouraged to set up instances and we can try it out. As
> long as Carl doesn't object, I would be interested in a setup where we
> run e.g. webhooks directly on git.notmuchmail.org to remove our
> dependence on github for CI.

I'm all in favor of removing a dependence on a third-party service here,
so would not object to adding some webhooks to our server.

-Carl


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


travis build env switched to xenial

2019-03-06 Thread David Bremner

I was feeling a bit annoyed at the idea of patching the notmuch test
framework so that C99 was used by default [1], so I bumped the travis
build env to xenial. trusty (the previous config) is EOL in April.

Unfortunately it looks like xenial is also too old to have gmime-3.0, so
we're still testing against libgmime-2.6.

Those of you about to tell me how much better FreedomAvocadoCI [2] is
than Travis are encouraged to set up instances and we can try it out. As
long as Carl doesn't object, I would be interested in a setup where we
run e.g. webhooks directly on git.notmuchmail.org to remove our
dependence on github for CI.

d

[1]: this being the 20th anniversary of C99.
[2]: Not (yet) a real product/project.


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch