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 <[email protected]>: > 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 <[email protected]> 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 <[email protected]>: >> > 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 <[email protected]> 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 <[email protected]>: >> >> > 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 <[email protected]> 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 <[email protected]>: >> >> >> > 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 >> >> >> > <[email protected]> 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 >> >> >> >> [email protected] >> >> >> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list >> >> >> > >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > desktop-devel-list mailing list >> >> >> > [email protected] >> >> >> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Cheers, >> >> >> Alberto Ruiz >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Cheers, >> >> Alberto Ruiz >> >> _______________________________________________ >> >> desktop-devel-list mailing list >> >> [email protected] >> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list >> > >> > >> >> >> >> -- >> Cheers, >> Alberto Ruiz > > -- Cheers, Alberto Ruiz _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
