Marina Zhurakhinskaya | 27 Sep 05:48 2014

Call for OPW project ideas

Dear Foundation,

The application process for the new round of Outreach Program for Women internships has recently started,
and we are looking for people willing to mentor GNOME projects in this round. Because we only usually have a
few participants in OPW, this round we would only like to offer projects that are most strategic for GNOME.
These include, but are not limited to, projects in the area of privacy [1], developer experience, GTK+
[2], core experience, core applications [3], and web infrastructure. We would also like people to think
ahead of time how they will be able to provide excellent mentorship to the interns before, during, and
after the internship, and whether there is a larger project team the intern will be able to receive support
from. Matthias Clasen, Allan Day, and Sriram Ramkrishna hav
 e kindly agreed to be a part of a cross-team triage committee for proposed project ideas. Please add ideas
you are willing to mentor to the wiki page for the round [4] by early next week.

You are also welcome to help us spread the word about OPW by using the available sample e-mail, social
network updates, and the flyer [5]. We are especially interested in getting more college women from the
Southern Hemisphere, who will have a school summer break during most of the internship time, to apply. If
you have connections in the Southern Hemisphere, please spread the word there.

One question people might have is whether we would limit GSoC to most strategic ideas too. Google
encourages the participating organizations to act as umbrella organizations and GNOME acting as one is
one of the reasons we get so many slots for GSoC. So, in my opinion, we should continue making all projects
under the GNOME umbrella available for GSoC. We already have a triage team for GSoC that ensures that the
proposed projects are agreed-upon and feasible.


(Continue reading)

Colin Walters | 26 Sep 14:56 2014

Stricter Vala destructor name in vala git master

A heads up to all Vala codebases, please check your code for:

For now, I have tagged vala in Continuous.
Brenton Rothchild | 25 Sep 09:08 2014

Detecting builtin displays


First of all, my apologies if this has been discussed before - I nor google could find
any prior postings. This is also my first post to this list, so please let me know if there's
a more appropriate list to be posting on.

I've been looking at why gnome-settings-daemon always has an inhibitor lock for
"Multiple displays attached".

It seems in libgnome-desktop/gnome_rr.c:_gnome_rr_output_name_is_builtin_display (),
a builtin display is determined by RANDR output names, namely "lvds", "LVDS", "Lvds",
"LCD", and "eDP".

I have a laptop (Dell M4800) that reports its output for the builtin display as "DP-4",
and thus always gets reported as having a builtin display attached, leading to the inhibitor
lock being set for multiple displays attached at all times.

I noticed that output of "xrandr --properties" shows a "ConnectorType" that has a value
"Panel" instead of "DisplayPort" for my builtin display named "DP-4". 
Would that be a possibly better way to help determine what is a builtin display instead of 
relying upon the RANDR output name alone?

I'm not looking to propose any changes, rather I have a few models of Dell laptops
we use at my office that run into this and I was looking at maintaining some patches for this locally.

I'm wondering if anyone has any advice as to whether "ConnectorType" would be a good direction
to go in, or any ideas for a different direction to look.

Best Regards,
desktop-devel-list mailing list
desktop-devel-list <at>
Colin Walters | 24 Sep 21:45 2014

New list for Continuous (and celebrating 17,296 trees to date)

We have a new dedicated list for the GNOME Continuous project:

Background on Continuous:

I believe GNOME Continuous is still presently the fastest of its
scale[1] public automated continuous delivery[2] (not just CI, and not
manual packaging) of an operating system.  Let's look at the repository
statistics as of today:

$ ostree --repo=repo log gnome-continuous/buildmaster/x86_64-devel-debug
| grep commit | wc -l

Each tree is a result of one or more git commits to one of the > 300 git
repositories actively tracked by Continuous, from NetworkManager,
systemd, the Linux kernel,, and of course the many, many git
repositories that make up GNOME core and many applications.

$ ostree --repo=repo log gnome-continuous/buildmaster/x86_64-devel-debug
| tail -5
commit 0143dd0e484ee81637cf530611fb048012fc614c1369314fc631696377e043b5
Date:  2013-09-12 05:09:03 +0000


That was the first commit in the current repository; then over ~377
days, that's an average of ~45 releases a day, with very little in the
way of human intervention.  Each release is booted, tested, and
screeenshots taken.

All of these builds presently occupy 153G:

$ du -shc repo/objects
153G    repo/objects

One of the reasons I believe Continuous is so successful in fulfilling
its design goal is by default it updates without human intervention, but
we have the ability to *undo* - to un-ship when things break.  This is
radically different from the traditional model of distributions which
update manually.

At any point, if there's a bad commit to one of the input git
repositories, it's very easy for a build administrator to just revert to
a previous commit, and tell the upstream author.  When it's fixed, we
can untag.

At the moment for example, both systemd and NetworkManager have been
tagged pending resolution of issues:

If you're interested in the system as a user or developer, please feel
free to join the new list!

[1] If you know of something that approaches the scale and speed and is
delivering an OS (e.g. kernel + userspace with update system, let me
Matthias Clasen | 24 Sep 18:34 2014

GNOME 3.14 released

The GNOME Project is proud to announce the release of GNOME 3.14.

This is another exciting release for GNOME, and brings many new features
and improvements, including multitouch, captive portal support, greatly
improved sharing settings. This release also includes improved and
redesigned applications for weather, maps, PDF viewing, running VMs,
and more.

The Wayland support has matured to the point where it is ready for
day-to-day use.

For more information about the changes in GNOME 3.14, you can visit
the release notes:

GNOME 3.14 will be available shortly in many distributions. Live images
of GNOME 3.14 are available too.

These images are based on Fedora.

To try the very latest developments in GNOME, you can also use the
VM disk images that are produced by the gnome-continuous build system.

This six months' effort wouldn't have been possible without the whole
GNOME community, made of contributors and friends from all around the
world: developers, designers, documentation writers, usability and
accessibility specialists, translators, maintainers, students, system
administrators, companies, artists, testers and last, not least, users.
GNOME would not exist without all of you.

Thank you to everyone!

Our next release, GNOME 3.16, is planned for March 2015.

Until then, enjoy GNOME 3.14!

The GNOME Release Team

devel-announce-list mailing list
devel-announce-list <at>

Allan Day | 23 Sep 12:24 2014

Improving Quality

Hi all,

I believe that the key to GNOME's success is providing quality UX
straight out of the box. We've made a lot of progress in this area,
but to take it to the next level, I believe that we need to be more
rigourous and coordinated.

For the 3.15 cycle, I'd like us to try and do a better job at tracking
issues that affect the overall GNOME user experience. The basic
features of what I'm proposing:

 * At the beginning of each cycle, the Release Team draws up a list of
bugs that affect the overall user experience.

 * The list is tracked in Bugzilla, and a summary is sent to d-d-l. We
set ourselves the goal of fixing as many of the issues as we can.

 * Over the cycle, the release team regularly reviews the list of bugs
and sends an update to d-d-l, saying how many have been fixed, what
the priorities are, and so on.

This should hopefully give us greater focus, and enable us to start
tracking issues early rather than late. I also hope that it will
encourage contributions.

My idea is to use the gnome-version Bugzilla field for setting the
list of bugs. (But I don't want to get too hung up on which exact
mechanism we use.) This means that the list will eventually turn into
blocker bugs at the end of the cycle, which I think is beneficial. We
can always punt non-critical bugs to the next version if they aren't a

There are plenty of other implementation details to work out, of
course. I can provide a more detailed proposal if there is support for
the idea. Or we can just get started and figure it along the way.


Matthias Clasen | 23 Sep 00:58 2014

Some missing tarballs

Hi everybody,

here's a first view of the state of the 3.14.0 release.

When I took a first look at the modulesets, I ended up with a
relatively long list with modules that could probably do with a 3.14
tarball (I've left out stable / dormant things that haven't had
releases for years, but included everything that had 3.13.x releases).
If any of these are yours, a tarball would be very much appreciated!

Thanks, Matthias

Alberts Muktupāvels | 19 Sep 19:26 2014

End Session Dialog


question to gnome-session and gnome-shell developers about End Session dialog.

Currently gnome-session expect that End Session Dialog is available on org.gnome.Shell. Can we change it so it does not require org.gnome.Shell for that dialog?

I would suggest to change this:
#define SHELL_END_SESSION_DIALOG_PATH "/org/gnome/SessionManager/EndSessionDialog" 
#define SHELL_END_SESSION_DIALOG_INTERFACE "org.gnome.SessionManager.EndSessionDialog"
#define END_SESSION_DIALOG_NAME "org.gnome.SessionManager.EndSessionDialog"
#define END_SESSION_DIALOG_PATH "/org/gnome/SessionManager/EndSessionDialog"
#define END_SESSION_DIALOG_INTERFACE "org.gnome.SessionManager.EndSessionDialog"

I am not expecting that someone of you are going to do it. I am ready to prepare patches for gnome-session and gnome-shell for this change, but before doing it I would like to know if patches are welcome for this.


Alberts Muktupāvels
desktop-devel-list mailing list
desktop-devel-list <at>
Release Team | 19 Sep 02:00 2014

GNOME 3.14.0 newstable tarballs due (and more) (responsible: mclasen)

Hello all,

We would like to inform you about the following:
* GNOME 3.14.0 newstable tarballs due
* Hard Code Freeze ends

Tarballs are due on 2014-09-22 before 23:59 UTC for the GNOME 3.14.0
newstable 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.14.0. 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!

Hard Code Freeze ends, but other freezes remain in effect for the
stable branch.

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>

Jan Niggemann | 13 Sep 21:31 2014

Only fallback mode with kernel 3.16

Hi list,

I'm currently looking into a weird behavior with GNOME 3 starting in 
fallback mode every now and then.
I only experience this issue with the latest 3.16 kernel, I suspect an 
issue with my graphics driver.
There are no issues using 3.14.18 instead, perhaps there's less video 
RAM available when running kernel 3.16...

To debug, I need to know when, why GNOME starts in fallback mode (using 

Debian stable, 32bit, Lenovo T400
GNOME Shell 3.4.2

laptop:~$ grep Mem /var/log/Xorg.0.log
[     8.975] (--) PCI:*(0:0:2:0) 8086:2a42:17aa:20e4 rev 7, Mem  <at>  
0xf4400000/4194304, 0xd0000000/268435456, I/O  <at>  0x00001800/8
[     8.975] (--) PCI: (0:0:2:1) 8086:2a43:17aa:20e4 rev 7, Mem  <at>  

laptop:~$ lspci |grep 02\.
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series 
Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset 
Integrated Graphics Controller (rev 07)

Thank you in advance
Andre Klapper | 17 Sep 15:42 2014

GNOME 3.14 Blocker Report (week 38, what's left.)

Welcome to a last (?) round of "TODO:XXX: FIX ME TIL MONDAY!":

== gnome-contacts ==

Make the search provider work again
  Untested patch attached.

== gnome-photos ==

gnome-photos: g_str_hash(): gnome-photos killed by SIGSEGV
  Stacktrace available but no further investigation yet.

== gnome-software ==

Core dump due to the assertion failed
  Reporter provided more info via log attached.

== gnome-tweak-tool == 'version'
  Anyone willing to try/comment on the attached 10-line Python patch?
  Not sure if Tweak Tool's maintainer is still alive...

== gnome-weather ==

gnome-weather leaks information of your saved locations in cleartext
when not using the app
  Unclear if more work needs to be done here?

== mutter ==

Nautilus window becomes larger every time when opening
  Cosimo could reproduce this.

===Three more reports that might be good to fix:===

== adwaita-icon-theme ==

Spinner has ghosting artifacts (alpha issue with xcursorgen)

== gnome-photos ==

Would be nice to have a smooth sliding transition between photos
  Debarshi: Allan says this should get reverted for 3.14.

== gnome-settings-daemon ==

use IBus 1.5 api when obtain keyboard variant & option.


Andre Klapper  |  ak-47 <at>