Frederic Peters fpet...@gnome.org wrote:
...
I believe this is no longer a problem; when I tried to merge the
by-then new BuildGnome page into the manual, and converting it to
Mallard, the primary problem was of license incompatibility between
the contents from the wiki and the existing
,
it will have to live as a part of the official manual. I get the
impression that there has been resistance to this in the past, due to
the desire to keep Jhbuild as a somewhat generic tool. However, I
don't see how the two use cases (Jhbuild for new GNOME contributors,
and Jhbuild for everyone else
into jhbuild documentation.
What I'm suggesting, and what Fred and Carlos seem to have done, is
that BuildGnome gets merged into the official manual. This makes the
manual the canonical place for documentation, whether it is for new
GNOME contributors, or for more generic JHBuild usage.
IMHO
On 11/02/2015, Frederic Peters fpet...@gnome.org wrote:
Allan Day wrote:
It would be nice if somebody could contact the authors:
James Henstridge james at jamesh.id.au
C.J. Adams-Collier cjcollier at colliertech.org
Frederic Peters (ok, done)
David Turner (Cillian64, from GHOP,
On Tue, Feb 10, 2015, at 01:00 PM, Ekaterina Gerasimova wrote:
https://wiki.gnome.org/HowDoI/Jhbuild is the one that seems to be
preferred by most docs newcomers and team members so from my point of
view it would be good that the final result resembles it and works
just as well.
jhbuilding
On 11/02/15 12:28, Michael Hill wrote:
On Tue, Feb 10, 2015, at 01:00 PM, Ekaterina Gerasimova wrote:
https://wiki.gnome.org/HowDoI/Jhbuild is the one that seems to be
preferred by most docs newcomers and team members so from my point of
view it would be good that the final result resembles
Problem: we have many pages on jhbuild documentation
We want to eliminate all of this and have
https://wiki.gnome.org/GnomeLove/BuildGnome
There seems to be some objections to removing some of the more
in-depth jhbuild documentation. I think overall this is a little
confusing, they are also
important thing about the manual that lives in the jhbuild
git repository it that it can be translated (currently it's almost
fully available in Spanish, Portuguese (_BR), Greek and Japanese).
impression that there has been resistance to this in the past, due to
the desire to keep Jhbuild
Sriram Ramkrishna wrote:
Problem: we have many pages on jhbuild documentation
Let's list them:
1. https://wiki.gnome.org/Projects/Jhbuild
2. https://developer.gnome.org/jhbuild/unstable/
3. https://wiki.gnome.org/GnomeLove/BuildGnome
4. https://wiki.gnome.org/GnomeLove/JhbuildIntroduction
On 10/02/2015, Sriram Ramkrishna s...@ramkrishna.me wrote:
Problem: we have many pages on jhbuild documentation
We want to eliminate all of this and have
https://wiki.gnome.org/GnomeLove/BuildGnome
There seems to be some objections to removing some of the more
in-depth jhbuild
Hi,
On Tue, Feb 10, 2015 at 11:27:11AM -0800, Sriram Ramkrishna wrote:
Problem: we have many pages on jhbuild documentation
Let's list them:
1. https://wiki.gnome.org/Projects/Jhbuild
2. https://developer.gnome.org/jhbuild/unstable/
3. https://wiki.gnome.org/GnomeLove/BuildGnome
4. https
In particular, we should identify material from the HowDoI/Jhbuild page
(which conflicts with the guidance on the BuildGnome page) that we want
to keep, and merge it into the BuildGnome page. We should not have
competing pages with competing advice; it's way too confusing for
newcomers
Sébastien Wilmet wrote:
Hi,
On Tue, Feb 10, 2015 at 11:27:11AM -0800, Sriram Ramkrishna wrote:
Problem: we have many pages on jhbuild documentation
Let's list them:
1. https://wiki.gnome.org/Projects/Jhbuild
2. https://developer.gnome.org/jhbuild/unstable/
3. https://wiki.gnome.org
as a part of the official manual. I get the
The most important thing about the manual that lives in the jhbuild
git repository it that it can be translated (currently it's almost
fully available in Spanish, Portuguese (_BR), Greek and Japanese).
impression that there has been resistance
On Tue, Feb 10, 2015 at 1:06 PM, Allan Day allanp...@gmail.com wrote:
Sriram Ramkrishna wrote:
Problem: we have many pages on jhbuild documentation
Let's list them:
1. https://wiki.gnome.org/Projects/Jhbuild
2. https://developer.gnome.org/jhbuild/unstable/
3. https://wiki.gnome.org
the 'jhbuild
build adwaita-icon-theme' command for the very first time.
Magdalen
On Thu, Jan 8, 2015 at 7:10 AM, Daniel Kasak d.j.kasak...@gmail.com wrote:
Hi all. I'm trying to build Gtk3 and a few other things, with jhbuild, on
OSX. When I try to install something like adwaita-icon-theme
Hi all. I'm trying to build Gtk3 and a few other things, with jhbuild, on
OSX. When I try to install something like adwaita-icon-theme, this happens:
smart-ass:~ dankasak$ jhbuild build
adwaita-icon-theme
*** Checking out libcroco *** [1/5]
*** Skipping libcroco (package and dependencies
Hi everyone,
As many of you who use jhbuild regularly already know, system services
(NetworkManager, ModemManager, geoclue etc) do not actually work when
installed in custom prefixes as normal user. These services require to
be installed on system to work.
The result is that typically people
On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak)
zeesha...@gnome.org wrote:
Unless someone has plans on fixing this (somehow) soon, I would
suggest we either kick out all system services from jhbuild all
together or at least remove them from dependency list of other
modules.
+1 for me
Sriram Ramkrishna wrote:
On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak)
zeesha...@gnome.org wrote:
Unless someone has plans on fixing this (somehow) soon, I would
suggest we either kick out all system services from jhbuild all
together or at least remove them from dependency list
from jhbuild all
together or at least remove them from dependency list of other
modules.
+1 for me, It should try to use what is already on the system.
It does (basically it sets PKG_CONFIG_PATH to also look into the
system directories, so if you have networkmanager development files
.libs/mutter-enum-types.o
.libs/gtk-shell-protocol.o .libs/xdg-shell-protocol.o
-L/home/gnomedev/src/jhbuild/install/lib64 -lupower-glib -lgnome-desktop-3
-lstartup-notification-1 -lcanberra-gtk3 -lcanberra -lgtk-3
-lgirepository-1.0 -lXcursor -lclutter-1.0 -lcogl-path -latk-1.0
-lcogl-pango -lcogl
Hi,
is there a way in JHBuild to download or pull a resource archive, such as a
theme, and unpack it simply to the install prefix? From the documented module
types only the Autotools type seems to be a halfways close solution, but it
forces me to have a makefile, even if this does nothing
configure JHBuild or my modules to do this?
Thank you in advance,
Sven
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
I am trying to build GNOME 3.10 (the release) using jhbuild, on a Fedora 19
machine (which comes with GNOME 3.8)
I checkout out jhbuild, follow the steps and can build using this command
up to pango:
jhbuild -m
http://download.gnome.org/teams/releng/3.10.1/gnome-apps-3.10.1.modulesbuild
-afc
I am trying to build GNOME 3.10 (the release) using jhbuild, on a Fedora 19
machine (which comes with GNOME 3.8)
I checkout out jhbuild, follow the steps and can build using this command
up to pango:
jhbuild -m
http://download.gnome.org/teams/releng/3.10.1/gnome-apps-3.10.1.modulesbuild
-afc
*** Checking out iso-codes *** [20/28]
curl --continue-at - -L
http://pkg-isocodes.alioth.debian.org/downloads/iso-codes-3.33.tar.bz2
-o /home/lamefun/gnome/iso-codes-3.33.tar.bz2
*** Error during phase force_checkout of iso-codes: downloaded file size
is incorrect (expected 6349976, got 326) ***
Nikita Churaev [2013-11-20 20:20 +0400]:
*** Checking out iso-codes *** [20/28]
curl --continue-at - -L
http://pkg-isocodes.alioth.debian.org/downloads/iso-codes-3.33.tar.bz2
-o /home/lamefun/gnome/iso-codes-3.33.tar.bz2
alioth has been down for about two weeks due to some hardware
Getting started with jhbuild will be easier if we just have better
defaults. Specifically prefix = /opt/gnome is annoying. We have a few
bugs about the changing the defaults already [1][2][3],
recommendations for overriding the defaults for beginners [4],
complaints [5], and previous discussions
Thomas H.P. Andersen wrote:
Are there non-bikeshed reasons not to do this? Are there things that
will break so bad that the cost outweigh the benefit?
Patch welcome; but do mind this comment:
The only slightly tricky thing about this I see is detecting the
case where the user was actually
are
specifically asking to get the default setting. Is a program allowed
to change defaults? For a program like jhbuild I would be pragmatic
and say yes, but others may disagree. IMO it would be reasonable to
announce the change one month in advance and then just do it.
-- Colin Walters https
Hi,
I am a beginner with jhbuild. But, I personally like the idea proposed
by Thomas
H.P. Andersen, as it builds a more coherent structure for the files to
saved at.
I also believe that, a bug [1], that I have reported, will prove relevant
in this case. I will also be very grateful, if somebody
On Fri, Mar 8, 2013 at 12:48 AM, Martin Pitt martin.p...@ubuntu.com wrote:
Hello fellow GNOMErs,
after the first round of discussions a month ago[1] about the jhbuild
CI building/testing [2] I'd like to give some status update.
Along the same topic, I wanted to bring to light something
On Wed, Mar 13, 2013 at 6:54 AM, Tristan Van Berkom t...@gnome.org wrote:
Did I miss some important information (i.e. is this already done somewhere
at least partially and I'm not aware of it) ?
I'd really rather get off gtester - as you've noticed, it is somewhat
lacking, and the Makefile
On Tue, Mar 12, 2013 at 04:00:29PM -0400, Colin Walters wrote:
That said - I'm just going to add the authors of DEP8 to this discussion
in the hopes of making it look more like fully installed tests (my
proposal does kind of lack a name, and that's the best I can come up
with at the moment...)
...@gnome.org, desktop-devel-list
desktop-devel-list@gnome.org
Sent: Wednesday, March 13, 2013 12:07:27 PM
Subject: Re: jhbuild continuous integration testing: status and plans
On Wed, Mar 13, 2013 at 6:54 AM, Tristan Van Berkom t...@gnome.org wrote:
Did I miss some important information (i.e
that
call internal API), I'd say upwards of 80% of tests in GLib for example
are black box, and could just as easily be run installed.
If we can standardize conventions (--enable-installed-tests, install
to /usr/share/$pkgname/tests), then jhbuild could be updated to be aware
of them, and the new
On 08/03/13 18:44, Colin Walters wrote:
On Fri, 2013-03-08 at 18:02 +, Simon McVittie wrote:
On 08/03/13 14:45, Colin Walters wrote:
This gets back to something I want to figure out how to do, which is
standardize metadata for tests (e.g. this test requires a public
Internet connection,
).
The parallelization stuff sounds quite cool by the way! Do you have a
link to the source code for the Jenkins/jhbuild glue work?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
On 08/03/13 14:45, Colin Walters wrote:
This gets back to something I want to figure out how to do, which is
standardize metadata for tests (e.g. this test requires a public
Internet connection, this test requires a logged in desktop session,
this test requires root, etc.).
It might be worth
On Fri, 2013-03-08 at 18:02 +, Simon McVittie wrote:
On 08/03/13 14:45, Colin Walters wrote:
This gets back to something I want to figure out how to do, which is
standardize metadata for tests (e.g. this test requires a public
Internet connection, this test requires a logged in desktop
Hell yah! This is great! Thank you!
sri
On Thu, Mar 7, 2013 at 7:48 AM, Martin Pitt martin.p...@ubuntu.com wrote:
Hello fellow GNOMErs,
after the first round of discussions a month ago[1] about the jhbuild
CI building/testing [2] I'd like to give some status update.
Since then, Jean
Jasper St. Pierre [2013-02-12 14:12 -0500]:
The libXi patches are because Ubuntu ships a libXi package that's marked as
if it's a new version, but doesn't contain the new XI stuff for some reason:
On 18/02/13 22:34, Martin Pitt wrote:
Please note that there is no system D-BUS and no default session D-BUS
running. If you need those, then the tests should start dbus-launch or
use GTestDBus.
dbus-launch is not particularly suitable for regression tests: if you
use it, you have to kill the
On Tue, Feb 19, 2013 at 10:13 PM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On 18/02/13 22:34, Martin Pitt wrote:
Please note that there is no system D-BUS and no default session D-BUS
running. If you need those, then the tests should start dbus-launch or
use GTestDBus.
On 19/02/13 13:54, Tristan Van Berkom wrote:
On Tue, Feb 19, 2013 at 10:13 PM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
GTestDBus is IMO ideal for regression testing (or in-tree unit tests),
I made a short write-up on this not long ago in my blog[0].
GTestDBus combines
:
$ xvfb-run jhbuild run
/home/ubuntu/gnome/packages/libexec/evolution-source-registry
Migrating mail accounts from GConf...
Migrating addressbook sources from GConf...
Migrating calendar sources from GConf...
Migrating task list sources from GConf...
Migrating memo list sources from GConf...
Registering
On Fri, 2013-02-15 at 11:54 +0100, Martin Pitt wrote:
Martin Pitt [2013-02-12 7:43 +0100]:
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
Right now there are 151 successes (blue), 5 modules fail to build
(red), and 4 modules build but fail in make check (yellow). It's
from here:
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%
20Gnome/job/jhbuild-amd64-folks/lastSuccessfulBuild/testReport/junit/folks/test/make_check/
On the main page, click on folks, which leads you to
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64
for details
But I can't seem to find the corresponding log from here:
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%
20Gnome/job/jhbuild-amd64-folks/lastSuccessfulBuild/testReport/junit/folks/test/make_check/
On the main page, click on folks, which leads you to
https
Tristan Van Berkom [2013-02-14 17:55 +0900]:
That's a trickier thing. For most commits, one should actually be able
to build them independently, but sometimes those in between breaks
are inevitable. Say, you make an API change in a library and then
update your application to the new API,
Hello Bastien,
Bastien Nocera [2013-02-13 11:23 +0100]:
I think build issues should be filed as Bugzilla bugs. At most we maybe
want to set some keyword / status whiteboard. But I guess the summary
would be consistent and people will quickly learn of it.
They should be filed as Bugzilla
Martin Pitt [2013-02-14 7:36 +0100]:
So yesterday evening we were down to 5 failures, but over night we got
a swath of new test failures.
Yesterday I did a git pull in jhbuild itself, which changed a few
components such as pulling in a new ibus version. We'll do this daily
from now
On Thu, Feb 14, 2013 at 3:12 PM, Martin Pitt martin.p...@ubuntu.com wrote:
Hello Tristan,
Tristan Van Berkom [2013-02-14 6:42 +0900]:
Upon reading this particular part (and I noticed before you are
using mostly jhbuild mechanics), it leads me to wonder, how
granular exactly
On Thu, 2013-02-14 at 07:36 +0100, Martin Pitt wrote:
Hi,
- gst-plugins-bad: unknown type GStaticRecMutex; this might be due to
recent changes in streamer? That smells like a case of broken by
change in dependency, needs updating to new API
Still outstanding.
That issue was
On Wed, 2013-02-13 at 23:08 +, Emmanuele Bassi wrote:
hi;
On 13 February 2013 22:11, Colin Walters walt...@verbum.org wrote:
On Thu, 2013-02-14 at 06:42 +0900, Tristan Van Berkom wrote:
I know, it sounds like some CPU will be melting quickly
at the rate gnome-wide commits are
problems right now are that the jhbuild update
stage takes some 5 minutes to update all the ~ 160 git trees, and
that jhbuild build doesn't parallelize at all, i. e. build modules
which don't depend on each other could build in parallel.
Could you perhaps do a test that does 10 git checkouts at once
of RAM, that really isn't a bottleneck right
now. The main two problems right now are that the jhbuild update
stage takes some 5 minutes to update all the ~ 160 git trees, and
that jhbuild build doesn't parallelize at all, i. e. build modules
which don't depend on each other could build
I do in ftpadmin (see sysadmin-bin) is:
- Check if there is a bug-database with 'bugzilla.gnome.org'
For those URL(s): Check if the URL containers product=$SOMETHING
- If there is a good product: use that
- else: assume tarball = bugzilla product (will fail for jhbuild, often
modules
On Wed, Feb 13, 2013 at 11:23:52AM +0100, Bastien Nocera wrote:
On Wed, 2013-02-13 at 10:59 +0100, Olav Vitters wrote:
On Wed, Feb 13, 2013 at 06:53:17AM +0100, Martin Pitt wrote:
The main issue that I see with this is that it's much harder to filter
away/opt out, so it requires some
On Wed, 2013-02-13 at 10:59 +0100, Olav Vitters wrote:
I think build issues should be filed as Bugzilla bugs. At most we maybe
want to set some keyword / status whiteboard. But I guess the summary
would be consistent and people will quickly learn of it.
Don't see a need for keywords here:
On Wed, 2013-02-13 at 10:59 +0100, Olav Vitters wrote:
On Wed, Feb 13, 2013 at 06:53:17AM +0100, Martin Pitt wrote:
Travis Reitter [2013-02-12 13:21 -0800]:
On Tue, 2013-02-12 at 07:43 +0100, Martin Pitt wrote:
To make this really useful, we can't rely on developers checking this
On Wed, Feb 13, 2013 at 5:23 AM, Bastien Nocera had...@hadess.net wrote:
If you file the bugs as soon as they're visible, you'll end up filing
outdated bugs, and severely reducing the good will of the people fixing
those bugs.
I don't think it would personally take me very long to yell I
On 2013-02-13 11:58, Andre Klapper ak...@gmx.net wrote:
When I checked three months ago, 79 of 654 non-archived Git modules had
no DOAP file at all. 287 out of 575 modules with a DOAP file had an
entry for bug-database. GNOME does not even list bug-database in
On Wed, 2013-02-13 at 18:44 +, David King wrote:
On 2013-02-13 11:58, Andre Klapper ak...@gmx.net wrote:
When I checked three months ago, 79 of 654 non-archived Git modules had
no DOAP file at all. 287 out of 575 modules with a DOAP file had an
entry for bug-database. GNOME does not even
jhbuild continuous
builds/integration test server to become actually useful:
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
This is building gnome-suites-core-3.8.modules, which currently
consists of 160 modules. Builds are updated every 15 minutes, and
triggered whenever
On Thu, 2013-02-14 at 06:42 +0900, Tristan Van Berkom wrote:
I know, it sounds like some CPU will be melting quickly
at the rate gnome-wide commits are made... but it would be
simply awesome, if we could automatically pull out the exact
commit which introduced exactly which failed build
hi;
On 13 February 2013 22:11, Colin Walters walt...@verbum.org wrote:
On Thu, 2013-02-14 at 06:42 +0900, Tristan Van Berkom wrote:
I know, it sounds like some CPU will be melting quickly
at the rate gnome-wide commits are made... but it would be
simply awesome, if we could automatically
Hello Tristan,
Tristan Van Berkom [2013-02-14 6:42 +0900]:
Upon reading this particular part (and I noticed before you are
using mostly jhbuild mechanics), it leads me to wonder, how
granular exactly are these rebuilds ?
Right now, every 15 minutes. Sometimes longer, when the previous run
Hello again,
first, thanks for everyone who jumped in and helped to fix failures! I
wanted to send a quick update.
Martin Pitt [2013-02-12 7:43 +0100]:
- colord: recently started depending on libsystemd-login, which we
don't have yet; that's a fault on the Ubuntu side
I installed the
On Tue, Feb 12, 2013 at 1:43 AM, Martin Pitt martin.p...@ubuntu.com wrote:
Hello fellow GNOME developers,
this already came up as a side issue recently[1], but now we are at a
point where have reasonably stabilized our GNOME jhbuild continuous
builds/integration test server to become actually
developers,
this already came up as a side issue recently[1], but now we are at a
point where have reasonably stabilized our GNOME jhbuild continuous
builds/integration test server to become actually useful:
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
This is building gnome
are at a
point where have reasonably stabilized our GNOME jhbuild continuous
builds/integration test server to become actually useful:
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
This is building gnome-suites-core-3.8.modules, which currently
consists of 160 modules. Builds
On Tue, 2013-02-12 at 07:43 +0100, Martin Pitt wrote:
Hello fellow GNOME developers,
this already came up as a side issue recently[1], but now we are at a
point where have reasonably stabilized our GNOME jhbuild continuous
builds/integration test server to become actually useful:
https
This is really awesome stuff!
On Tue, 2013-02-12 at 07:43 +0100, Martin Pitt wrote:
To make this really useful, we can't rely on developers checking this
every hour or every day, of course; instead we need push notifications
as soon as a module starts failing. That's the bit which needs
Hello all,
Travis Reitter [2013-02-12 13:21 -0800]:
On Tue, 2013-02-12 at 07:43 +0100, Martin Pitt wrote:
To make this really useful, we can't rely on developers checking this
every hour or every day, of course; instead we need push notifications
as soon as a module starts failing. That's
Hello Sriram,
Sriram Ramkrishna [2013-02-12 11:06 -0800]:
Christmas has come early this year! This is fantastic news. Perhaps I can
try to get some volunteers to help file bugs on the build?
I filed one on e-d-s yesterday, which already got fixed. I also
discussed colord with Richard and the
Hello fellow GNOME developers,
this already came up as a side issue recently[1], but now we are at a
point where have reasonably stabilized our GNOME jhbuild continuous
builds/integration test server to become actually useful:
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome
Hi,
On Mon, Dec 24, 2012 at 5:53 AM, Lanoxx lan...@gmx.net wrote:
Hi,
I am using jhbuild and trying to compile anjuta (with anjuta-extras) to test
a patch that was applied recently on anjuta-extras.
When I run jhbuild build, then I get a huge list of missing system
dependencies:
(snip
@Lanoxx You did not mention you tried 'jhbuild sysdeps --install'. Run
that too. It might save you some time finding all the devel packages
in Synaptic.
Am 24.12.2012 um 02:37 schrieb Emily Gonyer emilyyr...@gmail.com:
IME that means you need to go through and find all of those packages -
my
Hello,
On Sun, Dec 23, 2012 at 09:53:36PM +0100, Lanoxx wrote:
I am using jhbuild and trying to compile anjuta (with anjuta-extras)
to test a patch that was applied recently on anjuta-extras.
jhbuild build
The gnome-love list would have been a better place, but anyway, you must
mention
try sudo apt-get install wireless-tools libicu-dev - they are in
ubuntu's repos and should be a new enough version.
On Mon, Dec 24, 2012 at 8:29 AM, Lanoxx lan...@gmx.net wrote:
Hi,
I have already run jhbuild sysdeps --install, and also ran jhbuild build
anjuta, with the first one I get
in their packges?
Regards
Lanoxx
On 24/12/12 15:00, Emily Gonyer wrote:
try sudo apt-get install wireless-tools libicu-dev - they are in
ubuntu's repos and should be a new enough version.
On Mon, Dec 24, 2012 at 8:29 AM, Lanoxx lan...@gmx.net wrote:
Hi,
I have already run jhbuild sysdeps
.
On Mon, Dec 24, 2012 at 8:29 AM, Lanoxx lan...@gmx.net wrote:
Hi,
I have already run jhbuild sysdeps --install, and also ran jhbuild
build
anjuta, with the first one I get this output:
I: Using apt-file to search for providers; this may be slow. Please
wait.
I: No native package found
install wireless-tools libicu-dev - they are in
ubuntu's repos and should be a new enough version.
On Mon, Dec 24, 2012 at 8:29 AM, Lanoxx lan...@gmx.net wrote:
Hi,
I have already run jhbuild sysdeps --install, and also ran jhbuild build
anjuta, with the first one I get this output:
I
Hi,
I am using jhbuild and trying to compile anjuta (with anjuta-extras) to
test a patch that was applied recently on anjuta-extras.
When I run jhbuild build, then I get a huge list of missing system
dependencies:
jhbuild build
W: network-manager-applet has a dependency on unknown
mobile
...@gmx.net wrote:
Hi,
I am using jhbuild and trying to compile anjuta (with anjuta-extras) to test
a patch that was applied recently on anjuta-extras.
When I run jhbuild build, then I get a huge list of missing system
dependencies:
jhbuild build
W: network-manager-applet has a dependency
a --with-python option:
http://git.gnome.org/browse/pygobject/commit/?id=6d8b29ba
* JHBuild now defaults to building pygobject for Python 3, but
introduces a pygobject-python2 project for the transition phase
which provides pygobject built for Python 2:
http://git.gnome.org/browse
gypsy is breaking the build of GNOME due to unconditional use of
-Werror. As far as I can tell there's no simple way to disable the
-Werror behavior of this configure line in gypsy:
http://cgit.freedesktop.org/gypsy/tree/configure.ac#n61
Attached is a patch which removes the unconditional
When I run jhbuild build, it prints the following output and quits:
Required packages:
System installed packages which are too old:
(none)
No matching system package installed:
python-devel (python.pc, required=2.5)
jhbuild build: Required system dependencies not installed. Install
On Thu, Sep 6, 2012 at 5:23 AM, Jeremy Bicha jbi...@ubuntu.com wrote:
On 5 September 2012 15:13, Jasper St. Pierre jstpie...@mecheye.net wrote:
jhbuild is not meant to be packaged. I'd highly suggest you stop
packaging jhbuild.
Yes, you're not the only one to say that. But, I thought a big
Hi,
TL;DR: Run git pull -r make install in your jhbuild checkouts.
The latest systemmodules work has landed in jhbuild; in the default
configuration where modulesets are fetched via HTTP, the new ones will
fail to parse with the old code.
The upside though is that jhbuild sysdeps --install now
On 5 September 2012 14:56, Colin Walters walt...@verbum.org wrote:
Hi,
TL;DR: Run git pull -r make install in your jhbuild checkouts.
The latest systemmodules work has landed in jhbuild; in the default
configuration where modulesets are fetched via HTTP, the new ones will
fail to parse
On Wed, Sep 5, 2012 at 3:10 PM, Jeremy Bicha jbi...@ubuntu.com wrote:
On 5 September 2012 14:56, Colin Walters walt...@verbum.org wrote:
Hi,
TL;DR: Run git pull -r make install in your jhbuild checkouts.
The latest systemmodules work has landed in jhbuild; in the default
configuration
On Wed, 2012-09-05 at 15:13 -0400, Jasper St. Pierre wrote:
On Wed, Sep 5, 2012 at 3:10 PM, Jeremy Bicha jbi...@ubuntu.com wrote:
On 5 September 2012 14:56, Colin Walters walt...@verbum.org wrote:
Hi,
TL;DR: Run git pull -r make install in your jhbuild checkouts.
The latest
On Wed, 2012-09-05 at 14:56 -0400, Colin Walters wrote:
The upside though is that jhbuild sysdeps --install now does a LOT
more.
For future jhbuild updates we'll try to either add a moduleset version
field that makes this error more obvious, or even better - teach jhbuild
how to auto
Colin Walters wrote:
On Wed, 2012-09-05 at 15:13 -0400, Jasper St. Pierre wrote:
On Wed, Sep 5, 2012 at 3:10 PM, Jeremy Bicha jbi...@ubuntu.com wrote:
Could we get a new jhbuild release then? Some distributions (Debian,
Ubuntu, openSUSE) have jhbuild packaged in their repositories
On 5 September 2012 15:13, Jasper St. Pierre jstpie...@mecheye.net wrote:
jhbuild is not meant to be packaged. I'd highly suggest you stop
packaging jhbuild.
Yes, you're not the only one to say that. But, I thought a big part of
what jhbuild offers is that it makes it relatively easy to try out
I used to know that you set up jhbuild by:
1. Installing it / creating the config file
2. jhbuild bootstrap
3. jhbuild build [whatever]
If jhbuild used good default values then we could even get started
without creating a config file.
See bug #655714 for changing the default of prefix
So today I thought I would give jhbuild another try, so I can build gtk+
3.5. My question is, after I cloned jhbuild, should I run autogen.sh
with the --prefix=/usr option or is that not neccessary?
Is there a rule of thumb when this option is necessary?
Regards
Lanoxx
101 - 200 of 421 matches
Mail list logo
