On Fri, Aug 17, 2012 at 4:24 AM, Lanoxx lan...@gmx.net wrote:
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?
You want to build jhbuild
On 17 August 2012 17:24, Lanoxx lan...@gmx.net wrote:
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?
No, install as a normal user. Do not use
So if I just wand to build gtk+ 3.5.x with its dependencies. What
moduleset name would I use in my config file?
On 17/08/12 11:26, Javier Jardón wrote:
On 17 August 2012 17:24, Lanoxx lan...@gmx.net wrote:
So today I thought I would give jhbuild another try, so I can build gtk+
3.5. My
On Fri, 2012-08-17 at 14:40 +0200, Lanoxx wrote:
So if I just wand to build gtk+ 3.5.x with its dependencies. What
moduleset name would I use in my config file?
https://live.gnome.org/ThreePointFive states that the current unstable
series is 3.5.x which will become the 3.6.x stable series.
If
that I can also run
'jhbuild build gtk+' which seems to be a better alternative than to
build the whole core module set.
andre
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
://git.gnome.org/browse/jhbuild/commit/?id=85acd03623e965f6abdc05be32170dd74d1ef0f1
--
Javier Jardón Cabezas
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
hi Javier;
On 27 June 2012 23:03, Javier Jardón jjar...@gnome.org wrote:
we dropped pygtk at the beggining of the year ;) See [1]
[1]
http://git.gnome.org/browse/jhbuild/commit/?id=85acd03623e965f6abdc05be32170dd74d1ef0f1
good to see that; I thought we still had pygtk because the various
Hey Martin.
On 06/25/2012 01:54 AM, Martin Pitt wrote:
Hello Joanmarie,
Joanmarie Diggs [2012-06-22 12:30 -0400]:
This change, unfortunately, makes jhbuild unhappy when building Orca
(and later Accerciser) in an environment which lacks Python 3 versions
of the build dependencies. I
Joanmarie Diggs [2012-06-25 5:46 -0400]:
So unless I'm missing something (which could easily be the case), I
think we either need a jhbuild which has additional smarts to handle
this situation
You can set it for pygobject only, by doing this instead:
module_extra_env['pygobject
jhbuild unhappy when building Orca
(and later Accerciser) in an environment which lacks Python 3 versions
of the build dependencies. I was hoping it would be relatively
straightforward to adjust jhbuild to handle this new situation. But the
solution didn't jump out at me, so I asked in #release
review).
This change, unfortunately, makes jhbuild unhappy when building Orca
(and later Accerciser) in an environment which lacks Python 3 versions
of the build dependencies. I was hoping it would be relatively
straightforward to adjust jhbuild to handle this new situation. But the
solution
On Mon, Jun 25, 2012 at 8:50 AM, Joanmarie Diggs jdi...@igalia.com wrote:
So are you saying I need to revert back to Python 2?
I'm just stating my opinion here for now.
I think this is a decision the release team has to make.
Here is some input for the discussion:
On 06/25/2012 08:50 AM, Joanmarie Diggs wrote:
On 06/25/2012 08:48 AM, Matthias Clasen wrote:
[...]
So, after giving this a weekend, I don't think we can do a python 2-3
transition for 3.6 without some advance planning.
And having both python2 and python3 dependencies in the core GNOME
hi Joanie;
On 25 June 2012 14:38, Joanmarie Diggs jdi...@igalia.com wrote:
4. I will propose a GNOME Goal for 3.8 regarding everyone migrating to
Python 3.
this means dropping the current pygtk bindings from the moduleset,
given that porting to Python 3 was dropped due to resources. not
On Mon, Jun 25, 2012 at 9:42 AM, Emmanuele Bassi eba...@gmail.com wrote:
hi Joanie;
On 25 June 2012 14:38, Joanmarie Diggs jdi...@igalia.com wrote:
4. I will propose a GNOME Goal for 3.8 regarding everyone migrating to
Python 3.
this means dropping the current pygtk bindings from the
Hello Joanmarie,
Joanmarie Diggs [2012-06-22 12:30 -0400]:
This change, unfortunately, makes jhbuild unhappy when building Orca
(and later Accerciser) in an environment which lacks Python 3 versions
of the build dependencies. I was hoping it would be relatively
straightforward to adjust
On Mon, Jun 25, 2012 at 1:54 AM, Martin Pitt martin.p...@ubuntu.com wrote:
Hello Joanmarie,
Joanmarie Diggs [2012-06-22 12:30 -0400]:
This change, unfortunately, makes jhbuild unhappy when building Orca
(and later Accerciser) in an environment which lacks Python 3 versions
of the build
Team felt that this was worth doing for all its modules. As a result,
pyatspi2 is now Python 3 compatible and Accerciser's migration is
underway (just waiting for the code review).
This change, unfortunately, makes jhbuild unhappy when building Orca
(and later Accerciser) in an environment which lacks
On Fri, 2011-07-29 at 15:12 -0400, Owen Taylor wrote:
Thank you for your feedback on JHBuild. I want JHBuild to just work. I
want it to be easy to create a GNOME sandbox.
* I think we need to work on our setup process; if you get jhbuild
installed, typing jhbuild produces:
jhbuild
for everybody, and basically
impossible for the novice.
I'm really happy to see JHBuild getting some attention. These seem
like noble aims indeed. :)
* I'm a bit skeptical of the existence of meta-gnome-core-shell,
which, as I understand it, is supposed to contain the set of things
that need to be built
On 29 July 2011 05:53, John Stowers john.stowers.li...@gmail.com wrote:
This doesn't currently work on non-packagekit system, such as Ubuntu. I
created
You can use PackageKit on Ubuntu, it works fine. It's just not
installed by default, which is unfortunate.
Richard.
On 07/28/2011 11:49 PM, Colin Walters wrote:
In the latest jhbuild, when the partial_build key is set (the
default) we explicitly look at what's installed on the system, and if
they're new enough, omit them from the build list (unless you have
built them before).
You can better understand
On Fri, Jul 29, 2011 at 01:00:46PM +0200, Stef Walter wrote:
I can't help but wonder if this is going to cause common problems where
a system package links against an old version of glib, which will then
conflict with the glib inside of the jhbuild. I've run into this several
times when using
On 07/29/2011 01:45 PM, Olav Vitters wrote:
On Fri, Jul 29, 2011 at 01:00:46PM +0200, Stef Walter wrote:
I can't help but wonder if this is going to cause common problems where
a system package links against an old version of glib, which will then
conflict with the glib inside of the jhbuild
On Fri, Jul 29, 2011 at 12:53 AM, John Stowers
john.stowers.li...@gmail.com wrote:
In the latest jhbuild, when the partial_build key is set (the
default) we explicitly look at what's installed on the system, and if
they're new enough, omit them from the build list (unless you have
built them
On Fri, Jul 29, 2011 at 11:25 AM, Colin Walters walt...@verbum.org wrote:
The partial_build code works on any system that simply has pkg-config;
you're just responsible for finding and installing
packages/SDKs/whatever.
I misunderstood John's statement, there was indeed a bug that made us
shoot for:
jhbuild build X
jhbuild run X
working?
* I think we need to work on our setup process; if you get jhbuild
installed, typing jhbuild produces:
jhbuild: could not load config file, /home/otaylor/.jhbuildrc is
missing
With no help about how to create it. You have figure
Here are notes from trying a pretty much from-scratch build of
meta-gnome-core-shell. (I made an effort to remove as many
development packages as possible from my system before doing
this.)
Apparently I accidentally hit send in evolution. So, in particular ignore the
part at the end where it
Hi GNOME developers,
So for a long time, jhbuild has always looked in your system for
pkg-config dependencies. However, if the moduleset said to build
something, we'd still build it.
Concretely for example, if the moduleset said to build dbus, we'd
build it, even if your system had a new enough
In the latest jhbuild, when the partial_build key is set (the
default) we explicitly look at what's installed on the system, and if
they're new enough, omit them from the build list (unless you have
built them before).
This doesn't currently work on non-packagekit system, such as Ubuntu. I
Hi,
So the DBus port of GConf landed recently and there haven't been any
totally serious problems reported so far... would anyone object if I
changed jhbuild to use --disable-orbit in the GNOME 3.2 suites?
If that works out well I may well decide to change the default so you
have to --enable
On Wed, Jul 20, 2011 at 2:14 PM, Ross Burton r...@burtonini.com wrote:
Hi,
So the DBus port of GConf landed recently and there haven't been any
totally serious problems reported so far... would anyone object if I
changed jhbuild to use --disable-orbit in the GNOME 3.2 suites?
The general
On 20/07/2011 19:14, Ross Burton wrote:
Hi,
So the DBus port of GConf landed recently and there haven't been any
totally serious problems reported so far... would anyone object if I
changed jhbuild to use --disable-orbit in the GNOME 3.2 suites?
If that works out well I may well decide
object if I
changed jhbuild to use --disable-orbit in the GNOME 3.2 suites?
The general principle I see here is that we want partial builds to
work on at least the most recently released versions of widely-used[1]
distros. So check whether they work in this configuration? In this
case
On Wed, Jul 20, 2011 at 3:28 PM, Ross Burton r...@burtonini.com wrote:
Actually we've had reported breakage from jhbuild's gconf-over-orbit trying
to use Ubuntu Oneiric's gconf-over-dbus, so I suspect we're going to get some
problems either way.
Not sure what the best solution here is to
On Wednesday, 20 July 2011 at 20:29, Matthias Clasen wrote:
Obviously, the best solution is to complete
http://live.gnome.org/GnomeGoals/GSettingsMigration ...
And obviously I should have won the EuroMillions lottery last weekend... ;)
Ross
___
Hi,
Some developers might have noticed that I've been making some changes
in jhbuild this cycle. Why? So I spend less time staring at other
people's build pastebins. At a very high level, my main goals are:
* Improve the ability to do partial builds
* Try very hard to avoid unobvious build
Hello,
I am beginning a build for gnome 3.0 on LFS 6.8 using jhbuild.
I am updating modules using:
http://ftp.gnome.org/pub/GNOME/teams/releng/3.0.0/gnome-suites-core-3.0.0.modules
http://ftp.gnome.org/pub/GNOME/teams/releng/3.0.0/gnome-suites-core-deps-3.0.0.modules
Relevant line from
Le samedi 07 mai 2011 à 23:46 -0400, Jasper St. Pierre a écrit :
But this approach only goes so far: there's eventually going to be a
point where you'll need a newer polkit or networkmanager version, and
whoops, those need to run those as root.
That said, I think jhbuild is a convenient way
On Sat, 2011-05-07 at 18:53 -0700, bsquared wrote:
Tshepang Lekhonkhobe wrote:
I would use that package manager of yours to remove jhbuild from the
system (uninstall_package jhbuild), and the re-run the confmakeinstall
commands. This is just a guess, and me hopes someone who understands
Jasper St. Pierre wrote:
You already did. jhbuild will install in whatever you specified as prefix.
[1]
The jhbuild instructions are for people who already have a proper gnome2
install and want to try out gnome3 easily safely: run a shell script,
jhbuild build, jhbuild run gnome-shell
jhbuild is a convenient way of building and
installing GNOME and its deps to /usr. PolicyKit, NetworkManager and
friends can probably work if you install them as root. That can be
tricky, but that's LFS after all... ;-)
So to me your only problem (for now) is that --sysconfdir doesn't seem
to be taken
Tshepang Lekhonkhobe wrote:
I would use /opt as jhbuild prefix and see how things churn out. Also,
the only first-class jhbuild target is GNOME 3, meaning that Xorg
support might be broken even, so you might have to follow BLFS Xorg
instructions for it. But try the jhbuild way first, and report
On Sun, 2011-05-08 at 10:38 -0700, bsquared wrote:
Tshepang Lekhonkhobe wrote:
I would use /opt as jhbuild prefix and see how things churn out. Also,
the only first-class jhbuild target is GNOME 3, meaning that Xorg
support might be broken even, so you might have to follow BLFS Xorg
Tshepang Lekhonkhobe wrote:
Me too, but why not make an exception with jhbuild software. You already
made an exception by breaking the guidelines of your package management
system: according to it, each package must have its own package user,
but with jhbuild, stuff built all have jhbuild
On Fri, 2011-05-06 at 16:02 -0700, bsquared wrote:
I have installed jhbuild in a basic LFS environment using standard build
tools: configure --prefix=/usr ; make make install. files[1] are
installed to /usr. But modulsets dir remained with source, so I copied
to user dir /usr/src/jhbuild
Tshepang Lekhonkhobe wrote:
On Fri, 2011-05-06 at 16:02 -0700, bsquared wrote:
I have installed jhbuild in a basic LFS environment using standard build
tools: configure --prefix=/usr ; make make install. files[1] are
installed to /usr. But modulsets dir remained with source, so I copied
On Sat, 2011-05-07 at 10:05 -0700, bsquared wrote:
Tshepang Lekhonkhobe wrote:
On Fri, 2011-05-06 at 16:02 -0700, bsquared wrote:
I have installed jhbuild in a basic LFS environment using standard build
tools: configure --prefix=/usr ; make make install. files[1] are
installed to /usr
Tshepang Lekhonkhobe wrote:
Interesting approach there.
Does that make sense? Is it possible?
Have you tried using './configure --prefix=/usr --sysconfdir=/etc' for
jhbuild?
That was a good suggestion. I should have though of that myself, but no
go. After './comfigure ; make make
jhbuild is not a general purpose build system for building gnome. It's
designed to sandbox a gnome setup and keep anything from interacting with
it... like a chroot, but more usable.
The prefix variable defines where things like bin, lib and etc go.
Because of the sandbox aspect, setting your
Jasper St. Pierre wrote:
jhbuild is not a general purpose build system for building gnome. It's
designed to sandbox a gnome setup and keep anything from interacting with
it... like a chroot, but more usable.
The prefix variable defines where things like bin, lib and etc go.
Because
On Sat, 2011-05-07 at 14:23 -0700, bsquared wrote:
Tshepang Lekhonkhobe wrote:
Interesting approach there.
Does that make sense? Is it possible?
Have you tried using './configure --prefix=/usr --sysconfdir=/etc' for
jhbuild?
That was a good suggestion. I should have though
Tshepang Lekhonkhobe wrote:
I would use that package manager of yours to remove jhbuild from the
system (uninstall_package jhbuild), and the re-run the confmakeinstall
commands. This is just a guess, and me hopes someone who understands
this technology (can one specify sysconfdir to /etc
Jasper St. Pierre wrote:
jhbuild is not a general purpose build system for building gnome. It's
designed to sandbox a gnome setup and keep anything from interacting with
it... like a chroot, but more usable.
The prefix variable defines where things like bin, lib and etc go.
Because
You already did. jhbuild will install in whatever you specified as prefix.
The jhbuild instructions are for people who already have a proper gnome2
install and want to try out gnome3 easily safely: run a shell script,
jhbuild build, jhbuild run gnome-shell --replace. There's no chance
I have installed jhbuild in a basic LFS environment using standard build
tools: configure --prefix=/usr ; make make install. files[1] are
installed to /usr. But modulsets dir remained with source, so I copied
to user dir /usr/src/jhbuild (jhbuild user's home). I changed
modulesets_dir
You need write access to whatever you assign to 'prefix'.
On Fri, May 6, 2011 at 7:02 PM, bsquared bwcod...@gmail.com wrote:
I have installed jhbuild in a basic LFS environment using standard build
tools: configure --prefix=/usr ; make make install. files[1] are
installed to /usr
, 2010 at 02:03:43PM +0100, Vincent Untz wrote:
What's the difference between x-jhbuild and jhbuild? :-)
It attempts to be a scripting framework for multiple repositories.
And this is nothing that can be done as an extension to JHbuild?
It facilitates a lot. No registration. A plug
Hi,
I just released x-jhbuild-0.2 and as it can be used with gnome, too, I
thought I post a note.
By default the subcommand 'init' will create an Xorg config, but the
attached example configuration can be passed to 'init' from an online or
local location like so:
$ xjh init -c path
Hi,
Le jeudi 18 novembre 2010, à 11:28 +0100, Dirk Wallenstein a écrit :
Hi,
I just released x-jhbuild-0.2 and as it can be used with gnome, too, I
thought I post a note.
What's the difference between x-jhbuild and jhbuild? :-)
Thanks,
Vincent
--
Les gens heureux ne sont pas pressés
On Thu, Nov 18, 2010 at 02:03:43PM +0100, Vincent Untz wrote:
What's the difference between x-jhbuild and jhbuild? :-)
It attempts to be a scripting framework for multiple repositories.
--
Greetings,
Dirk
___
desktop-devel-list mailing list
desktop
Am Donnerstag, den 18.11.2010, 20:10 +0100 schrieb Dirk Wallenstein:
On Thu, Nov 18, 2010 at 02:03:43PM +0100, Vincent Untz wrote:
What's the difference between x-jhbuild and jhbuild? :-)
It attempts to be a scripting framework for multiple repositories.
And this is nothing that can be done
On Tue, 2010-10-26 at 17:21 +0200, Javier Jardón wrote:
mozilla (needed by gnome-shell) can't be builded because the version
in moduleset (1.9.1.11) is no longer
available in mozilla ftp repos:
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/
Should be updated to 1.9.1.14 or
Am Mittwoch, den 27.10.2010, 14:06 +0200 schrieb Jan de Groot:
On Tue, 2010-10-26 at 17:21 +0200, Javier Jardón wrote:
mozilla (needed by gnome-shell) can't be builded because the version
in moduleset (1.9.1.11) is no longer
available in mozilla ftp repos:
On Wed, 2010-10-27 at 15:32 +0200, Andre Klapper wrote:
I don't know why they release xulrunner sources now and then, but
it's
advised to build Xulrunner from Firefox sources. Firefox 3.6.11
would
result in Xulrunner 1.9.2.11 for example.
How ugly. Who advises downloading a frontend if
mozilla (needed by gnome-shell) can't be builded because the version
in moduleset (1.9.1.11) is no longer
available in mozilla ftp repos:
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/
Should be updated to 1.9.1.14 or maybe 1.9.2.10 ?
--
Javier Jardón Cabezas
El mar, 26-10-2010 a las 17:21 +0200, Javier Jardón escribió:
mozilla (needed by gnome-shell) can't be builded because the version
in moduleset (1.9.1.11) is no longer
available in mozilla ftp repos:
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/
Should be updated to
Greetings,
I am trying to build gnome desktop using jhbuild and hitting an error below:
make[2]: Entering directory
`/tmp/checkout/gnome/gobject-introspection-0.6.7/gir'
Makefile:851: *** Need to define GLib_2_0_gir_LIBS or GLib_2_0_gir_PROGRAM.
Stop.
make[2]: Leaving directory `/tmp
Il giorno mer, 17/03/2010 alle 21.12 -0400, Matthias Clasen ha scritto:
On Wed, Mar 17, 2010 at 11:05 AM, Luca Ferretti lferr...@gnome.org wrote:
I've just updated JHBuild, adding udisk and UPower modules and update
deps for gnome-powe-manager, gnome-sessione and gnome-disk-utility.
See http
Hello Luca,
Luca Ferretti wrote:
Il giorno mer, 17/03/2010 alle 21.12 -0400, Matthias Clasen ha scritto:
On Wed, Mar 17, 2010 at 11:05 AM, Luca Ferretti lferr...@gnome.org wrote:
I've just updated JHBuild, adding udisk and UPower modules and update
deps for gnome-powe-manager, gnome
udisks[1] and upower[2] have now a tarball release; what should we do on
2.30 external deps page[3]? Should them replace or put beside
DeviceKit-* ? Here is any official module still using DeviceKit-* ?
Plus, any idea about JHbuild? I remember some issues building
DeviceKit-* maybe related
On Wed, 2010-03-17 at 16:05 +0100, Luca Ferretti wrote:
udisks[1] and upower[2] have now a tarball release; what should we do on
2.30 external deps page[3]? Should them replace or put beside
DeviceKit-* ? Here is any official module still using DeviceKit-* ?
Plus, any idea about JHbuild? I
about JHbuild? I remember some issues building
DeviceKit-* maybe related to stuff needed to build (udev, mostly)...
Cheers, Luca
[1] http://lists.freedesktop.org/archives/devkit-devel/2010-March/000758.html
[2] http://lists.freedesktop.org/archives/devkit-devel/2010-March/000747.html
[3] http
Hi,
I'm maintainer of libvtemm (C++ bindings for vte). Is it possible to add
it to jhbuild? If yes, where should it be added?
gnome-suites-2.28.modules or gnome-2.28.modules?
Thanks for response,
Krzesimir Nowak
___
desktop-devel-list mailing list
Krzesimir Nowak wrote:
I'm maintainer of libvtemm (C++ bindings for vte). Is it possible to add
it to jhbuild? If yes, where should it be added?
gnome-suites-2.28.modules or gnome-2.28.modules?
gnome-suites2.28 is for modules part of the official suites,
gnome-2.28 is for all others. I just
Il giorno mer, 28/01/2009 alle 17.54 +0100, Luca Ferretti ha scritto:
Jon, I've applied the patch (see [1]) to xorg-server 1.5.2, building new
packages for ubuntu 8.10, but the issue is still present :-(
I retreat. It seems I forgot to rebuild gnome-power-manager against
lates gnome-session.
Il giorno sab, 24/01/2009 alle 11.12 -0500, William Jon McCann ha
scritto:
Hi,
Reverting it to revision 5188 fix the issue.
Filed as bug 568989
Thanks everyone :)
As Olav mentioned, this is due to a bug in xorg.
On Sun, Jan 25, 2009 at 5:13 AM, Luca Ferretti elle@libero.it wrote:
Il giorno sab, 24/01/2009 alle 11.12 -0500, William Jon McCann ha
scritto:
Hi,
Reverting it to revision 5188 fix the issue.
Filed as bug 568989
Thanks everyone :)
As Olav mentioned, this is due to a bug in
Sorry to write here, but I've no idea how to investigate this issue that
only recently is happening in my jhbuild session.
I've GNOME trunk installed with jhbuild under /opt/gnome2. When I log in
using the jhbuild session, the CPU average load is 98%, or better, the X
process uses for itself 98
2009-01-24 klockan 14:06 skrev Luca Ferretti:
Now, someone has the same issue? And how can I try to investigate it?
The only evidence that something is going wrong is the X process CPU
usage :-|
You could try looking (with ps) which Gnome-related processes are running.
Then you can try to kill
Try killing gnome-screensaver (or reverting back to an older release),
this solved it for me.
bye
Andreas
On Sat, 2009-01-24 at 14:06 +0100, Luca Ferretti wrote:
Sorry to write here, but I've no idea how to investigate this issue that
only recently is happening in my jhbuild session.
I've
On Sat, Jan 24, 2009 at 02:06:56PM +0100, Luca Ferretti wrote:
Sorry to write here, but I've no idea how to investigate this issue that
only recently is happening in my jhbuild session.
Mandriva had such an issue as well. The cause was a bug in X, killing
gnome-screensaver avoided the X bug
Hi,
On Sat, Jan 24, 2009 at 10:58 AM, Luca Ferretti elle@libero.it wrote:
Il giorno sab, 24/01/2009 alle 14.22 +0100, Wouter Bolsterlee ha
scritto:
2009-01-24 klockan 14:06 skrev Luca Ferretti:
Now, someone has the same issue? And how can I try to investigate it?
The only evidence that
with
jhbuild.
Frederic, this error appears after the addition of nss/nspr modules
gcc -std=gnu99 -g -O2 -o .libs/gnome-vfs-daemon dbus-utils.o
vfs-daemon.o daemon-connection.o -pthread
-L/opt/gnome2/lib ../libgnomevfs/.libs/libgnomevfsdaemon-2.a
/opt/gnome2/lib/libhal-storage.so /opt/gnome2/lib/libhal.so
.0.9.8
But there is no libssl.la;
Yes, sorry, my mistype..
and the command line had -lssl, perhaps the
libssl.a installed in jhbuild prefix is the problem; could you remove
it to check ?
Removed libssl.a. Now gnome-vfs builds fine.
___
desktop-devel
with
jhbuild.
Here is an issue with tracker. Tracker depends on gmime, but gmime
head provides gmime-2.4.pc, while tracker checks for gmime-2.0.pc
I'll open a bug against tracker, meanwhile could be good idea add a
gmime-2.0 module, of course after all needed checks: branch
availability, parallel install
I'm subscribe to d-d-l, no need to cc: me in :-)
On Sat, 2008-11-08 at 22:06 +0100, Luca Ferretti wrote:
* a little mess with clutter stuff: we have clutter in
gnome-external-deps-2.26 (0.8.2 targz) and in gnome-2.26 (svn
trunk) and clutter-0.8 (svn branch) as well as a
-
that's the usual rule we've been following since we released 0.2[1].
the external dependency on clutter for gnome 2.26 is 0.8, from the
clutter-0-8 branch.
So, could be good to use in jhbuild:
* clutter and clutter-[cairo|gtk|*] for external dep and
stable branches
* clutter
Hello all,
gnome-suites-2.26.modules | 188
1 file changed, 151 insertions(+), 37 deletions(-)
I spent some time passing over modules, checking their dependencies
against what was declared in jhbuild, removing libgnome/ui at places,
adding libnotify
with
jhbuild.
A quick report
* devhelp trunk (used in gnome-suites-2.26) depends on WebKit, not
mozilla
* WebKit missing in meta-gnome-proposed ?? note that WebKit will
grab ~400 MB from git.
* libunique missing in meta-gnome-proposed
* a little mess with clutter
if you use
jhbuild to build just one application (for example `jhbuild
build transmission`) and not the full desktop. The other
solution is make all modules installing icons in
$(prefix)/share/icons/hicolor depend on hicolor-icon-theme
Maybe as suggests
dependencies in meta-gnome-proposed;
unique and libproxy are already set in gnome-external-deps-2.26;
WebKit should be added.
Oh, that's true, sorry.
* a little request: could we force to build hicolor-icon-theme
before gtk+? This could be useful, for example if you use
jhbuild
Luca Ferretti wrote:
* a little request: could we force to build hicolor-icon-theme
before gtk+? This could be useful, for example if you use
jhbuild to build just one application (for example `jhbuild
build transmission`) and not the full desktop
Il giorno sab, 08/11/2008 alle 23.27 +0100, Frederic Peters ha scritto:
Luca Ferretti wrote:
* a little request: could we force to build hicolor-icon-theme
before gtk+? This could be useful, for example if you use
jhbuild to build just one application
On Sat, Nov 8, 2008 at 3:06 PM, Luca Ferretti [EMAIL PROTECTED] wrote:
* a little mess with clutter stuff: we have clutter in
gnome-external-deps-2.26 (0.8.2 targz) and in gnome-2.26 (svn
trunk) and clutter-0.8 (svn branch) as well as a lot of
clutter-XXX-0.8:
I've just added a sqlite3 module to jhbuild.
See http://svn.gnome.org/viewvc/jhbuild?view=revisionrevision=2181 for
details
Let me know if we are planning to use another sqlite3 version (for
example, sqlite.org says new code should use version 3.6.0, but it's
still in Beta or RC and it seems
was the following. GVFS was somehow compiled with
HAVE_HAL_FAST_INIT equals 1. This meant that
libhal_get_all_devices_with_properties was available. However jhbuild
installls hal 0.5.10 and libhal_get_all_devices_with_properties is
only available in 0.5.11. My ~/.xsession-errors contained an error
Kjartan,
- gnome-session doesn't seem to work. When logging in it just hangs and
I see a zombie gnome-login-sound(?) process. Tried running gconf-editor
to turn off the sound server but that didn't help.
Did you manage to solve this? When I start my jhbuild gnome session I
don't see
start my jhbuild gnome session I
don't see the desktop but just the background color of GDM (In my case
brown because I run ubuntu)
My account has the following processes running
avahi 5377 0.0 0.1 2880 1512 ?Ss 11:11 0:00
avahi-daemon: running [guzzi.local]
guzzi
On Sun, Jun 8, 2008 at 2:44 PM, Lucas Rocha [EMAIL PROTECTED] wrote:
The specific problem on Fedora Rawride (being unable to connect to
session manager) was solved on 2.23.3. Could you send me the output
(~/.xsession-errors) of gnome-session?
I'm running PLD here and I still get the zombies.
201 - 300 of 421 matches
Mail list logo
