On Fri, Apr 19, 2019 at 11:41 AM Leland Carlye via desktop-devel-list
wrote:
>
> Hi!. I'm having this issue when building gnome-terminal in jhbuild (jhbuild
> run gnome-terminal) in Ubuntu
>
> me@ubuntu:~/jhbuild/checkout/gnome-terminal$ jhbuild shell
> me@ubuntu:~
Hi!. I'm having this issue when building gnome-terminal in jhbuild (jhbuild run
gnome-terminal) in Ubuntu
me@ubuntu:~/jhbuild/checkout/gnome-terminal$ jhbuild shell
me@ubuntu:~/jhbuild/checkout/gnome-terminal$ gnome-terminal
# _g_io_module_get_default: Found default implementation
erminal in jhbuild
Hi!. I'm having this issue when building gnome-terminal in jhbuild (jhbuild run
gnome-terminal) in Ubuntu
me@ubuntu:~/jhbuild/checkout/gnome-terminal$ jhbuild shell
me@ubuntu:~/jhbuild/checkout/gnome-terminal$ gnome-terminal
# _g_io_module_get_default: Found default imple
Hi!. I'm having this issue when building gnome-terminal in jhbuild (jhbuild run
gnome-terminal) in Ubuntu
me@ubuntu:~/jhbuild/checkout/gnome-terminal$ jhbuild shell
me@ubuntu:~/jhbuild/checkout/gnome-terminal$ gnome-terminal
# _g_io_module_get_default: Found default implementation
Hi Tristan,
>
>
> Also, your question makes me realize I need to clarify some more
> things
> about sysdeps and how they have changed, there is a longer term plan
> which involves collaboration with the newly created freedesktop-sdk
> project (see: gitlab project[0] and mailing list[1]) for build
sagree with is that RT appears to actively
> > discourage maintainers from updating JHbuild before everyone actually
> > has the option to make the switch - sure, if updating GTK+ fails for
> > me because harfbuzz gained a new dependency, I'll be able to figure
> &
On Wed, Jan 24, 2018 at 2:11 PM, Florian Müllner
wrote:
Really, the only thing I disagree with is that RT appears to actively
discourage maintainers from updating JHbuild before everyone actually
has the option to make the switch - sure, if updating GTK+ fails for
me because harfbuzz gained a
Oh my. I certainly did not intend to start a rant thread, sorry for that.
To clarify: I am not complaining that RT is taking away my favorite
toy. JHbuild is a great tool when it works, but it still breaks far
too often for newcomers or non-regulars. And as you rightly point out,
this is not
On Wed, Jan 24, 2018 at 02:28:26AM +0200, Alberts Muktupāvels wrote:
> Sorry if that already is posted somewhere, but is there at least some kind
> of migration guide/tutorial?
See the first e-mail of this thread.
--
Sébastien
___
desktop-devel-list mai
On Wed, Jan 24, 2018 at 12:22 AM, Marco Trevisan (Treviño)
wrote:
> Il 22/01/2018 14:34, mcatanz...@gnome.org ha scritto:
> > On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
> >> Were you actually using JHBuild to run integrated system components
> >>
Il 22/01/2018 14:34, mcatanz...@gnome.org ha scritto:
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
>> Were you actually using JHBuild to run integrated system components
>> (gnome-shell, gnome-session)? If so, how? I was not aware that that
>> was e
It sounds like you never use 'jhbuild build', but instead manage your
dependencies manually and use 'jhbuild buildone'. Although I wouldn't
recommend that to newcomers, if that works for you, then great. But if
you never use 'jhbuild build' then you're
Hi all,
This will be a long email, so TL;DR:
o At this time you can keep using JHBuild for these few cases where
testing is very difficult, you can even do so indefinitely.
o For these few modules who dont benefit directly at development
time from the release team's off
On Mon, 2018-01-22 at 14:31 -0600, mcatanz...@gnome.org wrote:
>
>
> I'll use one specific anecdote. On October 30, the Autotools build
> files were removed from at-spi2-core. The accompanying JHBuild
> moduleset update switching it to use meson was pushed by Philip
>
>But I'm only speaking for the release team here, not the entire community
- I know that answer doesn't actually solve the problem, but hopefully that
explains our thinking.
Definitely, I imagined this is just a side effect of the release team not
using JHbuild anymore, which I und
On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano
wrote:
What's the workflow for those before a proper solution is done? Or
are the developers of those modules expected to maintain JHbuild on
the meantime?
Thanks Carlos; this is an important question. Let me provide a bit more
contex
Adding on top of Florian, some apps like gnome-boxes and Nautilus are not
yet ready for Flatpak, or Flatpak is not ready for them yet. While I agree
we should pursue that as a end goal, pulling out maintenance of JHbuild as
tool for people to contribute to our modules before a viable alternative
On Sat, Jan 20, 2018 at 9:47 AM, Tristan Van Berkom
wrote:
> Instructions for using the gnome-build-meta BuildStream project can be
> found at:
>
> https://wiki.gnome.org/Newcomers/BuildSystemComponent
We found a bug in BuildStream which is triggered by those
instructions. It's reported at
ht
On Mon, Jan 22, 2018 at 9:13 AM, Florian Müllner
wrote:
Very much, I actually use a jhbuild GNOME session as my everyday
system.
I don't have a good answer. :/
Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
mcatanz...@gnome.org 於 西元2018年01月22日 21:34 寫道:
>
>
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
>> Were you actually using JHBuild to run integrated system components
>> (gnome-shell, gnome-session)? If so, how? I was not aware that that
>>
On Mon, Jan 22, 2018 at 2:34 PM, wrote:
>
>
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
>>
>> Were you actually using JHBuild to run integrated system components
>> (gnome-shell, gnome-session)? If so, how? I was not aware that that was even
>>
On Mon, 2018-01-22 at 07:34 -0600, mcatanz...@gnome.org wrote:
>
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
> > Were you actually using JHBuild to run integrated system
> > components
> > (gnome-shell, gnome-session)? If so, how? I was not aware tha
On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
Were you actually using JHBuild to run integrated system components
(gnome-shell, gnome-session)? If so, how? I was not aware that that
was even possible nowadays.
When developing these components,
Sorry, trying again
When
.
If not, are we now expected to monitor all our dependencies'
dependencies (and so on) and effectively take over maintenance of the
jhbuild moduleset until someone figures out how to support our
components?
Were you actually using JHBuild to run integrated system components
(gnome-shell,
ake over maintenance of the
jhbuild moduleset until someone figures out how to support our
components?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
ing behind this.
We used to prefer to move modules from core-deps into sysdeps when
possible, to reduce the number of modules that can cause build failures
in JHBuild. That's not really going to be an issue anymore. I think
moving gexiv2 to core-deps would be uncontroversial, if ther
both etc) ? Only
gnome-build-meta as mandatory, jhbuild as goodwill? What about
continous?
Please do continue to update Continuous as needed for the time being.
The future plan is to generate the Continuous manifest from
gnome-build-meta, so that we don't have all this metadata specifi
Hi Jens,
Hurried reply whilst getting ready to go to airport...
On Sun, 2018-01-21 at 10:16 +0100, Jens Georg wrote:
> > On Sat, 2018-01-20 at 11:06 -0600, mcatanz...@gnome.org wrote:
>
> > Hi all,
> >
> > This bears repeating: the release team will no longer maint
On Sat, 2018-01-20 at 11:06 -0600, mcatanz...@gnome.org wrote:
> Hi all,
>
> This bears repeating: the release team will no longer maintain
> JHBuild
> or the JHBuild modulesets. When adding or removing a dependency from
> your module, please now update gnome-build-meta inste
On Sat, Jan 20, 2018 at 3:47 AM, Tristan Van Berkom
wrote:
JHBuild
---
For what regards the upcomming 3.28 release and further, patches
should
go to the gnome-build-meta project instead of the JHBuild modulesets -
otherwise these patches would not be considered in the releases we are
things which are not a
part of the "core" category in GNOME.
Instructions for using the gnome-build-meta BuildStream project can be
found at:
https://wiki.gnome.org/Newcomers/BuildSystemComponent
JHBuild
---
For what regards the upcomming 3.28 release and further, patches should
Hi,
I pushed wip/muktupavels/force-non-srcdir-build branch to jhbuild. Can
someone review few commits? It adds force-non-srcdir-builds attribute
support to autotools and adds this attribute to mozjs52 and colord modules.
On Tue, Aug 1, 2017 at 11:16 AM, Alberts Muktupāvels <
alberts.muktu
On Tue, Aug 1, 2017 at 9:39 AM, Tim-Philipp Müller
wrote:
2) patch Meson with patch/commit 12be4b66440 (if jhbuild uses its own
meson)
It does.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo
On Tue, 2017-08-01 at 11:16 +0300, Alberts Muktupāvels wrote:
Hi,
> Then build failure with gst-plugins-bad. It fails 100% if I try to
> update it. I need first uninstall it:
> jhbuild uninstall gst-plugins-bad
>
> Is there something I can do about it? Workaround?
This is
On 1 August 2017 at 09:16, Alberts Muktupāvels
wrote:
> is there anything that could be done to make building with JHBuild better?
Maintainers taking ownership of the things in the modulesets would help.
> jhbuild build
> This command I use at least few times in week and almost alw
Hi,
is there anything that could be done to make building with JHBuild better?
jhbuild build
This command I use at least few times in week and almost always there are
problems. :( Mostly I am using it to update existing modules, but sometimes
I start fresh by deleting checkout and install
Hi,
GtkSourceView 3.24 has branched, master is now open for GtkSourceView 4
development, which breaks backward-compatibility with GtkSourceView 3.
The jhbuild modulesets have been modified exactly as for GTK+:
1. Rename the gtksourceview module to gtksourceview-3
2. For gtksourceview-3, set the
On Tue, 2016-10-11 at 02:52 +0200, Jürg Billeter wrote:
> For bootstrapping, the dependency should be on valac, not on libvala.
> I'm not very familiar with jhbuild but what's the issue with a valac
> sysdep such as the following, similar to how the C compiler
#x27;s
internals and is not API-stable, hence the parallel installable
versions. However, it's also not needed by regular applications and
libraries that are written in Vala.
For bootstrapping, the dependency should be on valac, not on libvala.
I'm not very familiar with jhbuild but
d distros. Clearly nobody is
maintaining the jhbuild modulesets to ensure they work on anything not
Fedora.
Anyway, the problem is a bootstrap version of vala needs to be
installed as a sysdep, but we can't make a sysdep for it until the vala
developers stop pointlessly bumping their pkg-config
[20/30]
./autogen.sh --prefix /home/hulkbuster/jhbuild/install --disable-Werror
--enable-vapigen --disable-static --disable-gtk-doc
./autogen.sh: 10: ./autogen.sh: valac: not found
**Error**: You must have valac >= 0.12.0 installed
to build vala. Download the appropriate package
from your distributi
Hey
I am facing difficulty in building the JHbuild from the below instruction
page:
https://wiki.gnome.org/Newcomers/BuildGnome
I get the below error when i run the following command:
$jhbuild build adwaita-icon-theme dconf glib-networking gvfs libcanberra
*** Checking out vala *** [20/30
On Fri, Sep 09, 2016 at 11:43:51AM -0400, Owen Taylor wrote:
> On Tue, 2016-08-30 at 19:23 +0200, Sébastien Wilmet wrote:
> >
> > 1) Once a project is fully built, to re-build something I always do
> > something along those lines:
> >
> > To compile only what
On Tue, 2016-08-30 at 19:23 +0200, Sébastien Wilmet wrote:
>
> 1) Once a project is fully built, to re-build something I always do
> something along those lines:
>
> To compile only what I need:
>
> $ jhbuild shell
> [jhbuild] $ cd src/
> [jhbuild] $ make
>
&g
; > > I've been thinking about the exact same thing recently; how about
> > > a
> > > > 'jhbuild jump' command that will take you from a location under
> > > > srcdir to
> > > > the corresponding location under builddir a
On Fri, 2016-09-02 at 08:09 +, philip.chime...@gmail.com wrote:
> On Thu, Sep 1, 2016 at 5:43 AM Michael Catanzaro g> wrote:
> > On Tue, 2016-08-30 at 21:25 +, philip.chime...@gmail.com wrote:
> > > I've been thinking about the exact same thing recently; how
On Thu, Sep 1, 2016 at 5:43 AM Michael Catanzaro
wrote:
> On Tue, 2016-08-30 at 21:25 +, philip.chime...@gmail.com wrote:
> > I've been thinking about the exact same thing recently; how about a
> > 'jhbuild jump' command that will take you from a locati
On Tue, 2016-08-30 at 21:25 +, philip.chime...@gmail.com wrote:
> I've been thinking about the exact same thing recently; how about a
> 'jhbuild jump' command that will take you from a location under
> srcdir to
> the corresponding location under builddir and vic
On Tue, Aug 30, 2016 at 09:25:20PM +, philip.chime...@gmail.com wrote:
> I've been thinking about the exact same thing recently; how about a
> 'jhbuild jump' command that will take you from a location under srcdir to
> the corresponding location under builddir and vice
On Tue, Aug 30, 2016 at 07:05:49PM +0100, Emmanuele Bassi wrote:
> > To compile only what I need:
> >
> > $ jhbuild shell
> > [jhbuild] $ cd src/
> > [jhbuild] $ make
> >
> > To re-build only a certain *.c file, to see if there are any warnings:
> &g
'~/gnome')
> >
> > (to have again builddir == scrdir)
>
> That's not really how it's done.
>
> Just set:
>
> buildroot = None
>
> and jhbuild will use the srcdir by default.
It's indeed better. By looking at jhbuild/defaults.jhbuildr
about this too; it's more inconvenient than I
> expected. Some other issues:
>
> * Hard to clean the build directory ('rm -rf
> ~/.cache/jhbuild/build/epiphany' replaces a simple 'git clean -xfd')
>
> * Hard to upload tarballs ('scp
> ~/.cach
On Tue, 2016-08-30 at 19:05 +0100, Emmanuele Bassi wrote:
> We could avoid all of this by switching to other build systems, like
> CMake or (better) Meson, that use separate build directories by
> default.
CMake does not use a separate build directory by default. It's about as
easy to do as with A
ard to clean the build directory ('rm -rf
~/.cache/jhbuild/build/epiphany' replaces a simple 'git clean -xfd')
* Hard to upload tarballs ('scp
~/.cache/jhbuild/build/epiphany/epiphany-whatever.tar.xz...)
But I think this is actually mostly just a problem because we put
Hi;
On 30 August 2016 at 18:23, Sébastien Wilmet wrote:
> Hi,
>
> With the new jhbuild default configuration, it builds the module with
> scrdir != builddir. I wanted to explain why I don't like it, and why
> I've put the following in my jhbuildrc:
>
> checkoutroo
Hi,
With the new jhbuild default configuration, it builds the module with
scrdir != builddir. I wanted to explain why I don't like it, and why
I've put the following in my jhbuildrc:
checkoutroot = os.path.expanduser('~/gnome')
buildroot = os.path.expanduser('~/gnome
Hi;
On 6 June 2016 at 12:23, Bastien Nocera wrote:
> The "srcdir != builddir" implemented in jhbuild isn't the same one as
> the one implemented in Continuous[1].
I know, that's why I wrote:
"""
The main change is that jhbuild runs the autogen script
a commit or two from me on your
> > modules fixing builddir != srcdir issues); submitting bugs/patches
> > to
> > modules that are hosted elsewhere; and disabling non-srcdir builds
> > directly in the jhbuild modulesets. I'm fairly confident that all
> > remaining issues
On Fri, 2016-06-03 at 12:31 +0100, Emmanuele Bassi wrote:
> > What's the proper fix for this then?
>
> In general, everything that modifies the Git repository or the
> autotools files, like `git submodule update` or `gtkdocize` or
> `intltoolize` will need to be called inside the source directory;
ts, but I'd rather avoid it as it
>> defeats the purpose.
>
> Looks like this is uncovering more bugs.
Yes; right now I'm blocked on getting a WebKit build going because of
dependencies.
> $ jhbuild buildone -afn gnome-documents
> *** Configuring gnome-documents *** [1/
On Fri, Jun 3, 2016 at 1:12 PM Bastien Nocera wrote:
> The autogen.sh tries to run:
> git submodule update --init --recursive
>
> Which might, or might not be a good idea. In any case, that won't work
> if cwd isn't the git repo.
>
> What's the proper fix for this then?
Temporarily changing int
ting bugs/patches to
> modules that are hosted elsewhere; and disabling non-srcdir builds
> directly in the jhbuild modulesets. I'm fairly confident that all
> remaining issues are now limited to modules that are in gnome-apps or
> gnome-world, but I haven't tested things li
uilds
directly in the jhbuild modulesets. I'm fairly confident that all
remaining issues are now limited to modules that are in gnome-apps or
gnome-world, but I haven't tested things like all the C++ language
bindings modules.
If you maintain a module listed in jhbuild, *please* update you
On 31/05/2016 19:04, Emmanuele Bassi wrote:
> b) we don't have the resources to set up and maintain a try server
> running continuous
I've been recently playing with the CI service provided by gitlab.com
and I find it very convenient: you just have to create a single file in
your repository, cont
ent
> workflow than what Git and various tools and organisations use.
I said that jhbuild would build master-stable by default. A developer
would use master only for a few modules, the modules he/she works on.
Currently, GContinuous builds and tests the set of the latest commits
pushed on master.
ommits that work (from the GContinuous point of view).
> And jhbuild would pick up the master-stable branch by default.
>
> It doesn't need more servers,
Oh, I can assure you: it does need a separate build machine — and not a VM.
> it needs development time. Currently
> GContin
On Wed, Jun 01, 2016 at 11:33:41AM +0200, Sébastien Wilmet wrote:
> With master/master-stable, developers, translators etc continue to work
> exactly as before. But GContinuous would automatically sets
> master-stable to commits that work (from the GContinuous point of view).
> And j
rk
exactly as before. But GContinuous would automatically sets
master-stable to commits that work (from the GContinuous point of view).
And jhbuild would pick up the master-stable branch by default.
It doesn't need more servers, it needs development time. Currently
GContinuous needs maintenan
On Tue, 2016-05-31 at 17:51 +0100, Emmanuele Bassi wrote:
> I'm just worried about gnome-world, but for that I guess we'll
> have to wait until stuff breaks.
Most everything in gnome-world is already broken, so don't worry about
it. We don't maintain gnome-world. Feel free to fix anything you care
On Tue, May 31, 2016 at 6:47 PM Michael Catanzaro
wrote:
> Just please wait a couple days first to see if there are any
> substantial objections (which I do not expect).
Is this really necessary? This is a revived thread from February, so surely
there has been plenty of time to voice objections
e because
>> people don't test under builddir != srcdir; I really, *really* don't
>> want to deal with this kind of perfectly avoidable build breakages
>> any
>> more.
>>
>> Ciao,
>> Emmanuele.
>
> Emmanuele, I think you can feel free to cha
to deal with this kind of perfectly avoidable build breakages
> any
> more.
>
> Ciao,
> Emmanuele.
Emmanuele, I think you can feel free to change the default in jhbuild
provided that everything in the apps and core suites still builds after
doing so. i.e. you need to make sure to add exce
Hi;
On 31 May 2016 at 16:01, Sébastien Wilmet wrote:
> On Mon, May 30, 2016 at 11:44:48PM +0100, Emmanuele Bassi wrote:
>> So, it seems that the discussion died on these shores.
>>
>> In the meantime, GVfs is but the latest module that broke because
>> people don't test under builddir != srcdir;
nly
GNOME Continuous would be able to change master-stable. By default
jhbuild would use master-stable. And we would continue to push commits
on master as we do now.
--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.
On Mon, May 30, 2016 at 11:44:48PM +0100, Emmanuele Bassi wrote:
> So, it seems that the discussion died on these shores.
>
> In the meantime, GVfs is but the latest module that broke because
> people don't test under builddir != srcdir; I really, *really* don't
> want to deal with this kind of pe
Sorry for that! I've added "buildroot = '~/gnome/build'" into my jhbuildrc
thanks to this thread... so +1 for changing the defaults.
2016-05-31 0:44 GMT+02:00 Emmanuele Bassi :
> So, it seems that the discussion died on these shores.
>
> In the meantime, GVfs is but the latest module that broke b
I would like to have this as default too.
As pointed out previously, maybe we can run a whole build and create exceptions
for those that doesn't build and file bugs for them, but change already the
default?
I think the sooner the better, if not we are not going to take it out of our
chest.
Che
So, it seems that the discussion died on these shores.
In the meantime, GVfs is but the latest module that broke because
people don't test under builddir != srcdir; I really, *really* don't
want to deal with this kind of perfectly avoidable build breakages any
more.
Ciao,
Emmanuele.
On 2 March
On Sun, 2016-02-28 at 09:54 -0600, Michael Catanzaro wrote:
> On Sun, 2016-02-28 at 14:33 +, Emmanuele Bassi wrote:
> >
> > My proposal is to enable this behaviour in the default jhbuildrc,
> > so
> > that all GNOME projects automatically build in a separate root.
> > This
> > change should ha
I actually was thinking about putting the intermediate build state
inside `$XDG_CACHE_HOME/jhbuild/build` by default, like we put the
downloaded tarballs in `$XDG_CACHE_HOME/jhbuild/downloads` by default.
I can check if `$HOME/jhbuild` exists, and put a `build` directory under there.
Ciao
A big +1 to this idea.
As a nitpick, change the buildroot to '~/jhbuild/build'
because we use by default '~/jhbuild/checkout' and
'~/jhbuild/install', or convince jhbuild devs to change
default to '~/gnome/*'.
Cheers,
Carlos Soriano
- Original Mess
On So, 2016-02-28 at 15:43 +0100, Jens Georg wrote:
> > * automated builds of our software are possible without hacks
> > * distchecking projects does not fail at the very last minute
> > before
> > release but during development
> > * we bring the development environment and the continuous
> >
the interaction between the compiler and autotools, I'd say
that all Vala-based projects should use the
'supports-non-srcdir-builds="no"' attribute in their module definition
inside jhbuild modulesets.
Ciao,
Emmanuele.
--
https://www.bassi.io
[@] ebassi [@
On Sun, 2016-02-28 at 14:33 +, Emmanuele Bassi wrote:
> My proposal is to enable this behaviour in the default jhbuildrc, so
> that all GNOME projects automatically build in a separate root. This
> change should have no, or minimal impact on the subset of the
> moduleset that is covered by Cont
x27; in only one sub-directory. Instead of being at the
> same place in the git repo, I'll need to be somewhere in ~/gnome/build/.
I'd like to note that if you use `jhbuild make` from within your
project's directory, everything will work much better by default.
If you're us
On Sun, Feb 28, 2016 at 02:33:02PM +, Emmanuele Bassi wrote:
> buildroot = '~/gnome/build'
I agree it's a good idea, but I'll need to change a little my habits
when I run 'make' in only one sub-directory. Instead of being at the
same place in the git repo, I'll need to be somewhere in ~/gn
On 28 February 2016 at 14:33, Emmanuele Bassi wrote:
> What do maintainers think?
Makes sense to me. The quicker we catch a destdir/srcdir issue the
easier it is to fix.
Richard
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://m
> * automated builds of our software are possible without hacks
> * distchecking projects does not fail at the very last minute before
> release but during development
> * we bring the development environment and the continuous deployment
> environment closer
>
> What do maintainers think?
+1
Hi all;
as you may know, automated build services – for instance Continuous,
OBS, or the autotools distcheck – use a build directory that is not
the same as the source directory. Our own jhbuild allows this, even if
it's disabled by default. This means that developers may work on a
feature
Hi all,
A reminder to all maintainers: when bumping required versions of any of
your dependencies, please be sure to check jhbuild to make sure it has
the appropriate required versions, and update the modulesets if not. We
had multiple fairly-critical GNOME applications broken in jhbuild for
half
gnome-photos depends on dleyna-renderer, which in jhbuild is
provided by pkgconfig(dleyna-renderer-service-1.0), but this .pc file
is deleted in the Fedora spec file since it's apparently only for use
of the dleyna daemon (which raises the question why it exists at all).
Yeah, that *.pc
ms to run fine when dleyna-renderer is missing, and
we seem to have no way to install it (no guarantee the .pc file is
installed, no C header, no binary in $PATH) I've simply removed dleyna
-renderer from jhbuild.
Michael
___
desktop-devel-list mailing
Hey,
On Sat, Oct 24, 2015 at 08:49:02PM -0500, Michael Catanzaro wrote:
> I tried to build gnome-photos today and noticed it is broken in jhbuild
> on Fedora.
:(
> gnome-photos depends on dleyna-renderer, which in jhbuild is
> provided by pkgconfig(dleyna-renderer-service-1.0),
Hi,
I tried to build gnome-photos today and noticed it is broken in jhbuild
on Fedora. gnome-photos depends on dleyna-renderer, which in jhbuild is
provided by pkgconfig(dleyna-renderer-service-1.0), but this .pc file
is deleted in the Fedora spec file since it's apparently only for use
o
rs,
Carlos Soriano
- Original Message -
From: "Sriram Ramkrishna"
To: "Lasse Schuirmann"
Cc: "Carlos Soriano Sanchez" , "desktop-devel-list"
Sent: Friday, 13 March, 2015 9:15:27 PM
Subject: Re: Canonical jhbuild documentation
On Fri, Mar 13, 2015 at 1:
o problems in once right now
Thanks!
- Original Message -
From: "Lasse Schuirmann"
To: "Carlos Soriano Sanchez"
Cc: "Allan Day" , "desktop-devel-list"
Sent: Friday, 13 March, 2015 9:09:17 PM
Subject: Re: Canonical jhbuild documentation
2015-0
have been thinking on this for the past few days, and I think we agreed in
>> a not that good solution.
>> So what we try to fix, is not actually a "Canonical jhbuild documentation".
>> That is a problem that came
>> from another problem. So what we have to
On Fri, Mar 13, 2015 at 1:01 PM, Carlos Soriano Sanchez
wrote:
>
> - What do I propose?
> So, what we actually need is a "Canonical documentation for contributing
> gnome". In developers.gnome.org.
> As I offered before for the Jhbuild one, I offer me volunteer (with
t that good solution.
> So what we try to fix, is not actually a "Canonical jhbuild documentation".
> That is a problem that came
> from another problem. So what we have to do is actually fix that original
> problem.
> That original problem is, no documentation for "
Hi everyone again,
Sorry for reborn this, but now that most of the changes for 3.16 are done, it's
time to think again =)
I have been thinking on this for the past few days, and I think we agreed in a
not that good solution.
So what we try to fix, is not actually a "Canonic
1 - 100 of 473 matches
Mail list logo