Sébastien Wilmet | 22 May 18:06 2016
Picon

gnome-software and external plugins

Hi,

It looks like gnome-software will allow external, out-of-tree plugins:
https://blogs.gnome.org/hughsie/2016/05/19/external-plugins-in-gnome-software/

we discussed it a little on IRC on #gedit (related to libpeas).

(A discussion on a mailing list is easier than on blogs.gnome.org).

I wanted to comment with my experience on gedit. gedit allows external
plugins since a long time, probably more than a decade. I'm a relatively
young contributor to gedit, interested by the gedit core codebase
(making it more re-usable), but there is a big problem: maintaining the
gedit API. We cannot refactor the code freely without breaking the
plugins.

I think that Firefox is also struggling with its plugin system.

So, allowing external plugins looks appealing, and in the short term it
is probably not a problem. Problems arise later, when you don't have the
choice: either you need to maintain the API and it gets in the way, or
you break all third-party plugins.

My 2 cents,
Sébastien

PS: on an orthogonal matter, gnome-software doesn't use libpeas, I've
filed this bug about it:
https://bugzilla.gnome.org/show_bug.cgi?id=766775
libpeas supports in-tree and out-of-tree plugins fine.
(Continue reading)

Sebastian Geiger (Lanoxx | 20 May 14:40 2016
Picon
Picon

gnome-session logging

Hi fellow Gnome Devs,

Since my most recent system upgrade (Ubuntu 16.04, ~gnome 3.18) I got 
systemd and I noticed that _most_ gnome-session logs now endup in the 
journal rather then in ~/.xsession-errors where it used to be stored 
before (Ubuntu 14.04, ~gnome 3.10).

I generally like the move to the journal because it makes it easier to 
track what is happening on the system and I need to look at less files. 
I do have some thoughts and questions about this tough. I would be happy 
to help implement these ideas but I would first like to hear what the 
gnome (and gnome-session devs in particular) think about my toughts.

1. I said _most_ above, because there is still a tiny amout of output 
going to .xsession-errors, additionally the logs in the journal are 
filed under two different "tags", one is "gnome-session" and another is 
"gnome-session-binary". So in total there are now three ways to figure 
out what is happening in a session:

  * ~/.xsession-errors
  * journalctl SYSLOG_IDENTIFIER=gnome-session
  * journalctl SYSLOG_IDENTIFIER=gnome-session-binary

Can we somehow improve this to a) provide a single access point through 
the journal (or syslog) to get all logs from gnome-session and b) to 
allow easier filtering of logs not directly from gnome-session (see my 
next point about that)?

2. When I look at the journal meta data, I find that all application 
generated output which is all logged under the "gnome-session" tag goes 
(Continue reading)

Release Team | 20 May 02:00 2016
Picon

GNOME 3.21.2 unstable tarballs due (responsible: jjardon)

Hello all,

Tarballs are due on 2016-05-23 before 23:59 UTC for the GNOME 3.21.2
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.21.2. 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.21, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.21
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   https://wiki.gnome.org/Schedule

Thanks,
-- 
Automatically generated email. Source at:
https://git.gnome.org/browse/releng/tree/tools/schedule/automail.py
--

-- 
devel-announce-list mailing list
devel-announce-list <at> gnome.org
https://mail.gnome.org/mailman/listinfo/devel-announce-list

(Continue reading)

Frederic Peters | 12 May 20:11 2016
Picon

GNOME 3.20.2 released

Hello all,

The latest release of GNOME is here: GNOME 3.20.2.

This is the second and final release for the 3.20 branch; this update
brings many bug fixes and improvements as well as documentation and
translation updates.

For more information about the major changes in GNOME 3.20, please
visit our release notes:
  https://help.gnome.org/misc/release-notes/3.20/
and watch our release video:
  https://www.youtube.com/watch?v=JU2f_jkPRq4

Packages should shortly arrive in your distribution of choice, and if
you want to compile GNOME 3.20.2 by yourself, you can use the jhbuild
modulesets available here:
  https://download.gnome.org/teams/releng/3.20.2/

The lists of updated modules and changes are available here:
  core   -  https://download.gnome.org/core/3.20/3.20.2/NEWS
  apps   -  https://download.gnome.org/apps/3.20/3.20.2/NEWS

The source packages are available here:
  core   -  https://download.gnome.org/core/3.20/3.20.2/sources/
  apps   -  https://download.gnome.org/apps/3.20/3.20.2/sources/

Thanks for using GNOME,

        Fred
(Continue reading)

Bastien Nocera | 12 May 18:06 2016
Picon

upcoming "systemd --user" dependency in gnome-settings-daemon

Hey,

"systemd --user" has been enabled in Fedora 24 beta, which will ship
with GNOME 3.20. For GNOME 3.22, I'd like to make some changes in
gnome-settings-daemon, first in the sharing plugin, then in gnome-
settings-daemon itself.

Now
===

When I implemented the per-network sharing for UPnP/DLNA, VNC and
WebDAV services:
http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html
it was always the plan to switch to a better way of tracking the
services that gnome-settings-daemon would start.

When gnome-settings-daemon crashes, it loses track of the services it
started, and cannot stop them when it should, when switching networks.
It is a potential privacy problem.

The bug for gnome-settings-daemon is here:
https://bugzilla.gnome.org/show_bug.cgi?id=766329

The necessary changes in rygel, vino and gnome-user-share are in the
blocking bugs.

Then
====

The second part of the plan for using "systemd --user" is probably a
(Continue reading)

David Woodhouse | 12 May 10:58 2016

Re: about certificates

On Thu, 2016-05-12 at 12:47 +0530, prashant iiith wrote:
> Hi david,
>             I was trying to implement the workflow for certificates
> from files, do we have any case other than .p12  files in which
> certificate is protected by pin or passphrases.

Hi Tyagi,

I've replied on desktop-devel-list because this touches on the design
issues that I glossed over yesterday (I was *trying* to keep that mail
short, by focusing on the {file,pkcs11}-chooser requirement which comes
up twice in the overall flow)

We have a number of sources of the certs/keys we need:

 • .p12/.pfx (PKCS#12) files are password-protected, and will
   typically contain *both* the certificate and the key we need.

 • PKCS#11 modules (like gnome-keyring and other hardware and software
   tokens) can contain both certificates and keys. You may need to log
   in to a PKCS#11 token with a PIN before you can even list the 
   objects therein — including certificates, which answers your 
   question above. Or maybe you can see certs but not keys until
   you log in. Or maybe you can *see* keys but not *use* them.

 • .pem files of various kinds. These contain base64 data labelled with
   tags like '-----BEGIN PRIVATE KEY-----' and a given file can contain
   many things. Certificates in this form will be unencrypted, and won't
   need a password. Keys might (and often well) be encrypted. And might be
   in the *same* file as the cert, or might be in a different file.
(Continue reading)

David Woodhouse | 11 May 14:08 2016

Design help requested: Certificate Chooser UI.

Tyagi is working on a GSoC project this year, implementing a
certificate chooser which will probably live in the GCR library.

We currently have a variety of incomplete and buggy implementations of
this, spread across various places; especially NetworkManager UIs and
the VPN plugins. All of them get *something* wrong — not implementing
support for certain types of certificate/key file, or not supporting
PKCS#11 for access to objects in gnome-keyring and hardware crypto
tokens.

The point of the project is to have a consistent UI for choosing a
certificate (and corresponding private key), which everyone can use.

This is https://bugzilla.gnome.org/show_bug.cgi?id=679860

The "output" from such a widget would be four things:
  • Certificate location (file:… or pkcs11:…)
  • Passphrase or PIN for certificate, if necessary.
  • Key location (file:… or pkcs11:…)
  • Passphrase or PIN for private key, if necessary.

In some cases the certificate and key are found in the *same* location
(in the same file, or referenced by the same PKCS#11 URI). In some
cases there may not be a passphrase or PIN. In rare cases, you might
need different passphrase/PIN to access each of the certificate and the
key.

The overall UI flow of the certificate chooser probably ends up looking
something like...

(Continue reading)

Colin Walters | 10 May 21:10 2016
Gravatar

classic mode and wayland

Hi,

Currently GContinuous' smoketest-classic test often fails with:
http://build.gnome.org/continuous/buildmaster/builds/2016/05/10/42/smoketest-classic/work-gnome-continuous-x86_64-runtime/journal.txt

```
nautilus-classic.desktop: ** (nautilus-desktop:1030): WARNING **: Desktop icons only supported on
X11. Desktop not created
gnome-session: gnome-session-binary[682]: WARNING: App 'nautilus-classic.desktop' respawning too quickly
gnome-session-binary: WARNING: App 'nautilus-classic.desktop' respawning too quickly
gnome-session-binary: Unrecoverable failure in required component nautilus-classic.desktop
```

It seems like this started with:
https://bugzilla.gnome.org/show_bug.cgi?id=746286

But it's now a bit more fatal for reasons I haven't investigated.

Is anyone looking at classic + Wayland?  I can just disable the test for now I guess,
or perhaps we could consider a slightly-less-classic mode that just doesn't draw
desktop icons?
Release Team | 6 May 02:00 2016
Picon

GNOME 3.20.2 stable tarballs due (responsible: fredp)

Hello all,

Tarballs are due on 2016-05-09 before 23:59 UTC for the GNOME 3.20.2
stable 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.20.2. 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.21, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.21
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   https://wiki.gnome.org/Schedule

Thanks,
-- 
Automatically generated email. Source at:
https://git.gnome.org/browse/releng/tree/tools/schedule/automail.py
--

-- 
devel-announce-list mailing list
devel-announce-list <at> gnome.org
https://mail.gnome.org/mailman/listinfo/devel-announce-list

(Continue reading)

Matthias Clasen | 29 Apr 19:27 2016
Picon

GNOME 3.21.1 released

Hi GNOMEers!

development of the next GNOME release, 3.22, has started, and the
first snapshot, 3.21.1, is now available. This is a very early snapshot,
and not too much has landed yet; I expect that to change soon.

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

[1] http://library.gnome.org/devel/jhbuild/
[2] http://download.gnome.org/teams/releng/3.21.1/

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

core - http://download.gnome.org/core/3.21/3.21.1/NEWS
apps - http://download.gnome.org/apps/3.21/3.21.1/NEWS

The GNOME 3.21.1 release is available here:

core sources - http://download.gnome.org/core/3.21/3.21.1
apps sources - http://download.gnome.org/apps/3.21/3.21.1

WARNING! WARNING! WARNING!
--------------------------

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

(Continue reading)

Matthias Clasen | 26 Apr 20:56 2016
Picon

3.21.1 tarballs

A little late, but here it is: We need your latest features and bug
fixes in the form of 3.21.1 tarballs, since the 3.21 development cycle
is already underway!

Gmane