build.gnome.org: hardware issues

[Andrea Veri]

Hi,

the machine that was currently hosting build.gnome.org went down the past
thursday after an hardware problem, we're currently in touch with the
manufacturer for having the relevant piece substituted as soon as possible.

As a note, the 'No Route to Host' during git pushes is expected and related
to this issue. One of the hooks is failing to connect to the build machine,
thus failing. This won't affect git pushes or any other git activity.

Please keep an eye at [1] for the next status updates. Thanks for your
patience,

[1] https://status.gnome.org

-- 
Cheers,

Andrea

Debian Developer,
Fedora / EPEL packager,
GNOME Sysadmin,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: http://www.gnome.org/~av
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Sriram Ramkrishna]

I have gotten some success with using this method.  The link to the smoke
test was appreciated.  The only issue right now seems to be the fact that I
cannot connect to the ftp.gnome.org server past the /pub/ link.  I don't
know why that is.

sri


On Thu, Feb 7, 2013 at 5:12 PM, Sriram Ramkrishna  wrote:

> OK, I will see if I can get something going and then pass it along.  Like
> I said, I got people ready to do this, and getting a bullet proof build
> going without breakages will be awesome.  For these people, getting from
> released tarballs is going to be fine for them.
>
>
> On Thu, Feb 7, 2013 at 5:04 PM, Alberto Ruiz  wrote:
>
>> You can build everything that is part of our release, including most
>> external dependencies. Some tools have to be installed on the side,
>> which is a pain at the beginning, Colin is trying to solve that. I
>> haven't dealt with jhbuild-from-scratch in quite a while.
>>
>> 2013/2/7 Sriram Ramkrishna :
>> > can you build most of the platform out of this?  That would be
>> interesting
>> > to me.  Since I can just point people at that instead of asking them to
>> > build completely from git head.
>> >
>> >
>> > On Thu, Feb 7, 2013 at 11:47 AM, Alberto Ruiz  wrote:
>> >>
>> >> Yes, you can have this in your .jhbuildrc:
>> >>
>> >> moduleset =
>> >> '
>> http://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/gnome-apps-3.7.4.modules
>> '
>> >> [...]
>> >> branches['gtk+'] = ('git://git.gnome.org/gtk+', 'master')
>> >>
>> >>
>> >> This way it'll build everything from the point release except for gtk+
>> >>
>> >> As I said, it tends to be a lot more stable but if you try to build
>> >> something from master that requires something from another master
>> >> branch, you'll have to add that to branches[] as well.
>> >>
>> >> 2013/2/7 meg ford :
>> >> > Hi Alberto,
>> >> >
>> >> > So are you saying people should list the last release as the
>> moduleset
>> >> > in
>> >> > their ~/.jhbuildrc, and just build a current version of the module
>> they
>> >> > are
>> >> > going to hack on? Or did I not understand what you just said?
>> >> >
>> >> > Thanks,
>> >> > Meg
>> >> >
>> >> >
>> >> > On Thu, Feb 7, 2013 at 7:56 AM, Alberto Ruiz 
>> wrote:
>> >> >>
>> >> >> Jhbuild does build from tarballs!
>> >> >>
>> >> >> This is what I'm trying to say, each release has a moduleset for
>> >> >> jhbuild with a least of each tarball (have a look at the moduleset
>> on
>> >> >> the ftp url I posted). You can configure your jhbuild to use that
>> >> >> point release _and_ a single module from git.
>> >> >>
>> >> >> 2013/2/7 Sriram Ramkrishna :
>> >> >> > OK, what you're saying is that you get all the modules you want to
>> >> >> > get
>> >> >> > except the one module you want to hack on.  You get that from git,
>> >> >> > and
>> >> >> > then
>> >> >> > it should work.
>> >> >> >
>> >> >> > This makes sense because it's not likely going to run into
>> dependency
>> >> >> > problems like you would if you get all your packages from the
>> master
>> >> >> > packages.
>> >> >> >
>> >> >> > The downside though is that you have to do a configure;make;make
>> >> >> > install
>> >> >> > for
>> >> >> > a lot of packages.  Unless there is some hack on jhbuild to build
>> >> >> > from
>> >> >> > tarballs?
>> >> >> >
>> >> >> > sri
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz 
>> wrote:
>> >> >> >>
>> >> >> >> If you use the last point release moduleset[0] from tarballs I
>> find
>> >> >> >> the experience faster and less error prone.
>> >> >> >>
>> >> >> >> Then I configure the module I want to hack on to build from
>> master
>> >> >> >> and
>> >> >> >> this usually works, in some weird cases, master requires master
>> from
>> >> >> >> another dependency, but this is very rare and addressable case.
>> >> >> >>
>> >> >> >> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
>> >> >> >>
>> >> >> >> 2013/2/7 Sriram Ramkrishna :
>> >> >> >> > I'm not sure how I missed this thread..
>> >> >> >> >
>> >> >> >> > Regarding maintaining jhbuild  up to gtk+ - I would actually
>> like
>> >> >> >> > to
>> >> >> >> > see
>> >> >> >> > this up to at gnome-shell.  We have a number of people who I
>> have
>> >> >> >> > convinced
>> >> >> >> > to help volunteer to resolve bugs for GNOME 3.7, but are very
>> >> >> >> > frustrated
>> >> >> >> > with getting jhbuild to build for them.
>> >> >> >> >
>> >> >> >> > We really should make it a goal to get an SDK for our
>> volunteers
>> >> >> >> > to
>> >> >> >> > help
>> >> >> >> > fix
>> >> >> >> > issues.
>> >> >> >> >
>> >> >> >> > We are considering doing a jhbuild hackfest once a month for
>> >> >> >> > volunteers
>> >> >> >> > to
>> >> >> >> > learn and understand how to build under jhbuild and grow enough
>> >> >> >> > builders
>> >> >> >> > to
>> >> >> >> > make it self sustaining.
>> >> >> >> >
>> >> >> >> > But getting a certain set of modules always in buildable state
>> is
>> >> >> >> > a
>> >> >> >> > great
>> >> >> >> > goal and I hope we c

Re: build.gnome.org

[Sriram Ramkrishna]

OK, I will see if I can get something going and then pass it along.  Like I
said, I got people ready to do this, and getting a bullet proof build going
without breakages will be awesome.  For these people, getting from released
tarballs is going to be fine for them.


On Thu, Feb 7, 2013 at 5:04 PM, Alberto Ruiz  wrote:

> You can build everything that is part of our release, including most
> external dependencies. Some tools have to be installed on the side,
> which is a pain at the beginning, Colin is trying to solve that. I
> haven't dealt with jhbuild-from-scratch in quite a while.
>
> 2013/2/7 Sriram Ramkrishna :
> > can you build most of the platform out of this?  That would be
> interesting
> > to me.  Since I can just point people at that instead of asking them to
> > build completely from git head.
> >
> >
> > On Thu, Feb 7, 2013 at 11:47 AM, Alberto Ruiz  wrote:
> >>
> >> Yes, you can have this in your .jhbuildrc:
> >>
> >> moduleset =
> >> '
> http://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/gnome-apps-3.7.4.modules
> '
> >> [...]
> >> branches['gtk+'] = ('git://git.gnome.org/gtk+', 'master')
> >>
> >>
> >> This way it'll build everything from the point release except for gtk+
> >>
> >> As I said, it tends to be a lot more stable but if you try to build
> >> something from master that requires something from another master
> >> branch, you'll have to add that to branches[] as well.
> >>
> >> 2013/2/7 meg ford :
> >> > Hi Alberto,
> >> >
> >> > So are you saying people should list the last release as the moduleset
> >> > in
> >> > their ~/.jhbuildrc, and just build a current version of the module
> they
> >> > are
> >> > going to hack on? Or did I not understand what you just said?
> >> >
> >> > Thanks,
> >> > Meg
> >> >
> >> >
> >> > On Thu, Feb 7, 2013 at 7:56 AM, Alberto Ruiz  wrote:
> >> >>
> >> >> Jhbuild does build from tarballs!
> >> >>
> >> >> This is what I'm trying to say, each release has a moduleset for
> >> >> jhbuild with a least of each tarball (have a look at the moduleset on
> >> >> the ftp url I posted). You can configure your jhbuild to use that
> >> >> point release _and_ a single module from git.
> >> >>
> >> >> 2013/2/7 Sriram Ramkrishna :
> >> >> > OK, what you're saying is that you get all the modules you want to
> >> >> > get
> >> >> > except the one module you want to hack on.  You get that from git,
> >> >> > and
> >> >> > then
> >> >> > it should work.
> >> >> >
> >> >> > This makes sense because it's not likely going to run into
> dependency
> >> >> > problems like you would if you get all your packages from the
> master
> >> >> > packages.
> >> >> >
> >> >> > The downside though is that you have to do a configure;make;make
> >> >> > install
> >> >> > for
> >> >> > a lot of packages.  Unless there is some hack on jhbuild to build
> >> >> > from
> >> >> > tarballs?
> >> >> >
> >> >> > sri
> >> >> >
> >> >> >
> >> >> > On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz 
> wrote:
> >> >> >>
> >> >> >> If you use the last point release moduleset[0] from tarballs I
> find
> >> >> >> the experience faster and less error prone.
> >> >> >>
> >> >> >> Then I configure the module I want to hack on to build from master
> >> >> >> and
> >> >> >> this usually works, in some weird cases, master requires master
> from
> >> >> >> another dependency, but this is very rare and addressable case.
> >> >> >>
> >> >> >> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
> >> >> >>
> >> >> >> 2013/2/7 Sriram Ramkrishna :
> >> >> >> > I'm not sure how I missed this thread..
> >> >> >> >
> >> >> >> > Regarding maintaining jhbuild  up to gtk+ - I would actually
> like
> >> >> >> > to
> >> >> >> > see
> >> >> >> > this up to at gnome-shell.  We have a number of people who I
> have
> >> >> >> > convinced
> >> >> >> > to help volunteer to resolve bugs for GNOME 3.7, but are very
> >> >> >> > frustrated
> >> >> >> > with getting jhbuild to build for them.
> >> >> >> >
> >> >> >> > We really should make it a goal to get an SDK for our volunteers
> >> >> >> > to
> >> >> >> > help
> >> >> >> > fix
> >> >> >> > issues.
> >> >> >> >
> >> >> >> > We are considering doing a jhbuild hackfest once a month for
> >> >> >> > volunteers
> >> >> >> > to
> >> >> >> > learn and understand how to build under jhbuild and grow enough
> >> >> >> > builders
> >> >> >> > to
> >> >> >> > make it self sustaining.
> >> >> >> >
> >> >> >> > But getting a certain set of modules always in buildable state
> is
> >> >> >> > a
> >> >> >> > great
> >> >> >> > goal and I hope we can do this.
> >> >> >> >
> >> >> >> > sri
> >> >> >> >
> >> >> >> >
> >> >> >> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
> >> >> >> >  wrote:
> >> >> >> >>
> >> >> >> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
> >> >> >> >>>
> >> >> >> >>> Hello Colin,
> >> >> >> >>>
> >> >> >> >> Hi Martin, Colin,
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>> Colin Walters [2013-01-15 15:34 -0500]:
> >> >> >> 
> >> >> >>  >On Tue, 2013-01-15 at 1

Re: build.gnome.org

[Alberto Ruiz]

You can build everything that is part of our release, including most
external dependencies. Some tools have to be installed on the side,
which is a pain at the beginning, Colin is trying to solve that. I
haven't dealt with jhbuild-from-scratch in quite a while.

2013/2/7 Sriram Ramkrishna :
> can you build most of the platform out of this?  That would be interesting
> to me.  Since I can just point people at that instead of asking them to
> build completely from git head.
>
>
> On Thu, Feb 7, 2013 at 11:47 AM, Alberto Ruiz  wrote:
>>
>> Yes, you can have this in your .jhbuildrc:
>>
>> moduleset =
>> 'http://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/gnome-apps-3.7.4.modules'
>> [...]
>> branches['gtk+'] = ('git://git.gnome.org/gtk+', 'master')
>>
>>
>> This way it'll build everything from the point release except for gtk+
>>
>> As I said, it tends to be a lot more stable but if you try to build
>> something from master that requires something from another master
>> branch, you'll have to add that to branches[] as well.
>>
>> 2013/2/7 meg ford :
>> > Hi Alberto,
>> >
>> > So are you saying people should list the last release as the moduleset
>> > in
>> > their ~/.jhbuildrc, and just build a current version of the module they
>> > are
>> > going to hack on? Or did I not understand what you just said?
>> >
>> > Thanks,
>> > Meg
>> >
>> >
>> > On Thu, Feb 7, 2013 at 7:56 AM, Alberto Ruiz  wrote:
>> >>
>> >> Jhbuild does build from tarballs!
>> >>
>> >> This is what I'm trying to say, each release has a moduleset for
>> >> jhbuild with a least of each tarball (have a look at the moduleset on
>> >> the ftp url I posted). You can configure your jhbuild to use that
>> >> point release _and_ a single module from git.
>> >>
>> >> 2013/2/7 Sriram Ramkrishna :
>> >> > OK, what you're saying is that you get all the modules you want to
>> >> > get
>> >> > except the one module you want to hack on.  You get that from git,
>> >> > and
>> >> > then
>> >> > it should work.
>> >> >
>> >> > This makes sense because it's not likely going to run into dependency
>> >> > problems like you would if you get all your packages from the master
>> >> > packages.
>> >> >
>> >> > The downside though is that you have to do a configure;make;make
>> >> > install
>> >> > for
>> >> > a lot of packages.  Unless there is some hack on jhbuild to build
>> >> > from
>> >> > tarballs?
>> >> >
>> >> > sri
>> >> >
>> >> >
>> >> > On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz  wrote:
>> >> >>
>> >> >> If you use the last point release moduleset[0] from tarballs I find
>> >> >> the experience faster and less error prone.
>> >> >>
>> >> >> Then I configure the module I want to hack on to build from master
>> >> >> and
>> >> >> this usually works, in some weird cases, master requires master from
>> >> >> another dependency, but this is very rare and addressable case.
>> >> >>
>> >> >> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
>> >> >>
>> >> >> 2013/2/7 Sriram Ramkrishna :
>> >> >> > I'm not sure how I missed this thread..
>> >> >> >
>> >> >> > Regarding maintaining jhbuild  up to gtk+ - I would actually like
>> >> >> > to
>> >> >> > see
>> >> >> > this up to at gnome-shell.  We have a number of people who I have
>> >> >> > convinced
>> >> >> > to help volunteer to resolve bugs for GNOME 3.7, but are very
>> >> >> > frustrated
>> >> >> > with getting jhbuild to build for them.
>> >> >> >
>> >> >> > We really should make it a goal to get an SDK for our volunteers
>> >> >> > to
>> >> >> > help
>> >> >> > fix
>> >> >> > issues.
>> >> >> >
>> >> >> > We are considering doing a jhbuild hackfest once a month for
>> >> >> > volunteers
>> >> >> > to
>> >> >> > learn and understand how to build under jhbuild and grow enough
>> >> >> > builders
>> >> >> > to
>> >> >> > make it self sustaining.
>> >> >> >
>> >> >> > But getting a certain set of modules always in buildable state is
>> >> >> > a
>> >> >> > great
>> >> >> > goal and I hope we can do this.
>> >> >> >
>> >> >> > sri
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
>> >> >> >  wrote:
>> >> >> >>
>> >> >> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
>> >> >> >>>
>> >> >> >>> Hello Colin,
>> >> >> >>>
>> >> >> >> Hi Martin, Colin,
>> >> >> >>
>> >> >> >>
>> >> >> >>> Colin Walters [2013-01-15 15:34 -0500]:
>> >> >> 
>> >> >>  >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
>> >> >>  >
>> >> >> >
>> >> >> > > >We have experimented with that a bit, by building
>> >> >> > > >
>> >> >> > > >
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
>> >> >> 
>> >> >>  >
>> >> >>  >Interesting!  Looks quite useful.  Are you doing anything with
>> >> >>  >respect to the "jhbuild sysdeps --install" infrastructure or
>> >> >>  > is
>> >> >>  >the system package set maintained manually?
>> >> >> >>>
>> >> >> >>> Right now in our Juju charm it'

Re: build.gnome.org

[Sriram Ramkrishna]

can you build most of the platform out of this?  That would be interesting
to me.  Since I can just point people at that instead of asking them to
build completely from git head.


On Thu, Feb 7, 2013 at 11:47 AM, Alberto Ruiz  wrote:

> Yes, you can have this in your .jhbuildrc:
>
> moduleset = '
> http://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/gnome-apps-3.7.4.modules
> '
> [...]
> branches['gtk+'] = ('git://git.gnome.org/gtk+', 'master')
>
>
> This way it'll build everything from the point release except for gtk+
>
> As I said, it tends to be a lot more stable but if you try to build
> something from master that requires something from another master
> branch, you'll have to add that to branches[] as well.
>
> 2013/2/7 meg ford :
> > Hi Alberto,
> >
> > So are you saying people should list the last release as the moduleset in
> > their ~/.jhbuildrc, and just build a current version of the module they
> are
> > going to hack on? Or did I not understand what you just said?
> >
> > Thanks,
> > Meg
> >
> >
> > On Thu, Feb 7, 2013 at 7:56 AM, Alberto Ruiz  wrote:
> >>
> >> Jhbuild does build from tarballs!
> >>
> >> This is what I'm trying to say, each release has a moduleset for
> >> jhbuild with a least of each tarball (have a look at the moduleset on
> >> the ftp url I posted). You can configure your jhbuild to use that
> >> point release _and_ a single module from git.
> >>
> >> 2013/2/7 Sriram Ramkrishna :
> >> > OK, what you're saying is that you get all the modules you want to get
> >> > except the one module you want to hack on.  You get that from git, and
> >> > then
> >> > it should work.
> >> >
> >> > This makes sense because it's not likely going to run into dependency
> >> > problems like you would if you get all your packages from the master
> >> > packages.
> >> >
> >> > The downside though is that you have to do a configure;make;make
> install
> >> > for
> >> > a lot of packages.  Unless there is some hack on jhbuild to build from
> >> > tarballs?
> >> >
> >> > sri
> >> >
> >> >
> >> > On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz  wrote:
> >> >>
> >> >> If you use the last point release moduleset[0] from tarballs I find
> >> >> the experience faster and less error prone.
> >> >>
> >> >> Then I configure the module I want to hack on to build from master
> and
> >> >> this usually works, in some weird cases, master requires master from
> >> >> another dependency, but this is very rare and addressable case.
> >> >>
> >> >> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
> >> >>
> >> >> 2013/2/7 Sriram Ramkrishna :
> >> >> > I'm not sure how I missed this thread..
> >> >> >
> >> >> > Regarding maintaining jhbuild  up to gtk+ - I would actually like
> to
> >> >> > see
> >> >> > this up to at gnome-shell.  We have a number of people who I have
> >> >> > convinced
> >> >> > to help volunteer to resolve bugs for GNOME 3.7, but are very
> >> >> > frustrated
> >> >> > with getting jhbuild to build for them.
> >> >> >
> >> >> > We really should make it a goal to get an SDK for our volunteers to
> >> >> > help
> >> >> > fix
> >> >> > issues.
> >> >> >
> >> >> > We are considering doing a jhbuild hackfest once a month for
> >> >> > volunteers
> >> >> > to
> >> >> > learn and understand how to build under jhbuild and grow enough
> >> >> > builders
> >> >> > to
> >> >> > make it self sustaining.
> >> >> >
> >> >> > But getting a certain set of modules always in buildable state is a
> >> >> > great
> >> >> > goal and I hope we can do this.
> >> >> >
> >> >> > sri
> >> >> >
> >> >> >
> >> >> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
> >> >> >  wrote:
> >> >> >>
> >> >> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
> >> >> >>>
> >> >> >>> Hello Colin,
> >> >> >>>
> >> >> >> Hi Martin, Colin,
> >> >> >>
> >> >> >>
> >> >> >>> Colin Walters [2013-01-15 15:34 -0500]:
> >> >> 
> >> >>  >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
> >> >>  >
> >> >> >
> >> >> > > >We have experimented with that a bit, by building
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > > >
> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
> >> >> 
> >> >>  >
> >> >>  >Interesting!  Looks quite useful.  Are you doing anything with
> >> >>  >respect to the "jhbuild sysdeps --install" infrastructure or is
> >> >>  >the system package set maintained manually?
> >> >> >>>
> >> >> >>> Right now in our Juju charm it's a manual list:
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
> >> >> >>>
> >> >> >>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not
> work
> >> >> >>> well enough in principle?
> >> >> >>>
> >> >> >> In Quantal, there was missing dependencies, so I went the
> >> >> >> straightest
> >> >> >> way
> >> >> >> and installed them directly. Now that I have a better
> understanding
> >>

Re: build.gnome.org

[Alberto Ruiz]

Yes, you can have this in your .jhbuildrc:

moduleset = 
'http://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/gnome-apps-3.7.4.modules'
[...]
branches['gtk+'] = ('git://git.gnome.org/gtk+', 'master')


This way it'll build everything from the point release except for gtk+

As I said, it tends to be a lot more stable but if you try to build
something from master that requires something from another master
branch, you'll have to add that to branches[] as well.

2013/2/7 meg ford :
> Hi Alberto,
>
> So are you saying people should list the last release as the moduleset in
> their ~/.jhbuildrc, and just build a current version of the module they are
> going to hack on? Or did I not understand what you just said?
>
> Thanks,
> Meg
>
>
> On Thu, Feb 7, 2013 at 7:56 AM, Alberto Ruiz  wrote:
>>
>> Jhbuild does build from tarballs!
>>
>> This is what I'm trying to say, each release has a moduleset for
>> jhbuild with a least of each tarball (have a look at the moduleset on
>> the ftp url I posted). You can configure your jhbuild to use that
>> point release _and_ a single module from git.
>>
>> 2013/2/7 Sriram Ramkrishna :
>> > OK, what you're saying is that you get all the modules you want to get
>> > except the one module you want to hack on.  You get that from git, and
>> > then
>> > it should work.
>> >
>> > This makes sense because it's not likely going to run into dependency
>> > problems like you would if you get all your packages from the master
>> > packages.
>> >
>> > The downside though is that you have to do a configure;make;make install
>> > for
>> > a lot of packages.  Unless there is some hack on jhbuild to build from
>> > tarballs?
>> >
>> > sri
>> >
>> >
>> > On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz  wrote:
>> >>
>> >> If you use the last point release moduleset[0] from tarballs I find
>> >> the experience faster and less error prone.
>> >>
>> >> Then I configure the module I want to hack on to build from master and
>> >> this usually works, in some weird cases, master requires master from
>> >> another dependency, but this is very rare and addressable case.
>> >>
>> >> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
>> >>
>> >> 2013/2/7 Sriram Ramkrishna :
>> >> > I'm not sure how I missed this thread..
>> >> >
>> >> > Regarding maintaining jhbuild  up to gtk+ - I would actually like to
>> >> > see
>> >> > this up to at gnome-shell.  We have a number of people who I have
>> >> > convinced
>> >> > to help volunteer to resolve bugs for GNOME 3.7, but are very
>> >> > frustrated
>> >> > with getting jhbuild to build for them.
>> >> >
>> >> > We really should make it a goal to get an SDK for our volunteers to
>> >> > help
>> >> > fix
>> >> > issues.
>> >> >
>> >> > We are considering doing a jhbuild hackfest once a month for
>> >> > volunteers
>> >> > to
>> >> > learn and understand how to build under jhbuild and grow enough
>> >> > builders
>> >> > to
>> >> > make it self sustaining.
>> >> >
>> >> > But getting a certain set of modules always in buildable state is a
>> >> > great
>> >> > goal and I hope we can do this.
>> >> >
>> >> > sri
>> >> >
>> >> >
>> >> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
>> >> >  wrote:
>> >> >>
>> >> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
>> >> >>>
>> >> >>> Hello Colin,
>> >> >>>
>> >> >> Hi Martin, Colin,
>> >> >>
>> >> >>
>> >> >>> Colin Walters [2013-01-15 15:34 -0500]:
>> >> 
>> >>  >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
>> >>  >
>> >> >
>> >> > > >We have experimented with that a bit, by building
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
>> >> 
>> >>  >
>> >>  >Interesting!  Looks quite useful.  Are you doing anything with
>> >>  >respect to the "jhbuild sysdeps --install" infrastructure or is
>> >>  >the system package set maintained manually?
>> >> >>>
>> >> >>> Right now in our Juju charm it's a manual list:
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
>> >> >>>
>> >> >>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
>> >> >>> well enough in principle?
>> >> >>>
>> >> >> In Quantal, there was missing dependencies, so I went the
>> >> >> straightest
>> >> >> way
>> >> >> and installed them directly. Now that I have a better understanding
>> >> >> how
>> >> >> jhbuild works that's something I want to reconsider for Raring and
>> >> >> avoid
>> >> >> maintaining them in 2 different places.
>> >> >>
>> >> >> --
>> >> >> Jean-Baptiste
>> >> >> IRC: jibel
>> >> >>
>> >> >> ___
>> >> >> desktop-devel-list mailing list
>> >> >> desktop-devel-list@gnome.org
>> >> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>> >> >
>> >> >
>> >> >
>> >> > ___
>> >> > desk

Re: build.gnome.org

[Sriram Ramkrishna]

Actually this is perfect.. I can totally sell this to teh community as a
better way of building GNOME.  I'm excited!


On Thu, Feb 7, 2013 at 7:33 AM, meg ford  wrote:

> Hi Alberto,
>
> So are you saying people should list the last release as the moduleset in
> their ~/.jhbuildrc, and just build a current version of the module they are
> going to hack on? Or did I not understand what you just said?
>
> Thanks,
> Meg
>
>
> On Thu, Feb 7, 2013 at 7:56 AM, Alberto Ruiz  wrote:
>
>> Jhbuild does build from tarballs!
>>
>> This is what I'm trying to say, each release has a moduleset for
>> jhbuild with a least of each tarball (have a look at the moduleset on
>> the ftp url I posted). You can configure your jhbuild to use that
>> point release _and_ a single module from git.
>>
>> 2013/2/7 Sriram Ramkrishna :
>> > OK, what you're saying is that you get all the modules you want to get
>> > except the one module you want to hack on.  You get that from git, and
>> then
>> > it should work.
>> >
>> > This makes sense because it's not likely going to run into dependency
>> > problems like you would if you get all your packages from the master
>> > packages.
>> >
>> > The downside though is that you have to do a configure;make;make
>> install for
>> > a lot of packages.  Unless there is some hack on jhbuild to build from
>> > tarballs?
>> >
>> > sri
>> >
>> >
>> > On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz  wrote:
>> >>
>> >> If you use the last point release moduleset[0] from tarballs I find
>> >> the experience faster and less error prone.
>> >>
>> >> Then I configure the module I want to hack on to build from master and
>> >> this usually works, in some weird cases, master requires master from
>> >> another dependency, but this is very rare and addressable case.
>> >>
>> >> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
>> >>
>> >> 2013/2/7 Sriram Ramkrishna :
>> >> > I'm not sure how I missed this thread..
>> >> >
>> >> > Regarding maintaining jhbuild  up to gtk+ - I would actually like to
>> see
>> >> > this up to at gnome-shell.  We have a number of people who I have
>> >> > convinced
>> >> > to help volunteer to resolve bugs for GNOME 3.7, but are very
>> frustrated
>> >> > with getting jhbuild to build for them.
>> >> >
>> >> > We really should make it a goal to get an SDK for our volunteers to
>> help
>> >> > fix
>> >> > issues.
>> >> >
>> >> > We are considering doing a jhbuild hackfest once a month for
>> volunteers
>> >> > to
>> >> > learn and understand how to build under jhbuild and grow enough
>> builders
>> >> > to
>> >> > make it self sustaining.
>> >> >
>> >> > But getting a certain set of modules always in buildable state is a
>> >> > great
>> >> > goal and I hope we can do this.
>> >> >
>> >> > sri
>> >> >
>> >> >
>> >> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
>> >> >  wrote:
>> >> >>
>> >> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
>> >> >>>
>> >> >>> Hello Colin,
>> >> >>>
>> >> >> Hi Martin, Colin,
>> >> >>
>> >> >>
>> >> >>> Colin Walters [2013-01-15 15:34 -0500]:
>> >> 
>> >>  >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
>> >>  >
>> >> >
>> >> > > >We have experimented with that a bit, by building
>> >> > > >
>> >> > > >
>> >> > > >
>> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
>> >> 
>> >>  >
>> >>  >Interesting!  Looks quite useful.  Are you doing anything with
>> >>  >respect to the "jhbuild sysdeps --install" infrastructure or is
>> >>  >the system package set maintained manually?
>> >> >>>
>> >> >>> Right now in our Juju charm it's a manual list:
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
>> >> >>>
>> >> >>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
>> >> >>> well enough in principle?
>> >> >>>
>> >> >> In Quantal, there was missing dependencies, so I went the
>> straightest
>> >> >> way
>> >> >> and installed them directly. Now that I have a better understanding
>> how
>> >> >> jhbuild works that's something I want to reconsider for Raring and
>> >> >> avoid
>> >> >> maintaining them in 2 different places.
>> >> >>
>> >> >> --
>> >> >> Jean-Baptiste
>> >> >> IRC: jibel
>> >> >>
>> >> >> ___
>> >> >> desktop-devel-list mailing list
>> >> >> desktop-devel-list@gnome.org
>> >> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>> >> >
>> >> >
>> >> >
>> >> > ___
>> >> > desktop-devel-list mailing list
>> >> > desktop-devel-list@gnome.org
>> >> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>> >>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Alberto Ruiz
>> >
>> >
>>
>>
>>
>> --
>> Cheers,
>> Alberto Ruiz
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://ma

Re: build.gnome.org

[meg ford]

Hi Alberto,

So are you saying people should list the last release as the moduleset in
their ~/.jhbuildrc, and just build a current version of the module they are
going to hack on? Or did I not understand what you just said?

Thanks,
Meg

On Thu, Feb 7, 2013 at 7:56 AM, Alberto Ruiz  wrote:

> Jhbuild does build from tarballs!
>
> This is what I'm trying to say, each release has a moduleset for
> jhbuild with a least of each tarball (have a look at the moduleset on
> the ftp url I posted). You can configure your jhbuild to use that
> point release _and_ a single module from git.
>
> 2013/2/7 Sriram Ramkrishna :
> > OK, what you're saying is that you get all the modules you want to get
> > except the one module you want to hack on.  You get that from git, and
> then
> > it should work.
> >
> > This makes sense because it's not likely going to run into dependency
> > problems like you would if you get all your packages from the master
> > packages.
> >
> > The downside though is that you have to do a configure;make;make install
> for
> > a lot of packages.  Unless there is some hack on jhbuild to build from
> > tarballs?
> >
> > sri
> >
> >
> > On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz  wrote:
> >>
> >> If you use the last point release moduleset[0] from tarballs I find
> >> the experience faster and less error prone.
> >>
> >> Then I configure the module I want to hack on to build from master and
> >> this usually works, in some weird cases, master requires master from
> >> another dependency, but this is very rare and addressable case.
> >>
> >> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
> >>
> >> 2013/2/7 Sriram Ramkrishna :
> >> > I'm not sure how I missed this thread..
> >> >
> >> > Regarding maintaining jhbuild  up to gtk+ - I would actually like to
> see
> >> > this up to at gnome-shell.  We have a number of people who I have
> >> > convinced
> >> > to help volunteer to resolve bugs for GNOME 3.7, but are very
> frustrated
> >> > with getting jhbuild to build for them.
> >> >
> >> > We really should make it a goal to get an SDK for our volunteers to
> help
> >> > fix
> >> > issues.
> >> >
> >> > We are considering doing a jhbuild hackfest once a month for
> volunteers
> >> > to
> >> > learn and understand how to build under jhbuild and grow enough
> builders
> >> > to
> >> > make it self sustaining.
> >> >
> >> > But getting a certain set of modules always in buildable state is a
> >> > great
> >> > goal and I hope we can do this.
> >> >
> >> > sri
> >> >
> >> >
> >> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
> >> >  wrote:
> >> >>
> >> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
> >> >>>
> >> >>> Hello Colin,
> >> >>>
> >> >> Hi Martin, Colin,
> >> >>
> >> >>
> >> >>> Colin Walters [2013-01-15 15:34 -0500]:
> >> 
> >>  >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
> >>  >
> >> >
> >> > > >We have experimented with that a bit, by building
> >> > > >
> >> > > >
> >> > > >
> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
> >> 
> >>  >
> >>  >Interesting!  Looks quite useful.  Are you doing anything with
> >>  >respect to the "jhbuild sysdeps --install" infrastructure or is
> >>  >the system package set maintained manually?
> >> >>>
> >> >>> Right now in our Juju charm it's a manual list:
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
> >> >>>
> >> >>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
> >> >>> well enough in principle?
> >> >>>
> >> >> In Quantal, there was missing dependencies, so I went the straightest
> >> >> way
> >> >> and installed them directly. Now that I have a better understanding
> how
> >> >> jhbuild works that's something I want to reconsider for Raring and
> >> >> avoid
> >> >> maintaining them in 2 different places.
> >> >>
> >> >> --
> >> >> Jean-Baptiste
> >> >> IRC: jibel
> >> >>
> >> >> ___
> >> >> desktop-devel-list mailing list
> >> >> desktop-devel-list@gnome.org
> >> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >> >
> >> >
> >> >
> >> > ___
> >> > desktop-devel-list mailing list
> >> > desktop-devel-list@gnome.org
> >> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Alberto Ruiz
> >
> >
>
>
>
> --
> Cheers,
> Alberto Ruiz
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Alberto Ruiz]

Jhbuild does build from tarballs!

This is what I'm trying to say, each release has a moduleset for
jhbuild with a least of each tarball (have a look at the moduleset on
the ftp url I posted). You can configure your jhbuild to use that
point release _and_ a single module from git.

2013/2/7 Sriram Ramkrishna :
> OK, what you're saying is that you get all the modules you want to get
> except the one module you want to hack on.  You get that from git, and then
> it should work.
>
> This makes sense because it's not likely going to run into dependency
> problems like you would if you get all your packages from the master
> packages.
>
> The downside though is that you have to do a configure;make;make install for
> a lot of packages.  Unless there is some hack on jhbuild to build from
> tarballs?
>
> sri
>
>
> On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz  wrote:
>>
>> If you use the last point release moduleset[0] from tarballs I find
>> the experience faster and less error prone.
>>
>> Then I configure the module I want to hack on to build from master and
>> this usually works, in some weird cases, master requires master from
>> another dependency, but this is very rare and addressable case.
>>
>> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
>>
>> 2013/2/7 Sriram Ramkrishna :
>> > I'm not sure how I missed this thread..
>> >
>> > Regarding maintaining jhbuild  up to gtk+ - I would actually like to see
>> > this up to at gnome-shell.  We have a number of people who I have
>> > convinced
>> > to help volunteer to resolve bugs for GNOME 3.7, but are very frustrated
>> > with getting jhbuild to build for them.
>> >
>> > We really should make it a goal to get an SDK for our volunteers to help
>> > fix
>> > issues.
>> >
>> > We are considering doing a jhbuild hackfest once a month for volunteers
>> > to
>> > learn and understand how to build under jhbuild and grow enough builders
>> > to
>> > make it self sustaining.
>> >
>> > But getting a certain set of modules always in buildable state is a
>> > great
>> > goal and I hope we can do this.
>> >
>> > sri
>> >
>> >
>> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
>> >  wrote:
>> >>
>> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
>> >>>
>> >>> Hello Colin,
>> >>>
>> >> Hi Martin, Colin,
>> >>
>> >>
>> >>> Colin Walters [2013-01-15 15:34 -0500]:
>> 
>>  >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
>>  >
>> >
>> > > >We have experimented with that a bit, by building
>> > > >
>> > > >
>> > > > https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
>> 
>>  >
>>  >Interesting!  Looks quite useful.  Are you doing anything with
>>  >respect to the "jhbuild sysdeps --install" infrastructure or is
>>  >the system package set maintained manually?
>> >>>
>> >>> Right now in our Juju charm it's a manual list:
>> >>>
>> >>>
>> >>>
>> >>> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
>> >>>
>> >>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
>> >>> well enough in principle?
>> >>>
>> >> In Quantal, there was missing dependencies, so I went the straightest
>> >> way
>> >> and installed them directly. Now that I have a better understanding how
>> >> jhbuild works that's something I want to reconsider for Raring and
>> >> avoid
>> >> maintaining them in 2 different places.
>> >>
>> >> --
>> >> Jean-Baptiste
>> >> IRC: jibel
>> >>
>> >> ___
>> >> desktop-devel-list mailing list
>> >> desktop-devel-list@gnome.org
>> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>> >
>> >
>> >
>> > ___
>> > desktop-devel-list mailing list
>> > desktop-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>>
>>
>> --
>> Cheers,
>> Alberto Ruiz
>
>



--
Cheers,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Germán Póo-Caamaño]

On Wed, 2013-02-06 at 20:36 -0800, Sriram Ramkrishna wrote:
> OK, what you're saying is that you get all the modules you want to get
> except the one module you want to hack on.  You get that from git, and then
> it should work.

Strictly speaking you only need the dependencies of the programs you
want to hack on.

> This makes sense because it's not likely going to run into dependency
> problems like you would if you get all your packages from the master
> packages.
> 
> The downside though is that you have to do a configure;make;make install
> for a lot of packages.  Unless there is some hack on jhbuild to build from
> tarballs?

The hack you need is to download the module sets from
http://ftp.gnome.org/pub/GNOME/teams/releng/3.7.4/ ;-)

You might want read: https://live.gnome.org/Smoketesting

And eventually, check: http://git.gnome.org/browse/releng/tree/ and
https://live.gnome.org/ReleasePlanning/MakingARelease to get an idea how
the release team does it.

-- 
Germán Poo-Caamaño
http://calcifer.org/


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Sriram Ramkrishna]

OK, what you're saying is that you get all the modules you want to get
except the one module you want to hack on.  You get that from git, and then
it should work.

This makes sense because it's not likely going to run into dependency
problems like you would if you get all your packages from the master
packages.

The downside though is that you have to do a configure;make;make install
for a lot of packages.  Unless there is some hack on jhbuild to build from
tarballs?

sri


On Wed, Feb 6, 2013 at 6:35 PM, Alberto Ruiz  wrote:

> If you use the last point release moduleset[0] from tarballs I find
> the experience faster and less error prone.
>
> Then I configure the module I want to hack on to build from master and
> this usually works, in some weird cases, master requires master from
> another dependency, but this is very rare and addressable case.
>
> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
>
> 2013/2/7 Sriram Ramkrishna :
> > I'm not sure how I missed this thread..
> >
> > Regarding maintaining jhbuild  up to gtk+ - I would actually like to see
> > this up to at gnome-shell.  We have a number of people who I have
> convinced
> > to help volunteer to resolve bugs for GNOME 3.7, but are very frustrated
> > with getting jhbuild to build for them.
> >
> > We really should make it a goal to get an SDK for our volunteers to help
> fix
> > issues.
> >
> > We are considering doing a jhbuild hackfest once a month for volunteers
> to
> > learn and understand how to build under jhbuild and grow enough builders
> to
> > make it self sustaining.
> >
> > But getting a certain set of modules always in buildable state is a great
> > goal and I hope we can do this.
> >
> > sri
> >
> >
> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
> >  wrote:
> >>
> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
> >>>
> >>> Hello Colin,
> >>>
> >> Hi Martin, Colin,
> >>
> >>
> >>> Colin Walters [2013-01-15 15:34 -0500]:
> 
>  >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
>  >
> >
> > > >We have experimented with that a bit, by building
> > > >
> > > >
> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
> 
>  >
>  >Interesting!  Looks quite useful.  Are you doing anything with
>  >respect to the "jhbuild sysdeps --install" infrastructure or is
>  >the system package set maintained manually?
> >>>
> >>> Right now in our Juju charm it's a manual list:
> >>>
> >>>
> >>>
> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
> >>>
> >>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
> >>> well enough in principle?
> >>>
> >> In Quantal, there was missing dependencies, so I went the straightest
> way
> >> and installed them directly. Now that I have a better understanding how
> >> jhbuild works that's something I want to reconsider for Raring and avoid
> >> maintaining them in 2 different places.
> >>
> >> --
> >> Jean-Baptiste
> >> IRC: jibel
> >>
> >> ___
> >> desktop-devel-list mailing list
> >> desktop-devel-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >
> >
> >
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> --
> Cheers,
> Alberto Ruiz
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Hashem Nasarat]

How do you set that up? Do you somehow install the tarballs into the
jhbuild install directory?
On Feb 6, 2013 9:35 PM, "Alberto Ruiz"  wrote:

> If you use the last point release moduleset[0] from tarballs I find
> the experience faster and less error prone.
>
> Then I configure the module I want to hack on to build from master and
> this usually works, in some weird cases, master requires master from
> another dependency, but this is very rare and addressable case.
>
> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
>
> 2013/2/7 Sriram Ramkrishna :
> > I'm not sure how I missed this thread..
> >
> > Regarding maintaining jhbuild  up to gtk+ - I would actually like to see
> > this up to at gnome-shell.  We have a number of people who I have
> convinced
> > to help volunteer to resolve bugs for GNOME 3.7, but are very frustrated
> > with getting jhbuild to build for them.
> >
> > We really should make it a goal to get an SDK for our volunteers to help
> fix
> > issues.
> >
> > We are considering doing a jhbuild hackfest once a month for volunteers
> to
> > learn and understand how to build under jhbuild and grow enough builders
> to
> > make it self sustaining.
> >
> > But getting a certain set of modules always in buildable state is a great
> > goal and I hope we can do this.
> >
> > sri
> >
> >
> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
> >  wrote:
> >>
> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
> >>>
> >>> Hello Colin,
> >>>
> >> Hi Martin, Colin,
> >>
> >>
> >>> Colin Walters [2013-01-15 15:34 -0500]:
> 
>  >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
>  >
> >
> > > >We have experimented with that a bit, by building
> > > >
> > > >
> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
> 
>  >
>  >Interesting!  Looks quite useful.  Are you doing anything with
>  >respect to the "jhbuild sysdeps --install" infrastructure or is
>  >the system package set maintained manually?
> >>>
> >>> Right now in our Juju charm it's a manual list:
> >>>
> >>>
> >>>
> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
> >>>
> >>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
> >>> well enough in principle?
> >>>
> >> In Quantal, there was missing dependencies, so I went the straightest
> way
> >> and installed them directly. Now that I have a better understanding how
> >> jhbuild works that's something I want to reconsider for Raring and avoid
> >> maintaining them in 2 different places.
> >>
> >> --
> >> Jean-Baptiste
> >> IRC: jibel
> >>
> >> ___
> >> desktop-devel-list mailing list
> >> desktop-devel-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >
> >
> >
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> --
> Cheers,
> Alberto Ruiz
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Alberto Ruiz]

If you use the last point release moduleset[0] from tarballs I find
the experience faster and less error prone.

Then I configure the module I want to hack on to build from master and
this usually works, in some weird cases, master requires master from
another dependency, but this is very rare and addressable case.

[0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/

2013/2/7 Sriram Ramkrishna :
> I'm not sure how I missed this thread..
>
> Regarding maintaining jhbuild  up to gtk+ - I would actually like to see
> this up to at gnome-shell.  We have a number of people who I have convinced
> to help volunteer to resolve bugs for GNOME 3.7, but are very frustrated
> with getting jhbuild to build for them.
>
> We really should make it a goal to get an SDK for our volunteers to help fix
> issues.
>
> We are considering doing a jhbuild hackfest once a month for volunteers to
> learn and understand how to build under jhbuild and grow enough builders to
> make it self sustaining.
>
> But getting a certain set of modules always in buildable state is a great
> goal and I hope we can do this.
>
> sri
>
>
> On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
>  wrote:
>>
>> On 01/16/2013 07:39 AM, Martin Pitt wrote:
>>>
>>> Hello Colin,
>>>
>> Hi Martin, Colin,
>>
>>
>>> Colin Walters [2013-01-15 15:34 -0500]:

 >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
 >
>
> > >We have experimented with that a bit, by building
> > >
> > >   https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/

 >
 >Interesting!  Looks quite useful.  Are you doing anything with
 >respect to the "jhbuild sysdeps --install" infrastructure or is
 >the system package set maintained manually?
>>>
>>> Right now in our Juju charm it's a manual list:
>>>
>>>
>>> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
>>>
>>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
>>> well enough in principle?
>>>
>> In Quantal, there was missing dependencies, so I went the straightest way
>> and installed them directly. Now that I have a better understanding how
>> jhbuild works that's something I want to reconsider for Raring and avoid
>> maintaining them in 2 different places.
>>
>> --
>> Jean-Baptiste
>> IRC: jibel
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



--
Cheers,
Alberto Ruiz
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Sriram Ramkrishna]

I'm not sure how I missed this thread..

Regarding maintaining jhbuild  up to gtk+ - I would actually like to see
this up to at gnome-shell.  We have a number of people who I have convinced
to help volunteer to resolve bugs for GNOME 3.7, but are very frustrated
with getting jhbuild to build for them.

We really should make it a goal to get an SDK for our volunteers to help
fix issues.

We are considering doing a jhbuild hackfest once a month for volunteers to
learn and understand how to build under jhbuild and grow enough builders to
make it self sustaining.

But getting a certain set of modules always in buildable state is a great
goal and I hope we can do this.

sri


On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement <
jean-baptiste.lallem...@canonical.com> wrote:

> On 01/16/2013 07:39 AM, Martin Pitt wrote:
>
>> Hello Colin,
>>
>>  Hi Martin, Colin,
>
>
>  Colin Walters [2013-01-15 15:34 -0500]:
>>
>>> >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
>>> >
>>>
 > >We have experimented with that a bit, by building
 > >
 > >   https://jenkins.qa.ubuntu.com/**view/Raring/view/JHBuild%**
 20Gnome/

>>> >
>>> >Interesting!  Looks quite useful.  Are you doing anything with
>>> >respect to the "jhbuild sysdeps --install" infrastructure or is
>>> >the system package set maintained manually?
>>>
>> Right now in our Juju charm it's a manual list:
>>
>>http://bazaar.launchpad.net/~**jibel/charms/quantal/jhbuild/**
>> trunk/view/head:/files/**jhbuild.config/gnome-core.**sysdeps
>>
>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
>> well enough in principle?
>>
>>  In Quantal, there was missing dependencies, so I went the straightest
> way and installed them directly. Now that I have a better understanding how
> jhbuild works that's something I want to reconsider for Raring and avoid
> maintaining them in 2 different places.
>
> --
> Jean-Baptiste
> IRC: jibel
>
> __**_
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/**mailman/listinfo/desktop-**devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Jean-Baptiste Lallement]

On 01/16/2013 07:39 AM, Martin Pitt wrote:

Hello Colin,


Hi Martin, Colin,


Colin Walters [2013-01-15 15:34 -0500]:

>On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
>

> >We have experimented with that a bit, by building
> >
> >   https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/

>
>Interesting!  Looks quite useful.  Are you doing anything with
>respect to the "jhbuild sysdeps --install" infrastructure or is
>the system package set maintained manually?

Right now in our Juju charm it's a manual list:

   
http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps

I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
well enough in principle?

In Quantal, there was missing dependencies, so I went the straightest 
way and installed them directly. Now that I have a better understanding 
how jhbuild works that's something I want to reconsider for Raring and 
avoid maintaining them in 2 different places.


--
Jean-Baptiste
IRC: jibel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Colin Walters]

On Wed, 2013-01-16 at 07:39 +0100, Martin Pitt wrote:

> Right now in our Juju charm it's a manual list:
> 
>   
> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
> 
> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
> well enough in principle?

I'd be the first to admit the jhbuild sysdeps stuff is still quite
hacky, but it's also a lot more sustainable and reproducible.

> Yeah, there are several modules which show a problem with the test
> environment; that, and e. g. g-settings-daemon is stumbling over
> "PYTHONPATH for python3"
> (https://bugzilla.gnome.org/show_bug.cgi?id=688353) etc.

Yeah, ugly =(  

> I fully agree; we need both unit and these system integration tests.
> I'd like to think that adding "make check" tests isn't conflicting to
> that; when writing tests with above in mind, you can usually set them
> up in a way that they can run both against the built source tree as
> well as the installed system; for example, when submitting the tests
> for gvfs I added both a "make check" as well as a "make installcheck"
> rule, and you can just run e. g.  tests/gvfs-test.py out of a pristine
> git checkout. In many cases that's usually a matter of not writing the
> tests with hardcoded paths against the source and then setting
> variables like $PATH, $GST_REGISTRY_1_0, etc. to the build tree when
> running the tests against the build tree.

Right, but this gets very ugly very fast...there are a lot of those
environment variables, they don't all have quite the same semantics,
etc.  jhbuild is pretty much the canonical reference set.

In this discussion let's use glib as our example, because:

1) glib is fundamentally necessary
2) It has a lot of tests
3) Where glib goes, so goes the rest of our ecosystem

> We also use those tests in our "autopkgtest" model where we install a
> proposed package update into a standard distro install and then run
> the package's tests against that system. Architecture wise this has
> the same requirements as for above "system-wide smoke tests".

Ah, so this is:
http://developer.ubuntu.com/packaging/html/auto-pkg-test.html

Pretty interesting.  But here's the thing - the glib example from that
page is pretty lame, because all of the "makecheck" tests that are
presently trapped inside the glib tree could do this much better, if we
liberated them to be installed tests.

What I hope is that for projects like glib, we simply change the vast
majority of tests that exist now to be installed.  What then replaces
the "make check" developer workflow is:

$ jhbuild make
$ (set -e; for x in ~/build/gnome/bin/tests/glib/*; do $x; done)

Or perhaps we could define a standard "run all the tests" binary name,
so that'd be:

$ jhbuild make
$ ~/build/gnome/bin/tests/glib/all-tests

Now what gets interesting about the installed model is that after
updating GLib, it's trivial to run the *pygobject* tests, without
arbitrarily rebuilding pygobject.  Particularly important if you care
about binary compatibility, as we do for glib, since you're testing new
GLib against old pygobject binaries:

$ jhbuild buildone glib
$ ~/build/gnome/bin/tests/pygobject/all-tests

If we'd had this infrastructure in place, Ryan would have immediately
seen gjs and pygobject's tests blow up after committing:
http://git.gnome.org/browse/glib/commit/?id=c2055f22f4399a23d1c02a94f8b029212e37e162

I was going to raise this proposal once I had the infrastructure in
place to implement it, which is hopefully by the end of this month, but
since you brought it up - let's figure out a plan.

There are some people just hacking up the Makefiles in OpenEmbedded:
http://patches.openembedded.org/patch/32063/
Clearly not long term sustainable.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Martin Pitt]

Hello Colin,

Colin Walters [2013-01-15 15:34 -0500]:
> On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
> 
> > We have experimented with that a bit, by building 
> > 
> >   https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
> 
> Interesting!  Looks quite useful.  Are you doing anything with
> respect to the "jhbuild sysdeps --install" infrastructure or is
> the system package set maintained manually?

Right now in our Juju charm it's a manual list:

  
http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps

I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
well enough in principle?

> The gnome-control-center failure appears to be something in the
> jenkins/jhbuild glue not understanding how to properly do git
> submodules.

Yeah, there are several modules which show a problem with the test
environment; that, and e. g. g-settings-daemon is stumbling over
"PYTHONPATH for python3"
(https://bugzilla.gnome.org/show_bug.cgi?id=688353) etc.

As I said, this needs some caretaking. Yesterday we got some fixes to
a couple of modules; we now have some time to devote to this.

> http://git.gnome.org/browse/gnome-ostree/tree/src/ostbuild/js/builtins/qa_smoketest.js
> 
> This should all be pretty fast - I want this test running within 5
> minutes after I push a commit to glib/gjs/whatever.  And 5 minutes is
> slow - with some optimizations, that could be 1 minute.
> 
> *After* that test has completed, we can do stuff like run selected tests
> from glib/pygobject/gjs etc.  In the installed test model, we can choose
> exactly which one of those tests to run.
> 
> I know this installed tests model is orthogonal (somewhat complementary,
> somewhat conflicting) to the work you've been doing for the current
> "distcheck" model of nondestructive per-user tests.  It's true that
> those types of tests can be very easy and fast for developers to run.  
> 
> But the qemu-based testing model is very powerful, and there's no excuse
> for not having a suite of qemu-based tests run automatically build
> server side.

I fully agree; we need both unit and these system integration tests.
I'd like to think that adding "make check" tests isn't conflicting to
that; when writing tests with above in mind, you can usually set them
up in a way that they can run both against the built source tree as
well as the installed system; for example, when submitting the tests
for gvfs I added both a "make check" as well as a "make installcheck"
rule, and you can just run e. g.  tests/gvfs-test.py out of a pristine
git checkout. In many cases that's usually a matter of not writing the
tests with hardcoded paths against the source and then setting
variables like $PATH, $GST_REGISTRY_1_0, etc. to the build tree when
running the tests against the build tree.

We also use those tests in our "autopkgtest" model where we install a
proposed package update into a standard distro install and then run
the package's tests against that system. Architecture wise this has
the same requirements as for above "system-wide smoke tests".

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Colin Walters]

On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:

> We have experimented with that a bit, by building 
> 
>   https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/

Interesting!  Looks quite useful.  Are you doing anything with
respect to the "jhbuild sysdeps --install" infrastructure or is
the system package set maintained manually?

> So we currently have 159 modules of which some 30 are
> unstable/failing. This is not totally hopeless, but it would be good
> to at least get the libraries working (glib, gvfs, etc.)

Yeah, up to gtk+ at least.  

The gnome-control-center failure appears to be something in the
jenkins/jhbuild glue not understanding how to properly do git
submodules.

> Your http://ostree.gnome.org builds indeed look very stable, mostly
> because they aren't runningi checks.

That's one factor.  It's also not building apps.  A further nontechnical
factor is that I watch the ostree.gnome.org builds like a mother with a
newborn baby...

>  Do you eventually plan on doing
> this, or is OSTree not the right place for this?

So...tests.  An interesting and complex topic.  I've had a document
started about this for a while:

https://docs.google.com/document/d/1DXgGEKTbC4ed1DFW3Mu-48TpHtq-xdfhDtwoUOWWcHg/edit

> Our goal is to provide CI with not only build tests, but also runtime
> tests, so that we can immediately see if e. g. a glib commit breaks
> something in settings-daemon or pygobject. Do you think it makes sense
> to do that in ostree.g.o, or should we have separate
> "functionality/reverse dependency test" builds for those?

Pretty soon, once I finish up some infrastructure, I'll have the key
"smoke test" - does the system boot in a standard qemu configuration,
with no core dumps or fatal service errors, successfully logging into
gdm?

See:
http://git.gnome.org/browse/gnome-ostree/tree/src/ostbuild/js/builtins/qa_smoketest.js

This should all be pretty fast - I want this test running within 5
minutes after I push a commit to glib/gjs/whatever.  And 5 minutes is
slow - with some optimizations, that could be 1 minute.

*After* that test has completed, we can do stuff like run selected tests
from glib/pygobject/gjs etc.  In the installed test model, we can choose
exactly which one of those tests to run.

I know this installed tests model is orthogonal (somewhat complementary,
somewhat conflicting) to the work you've been doing for the current
"distcheck" model of nondestructive per-user tests.  It's true that
those types of tests can be very easy and fast for developers to run.  

But the qemu-based testing model is very powerful, and there's no excuse
for not having a suite of qemu-based tests run automatically build
server side.



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Martin Pitt]

Hello Colin, all,

Colin Walters [2013-01-04 13:30 -0500]:
> On Sun, 2012-12-30 at 17:50 +0100, Andre Klapper wrote:
> > http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to be
> > offline, and the Debian one has not been updated since October.
> 
> There are a couple of things here - one thing I want to emphasize here
> (I mentioned this too in the Boston Summit), is that it's really, really
> important that we keep "jhbuild up to gtk+" working.

Totally agreed. E. g. a few days ago, gtk-doc stopped building (I
filed it as https://bugzilla.gnome.org/show_bug.cgi?id=691775), which
completely breaks pretty much everything else.

> It's therefore quite important that we have and maintain jhbuild-based
> autobuilders on at least the latest Ubuntu and
> Fedora/Debian/OpenSUSE/whatever.

We have experimented with that a bit, by building 

  https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/

This uses jhbuild to build individual modules on new commits, with
--check. This was mostly a first step to see where we stand, and we
wanted to discuss it on desktop-devel@ soon, how to integrate it with
other efforts like build.gnome.org and ostree, set up notifications,
etc. We got distracted by some other stuff in the meantime, though.

So we currently have 159 modules of which some 30 are
unstable/failing. This is not totally hopeless, but it would be good
to at least get the libraries working (glib, gvfs, etc.)

> But personally I don't run jhbuild past gtk+ much myself anymore because
> I use gnome-ostree for hacking on GNOME.

Your http://ostree.gnome.org builds indeed look very stable, mostly
because they aren't runningi checks. Do you eventually plan on doing
this, or is OSTree not the right place for this?

Our goal is to provide CI with not only build tests, but also runtime
tests, so that we can immediately see if e. g. a glib commit breaks
something in settings-daemon or pygobject. Do you think it makes sense
to do that in ostree.g.o, or should we have separate
"functionality/reverse dependency test" builds for those?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Travis Reitter]

On Fri, 2013-01-04 at 14:05 -0500, Colin Walters wrote:
> On Wed, 2013-01-02 at 11:23 -0800, Travis Reitter wrote:
> 
> > I think our best bet for a usable SDK would be something that sets up a
> > QEMU instance on top of OSTree
> 
> I have scripts for this
> ( 
> http://git.gnome.org/browse/gnome-ostree/tree/src/ostbuild/ostbuild-qemu-pull-deploy?id=d99b501bb0fbc5c866f7f7774b1c7710308ddbd1
>  )
> 
> but really the whole ostree/gnome-ostree stack here needs significant
> levels of work and polish.
> 
> > Being able to build against a single set of
> > pre-built binaries should dramatically lower the trouble of getting
> > started with development on Gnome.
> 
> The question here is build...what?  Applications?  Or contribute to the
> desktop itself?  These are quite independent things with potentially
> quite different tools to use.

Certainly, they're different use cases. I would think an SDK would be
primarily targeted to third-party application and library developers.
But I don't think it should be too much of a stretch to make it usable
for first-party application and library developers as well, since there
should be a fair amount of overlap there (and the dogfooding would help
quality a lot).

I think the main split is between the development above and lower-level
desktop development (daemons like D-Bus, libraries like glib and
pulseaudio, systems like systemd).

> > Every time I start a new jhbuild build tree, it's a very long and
> > painful process. And every full-tree update is a big risk.
> 
> Yeah, and there is still yet more we can do to jhbuild to make things
> better here; the two biggest things are:
> 
> 1) improving the sysdeps tooling see
> https://bugzilla.gnome.org/show_bug.cgi?id=691036 for an example case
> where it works on OpenSUSE/Fedora, but fails on Debian due to confusion
> over the package split
> 
> 2) Maintaining autobuilders; see my other mail

These would certainly help a lot. Jhbuild itself isn't usually the
source of the problems; but its design isn't resilient to module build
breaks (which are way too frequent) and excessive re-building of any
modules which aren't directly interesting to most developers. As a
library developer, I only really care about my library, its direct
dependencies (mostly that they don't break API) and my consumer
applications. Most of the time, I only want to work with a few modules,
so constant churn of a few hundred others is a distraction I'd like to
minimize. And application developers don't even have the "consumer
application" modules to care about.

Those two points above could go a long way to improving development
experience.


smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Colin Walters]

On Sun, 2012-12-30 at 19:43 +0100, Cosimo Cecchi wrote:
> Exactly, often a module was "red" because it needed a "git clean",

See https://bugzilla.gnome.org/show_bug.cgi?id=656081

I wrote that patch specifically for use in autobuilders.  A lot of the
reliability of the gnome-ostree build system versus jhbuild comes from
*always* starting from a git clean -dfx tree; by using the --distclean
option, jhbuild too can be a lot more reliable.  (At a cost of some
compilation speed, but if you're worried about that, first install
and configure ccache)

>  for a missing dependency, or because the moduleset wasn't updated to
> include a newer version of a dependency.

Both of these are blocked on a sustainable way for multiple people
to control the base set of packages installed on the build servers; see
my other mail.

> Finally, when a new module was added to the moduleset (usually a new
> dependency), the build.gnome.org master instance itself needed a
> manual restart to get the change propagated to the build slaves, and
> this required pinging people with a SSH access to the server to do it.

Honestly, the jhbuild-buildbot integration is well intentioned, but not
worth the pain.

It'd be *significantly* simpler and more reliable if a jhbuild-based
build bot was effectively:

while true; do sleep 1m; jhbuild build || post-irc-message; done

Basically all of the jhbuild-buildbot glue work is so that modules can
be in a build-or-not-building state *independently*, but that doesn't
make any sense because we want to act aggressively on any failures - we
don't want to let e.g. at-spi2-atk be in a failing state but still build
gtk+.



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Colin Walters]

On Wed, 2013-01-02 at 11:23 -0800, Travis Reitter wrote:

> I think our best bet for a usable SDK would be something that sets up a
> QEMU instance on top of OSTree

I have scripts for this
( 
http://git.gnome.org/browse/gnome-ostree/tree/src/ostbuild/ostbuild-qemu-pull-deploy?id=d99b501bb0fbc5c866f7f7774b1c7710308ddbd1
 )

but really the whole ostree/gnome-ostree stack here needs significant
levels of work and polish.

> Being able to build against a single set of
> pre-built binaries should dramatically lower the trouble of getting
> started with development on Gnome.

The question here is build...what?  Applications?  Or contribute to the
desktop itself?  These are quite independent things with potentially
quite different tools to use.

> Every time I start a new jhbuild build tree, it's a very long and
> painful process. And every full-tree update is a big risk.

Yeah, and there is still yet more we can do to jhbuild to make things
better here; the two biggest things are:

1) improving the sysdeps tooling see
https://bugzilla.gnome.org/show_bug.cgi?id=691036 for an example case
where it works on OpenSUSE/Fedora, but fails on Debian due to confusion
over the package split

2) Maintaining autobuilders; see my other mail



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Colin Walters]

On Sun, 2012-12-30 at 17:50 +0100, Andre Klapper wrote:
> http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to be
> offline, and the Debian one has not been updated since October.

There are a couple of things here - one thing I want to emphasize here
(I mentioned this too in the Boston Summit), is that it's really, really
important that we keep "jhbuild up to gtk+" working.

Allowing application developers to test their apps against newer
versions of the GTK+ stack is extremely important for getting feedback
before APIs are fully stabilized, etc., without forcing them to
overwrite their stable distribution entirely.  Also, jhbuild makes it
easier for application authors to *contribute patches*, something the
distribution package model makes way too hard.

It's therefore quite important that we have and maintain jhbuild-based
autobuilders on at least the latest Ubuntu and
Fedora/Debian/OpenSUSE/whatever.
However, a scalable way to maintain this requires a *group* of people
who are able to control the build servers without blocking on the
sysadmin team to (for example) install packages that are jhbuild
"sysdeps".

See
https://mail.gnome.org/archives/gnome-infrastructure/2012-November/msg00030.html
for how I think we can scale infrastructure better.

But personally I don't run jhbuild past gtk+ much myself anymore because
I use gnome-ostree for hacking on GNOME.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Travis Reitter]

On Sun, 2012-12-30 at 19:09 +0100, Giovanni Campagna wrote:
> 2012/12/30 Jasper St. Pierre :
> > Can we just redirect build.gnome.org to ostree.gnome.org ?
> >
> > Having it build apps or something like that on top of its root tree as a
> > separate build process would be nice.
> 
> FWIW, I'm currently testing building core apps with ostree, as well as
> fixing ostree enough to be dogfoodable for me. I'll report back when I
> have it finished, but so far it seems to work.
> However, there is still a value in keeping jhbuild running, as
> application development with jhbuild is a lot faster than
> ostree/ostbuild, in particular given the "setup costs" of building the
> entirety of gnomeos just to get running. This until we have an SDK and
> application story...

I think our best bet for a usable SDK would be something that sets up a
QEMU instance on top of OSTree with a click and updates with a single
click/command as well (which, as I understand it, is basically how the
Android and iOS SDKs work). Being able to build against a single set of
pre-built binaries should dramatically lower the trouble of getting
started with development on Gnome.

Every time I start a new jhbuild build tree, it's a very long and
painful process. And every full-tree update is a big risk.

-Travis


smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Piñeiro]

On 12/30/2012 06:15 PM, Jasper St. Pierre wrote:
> Can we just redirect build.gnome.org <http://build.gnome.org> to
> ostree.gnome.org <http://ostree.gnome.org> ?
>
> Having it build apps or something like that on top of its root tree as
> a separate build process would be nice.

Recently I talked about this with Emmanuele, when he detected an ATK
build failure thanks to #testable. In summary I think that we need to
debate what we should do with build.gnome.org and the build-brigade.
Emmanuele suggested that it would be a good idea to debate about that on
gnome-os-list, so I added that mail on my TODO list.

BR


-- 
Alejandro Piñeiro Iglesias

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Cosimo Cecchi]

Exactly, often a module was "red" because it needed a "git clean", for a
missing dependency, or because the moduleset wasn't updated to include a
newer version of a dependency.

It also used to happen (but it might be fixed now) that tarball updates
weren't handled properly by the bot, so you would need to update the
moduleset and restart it manually to pick up the newer tarball (which
generates a bit more trouble/false positives for dependencies sometimes).

Finally, when a new module was added to the moduleset (usually a new
dependency), the build.gnome.org master instance itself needed a manual
restart to get the change propagated to the build slaves, and this required
pinging people with a SSH access to the server to do it.

Cosimo

On Sun, Dec 30, 2012 at 7:08 PM, Philip Withnall wrote:

> On Sun, 2012-12-30 at 18:12 +0100, Cosimo Cecchi wrote:
> > Maintaining the Debian jhbuild server running was quite a bit of
> > manual work for no clear benefit, so I turned it off at some point
> > this fall.
>
> Out of interest, what kind of manual work did you have to do to keep the
> server running? Was it a result of bugs in projects’ build systems (e.g.
> missing dependencies, incomplete cleanups)?
>
> Philip
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Cosimo Cecchi]

Yeah; my goal for that buildbot was just to monitor and fix build failures,
and ostree is much better at that - for application development, jhbuild is
still the recommended option and is much easier to setup.


On Sun, Dec 30, 2012 at 7:09 PM, Giovanni Campagna <
scampa.giova...@gmail.com> wrote:

> 2012/12/30 Jasper St. Pierre :
> > Can we just redirect build.gnome.org to ostree.gnome.org ?
> >
> > Having it build apps or something like that on top of its root tree as a
> > separate build process would be nice.
>
> FWIW, I'm currently testing building core apps with ostree, as well as
> fixing ostree enough to be dogfoodable for me. I'll report back when I
> have it finished, but so far it seems to work.
> However, there is still a value in keeping jhbuild running, as
> application development with jhbuild is a lot faster than
> ostree/ostbuild, in particular given the "setup costs" of building the
> entirety of gnomeos just to get running. This until we have an SDK and
> application story...
>
> Giovanni
>
> >
> > On Sun, Dec 30, 2012 at 12:12 PM, Cosimo Cecchi 
> wrote:
> >>
> >> Maintaining the Debian jhbuild server running was quite a bit of manual
> >> work for no clear benefit, so I turned it off at some point this fall.
> >> If it's still useful for people, I can try to revive it but IMO Colin's
> >> build server in #testable is a much better solution (even if it's not
> based
> >> on jhbuild). Maybe we should try to have it also build another wider
> >> gnome-apps-like moduleset?
> >>
> >> Cosimo
> >>
> >>
> >> On Sun, Dec 30, 2012 at 5:50 PM, Andre Klapper  wrote:
> >>>
> >>> http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to
> be
> >>> offline, and the Debian one has not been updated since October.
> >>>
> >>> Does anybody feel responsible for this?
> >>>
> >>> andre
> >>> --
> >>> Andre Klapper  |  ak...@gmx.net
> >>> http://blogs.gnome.org/aklapper/
> >>>
> >>> ___
> >>> desktop-devel-list mailing list
> >>> desktop-devel-list@gnome.org
> >>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >>
> >>
> >>
> >> ___
> >> desktop-devel-list mailing list
> >> desktop-devel-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >
> >
> >
> >
> > --
> >   Jasper
> >
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Hashem Nasarat]

Is one (jhbuild vs ostree) preferable going forward when there is an SDK
and developer story?
On Dec 30, 2012 1:09 PM, "Giovanni Campagna" 
wrote:

> 2012/12/30 Jasper St. Pierre :
> > Can we just redirect build.gnome.org to ostree.gnome.org ?
> >
> > Having it build apps or something like that on top of its root tree as a
> > separate build process would be nice.
>
> FWIW, I'm currently testing building core apps with ostree, as well as
> fixing ostree enough to be dogfoodable for me. I'll report back when I
> have it finished, but so far it seems to work.
> However, there is still a value in keeping jhbuild running, as
> application development with jhbuild is a lot faster than
> ostree/ostbuild, in particular given the "setup costs" of building the
> entirety of gnomeos just to get running. This until we have an SDK and
> application story...
>
> Giovanni
>
> >
> > On Sun, Dec 30, 2012 at 12:12 PM, Cosimo Cecchi 
> wrote:
> >>
> >> Maintaining the Debian jhbuild server running was quite a bit of manual
> >> work for no clear benefit, so I turned it off at some point this fall.
> >> If it's still useful for people, I can try to revive it but IMO Colin's
> >> build server in #testable is a much better solution (even if it's not
> based
> >> on jhbuild). Maybe we should try to have it also build another wider
> >> gnome-apps-like moduleset?
> >>
> >> Cosimo
> >>
> >>
> >> On Sun, Dec 30, 2012 at 5:50 PM, Andre Klapper  wrote:
> >>>
> >>> http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to
> be
> >>> offline, and the Debian one has not been updated since October.
> >>>
> >>> Does anybody feel responsible for this?
> >>>
> >>> andre
> >>> --
> >>> Andre Klapper  |  ak...@gmx.net
> >>> http://blogs.gnome.org/aklapper/
> >>>
> >>> ___
> >>> desktop-devel-list mailing list
> >>> desktop-devel-list@gnome.org
> >>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >>
> >>
> >>
> >> ___
> >> desktop-devel-list mailing list
> >> desktop-devel-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >
> >
> >
> >
> > --
> >   Jasper
> >
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Giovanni Campagna]

2012/12/30 Jasper St. Pierre :
> Can we just redirect build.gnome.org to ostree.gnome.org ?
>
> Having it build apps or something like that on top of its root tree as a
> separate build process would be nice.

FWIW, I'm currently testing building core apps with ostree, as well as
fixing ostree enough to be dogfoodable for me. I'll report back when I
have it finished, but so far it seems to work.
However, there is still a value in keeping jhbuild running, as
application development with jhbuild is a lot faster than
ostree/ostbuild, in particular given the "setup costs" of building the
entirety of gnomeos just to get running. This until we have an SDK and
application story...

Giovanni

>
> On Sun, Dec 30, 2012 at 12:12 PM, Cosimo Cecchi  wrote:
>>
>> Maintaining the Debian jhbuild server running was quite a bit of manual
>> work for no clear benefit, so I turned it off at some point this fall.
>> If it's still useful for people, I can try to revive it but IMO Colin's
>> build server in #testable is a much better solution (even if it's not based
>> on jhbuild). Maybe we should try to have it also build another wider
>> gnome-apps-like moduleset?
>>
>> Cosimo
>>
>>
>> On Sun, Dec 30, 2012 at 5:50 PM, Andre Klapper  wrote:
>>>
>>> http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to be
>>> offline, and the Debian one has not been updated since October.
>>>
>>> Does anybody feel responsible for this?
>>>
>>> andre
>>> --
>>> Andre Klapper  |  ak...@gmx.net
>>> http://blogs.gnome.org/aklapper/
>>>
>>> ___
>>> desktop-devel-list mailing list
>>> desktop-devel-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>>
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
>
> --
>   Jasper
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Philip Withnall]

On Sun, 2012-12-30 at 18:12 +0100, Cosimo Cecchi wrote:
> Maintaining the Debian jhbuild server running was quite a bit of
> manual work for no clear benefit, so I turned it off at some point
> this fall.

Out of interest, what kind of manual work did you have to do to keep the
server running? Was it a result of bugs in projects’ build systems (e.g.
missing dependencies, incomplete cleanups)?

Philip


signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Jasper St. Pierre]

Can we just redirect build.gnome.org to ostree.gnome.org ?

Having it build apps or something like that on top of its root tree as a
separate build process would be nice.


On Sun, Dec 30, 2012 at 12:12 PM, Cosimo Cecchi  wrote:

> Maintaining the Debian jhbuild server running was quite a bit of manual
> work for no clear benefit, so I turned it off at some point this fall.
> If it's still useful for people, I can try to revive it but IMO Colin's
> build server in #testable is a much better solution (even if it's not based
> on jhbuild). Maybe we should try to have it also build another wider
> gnome-apps-like moduleset?
>
> Cosimo
>
>
> On Sun, Dec 30, 2012 at 5:50 PM, Andre Klapper  wrote:
>
>> http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to be
>> offline, and the Debian one has not been updated since October.
>>
>> Does anybody feel responsible for this?
>>
>> andre
>> --
>> Andre Klapper  |  ak...@gmx.net
>> http://blogs.gnome.org/aklapper/
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>



-- 
  Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Cosimo Cecchi]

Maintaining the Debian jhbuild server running was quite a bit of manual
work for no clear benefit, so I turned it off at some point this fall.
If it's still useful for people, I can try to revive it but IMO Colin's
build server in #testable is a much better solution (even if it's not based
on jhbuild). Maybe we should try to have it also build another wider
gnome-apps-like moduleset?

Cosimo


On Sun, Dec 30, 2012 at 5:50 PM, Andre Klapper  wrote:

> http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to be
> offline, and the Debian one has not been updated since October.
>
> Does anybody feel responsible for this?
>
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> http://blogs.gnome.org/aklapper/
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

build.gnome.org

[Andre Klapper]

http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to be
offline, and the Debian one has not been updated since October.

Does anybody feel responsible for this?

andre
-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list