Re: Issue running gnome-terminal in jhbuild

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:~/jhbu

Issue running gnome-terminal 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 implementation local

Re: Issue building gnome-terminal in jhbuild

e-terminal 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 implementa

Issue building gnome-terminal 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 implementation local

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

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 new dependency, I'll be able to figure  >

Re: Release team now using gnome-build-meta repository, not JHBuild

On Wed, Jan 24, 2018 at 2:11 PM, Florian Müllner <fmuell...@gnome.org> 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 f

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

On Wed, Jan 24, 2018 at 12:22 AM, Marco Trevisan (Treviño) <m...@3v1n0.net> 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 comp

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

nce a week. Hi, 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 also not using the depend

Re: Release team now using gnome-build-meta repository, not JHBuild

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 official

Re: Release team now using gnome-build-meta repository, not JHBuild

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 >

Re: Release team now using gnome-build-meta repository, not JHBuild

>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 understand. J

Re: Release team now using gnome-build-meta repository, not JHBuild

On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano <csori...@gnome.org> 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 p

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

On Mon, Jan 22, 2018 at 9:13 AM, Florian Müllner <fmuell...@gnome.org> 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-deve

Re: Release team now using gnome-build-meta repository, not JHBuild

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 >>

Re: Release team now using gnome-build-meta repository, not JHBuild

On Mon, Jan 22, 2018 at 2:34 PM, <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 awa

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

would be hard to run them. 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 comp

Re: Release team now using gnome-build-meta repository, not JHBuild

o on) and effectively take 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

Re: Release team now using gnome-build-meta repository, not JHBuild

l have to figure out the reasoning 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 uncontrov

Re: Release team now using gnome-build-meta repository, not JHBuild

he new branch or provide 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 ha

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

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

Re: Release team now using gnome-build-meta repository, not JHBuild

On Sat, Jan 20, 2018 at 3:47 AM, Tristan Van Berkom <tristan.vanber...@codethink.co.uk> 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

Release team now using gnome-build-meta repository, not JHBuild

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

Re: JHBuild

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

Re: JHBuild

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

Re: JHBuild

On 1 August 2017 at 09:16, Alberts Muktupāvels <alberts.muktupav...@gmail.com> 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

JHBuild

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

GtkSourceView changes in jhbuild

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

Re: Problems regarding jhbuild

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 sysdep is

Re: Problems regarding jhbuild

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 what's the issue w

Re: Problems regarding jhbuild

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 vers

Re: Problems regarding jhbuild

[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

Problems regarding jhbuild

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

Re: builddir != srcdir in jhbuild breaks my workflow

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

Re: builddir != srcdir in jhbuild breaks my workflow

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

Re: builddir != srcdir in jhbuild breaks my workflow

6-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 corr

Re: builddir != srcdir in jhbuild breaks my workflow

e 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 versa? And > > perhaps > > > have > > > some environment variab

Re: builddir != srcdir in jhbuild breaks my workflow

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 versa? And per

Re: builddir != srcdir in jhbuild breaks my workflow

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

Re: builddir != srcdir in jhbuild breaks my workflow

duser('~/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.jhbuildrc, there is n

Re: builddir != srcdir in jhbuild breaks my workflow

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

Re: builddir != srcdir in jhbuild breaks my workflow

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 the build directory in a shitty

builddir != srcdir in jhbuild breaks my workflow

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') (to have again builddir

Re: Enabling builddir != srcdir by default in jhbuild

Hi; On 6 June 2016 at 12:23, Bastien Nocera <had...@hadess.net> 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

Re: Enabling builddir != srcdir by default in jhbuild

mmit 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 are now l

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

ilds in the various modulesets, 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-

Re: Enabling builddir != srcdir by default in jhbuild

ng 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 like all the C++

Re: Enabling builddir != srcdir by default in jhbuild

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 your jhbuild local

Re: Enabling builddir != srcdir by default in jhbuild

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,

Re: Enabling builddir != srcdir by default in jhbuild

ow 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. It doesn't h

Re: Enabling builddir != srcdir by default in jhbuild

ts > 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, Oh, I can assure you: it does need a separate build machine — and not a VM. > it needs development time. Cur

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

t 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. > > Emmanuele, I think you can feel free to ch

Re: Enabling builddir != srcdir by default in jhbuild

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 exceptions in

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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.

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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.

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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 Message - | Hi all; | | as you may know

Re: Enabling builddir != srcdir by default in jhbuild

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 > >

Re: Enabling builddir != srcdir by default in jhbuild

o Vala, and especially 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 [@gma

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

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

Re: Enabling builddir != srcdir by default in jhbuild

>  * 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?

Enabling builddir != srcdir by default in jhbuild

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

Reminder: keep jhbuild dependencies updated

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

Re: gnome-photos in jhbuild

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 file

Re: gnome-photos in jhbuild

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),

Re: gnome-photos in jhbuild

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 list desk

gnome-photos in jhbuild

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

Re: Canonical jhbuild documentation

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 Canonical jhbuild

Re: Canonical jhbuild documentation

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 Getting started with contribution for Gnome. Given

Re: Canonical jhbuild documentation

jhbuild documentation 2015-03-13 21:01 GMT+01:00 Carlos Soriano Sanchez csori...@redhat.com: 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

Re: Canonical jhbuild documentation

Soriano - Original Message - From: Sriram Ramkrishna s...@ramkrishna.me To: Lasse Schuirmann lasse.schuirm...@gmail.com Cc: Carlos Soriano Sanchez csori...@redhat.com, desktop-devel-list desktop-devel-list@gnome.org Sent: Friday, 13 March, 2015 9:15:27 PM Subject: Re: Canonical jhbuild

Re: Canonical jhbuild documentation

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 do is actually fix that original problem. That original

Re: Canonical jhbuild documentation

On Fri, Mar 13, 2015 at 1:01 PM, Carlos Soriano Sanchez csori...@redhat.com 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 whoever wants

Re: Canonical jhbuild documentation

it is not a generic jhbuild guide, it's a guide for get started asap in Gnome which uses jhbuild to build and run Gnome applications. That's it. I don't think a newcomer needs more. Thanks for all the work you've put into the guides, Carlos, as well as advising newcomers. It's really great to have you

Re: Canonical jhbuild documentation

Hello (sorry for the delay, there were some problems with the email) A little of history of the latest wiki jhbuild pages: When I created the series of BuildGnome CodeContributionWorkflow my intention was creating a simple straightforward workflow for contributing to Gnome for newcommers

Re: Canonical jhbuild documentation

issue. Again: the manual ranks highly in search results for jhbuild, and attracts attention as, well, the JHBuild documentation. For newcomers it is at best a dead end, and at worst misleading. So in my opinion, something really needs to be done about the manual. So, let's try to get something

Re: Canonical jhbuild documentation

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. Also jhbuild has been absorbing good practices

Re: Canonical jhbuild documentation

wrote: 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. Also jhbuild has been absorbing good

Re: Canonical jhbuild documentation

, if you really want people to easily find the introductory documentation, 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

Re: Canonical jhbuild documentation

Germán Poo-Caamaño wrote: IMHO, the jhbuild documentation is more like a reference manual, whereas the information for newcomers is like a tutorial (or expected to be). Indeed it's mostly like that at the moment. Maybe both could be in the same documentation/place, but the separation

Re: Canonical jhbuild documentation

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, back in 2007/2008, I can't find an

  1   2   3   4   5   >