Hi;
On 6 June 2016 at 12:23, Bastien Nocera wrote:
> The "srcdir != builddir" implemented in jhbuild isn't the same one as
> the one implemented in Continuous[1].
I know, that's why I wrote:
"""
The main change is that jhbuild runs the autogen script from within
the build
On Fri, 2016-06-03 at 13:11 +0200, Bastien Nocera wrote:
> On Thu, 2016-06-02 at 23:50 +0100, Emmanuele Bassi wrote:
> > [ Picking this up again ]
> >
> > I've been spending the last couple of days fixing modules on
> > git.gnome.org (you may have noticed a commit or two from me on your
> >
On Fri, 2016-06-03 at 12:31 +0100, Emmanuele Bassi wrote:
> > What's the proper fix for this then?
>
> In general, everything that modifies the Git repository or the
> autotools files, like `git submodule update` or `gtkdocize` or
> `intltoolize` will need to be called inside the source
Hi Bastien;
On 3 June 2016 at 12:11, Bastien Nocera wrote:
> On Thu, 2016-06-02 at 23:50 +0100, Emmanuele Bassi wrote:
>> [ Picking this up again ]
>>
>> As a last resource, we can mark modules that do not support non-
>> srcdir
>> builds in the various modulesets, but I'd
On Thu, 2016-06-02 at 23:50 +0100, Emmanuele Bassi wrote:
> [ Picking this up again ]
>
> I've been spending the last couple of days fixing modules on
> git.gnome.org (you may have noticed a commit or two from me on your
> modules fixing builddir != srcdir issues); submitting bugs/patches to
>
[ Picking this up again ]
I've been spending the last couple of days fixing modules on
git.gnome.org (you may have noticed a commit or two from me on your
modules fixing builddir != srcdir issues); submitting bugs/patches to
modules that are hosted elsewhere; and disabling non-srcdir builds
On 31/05/2016 19:04, Emmanuele Bassi wrote:
> b) we don't have the resources to set up and maintain a try server
> running continuous
I've been recently playing with the CI service provided by gitlab.com
and I find it very convenient: you just have to create a single file in
your repository,
On Wed, Jun 01, 2016 at 01:12:08PM +0100, Emmanuele Bassi wrote:
> The same thing will happen if you have a master/master-stable split,
> because now people will commit to master, break it anyway, and nobody
> will look at 'master-stable' because it's a completely different
> workflow than what
On 1 June 2016 at 10:33, Sébastien Wilmet wrote:
>> A try server is not a simple thing to set up; and if the cost of
>> setting it up is non-negligible, it simply pales compared to the cost
>> of keeping it up. We can barely keep Continuous building as it is —
>> somebody
On Wed, Jun 01, 2016 at 11:33:41AM +0200, Sébastien Wilmet wrote:
> With master/master-stable, developers, translators etc continue to work
> exactly as before. But GContinuous would automatically sets
> master-stable to commits that work (from the GContinuous point of view).
> And jhbuild would
On Tue, 2016-05-31 at 17:51 +0100, Emmanuele Bassi wrote:
> I'm just worried about gnome-world, but for that I guess we'll
> have to wait until stuff breaks.
Most everything in gnome-world is already broken, so don't worry about
it. We don't maintain gnome-world. Feel free to fix anything you
On Tue, May 31, 2016 at 6:47 PM Michael Catanzaro
wrote:
> Just please wait a couple days first to see if there are any
> substantial objections (which I do not expect).
Is this really necessary? This is a revived thread from February, so surely
there has been plenty of
Hi;
I already pushed the default change to master, as that will only
affect new clones or updates. I'm also building locally the default
gnome moduleset — but I can safely say that the core platform builds
fine. I'm just worried about gnome-world, but for that I guess we'll
have to wait until
On Mon, 2016-05-30 at 23:44 +0100, Emmanuele Bassi wrote:
> So, it seems that the discussion died on these shores.
>
> In the meantime, GVfs is but the latest module that broke because
> people don't test under builddir != srcdir; I really, *really* don't
> want to deal with this kind of
Hi;
On 31 May 2016 at 16:01, Sébastien Wilmet wrote:
> On Mon, May 30, 2016 at 11:44:48PM +0100, Emmanuele Bassi wrote:
>> So, it seems that the discussion died on these shores.
>>
>> In the meantime, GVfs is but the latest module that broke because
>> people don't test under
On Tue, May 31, 2016 at 05:01:23PM +0200, Sébastien Wilmet wrote:
> There could be a master-next branch that GNOME Continuous test and
> rebase/merge on top of master automatically if the build and tests
> succeed.
Or instead of master-next/master, having master/master-stable. Only
GNOME
On Mon, May 30, 2016 at 11:44:48PM +0100, Emmanuele Bassi wrote:
> So, it seems that the discussion died on these shores.
>
> In the meantime, GVfs is but the latest module that broke because
> people don't test under builddir != srcdir; I really, *really* don't
> want to deal with this kind of
Sorry for that! I've added "buildroot = '~/gnome/build'" into my jhbuildrc
thanks to this thread... so +1 for changing the defaults.
2016-05-31 0:44 GMT+02:00 Emmanuele Bassi :
> So, it seems that the discussion died on these shores.
>
> In the meantime, GVfs is but the latest
I would like to have this as default too.
As pointed out previously, maybe we can run a whole build and create exceptions
for those that doesn't build and file bugs for them, but change already the
default?
I think the sooner the better, if not we are not going to take it out of our
chest.
So, it seems that the discussion died on these shores.
In the meantime, GVfs is but the latest module that broke because
people don't test under builddir != srcdir; I really, *really* don't
want to deal with this kind of perfectly avoidable build breakages any
more.
Ciao,
Emmanuele.
On 2
On Sun, 2016-02-28 at 09:54 -0600, Michael Catanzaro wrote:
> On Sun, 2016-02-28 at 14:33 +, Emmanuele Bassi wrote:
> >
> > My proposal is to enable this behaviour in the default jhbuildrc,
> > so
> > that all GNOME projects automatically build in a separate root.
> > This
> > change should
I actually was thinking about putting the intermediate build state
inside `$XDG_CACHE_HOME/jhbuild/build` by default, like we put the
downloaded tarballs in `$XDG_CACHE_HOME/jhbuild/downloads` by default.
I can check if `$HOME/jhbuild` exists, and put a `build` directory under there.
Ciao,
A big +1 to this idea.
As a nitpick, change the buildroot to '~/jhbuild/build'
because we use by default '~/jhbuild/checkout' and
'~/jhbuild/install', or convince jhbuild devs to change
default to '~/gnome/*'.
Cheers,
Carlos Soriano
- Original Message -
| Hi all;
|
| as you may know,
On So, 2016-02-28 at 15:43 +0100, Jens Georg wrote:
> > * automated builds of our software are possible without hacks
> > * distchecking projects does not fail at the very last minute
> > before
> > release but during development
> > * we bring the development environment and the continuous
> >
Hi;
On 28 February 2016 at 15:54, Michael Catanzaro wrote:
> On Sun, 2016-02-28 at 14:33 +, Emmanuele Bassi wrote:
>> My proposal is to enable this behaviour in the default jhbuildrc, so
>> that all GNOME projects automatically build in a separate root. This
>> change
On Sun, 2016-02-28 at 14:33 +, Emmanuele Bassi wrote:
> My proposal is to enable this behaviour in the default jhbuildrc, so
> that all GNOME projects automatically build in a separate root. This
> change should have no, or minimal impact on the subset of the
> moduleset that is covered by
On Sun, Feb 28, 2016 at 02:33:02PM +, Emmanuele Bassi wrote:
> buildroot = '~/gnome/build'
I agree it's a good idea, but I'll need to change a little my habits
when I run 'make' in only one sub-directory. Instead of being at the
same place in the git repo, I'll need to be somewhere in
On 28 February 2016 at 14:33, Emmanuele Bassi wrote:
> What do maintainers think?
Makes sense to me. The quicker we catch a destdir/srcdir issue the
easier it is to fix.
Richard
___
desktop-devel-list mailing list
> * automated builds of our software are possible without hacks
> * distchecking projects does not fail at the very last minute before
> release but during development
> * we bring the development environment and the continuous deployment
> environment closer
>
> What do maintainers think?
Hi all;
as you may know, automated build services – for instance Continuous,
OBS, or the autotools distcheck – use a build directory that is not
the same as the source directory. Our own jhbuild allows this, even if
it's disabled by default. This means that developers may work on a
feature or a
30 matches
Mail list logo