Re: Request for comments: damned-lies feature to display release dates of extra packages

Hi, On Mon, Oct 29, 2012 at 04:00:33PM +0100, Daniel Mustieles García wrote: This is a great idea, but I have a question about this new feature: assuming that it finally gets implemented, and maintainers use it, how would translators be noticed about the release date of the module? It would

Re: Request for comments: damned-lies feature to display release dates of extra packages

On Mon, Oct 29, 2012 at 06:35:33PM +0100, Gabor Kelemen wrote: I'd like to hear if developers - those who are occasionally mailing us reminders and especially those who do not - like the idea. Let's stay with this and only this topic :). I like the idea, as far as the maintainers are aware

Re: jhbuild

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 the

Prepare the ground for the future GNOME IDE

Hi, When seeing the tentative design of the future GNOME IDE [1] (for JavaScript), it seems that Anjuta is not a good base. Anjuta is a general-purpose IDE with a completely different design. It's probably better to create a new application to focus only on JavaScript. The new application

Re: GNOME coding guidelines doc gone?

Hello, On Sun, Jun 16, 2013 at 11:33:53AM +0200, Stefan Sauer wrote: once upon a time we had http://developer.gnome.org/doc/guides/programming-guidelines/book1.html;. We link to that from the gstreamer manual as a recommended reading. Can anyone suggest a replacement? It is still available

Potential GNOME IDE

Hi, On Fri, Jan 03, 2014 at 08:02:40PM +, Michael Ikey Doherty wrote: Heh, true enough. I must admit when I saw the mockup artwork for the potential GNOME IDE I somewhat drooled. Is that project still a-go, and if so is there somewhere where I could provide a little help? There is

Re: Potential GNOME IDE

On Fri, Jan 03, 2014 at 11:01:53PM +, Michael Ikey Doherty wrote: On Fri, 2014-01-03 at 22:12 +0100, Sébastien Wilmet wrote: There is Builder, for the C language: https://github.com/chergert/gnome-builder Have it built locally. Noticed something here that I've seen in gedit too

Re: Potential GNOME IDE

On Sat, Jan 04, 2014 at 02:08:52PM +, Michael Ikey Doherty wrote: I'd personally hope they became libraries over submodules, as others may wish to reuse the components in an easier fashion. Perhaps the best thing to do on my end is to start a playground repo to test various concepts long

Re: [desktop-devel-list] Potential GNOME IDE

On Sun, Jan 05, 2014 at 04:44:31PM +0100, Sébastien Granjoux wrote: I'm one of the developer of Anjuta, so this discussion looks a bit strange. I think Anjuta is already quite mature as a GNOME IDE. It supports smart indentation, debugger, git, code completion, automatic generation of GObject

Re: [desktop-devel-list] Potential GNOME IDE

On Sun, Jan 05, 2014 at 11:51:29AM -0600, Michael Catanzaro wrote: I'm all for moving more features from gedit into gtksourceview, since that benefits all users of gtksourceview, but I'm not sure that I agree with your argument in favor of specialized text editors. Eclipse and Netbeans are

Re: [desktop-devel-list] Potential GNOME IDE

On Sun, Jan 05, 2014 at 07:31:01PM +0100, Sébastien Granjoux wrote: Le 05/01/2014 18:03, Sébastien Wilmet a écrit : Having both gedit and Anjuta is already a duplication of effort. I don't think so. You can run Anjuta with only the editor plugin to looks like a simple editor or run gedit

Re: Underlying DE for the Fedora Workstation product

On Thu, Feb 06, 2014 at 12:57:08PM -0600, Jim Campbell wrote: But if the MATE developers directed their attention to making the GNOME Classic Session all that they want it to be rather than supporting an aging, legacy codebase, I think both parties would be better off. Or convincing Xfce

About writing new apps from scratch

Hi, I think it is a waste of effort to start writing new apps from scratch, instead of improving the existing applications. To give two examples: - GNOME Music, instead of working on Rhythmbox or Banshee (or …); - GNOME Photos, instead of working on eog or Shotwell (or …). The existing

Re: About writing new apps from scratch

On Sun, Feb 16, 2014 at 05:57:09PM +, Emmanuele Bassi wrote: I hope this answers your question. Yes, partly. New apps for GNOME is a good thing, when the existing applications in the field aren't well integrated with GNOME. But for Music and Photos I think it is different. It seems that

Re: About writing new apps from scratch

On Mon, Feb 17, 2014 at 12:25:34AM +, Allan Day wrote: It's a slightly complex issue, but let me introduce some issues which might illuminate. Thanks for the replies. I'm now more convinced. Cheers, Sébastien ___ desktop-devel-list mailing list

Translating GObject properties names and descriptions

Hi again, GObject properties names and descriptions are usually translatable (and translated) for tools like gtk parasite or glade. It seems that it has always been like that. But is there a really good reason? GObject properties are targetted to the developers. All our APIs are written in

Re: Translating GObject properties names and descriptions

On Mon, Feb 17, 2014 at 07:20:19PM +, Emmanuele Bassi wrote: this blog from Stack Overflow about the introduction of their localised version in Portuguese gives a nice introduction to the issue, and some very interesting discussion points:

Re: Unreviewed patches - is the boat sinking?

Hi, On Sun, Apr 13, 2014 at 09:34:01AM +0200, Joanna Larsen wrote: Hundreds or thousands of people have taken the time to create a patch, submit it and then heard absolutely nothing back. Any free software project would crave for even this many contributions alone. There was a recent

Translation commits pushed when rolling a tarball

Hi, At some rare occasions, especially after the string freeze, translation commits are pushed when rolling a tarball for making a new release. Since the commit for the release should be pushed only when 'make distcheck' has succeeded, there can be a push conflict and the maintainer have to

Re: Translation commits pushed when rolling a tarball

On Fri, 2014-08-01 at 18:40 +0200, Kalev Lember wrote: It's not really much of a problem for me to run 'make distcheck' once more to pick up additional translation goodness. For stable releases taking the latest translations is important, but for unstable releases it's not a big deal if the

Re: Translation commits pushed when rolling a tarball

On Fri, 2014-08-01 at 11:31 +0200, Zeeshan Ali (Khattak) wrote: I don't think so but being a maintainer for years, you'll learn to do `git push origin master` first always. :) 'make distcheck' sometimes fails, for example a file which is not distributed in tarballs. Maybe GNOME Continuous

Re: Translation commits pushed when rolling a tarball

On Sat, 2014-08-02 at 09:37 +0200, Ekaterina Gerasimova wrote: Have you considered dropping an email to gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running the distcheck? I found communicating with translators to be very effective and the docs team would prefer communication

Re: Translation commits pushed when rolling a tarball

On Fri, 2014-08-01 at 17:22 +0200, Olav Vitters wrote: I think we could add something as equivalent to svn lock. It takes a bit of time to setup though, and damned lies (l10n.gnome.org) would have to be able to handle errors from git.gnome.org. If enough devs speak up I could maybe make

Re: Translation commits pushed when rolling a tarball

On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master afterwards. In GNOME we generally prefer to have a linear git history,

Re: Translation commits pushed when rolling a tarball

On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote: On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master

Re: Translation commits pushed when rolling a tarball

On Sat, 2014-08-02 at 15:38 +0100, David Woodhouse wrote: The correct thing to do when that happens is to pull, resulting in a merge commit in your tree, and then push that upstream. Merge conflicts are probably less likely to happen in GNOME thanks to the longer development cycle. In contrast

Re: Translation commits pushed when rolling a tarball

On Mon, 2014-08-04 at 12:49 +0200, Bastien Nocera wrote: Not seeing releases on the master commit list is going to confuse more than a few drive-by developers, bug squaders, and translators. It depends on what tools to use to view the commit list. With a merge commit, the release commit and tag

Re: Translation commits pushed when rolling a tarball

On Mon, 2014-08-04 at 14:25 +0200, Sébastien Wilmet wrote: On Mon, 2014-08-04 at 12:49 +0200, Bastien Nocera wrote: Not seeing releases on the master commit list is going to confuse more than a few drive-by developers, bug squaders, and translators. It depends on what tools to use to view

Visual effects

Hi, I've tried recently KDE, and by default it has too much visual effects, IMHO. With time, it seems that GNOME follows the same path, there are more and more visual effects. I think too much visual effects is bad for a distraction-free desktop. Exactly the same principle applies for

Re: Translation commits pushed when rolling a tarball

On Mon, 2014-08-04 at 15:31 +0100, David Woodhouse wrote: I'm not trying to take away your options, of which rebasing is sometimes a perfectly valid one. I'm pointing out that this thread only exists because one of the useful options (i.e. *not* rebasing) *has* been taken away. Yes, thank you

Re: git.gnome.org changes and new doap file requirements

On Wed, 2014-08-06 at 08:03 -0500, Michael Catanzaro wrote: On Sun, 2014-08-03 at 08:05 +0200, scl wrote: remote: ERROR: babl.doap is not valid: remote:doap:category property should be one of: apps,core,core-apps,deprecated,infrastructure Er, so what category does babl belong in?

Re: Proposed future for Tracker - Smaller modules

Hi, On Mon, Sep 08, 2014 at 07:30:38AM -0400, Matthias Clasen wrote: - 2^x new module-module interfaces (It's x^2 (maximum x * (x-1) more precisely), not 2^x.) -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: 3.14 Release Notes

Hello Allan, On Wed, Aug 27, 2014 at 02:08:14PM +0100, Allan Day wrote: This is a reminder that I'm still looking for details for the release notes. I need more than just a bullet for each feature - some description is essential. In the wiki I added something for GtkSourceView, now in the

Re: 3.14 Release Notes

On Mon, Sep 15, 2014 at 05:03:51PM +0200, Alexandre Franke wrote: If it's just moving things around, it doesn't change anything for translators. If it's removing something, it's less work for those that haven't translated it yet (and not a real problem if it has already been translated). Also

Re: Improving Quality

Hi, As a related matter, it seems that the GNOME Goals don't have a lot of success. https://wiki.gnome.org/Initiatives/GnomeGoals/ I think it's a nice initiative though, to have some consistency across modules. Some current goals are there since a long time. Maybe some of them are done for all

Re: new maintainer for gnome-dictionary?

On Thu, Oct 09, 2014 at 08:36:41AM -0500, Michael Catanzaro wrote: Do you want to make a 3.14.1 release this weekend [2], to pick up the translation updates and the sidebar fix? If no 3.14.0 version was released for gnome-dictionary, the version should be 3.14.0, not 3.14.1 (but it can be

Re: The GNOME Infrastructure is now powered by FreeIPA!

Hi, Thank you for the migration! On Tue, Oct 07, 2014 at 11:28:44AM +0200, Andrea Veri wrote: If you are interested in receiving or keeping using your people.gnome.org's webspace please mail accounts AT gnome DOT org stating so. Why not documenting how to access people.gnome.org on the

Re: The GNOME Infrastructure is now powered by FreeIPA!

On Sat, Oct 11, 2014 at 11:42:52AM +0200, Andrea Veri wrote: There you go. [1] The page has been added as a link at [2]. [1] https://wiki.gnome.org/AccountsTeam/AccessingPersonalWebspace [2] https://wiki.gnome.org/AccountsTeam/NewAccounts Thanks!

Re: Feedback from downstreams presentation from DX hackfest 2015

On Mon, Feb 02, 2015 at 04:51:32PM +0100, Aleksander Morgado wrote: Devhelp could also have a 'next' or 'latest' default profile which could sync the daily? built documentation from gnome.org. Although not sure how useful this could be if we setup the default jhbuild-based profile. I

Re: Discouraging use of sync APIs

On Fri, Feb 13, 2015 at 09:33:24AM +, Philip Withnall wrote: 3. Rearranging the docs to promote async functions more ? Has not been discussed - Big red warnings in the docs may just be ignored by people Anybody have any thoughts about option #3? I’m wary about filling the docs up

Re: Killing off UNCONFIRMED in Bugzilla

On Sun, Feb 15, 2015 at 11:07:50AM +0100, Sébastien Wilmet wrote: On Sat, Feb 14, 2015 at 10:12:22PM +0100, Andre Klapper wrote: On Sat, 2015-02-14 at 21:27 +0100, Sébastien Wilmet wrote: A bug triager only needs to look at UNCONFIRMED bugs. I strongly disagree with that statement

Re: Killing off UNCONFIRMED in Bugzilla

On Sat, Feb 14, 2015 at 10:12:22PM +0100, Andre Klapper wrote: On Sat, 2015-02-14 at 21:27 +0100, Sébastien Wilmet wrote: A bug triager only needs to look at UNCONFIRMED bugs. I strongly disagree with that statement. Triage takes place across the full life cycle of a report [1]. I meant

Re: Killing off UNCONFIRMED in Bugzilla

On Fri, Feb 13, 2015 at 06:20:15PM +0100, Bastien Nocera wrote: On Fri, 2015-02-13 at 18:15 +0100, Rick Opper wrote: Then how will project devs know if a bug is - as the status implies - not yet confirmed? It may be a problem with a single users unique setup, Which is still a bug, and

Re: Killing off UNCONFIRMED in Bugzilla

On Fri, Feb 13, 2015 at 06:43:35PM +0100, Sébastien Wilmet wrote: For example in gedit UNCONFIRMED means that the bug is not triaged. With NEW, you're sure that the bug exists (or existed) and should be fixed upstream. What about NEW and CONFIRMED statuses? Those are more positive than

Re: Killing off UNCONFIRMED in Bugzilla

On Sat, Feb 14, 2015 at 09:09:10PM +0100, Andre Klapper wrote: On Sat, 2015-02-14 at 19:02 +0100, Sébastien Wilmet wrote: On Fri, Feb 13, 2015 at 06:43:35PM +0100, Sébastien Wilmet wrote: For example in gedit UNCONFIRMED means that the bug is not triaged. How and to who does it actually

Re: Canonical jhbuild documentation

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.

Re: Killing off UNCONFIRMED in Bugzilla

On Fri, Feb 13, 2015 at 04:51:58PM +0100, Olav Vitters wrote: Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Please keep the UNCONFIRMED status for: gedit gtksourceview latexila ___ desktop-devel-list mailing

Re: GNOME 3.17.1 unstable release TODAY

Hi Javier, On Wed, Apr 29, 2015 at 11:48:01AM +0100, Javier Jardón wrote: Only a quick reminder that 3.17.1 is scheduled for today [1] I noticed that quite a few of modules have not been updated, so it would be great if you can upload your tarball as soon as possible if you plan to do so.

Re: Death of gnome-common

Hi, On Thu, May 28, 2015 at 12:47:47PM +0100, Philip Withnall wrote: There’s a migration guide here: https://wiki.gnome.org/Projects/GnomeCommon/Migration We’ve tried to make the transition as easy and smooth as possible, but there will inevitably be hiccups. Please let me know about

Re: Death of gnome-common

On Fri, Aug 21, 2015 at 04:18:09PM -0500, Michael Catanzaro wrote: On Sun, 2015-08-16 at 11:31 +0200, Sébastien Wilmet wrote: --install has been added to the ACLOCAL_AMFLAGS. You don't want to touch that (in Makefile.am) anymore; see: https://mail.gnome.org/archives/desktop-devel-list

Re: Death of gnome-common

On Tue, Aug 18, 2015 at 08:36:43AM +0100, Philip Withnall wrote: Do you know what's wrong? Do we need to do something about it? Just ignore the message. Added to the wiki, in the FAQ. -- Sébastien ___ desktop-devel-list mailing list

Re: Death of gnome-common

On Mon, Aug 17, 2015 at 08:06:15PM +0900, Daiki Ueno wrote: Sébastien Wilmet swil...@gnome.org writes: I've migrated GtkSourceView, and now when running autogen.sh I see those messages: + glib-gettextize --force --copy Copying file po/Makefile.in.in Please add

Re: How do you hack on GNOME? How can we do better?

On Mon, Jul 20, 2015 at 07:11:07PM -0400, Owen Taylor wrote: 4) Hacking on libraries (gtk+) 5) Hacking on applications Another minor issue is that sometimes the gvfs daemons of the system are not recent enough wrt GIO from jhbuild. So the gvfs processes need to be killed manually, to run

Re: GNOME 3.19.1 unstable tarballs due

Hi, On Mon, Oct 26, 2015 at 05:05:24PM +0100, Pierre-Yves Luyten wrote: > I will perhaps lack time to build bijiben for this release. > Sorry to discover this lately! > > Given there are no changes and this is still early in the cycle, is it > possible to skip this (in case I fail to upload

Re: Hosting gspell on gnome.org

On Sat, Oct 03, 2015 at 03:28:51PM -0500, Michael Catanzaro wrote: > I think gspell is clearly suitable for git.gnome.org, so I would go > ahead and create it. Here we go: https://git.gnome.org/browse/gspell/ ___ desktop-devel-list mailing list

Re: Integrate ITS Tool with gettext and Autotools

On Fri, Oct 09, 2015 at 09:58:34AM -0400, Shaun McCance wrote: > On Fri, 2015-10-09 at 13:16 +0200, Sébastien Wilmet wrote: > > There is a difference between: > > String to translate > > > > And: > > > > Jumping in at a random spot with a few rando

Re: Integrate ITS Tool with gettext and Autotools

On Thu, Oct 08, 2015 at 06:51:59PM +0900, Daiki Ueno wrote: > > To mark XML attributes as translatable, a common thing to do is to > > prefix them with an underscore. Intltool supports that, but not gettext > > AFAIK. If the ITS branch supports that, it would cover lots of simple > > cases. > >

Re: Integrate ITS Tool with gettext and Autotools

On Fri, Oct 09, 2015 at 11:41:59AM +0100, Emmanuele Bassi wrote: > No, not really. It's easier to see if a string is translatable if > there is an attribute called "translate" or "translatable". There is a difference between: String to translate And: For the latter, it is convenient to prefix

Tool to rename a GObject written in C?

Hi, Renaming a GObject written in C can be done with some sed substitutions, but after that the indentation is broken. Do you know a tool to rename a GObject while still keeping a good indentation and coding style? I'm interested more specifically about aligning parameters on the parenthesis

Re: Tool to rename a GObject written in C?

On Thu, Sep 10, 2015 at 10:41:20AM -0700, Germán Poo-Caamaño wrote: > Builder? AFAIK it's not present in gnome-builder, but it would be a useful feature. More generally, having higher-level refactoring tools other than what the basic Unix commands provide. > > [...] > > In any case, it should be

Re: Tool to rename a GObject written in C?

On Thu, Sep 10, 2015 at 11:00:49PM +0530, Nirbheek Chauhan wrote: > A few years ago, LWN did some coverage of a semantic > patching/indentation project for C called Coccinelle: > > http://coccinelle.lip6.fr/documentation.php > https://lwn.net/Articles/315686/ > https://lwn.net/Articles/380835/ >

Re: Tool to rename a GObject written in C?

On Thu, Sep 10, 2015 at 07:22:04PM +0200, Sébastien Wilmet wrote: > For function definitions, I've already written a script: > https://github.com/swilmet/gnome-c-utils > > For function calls, a script could be written to do the substitutions. > When the script detects that

Re: Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)

On Fri, Oct 02, 2015 at 04:48:31PM -0400, Shaun McCance wrote: > On Fri, 2015-10-02 at 19:55 +0200, Sébastien Wilmet wrote: > > So a solution is to add the generated *.pot files to Git. > > > > Is there another solution? > > This is what yelp and yelp-xsl do. They h

Hosting gspell on gnome.org

Hi, I would like to host gspell on gnome.org. gspell is a new spell checking library for GTK+ applications. The code comes from the gedit spell plugin, and is licensed under GPLv2+. gspell is currently hosted on my GitHub repository: https://github.com/swilmet/gspell gspell is already used in

Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)

Hi, On Wed, Jun 24, 2015 at 02:17:52PM +0100, Emmanuele Bassi wrote: > On 24 June 2015 at 14:13, Michael Catanzaro wrote: > > On Wed, 2015-06-24 at 08:56 +0100, Emmanuele Bassi wrote: > >> I do hope that, if you're using glib-gettext or intltool, you spend a > >> little bit

Re: FOSDEM Desktops DevRoom 2016 Call for Participation

On Tue, Dec 15, 2015 at 06:55:39PM +, Zeeshan Ali (Khattak) wrote: > Yeah I understand that but I'm wondering if they could be persuaded > not to treat all applying projects equally and give more room and time > to projects that are more popular/bigger. I didn't want to say bad of > any

Re: GNOME Games source name

On Fri, Jun 03, 2016 at 10:50:04AM -0500, Michael Catanzaro wrote: > I talked with Adrien and he doesn't want to change the name... so GNOME > Games it will continue to be. So there's probably not much point to > continued discussion here. > > I realize this is inconvenient for Debian and other

Re: Continuous Builds in GNOME

On Mon, Jun 06, 2016 at 10:10:58PM +0200, Sébastien Wilmet wrote: > There is a solution: bump the major version of Camel or EDS each time an > API or ABI break is unavoidable, making the new major version > parallel-installable with the previous ones. And that, every 6 months if > ne

Re: GNOME Games source name

On Thu, Jun 02, 2016 at 03:10:59PM +0200, Bastien Nocera wrote: > Yet this is what you're doing. If you want an application to be > renamed, you'd better make sure that you can actually come up with a > good name, and argue why it is an insurmountable problem to call the > package

Re: GNOME Games source name

On Thu, Jun 02, 2016 at 03:10:59PM +0200, Bastien Nocera wrote: > If you want an application to be > renamed, you'd better make sure that you can actually come up with a > good name, and argue why it is an insurmountable problem to call the > package "gnome-games-app" or similar in your

Re: Enabling builddir != srcdir by default in jhbuild

On Wed, Jun 01, 2016 at 01:12:08PM +0100, Emmanuele Bassi wrote: > The same thing will happen if you have a master/master-stable split, > because now people will commit to master, break it anyway, and nobody > will look at 'master-stable' because it's a completely different > workflow than what

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, May 31, 2016 at 05:01:23PM +0200, Sébastien Wilmet wrote: > There could be a master-next branch that GNOME Continuous test and > rebase/merge on top of master automatically if the build and tests > succeed. Or instead of master-next/master, having master/master-stable. O

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: [ Revised Proposal ] Continuous Builds in GNOME

On Sat, Jun 18, 2016 at 08:15:19AM +0100, Emmanuele Bassi wrote: > So, I want to stop this thread on my side because not only is making > me not want to contribute anything ever again, but it also is > absolutely pointless busy work that relies on two people architecture > astronauting without the

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: Pull request template for github mirror

On Fri, Feb 26, 2016 at 11:16:32PM +0100, Thomas H.P. Andersen wrote: > We have mirrors of git set up at github.com/gnome. Apparently developers > are mistaking these mirrors as upstream and send pull requests there. > Unless the maintainers actively keeps an eye on it these pull requests will >

Re: Including content ratings in games

On Wed, Mar 09, 2016 at 01:57:07PM +, Richard Hughes wrote: > It's probably also worth stating that I think this kind > of content rating should be informational-only, i.e. we're never going > to be stopping people installing applications. For a young child (e.g. 8), I think parental control

Installed tests - parallel installability

Hi, Currently the installed tests [1] of libraries are not parallel installable. For example the GTK+ tests are installed in: .../installed-tests/gtk+/ When GTK+ 4 will be released, it would be nice to still run the GTK+ 3 tests. Especially because GTK+ 3 will be advertised as more stable. But

Re: Installed tests - parallel installability

On Mon, Mar 14, 2016 at 02:16:21AM +0900, Tristan Van Berkom wrote: > On Sun, 2016-03-13 at 15:33 +0100, Sébastien Wilmet wrote: >   B.) Claiming that they are not parallel installable is a bit >       dramatic. > >       When GTK+-4 is released, it should install it's tests in a &

Re: Installed tests - parallel installability

On Sun, Mar 13, 2016 at 02:17:19PM -0400, Matthias Clasen wrote: > On Sun, Mar 13, 2016 at 10:33 AM, Sébastien Wilmet <swil...@gnome.org> wrote: > > Hi, > > > > Currently the installed tests [1] of libraries are not parallel > > installable. > > >

List of unmaintained modules

Hi, To follow what the GNU project does: http://www.gnu.org/server/takeaction.html#unmaint I've created a wiki page to list the unmaintained applications: https://wiki.gnome.org/Apps/Unmaintained With a link at the top of: https://wiki.gnome.org/Apps (as a reminder, every wiki page should be

Re: SVG rendering - Librsvg and Lasem

On Tue, Jun 21, 2016 at 03:41:48PM +0200, Emmanuel Pacaud wrote: > This is a message I intended to write for some times, but the Toronto > hackfest notes gives me incentives to actually send it. > > In these notes, there is a paragraph saying Benjamin seems not too happy > with librsvg. > So I

Re: Hello && About Maintainership of Gtranslator

On Wed, Feb 15, 2017 at 11:27:25PM +0300, Muhammet Kara wrote: > I have been using gtranslator for years, and I love it. Lack of updates on > gtranslator has been bugging me for quite some time, and I have decided to > take action after seeing it on the Unmaintained list.[0] > > I would like to

Equivalent of recursive make with meson/ninja?

Hi, With the Autotools, recursive make is very convenient to re-build only the stuff present in a sub-directory. And with builddir == srcdir, it's convenient to do things like: $ cd src/ $ make $ touch file-that-i-modified.c $ make To see the warnings only for the file that I modified. (see

Re: Equivalent of recursive make with meson/ninja?

On Sat, Feb 11, 2017 at 03:58:54PM +, Tim-Philipp Müller wrote: > Dunno, for me the fact that gtk-doc is so slow is extremely annoying in > my normal dev workflow, especially when it rebuilds the docs just > because I or someone else touched a source file somewhere (i.e. pretty > much

Re: Documentation for build system setup

On Thu, Feb 09, 2017 at 04:14:13PM +0100, Sebastian Geiger (Lanoxx) wrote: > I have just updated the wiki, please let me know if something I changed > is not right: > > https://wiki.gnome.org/Projects/GnomeCommon/Migration This is probably bikeshedding, but it's easier to remove lines than

Re: Equivalent of recursive make with meson/ninja?

On Sat, Feb 11, 2017 at 07:03:01PM +0530, Nirbheek Chauhan wrote: > On 11-Feb-2017 18:32, "Sébastien Wilmet" <swil...@gnome.org> wrote: > > It'll also relink all the tests and rebuild the docs (GTK-Doc is very > > slow). > > Fwiw, it won't rebuild the do

Re: Equivalent of recursive make with meson/ninja?

On Sat, Feb 11, 2017 at 11:54:40AM +, Tim-Philipp Müller wrote: > With meson/ninja, everything will end up in one single build.ninja file > (the equivalent to a Makefile). > > You'd just do > > touch foo.c > ninja In two different terminal tabs though. > and it will only recompile/relink

Re: GNOME goal candidates

On Wed, Mar 01, 2017 at 03:12:17PM -0600, Michael Catanzaro wrote: > On Wed, 2017-03-01 at 14:22 -0500, Carlos Soriano via desktop-devel- > list wrote: > > I think installed test etc it's not going to happen or be maintained > > if we don't enable coverage with it too. I think that's the actual >

Re: GNOME 3.23.91

On Thu, Mar 02, 2017 at 07:37:12AM -0500, Matthias Clasen wrote: > The release notes that describe the changes between 3.21.90 and 3.21.91 > are available. Go read them to learn what's new in this release: > > core - https://download.gnome.org/core/3.21/3.23.91/NEWS > apps -

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: > > [jhbuild] $ touch file.c > > [jhbuild] $ make >

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

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: builddir != srcdir in jhbuild breaks my workflow

On Tue, Aug 30, 2016 at 07:05:49PM +0100, Emmanuele Bassi wrote: > On 30 August 2016 at 18:23, Sébastien Wilmet <swil...@gnome.org> wrote: > > I've put the following in my jhbuildrc: > > > > checkoutroot = os.path.expanduser('~/gnome') > > buildroot = os.path.expan

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: Looking for a GNOME Calculator maintainer

On Mon, Sep 05, 2016 at 04:43:02PM +0100, Alberto Ruiz wrote: > I'm looking for someone to inherit GNOME Calculator. > > I've been trying to cope with maintenance tasks but there are more bugs > that I can handle atm and I thought I should prolly look for another > maintainer or at least a

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 the

Re: Ok to release GtkSourceView 3.24 in a few weeks?

On Mon, Oct 24, 2016 at 03:20:08PM -0500, Michael Catanzaro wrote: > On Mon, 2016-10-24 at 22:00 +0200, Sébastien Wilmet wrote: > > It is primarily new APIs replacing old ones. In one case, the new API > > is > > more powerful than the previous one, so it can be seen as a ne

Re: Ok to release GtkSourceView 3.24 in a few weeks?

On Mon, Oct 24, 2016 at 01:28:49PM -0500, Michael Catanzaro wrote: > On Mon, 2016-10-24 at 20:22 +0200, Sébastien Wilmet wrote: > > And, the master branch is now ready for GtkSourceView 3.24. The > > question > > is: when to release it? Do we do a period of freeze? There

  1   2   >