Emmanuele Bassi | 2 Feb 13:04 2016

Application id, XDG App, and you.

Hi all;

as you may have noticed[0] from Planet GNOME, there has been some
effort to start generating nightly XDG App bundles of various GNOME

This effort, amongst other things, allows us to see what's currently
required to get GNOME apps in a bundle.

The first hurdle has been that the concept of "application id" in
GApplication is currently too lax — or, alternatively, that the
concept of "application id" in XDG App is too strict.

Currently, GApplication will use the application id as a name on the
session bus; DBus names allow dashes in their syntax[1]. XDG App, on
the other hand, does not allow dashes in the syntax for application
id, because it will use that identifier as the base for other things,
including the base namespace for everything the app may export on the

As you can see in https://bugzilla.gnome.org/show_bug.cgi?id=761298 we
should add a warning in XDG App, and consider '-' and '_' semantically
equivalent; but it's probably easier to standardise on application ids
that use the strictest DBus syntax subset. In other words, if your app
is named:


please consider renaming it to:

(Continue reading)

Piotr Drąg | 30 Jan 19:14 2016

Adding context to strings in the shortcut windows


I really love the shortcut windows that you are introducing this
cycle, but I'm concern about translation. I would like to add a
requirement to the GNOME Goal that every translatable string in
help-overlay.ui must have the attribute context="shortcut window" (or
similar) set. This way we can differentiate the help strings from e.g.
menus and translate them accordingly.

I would be happy to add the context attribute to the already existing
shortcut windows, if you are OK with this change.

Best regards,


Piotr Drąg
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
Tristan Van Berkom | 24 Jan 11:02 2016

Re: Build sheriffs for GNOME

On Sun, 2016-01-24 at 05:18 +0100, Vamp898 wrote:
> Hi, 

Hi Shirakawa,

I see you replied off list, I am returning this to the list because it
is a good question to answer and it's rather wasteful to compose a full
reply to this and not have the benefit of it being recorded in the
archives for posterity. Also if we shake the tree on the list, maybe
something interesting will fall out :)

> I hope this mail doesn't sound too stupid (I'm not that into the
> GNOME build system). 
> Jhbuild checks out the git repository and builds them. 
> I personally would say that even master should be buildable,
> otherwise it's not of much use, or is it? 

No it does not sound stupid at all, without a deeper understanding of
how the projects inside GNOME function when they are under active
development combined with some understanding of the history of how
things were done before we had jhbuild, it is perfectly understandable
that you might think that is what jhbuild is for.

In fact, it is even possible that some people within GNOME have
presented jhbuild to you as if it were a tool you could use to always
build and "obtain" the latest master of everything, and that it should
always work, that if it did not build it was in fact a problem that
(Continue reading)

Javier Jardón | 22 Jan 02:33 2016

GNOME 3.19.4 released


GNOME 3.19.4 is out. This is a development snapshot, so use it with caution.

To compile GNOME 3.19.4, you can use the jhbuild [1] modulesets [2]
(which use the exact tarball versions from the official release).

You can also test the latest code using the vm images [3] that are
produced by our continuous integration infrastructure, build.gnome.org.

[1] http://library.gnome.org/devel/jhbuild/
[2] http://download.gnome.org/teams/releng/3.19.4/
[3] https://wiki.gnome.org/Projects/GnomeContinuous#Installation

The release notes that describe the changes between 3.19.3 and 3.19.4
are available. Go read them to learn what's new in this release:

core - http://download.gnome.org/core/3.19/3.19.4/NEWS
apps - http://download.gnome.org/apps/3.19/3.19.4/NEWS

The GNOME 3.19.4 release itself is available here:

core sources - http://download.gnome.org/core/3.19/3.19.4
apps sources - http://download.gnome.org/apps/3.19/3.19.4


This release is a snapshot of early development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
(Continue reading)

Antonio Ospite | 21 Jan 19:59 2016

libgnomekbd development


I have several patches for libgnomekbd[1], I submitted some of them to
bugzilla[2,3,4] but nobody seems to have commented on them in more
than a year.

How do I have to proceed to have them reviewed and possibly merged?
Sergey, do you still maintain libgnomekbd?


[1] https://git.gnome.org/browse/libgnomekbd/
[2] https://bugzilla.gnome.org/show_bug.cgi?id=734618
[3] https://bugzilla.gnome.org/show_bug.cgi?id=734619
[4] https://bugzilla.gnome.org/show_bug.cgi?id=734621


Antonio Ospite

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
Emmanuele Bassi | 21 Jan 15:54 2016

Build sheriffs for GNOME

Hi all;

Many of you know about GNOME Continuous, and build.gnome.org — and for
those who don't, here's two handy links:

  - https://build.gnome.org
  - https://wiki.gnome.org/Projects/GnomeContinuous

In short: we're currently building the core GNOME and some
applications every time something gets committed to git.gnome.org;
we're also doing various tests — like smoketesting the session and
running applications — and building VM images out of the build

This effort led to various benefits, including JHBuild not constantly
being in a broken state, and most projects hosted on git.gnome.org
finally building when builddir != srcdir, which should improve the
ability of maintainers to do `make distcheck` on release days.

What we need now, though, are "build sheriffs", i.e. people that watch
the build process and ensure that it continues smoothly. Ideally,
every maintainer would be on IRC, and would join the #testable
channel; sadly, that's not the case. Many are not even on
#gnome-hackers, which means they miss the notification that the
something broke the build. We cannot always send emails to the last
committer of a broken module because GNOME is a complex project, and a
change in a dependency may indeed break your project, even if you
didn't know about it.

For the past few months a few people, myself included, have been
(Continue reading)

Release Team | 15 Jan 01:00 2016

GNOME 3.19.4 unstable tarballs due

Hello all,

Tarballs are due on 2016-01-18 before 23:59 UTC for the GNOME 3.19.4
unstable release, which will be delivered on Wednesday. Modules which
were proposed for inclusion should try to follow the unstable schedule
so everyone can test them.  Please make sure that your tarballs will
be uploaded before Monday 23:59 UTC: tarballs uploaded later than that
will probably be too late to get in 3.19.4. If you are not able to
make a tarball before this deadline or if you think you'll be late,
please send a mail to the release team and we'll find someone to roll
the tarball for you!

For more information about 3.19, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.19

For a quick overview of the GNOME schedule, please see:

Automatically generated email. Source at:

devel-announce-list mailing list
devel-announce-list <at> gnome.org

(Continue reading)

Federico Mena Quintero | 8 Jan 02:55 2016

Librsvg 2.40.13 is released

Dear lovers of arrowheads pointing in the right direction,

I've just released librsvg version 2.40.13.  Librsvg is a library to
render SVG files into raster images.

In this release we got a lot of help from Menner, a Wikimedian who has
been tracking down SVG images from Wikimedia Commons that don't render
correctly with librsvg.  I'm very happy to see bugs falling down one by
one.  Hopefully Wikimedia will be able to update their version of
librsvg (they use 2.40.2 - can you believe that?) and regenerate the
faulty images.

Librsvg 2.40.13 is available here:


SHA256 checksums:


What's new in this release?

- Chun-wei Fan and Paolo Borelli fixed the Windows build.

- Menner added basic support for the "baseline-shift" attribute in
(Continue reading)

philip.chimento | 6 Jan 08:08 2016

RFC: documentation browser


I've been working on a documentation browser for documentation generated from GObject introspection files. Besides good old DevHelp on the desktop, there are several good online open-source documentation browsers that already exist, and one of them is DevDocs [1] which has lots of nifty features such as fuzzy search and storing documentation for offline use.

I have a branch of gobject-introspection [2] which modifies g-ir-doc-tool to generate docs that can then be imported by a branch of DevDocs [3]. Among the modifications to g-ir-doc-tool is a refactoring to give it an output format switch which I've already filed as bgo#750534 [4].

I've hosted an instance of the modified DevDocs on AWS [5]. This link is temporary, because at some point it'll start costing me money. I also have instructions [6] for how I set up DevDocs from a bare RHEL 7 install on AWS in case anyone wants to replicate it themselves.

If you're interested in this, please give it a try and let me know your thoughts and suggestions. I'm hoping to get more people interested in it, especially with the upcoming DX hackfest.

Currently this is just for Javascript docs. We already have decent C, Python, and Vala docs hosted elsewhere, but it wouldn't be too hard to modify this setup to include all four languages.

Philip C.

[5] http://ec2-52-32-237-163.us-west-2.compute.amazonaws.com:9292/

desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
Andre Klapper | 5 Jan 19:34 2016

Annual GNOME Bugzilla statistics for 2015

Hej hej,

a quick look at some basic GNOME Bugzilla activity in 2015.

Overall statistics:
                                2015    2014   2013
  Open reports at the end(*):   47205  46056  46130
  Opened in that year:          17481  20695  25137
  Closed in that year:          16417  20609  22120
    (*): Excludes reports marked as enhancements

The following people closed more than 500 bugs in 2015:
   988       Milan Crha
   973       Matthias Clasen
   624       Florian Müllner
   588       Sebastian Dröge
   509       Bastien Nocera
   503       Michael Catanzaro

The following people reported more than 150 bugs in 2015:
   303       Bastien Nocera
   215       Michael Catanzaro
   187       Allan Day
   167       Matthias Clasen
   161       Vineeth

The following people contributed more than 250 patches in 2015:
   402       Debarshi Ray
   306       Bastien Nocera
   299       Ray Strode
   284       Philip Withnall
   281       Carlos Garnacho
   264       Florian Müllner

The following people reviewed more than 400 patches in 2015:
  1274       Sebastian Dröge (slomo)
   822       Bastien Nocera
   731       Matthias Clasen
   527       Debarshi Ray
   445       Michael Catanzaro

Enjoy 2016!

Andre Klapper  |  ak-47 <at> gmx.net
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
Michael Catanzaro | 5 Jan 02:01 2016

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 a month, due to a small dependency bump in one library beyond the
version of the library provided by jhbuild. I guess the maintainer was
not using jhbuild, so did not notice.

Breaks like this make it very hard for new contributors to get started
with GNOME development. I'm hoping that we can soon have an automated
system for detecting jhbuild build breaks, but we're not there yet, so
in the meantime we all have a shared responsibility to make sure new
contributors can build GNOME. Well, all contributors should be able to
build GNOME... but it's hardest for new contributors when jhbuild is

* Please be careful to never bump an external dependency of your module
without checking the jhbuild modulesets to ensure the new required
version is available. Edit the jhbuild moduleset appropriately if
needed. No need to get permission for this.

* Please be careful to never add new dependencies to your module
without also editing the jhbuild moduleset appropriately. It is
*always* wrong to add or remove a dependency for your module without
making a commit to jhbuild.

* If you want to add a dependency not already in GNOME, and you're not
sure if it's reasonable to add it to the jhbuild modulesets or where to
put it, please ask the release team for help.

My vision is that by making jhbuild more reliable, we can make it much
easier to contribute to GNOME. I'm tired of hearing stories from
interns about how difficult it is to get set up.