[pulseaudio-discuss] [PATCH] Add a .travis.yml for Travis CI
Felipe Sateler
fsateler at debian.org
Thu Apr 16 06:00:25 PDT 2015
On 16 April 2015 at 05:55, Arun Raghavan <arun at accosted.net> wrote:
> On 16 April 2015 at 14:23, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote:
>> On Wed, 2015-04-15 at 12:43 -0300, Felipe Sateler wrote:
>>> The edit-try loop is fairly slow since you have to wait for the travis
>>> build to happen, which is why I didn't attempt to prune the list.
>>
>> Can you give a short overview of the edit-try loop? After this is patch
>> is applied, and Travis does automatic builds, how do contributors test
>> their changes before submitting a patch, if they want to change this
>> file?
>
> I made a fork on Github and tried changes by pushing them to my fork.
I'm not sure how this works once travis is enabled on the main
repository, but I had to manually enable my fork on travis-ci. You can
see my try history here:
https://travis-ci.org/fsateler/pulseaudio/builds
I then squashed all that and sent it here.
>
>>> But some reasons for installing packages explicitly:
>>>
>>> 1. Not in build-dep (git-core, check)
>>> 2. Version upgrade after adding the trusty repositories. The build
>>> failed if I didn't upgrade the autotools before building (not sure
>>> why).
>>
>> So "apt-get build-dep" doesn't automatically upgrade all dependencies if
>> they're already installed? And you didn't want to do a full system
>> upgrade from 12.04 to 14.04.
>>
>>> 3. Me being lazy. dh-autoreconf is not used but I know it brings in
>>> all the required deps for running autotools (we use that in the debian
>>> package).
>>>
>>> Some pruning may be possible, but perhaps it is better to scrap the
>>> build-dep and be explicit on what is depended upon.
>>
>> Having an explicit list of the build dependencies seems like the best
>> way forward.
>
> I'm not a huge fan of this since we'd have to remember to update the
> file each time deps change. Using the Ubuntu packaging deps seems more
> pragmatic.
This is not really new work, as it is done already by downstream. But
this would require tracking what features the Ubuntu package has
disabled and installing new any dependencies if we want to test that.
--
Saludos,
Felipe Sateler
More information about the pulseaudio-discuss
mailing list