Olav Vitters | 30 Jul 17:12 2014

Archived git modules

The following git modules have been archived:
 - sabayon
 - nanny
 - gnome-python
 - gtk-theme-engine-clearlooks
 - drivel
 - annum
 - at-poke
 - docbook-dtds
 - pygtkglext
 - java-gobject-introspection
 - model-examples
 - j5tester
 - pyorbit
 - podsleuth
 - perl-Champlain
 - perl-Gtk2-Champlain
 - glide
 - pygoocanvas
 - hippo-canvas
 - gnome-python-desktop
 - gnome-globalmenu
 - horizon
 - pygio


Bileg Battumu | 29 Jul 16:23 2014

gnome panel applet won't compile

I was trying to compile official Hello World example of gnome applet and end up having errors.
Here is the source code:
#include <gtk/gtk.h> #include <panel-applet.h> static gboolean hello_world_applet_start (PanelApplet *applet) { GtkWidget *label; label = gtk_label_new ("Hello World"); gtk_container_add (GTK_CONTAINER (applet), label); gtk_widget_show_all (GTK_WIDGET (applet)); return TRUE; } static gboolean hello_world_factory_callback (PanelApplet *applet, const gchar *iid, gpointer data) { gboolean retval = FALSE; if (g_strcmp0 (iid, "HelloWorldApplet") == 0) retval = hello_world_applet_start (applet); return retval; } PANEL_APPLET_OUT_PROCESS_FACTORY ("HelloWorldFactory", PANEL_TYPE_APPLET, hello_world_factory_callback, NULL)

Compile command: (copied off of some guys post)
g++ -Wall -DGTK_DISABLE_SINGLE_INCLUDES -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGSEAL_ENABLE `pkg-config --cflags --libs gtk+-3.0 libpanelapplet-4.0` *.cpp -o helloworld

Error message:
/usr/include/gnome-panel-4.0/libpanel-applet/panel-applet.h:169:13: error: ‘GtkActionGroup’ has not been declared
GtkActionGroup *action_group);
/usr/include/gnome-panel-4.0/libpanel-applet/panel-applet.h:172:13: error: ‘GtkActionGroup’ has not been declared
GtkActionGroup *action_group);
/usr/include/gnome-panel-4.0/libpanel-applet/panel-applet.h:175:10: error: ‘GtkActionGroup’ has not been declared
GtkActionGroup *action_group);

desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
Release Team | 29 Jul 02:00 2014

GUADEC conference

Hello all,

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

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

Andrea Veri | 18 Jul 21:55 2014

GUADEC 2014 registration is now open!

The GUADEC organization team is happy to announce the availability of the registration form [1] for the upcoming GUADEC to be held in Strasbourg, France at Epitech, a software engineer school in the heart of the city, is glad to welcome our community and host the venue [2] for the event! This year we are going to include a list of participants to the event online at [3]. 

Once registered to the event do not forget we also provide a set of badges [4] you can use to share on your website! Let everyone know you are coming to such a great event held in one of the most beautiful cities of Europe!


The GNOME Users And Developers European Conference (GUADEC), is an annual conference taking place in Europe, whose prime topic is the development of the GNOME desktop environment which sees many participants from all over the world.



Debian Developer,
Fedora / EPEL packager,
GNOME Infrastructure Team Coordinator,
GNOME Foundation Board of Directors member,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: http://www.gnome.org/~av
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
Giovanni Campagna | 17 Jul 16:13 2014

Heads up: package.js merged in gjs master

Hi everyone

This is a heads up that I merged package.js in gjs master, and it will
be in the 3.13.4 release on Monday. The currently known users,
gnome-weather and gnome-sound-recorder, have been updated as well.

For those that don't know about it, package.js is a module aimed at
making it easier to write and develop gjs apps, without fighting the
autotools all the time or waiting to install the app.

You can see the full detailed specification of the conventions an app
must adhere to use it at https://wiki.gnome.org/Projects/Gjs/Package,
or you can just download a template app from
https://github.com/gcampax/gtk-js-app and start playing with it.

The aim is to standardize the difference between the various JS apps:
currently there is gnome-documents-style (bash launcher script, used
by gnome-documents and polari), gnome-maps-style (C binary, used by
gnome-maps and gnome-shell-extension-tool/portal-helper) and
gnome-weather-style (package.js, used by gnome-weather and
gnome-sound-recorder, and now official). One should not need to
understand bash or C to write a JS app.

It also somehow encourages a "single application ID" format, where
everything is installed with reverse DNS names, which should make the
transition to bundled/sandboxed applications easier, and is explicitly
designed around dbus activatable apps, while still allowing to develop
and test the app without even installing it once (which is something
all IDEs for other platforms get right, and we don't)

So if you have some spare time, please go ahead and take a look at it,
comments are welcome, on the specification, the implementation. And of
course integration with Anjuta or GNOME Builder (if only to set up a
working template) would be awesome.


Alexandre Franke | 14 Jul 17:43 2014

Screenshot automation BoF at GUADEC


It's 2014 and translators and documentation writers still have to
spend a lot of time to manually create screenshots. There must be a
better way. Therefore I'm planning a half-day BoF on this topic at

This is relevant to you if you're a translator or writer, but we also
hope people with experience in automated UI testing will show up to
give us a hand.

If you're thinking of attending, please add yourself to



Alexandre Franke
I18n coordinator
French translation team coordinator
Haddadi MHOUMADI | 26 Apr 23:29 2014

version issue of Ubuntu 14.04 LTS


I have found this isssue in ubuntu-gnome 14.04.

You can see that i have UBUNTU 13.10 in graphical detail, and ubuntu 14.04 LTS with the command line "cat /etc/issue"

sorry for my english (i am french)



desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
Matthias Clasen | 9 Jul 16:11 2014

Gear menu cleanup

Hi everybody,

we're trying to clean up gear menus across GNOME apps. See
for the details. Ideally, we can move away from explicitly specifying
the icon name altogether, and just use a menu button with
direction==none. Even where that is not possible, it should be a
really quick and easy fix to replace the current icon name
(emblem-system-symbolic) by the new one (open-menu-symbolic).

Thanks, Matthias
Federico Mena Quintero | 4 Jul 00:47 2014

Gnome.org's crypto infrastructure

Hi, all,

This mail is intended for brainstorming some ideas before GUADEC.  It's
not to decide anything and set it in stone.

I've been preparing my GUADEC talk about crypto infrastructure for
newbies, and I've started to realize that it may be useful for gnome.org
to have an "official", publicly-documented crypto infrastructure of its

Here is a set of somewhat related ideas:

* GNOME releases tarballs of source code.  Maintainers regularly post
checksums of their tarballs along with their announcement emails.  Until
now, I'm not sure if we have had the need to *guarantee* that a
particular release of code is authentic.  For example, we don't actually
crypto-sign tarballs like the Tor project would --- in their case,
whoever downloads the code *really* wants to ensure that it hasn't been
tampered with.  Again, I'm not sure if we have such kind of
security-conscious code, but maybe we could start crypto-signing our
tarballs.  Which brings me to...

* Identity in the GNOME project.  We have keysigning parties at GUADEC.
Some maintainers actually sign their tarball announcement emails, so if
you have their GPG public key (and if they posted a checksum of their
tarball in their email), you can actually verify whether a tarball is
pristine.  I doubt that anyone actually does this sort of checking ;)

* If we ever get an infrastructure to publish compiled "apps", what with
all the sandboxing stuff being worked on, will we need harder guarantees
about authentic binaries and code?

* Would it be useful / trustworthy to have a gnome.org-specific GPG
keyserver?  One that cannot be poisoned like public keyservers?  (I
don't really know how to do this, but if only people with SSH keys can
push to git.gnome.org, maybe we can do something similar for a

* Would app authors need certificates?  Should gnome.org be able to
issue certificates (and should we ship our Certificate Authority
information somewhere)?

* Can we have some sort of synergy with keybase.io?

* There is a public key in the keyservers for secresp <at> gnome.org, but as
far as I can tell it has no signatures.  How would people verify it?
(AFAICT it was announced here:

* Should we have a web page linking to GNOME's important public keys and
such?  (The ones you would use to encrypt reports of security bugs and

* (I know Debian has well-documented procedures for signing things and
such; I'm sure we can copy those procedures for some things.)

Again, these are just questions or ideas for now.  Any input is
appreciated.  All the (conflicting) information about crypto-related
matters out there on the web is giving me the biggest case of impostor
syndrome ever :)

Giovanni Campagna | 3 Jul 10:53 2014

Rebuild of packages with gobject introspection typelibs

Hello all,

I just landed https://bugzilla.gnome.org/show_bug.cgi?id=729662, which
introduces a new attribute in gobject-introspection typelibs that is
critical for correct memory management in language bindings.
While the bug should not affect many functions (only those that
unref/free their instance arguments), and primarily we saw crashes in
gjs caused by Gio, it is hard to determine if a library is affected or
not automatically, and therefore it would be best  if all typelibs
would be rebuilt with the new gobject-introspection, now or as soon as
a release is available.
This in particular to avoid reports against gjs or pygobject that
would be hard to debug for developers under different distros or using
jhbuild packages with the fix.


Colin Walters | 1 Jul 19:29 2014

[Continuous] Work around SSL issue with ostree admin upgrade

Hi, a notice for Continuous users:

regressed ostree in Continuous; you will see "Unacceptable TLS
certiifcate" when doing
"ostree admin upgrade".

This is the fix:

To work around it, edit
/ostree/repo/config, and change https:// to http://, do an upgrade, then
change it back, then