json-glib 1.5.2

[Emmanuele Bassi]

News


Overview of changes for 1.6
==
• Add getters with default fallback for JsonObject [Emmanuele Bassi]
• #26 - Clarify some expections of the json_object_get_*_member APIs [Debarshi 
Ray]
• #29 - Improve reproducibility of the build [Ravish Bhatia]
• Use json_node_unref() with g_autoptr() [Robert Ancell]
• Clarify documentation regarding programmer errors [Philip Withnall]
• Fix getting immutable root nodes from empty input [Philip Withnall]
• Fix various memory leaks [Philip Withnall, Emmanuele Bassi]
• Add `--output` option to json-glib-format [Emmanuele Bassi]
• Refresh the build [Emmanuele Bassi]
• Add glib as a fallback sub-project [Xavier Claessens]
• Don't error with MSVC C4819 warning [Seungha Yang]
• Fix nullable annotation [Niels De Graef]
• Allow disabling tests when building [Stéphane Cerveau]
• #39 - Fix default deserialization method for JsonSerializable [Jeremy 
Philippe]
• Stop string to GVariant conversion failing due to unrelated errno changes 
[Robert Ancell]
• Support loading files via memory mapping [Philip Withnall]
• #33 - Add a symbol version to all exported symbols [Simon McVittie]
• #48 - Fix build with Clang 11 [Dimitry Andric]
• Stop using deprecated g_object_newv() constructor [Emmanuele Bassi]
• Add ordered iteration to JsonObjectIter [Emmanuele Bassi]
• #46 - Document nullability of `json_from_string()` [Emmanuele Bassi]
• #45 - Properly detect multiple top-level statements [Emmanuele Bassi]
• #41, #22 - Fix library versions on Darwin [Tom Schoonjans]



Download

https://download.gnome.org/sources/json-glib/1.5/json-glib-1.5.2.tar.xz (165K)
  sha256sum: ad08438327b6106dc040c0581477bdf1cd3daaa5d285920cc768b8627f74

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.10.2

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.10/graphene-1.10.2.tar.xz (286K)
  sha256sum: e97de8208f1aac4f913d4fa71ab73a7034e807186feb2abe55876e51c425a7f6

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Emmanuele Bassi]

And approval 2/2.

Ciao,
Emmanuele.

On Mon, 2 Mar, 2020 at 09:11, Michael Catanzaro  
wrote:


Approval 1


___
release-team@gnome.org 

Release-team lurker? Do NOT participate in discussions.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

libepoxy 1.5.4

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/libepoxy/1.5/libepoxy-1.5.4.tar.xz (222K)
  sha256sum: 0bd2cc681dfeffdef739cb29913f8c3caa47a88a451fd2bc6e606c02997289d2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: New Mutter dependency: Graphene

[Emmanuele Bassi]

From my perspective, it's better to use a stable release, if one 
exists, especially for dependencies that sit outside, or on the border 
of the GNOME project itself.


Anyway, I've opened two MR against:

- jhbuild: <https://gitlab.gnome.org/GNOME/jhbuild/merge_requests/49>
- gnome-build-meta: 
<https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/420>


Ciao,
Emmanuele.

On Wed, 16 Oct, 2019 at 17:32, Georges Basile Stavracas Neto 
 wrote:

No specific reason beyong the API we depend on being added on 1.9.3.

Em qua, 16 de out de 2019 às 16:31, Emmanuele Bassi 
 escreveu:
Is there a specific reason why you're depending on an (older) 
unstable snapshot, instead of depending on Graphene 1.10.0?


Ciao,
 Emmanuele.

On Wed, 16 Oct, 2019 at 12:22, Georges Basile Stavracas Neto via 
release-team  wrote:

Greetings,

I hereby notify that Mutter will depend on a graphene >= 1.9.3 
<https://github.com/ebassi/graphene> [1] very soon. We won't depend 
on any specific build flags for graphene.


[1] <https://github.com/ebassi/graphene>


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Time to move to Discord...?

[Emmanuele Bassi]

We should definitely use to GitLab for tracking actionable items 
identified during discussion and meetings, but the discussion should 
not happen on GitLab issues.


Ciao,
Emmanuele.

On Sat, 12 Oct, 2019 at 08:47, Michael Catanzaro  
wrote:


On Sat, Oct 12, 2019 at 9:20 am, Andre Klapper > wrote:

You mean Discourse, I guess.


Er, yeah... different things :P

Using  feels a bit like a 
stretch
to me, compared to the existing  
scheme,

so might want a separate team project in Gitlab.


Yeah, a Team would be better. I think that could easily replace our 
mailing list.



Regarding getting acquainted to new infrastructure technology:
  For Gitlab I have at least found out that

allows defining mail notifications on a per-project level.
  For Discourse I have no idea how to set notifications for an r-t
channel / category / whatever it's called.


Preferences -> Notifications -> Categories

Now, I haven't actually tried this before and I don't know if the 
workflow will be satisfactory. But it *looks* like it would work.


Maybe GitLab wins regardless, though, because it's fundamentally an 
issue tracker and that's more or less how we use this mailing list.


Michael


___
release-team@gnome.org 

Release-team lurker? Do NOT participate in discussions.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: New Mutter dependency: Graphene

[Emmanuele Bassi]

Is there a specific reason why you're depending on an (older) unstable 
snapshot, instead of depending on Graphene 1.10.0?


Ciao,
Emmanuele.

On Wed, 16 Oct, 2019 at 12:22, Georges Basile Stavracas Neto via 
release-team  wrote:

Greetings,

I hereby notify that Mutter will depend on a graphene >= 1.9.3 
 [1] very soon. We won't depend 
on any specific build flags for graphene.


[1] 


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Straw man proposal: changing the versioning scheme of GNOME releases

[Emmanuele Bassi]

I've written down a straw man on Discourse:



Comments are very welcome.

Ciao,
Emmanuele.

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Maintainers should announce build-related changes in their modules

[Emmanuele Bassi]

On Fri, 13 Sep, 2019 at 10:21, Bastien Nocera  wrote:

On Fri, 2019-09-13 at 10:12 +0100, Emmanuele Bassi via desktop-devel-
list wrote:


 Not every single problem we have in building a complex project like
 GNOME can be solved by a script; if it were, we wouldn't need
 maintainers, and y'all would have been replaced by a script already.


This doesn't sound one bit nice or polite.



I apologise for the rudeness.


I'd like to apologise in advance for the time that I'll also forget to
send a mail to the release-team, or wondering why I need to tell the
release-team when I bump a dependency that's going to be shipped with
the new GNOME anyway, such as GTK or glib.


If a dependency is already in the GNOME SDK then there's no real need 
to notify us; unless, of course, the dependency in the SDK is pinned to 
a specific version, and you require a later one.


As I said in the original email, before this detour into whether humans 
can or should be automated out of their jobs, this is definitely more 
important for dependencies hosted outside of gitlab.gnome.org.


Ciao,
Emmanuele.


___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Maintainers should announce build-related changes in their modules

[Emmanuele Bassi via release-team]

On Thu, 12 Sep 2019 at 22:40, Philip Withnall 
wrote:

> On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote:
>
> On Thu, 12 Sep, 2019 at 19:08, Philip Withnall 
> wrote:
>
> That sounds like something people are going to forget to do. Would it be
> possible to use computers to automate this?
>
>
> It's software: anything is possible.
>
> As to whether we can automate this **right now**, the answer is: no.
>
> I'm not going to block on a feature that may or may not appear in Gitlab's
> enterprise edition and then may or may not be backported to the community
> edition we have. Of course, enterprising hackers are strongly encouraged to
> work on that.
>
>
> The link to the GitLab EE issue was illustrative, not definitive. If it
> solves the problem, a cronjob which polls every module’s `/meson.build` and
> `/meson_options.txt` files every 30 minutes and uses sendmail to send you
> an e-mail about changes would work.
>
>
If you're volunteering to write that script, make it work for Autotools and
CMake, then feel free.

Of course, a script polling your meson.build files doesn't help us in the
slightest when you add a dependency on libfoobar, hosted on a random
repository on GitHub, from a specific tag or branch, but only built with a
set of specific options because you rely on an optional feature.

Not every single problem we have in building a complex project like GNOME
can be solved by a script; if it were, we wouldn't need maintainers, and
y'all would have been replaced by a script already.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Maintainers should announce build-related changes in their modules

[Emmanuele Bassi via release-team]

On Thu, 12 Sep 2019 at 23:49, Michael Gratton  wrote:

> On Thu, 12 Sep, 2019 at 22:39, Philip Withnall 
> wrote:
> > On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote:
> >> On Thu, 12 Sep, 2019 at 19:08, Philip Withnall
> >>  wrote:
> >>> That sounds like something people are going to forget to do. Would
> >>> it be possible to use computers to automate this?
> >>
> >> It's software: anything is possible.
> >>
> >> As to whether we can automate this **right now**, the answer is: no.
>
> It's a shame that build deps can't be picked up automatically from the
> meson build config, where it's already specified.
>
> What about requiring modules include a buildstream config fragment with
> a well-known name in their repos, much like how DOAP files are
> required, which then gets pulled in by the release team's CI?
>

If maintainers want to be responsible for their own module's BuildStream
recipe, by all means: submit MRs to gnome-build-meta.

Adding a BuildStream recipe in your repo doesn't solve anything, though.

 1. BuildStream is an implementation detail of how we build the GNOME SDK
and releases
 2. Applications already have their own build system, a CI configuration,
and a flatpak builder manifest; adding yet another place, with a completely
different syntax and semantics where your dependencies are listed is a
recipe for maintainers just not doing this work
 3. GNOME releases are built out of gnome-build-meta; distributing the
BuildStream recipes isn't going to fix broken builds in gnome-build-meta

Let's not overengineer ourselves out of sending an email.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Maintainers should announce build-related changes in their modules

[Emmanuele Bassi]

On Thu, 12 Sep, 2019 at 19:08, Philip Withnall  
wrote:
That sounds like something people are going to forget to do. Would it 
be possible to use computers to automate this?


It's software: anything is possible.

As to whether we can automate this **right now**, the answer is: no.

I'm not going to block on a feature that may or may not appear in 
Gitlab's enterprise edition and then may or may not be backported to 
the community edition we have. Of course, enterprising hackers are 
strongly encouraged to work on that.


From my perspective, I don't think is much to ask to the community of 
GNOME maintainers to help us on the release team (and all the people 
that build GNOME components) in ensuring their projects actually build 
instead of deploying hopes and prayers to users.


Ciao,
Emmanuele.



___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Maintainers should announce build-related changes in their modules

[Emmanuele Bassi via release-team]

Hi all;

the 3.34 release is out of the door, but before we go into the 3.35 
development cycle, the release team would like to kindly ask **all** 
GNOME maintainers to send an email to release-team@gnome.org 
 (and possibly Cc: 
distributor-l...@gnome.org ) every 
time their project(s) introduce a new dependency, or update the version 
requirement of existing dependencies, or change the build options of 
their project(s).


The announcement is especially important for dependencies hosted 
outside of gitlab.gnome.org.


## How does an announcement look like?

A simple email sent to release-team@gnome.org 
 will suffice.


If you added or updated a dependency, please specify:

- the name of the dependency
- the minimum required version of the dependency
- the build options of the dependency your project requires
- the source code repository of the dependency and the branch/tag to 
be used -OR-
- the location of the release archive, possibly with the size and 
SHA256 checksum of the release


If you changed a build option:

- the name of the old and new build option
- whether it's automatically enabled or disabled based on a dependency

As a friendly notice to the downstream distributors of GNOME modules, 
you may also want to Cc: distributor-l...@gnome.org 
.


## Why is this necessary?

GNOME releases are built from [gnome-build-meta][1] recipes; if a build 
option is changed, a new dependency is introduced, or if a minimum 
requirement gets updated, the build will fail until the recipe is 
updated; and, in the case of new dependencies, until a new recipe for 
the dependency is written and tested.


Failed builds block everything:

- the CD pipeline that generates the Flatpak run times for CI
- the release pipeline
- in the future, it'll also block the build of installable VMs for 
design, QA, and user testing


This means that a broken build is going to make the life of everyone 
else in the project harder.


As builds take a lot of time to complete, it might happen that the 
breakage introduced by a new dependency will go unnoticed for a while; 
on top of that, it requires the release team to go and hunt down the 
dependencies repositories, tarballs, or release archives, and figure 
out the build options your own project depends on.


## I already have to update the CI, I might forget to send an email

It's understandable: we do have a large infrastructure, so it might 
happen that you forget something. Ideally, if you're updating your 
custom CI, you're also going to have time to send a very short email to 
a mailing list.


## Can I update gnome-build-meta myself?

Of course! Open a [new merge request][2] against gnome-build-meta, and 
the release team will be happy to review it and merge it.


## Is this mandatory?

Currently, we want to be flexible with maintainers, so this requirement 
is not going to be enforced; this is also why it's an *announcement*.


If builds keep breaking during 3.35 because of new/updated 
dependencies, the release-team might start considering something more 
binding, like pinning modules to previously released tags/versions; if 
that proves to be impossible due to module interdependencies, we might 
very well end up reverting commits in the offending module(s).


On behalf of the release team,
Emmanuele.

[1]: 
[2]: 
W: https://www.bassi.io

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[Emmanuele Bassi]

On , Abderrahim Kitouni wrote:

Le jeu. 12 sept. 2019 à 15:24,  a écrit :


On Thu, Sep 12, 2019 at 8:59 AM, Emmanuele Bassi 
wrote:
> ```
> If you change anything related to the build system:
>
>  - dependencies
>  - build options
>
> then send a message to release-team@gnome.org.
> ```

Nice, simple, LGTM.


I like this too.


Okay, reworded:



Hi all;

the 3.34 release is out of the door, but before we go into the 3.35 
development cycle, the release team would like to kindly ask **all** 
GNOME maintainers to send an email to release-team@gnome.org (and 
possibly Cc: distributor-l...@gnome.org) every time their project(s) 
introduce a new dependency, or update the version requirement of 
existing dependencies, or change the build options of their project(s).


The announcement is especially important for dependencies hosted outside 
of gitlab.gnome.org.


## How does an announcement look like?

A simple email sent to release-team@gnome.org will suffice.

If you added or updated a dependency, please specify:

 - the name of the dependency
 - the minimum required version of the dependency
 - the build options of the dependency your project requires
 - the source code repository of the dependency and the branch/tag to be 
used -OR-
 - the location of the release archive, possibly with the size and 
SHA256 checksum of the release


If you changed a build option:

 - the name of the old and new build option
 - whether it's automatically enabled or disabled depending on a 
dependency


As a friendly notice to the downstream distributors of GNOME modules, 
you may also want to Cc: distributor-l...@gnome.org.


## Why is this necessary?

GNOME releases are built from [gnome-build-meta][1] recipes; if a build 
option is changed, a new dependency is introduced, or if a minimum 
requirement gets updated, the build will fail until the recipe is 
updated; and, in the case of new dependencies, until a new recipe for 
the dependency is written and tested.


Failed builds block everything:

 - the CD pipeline that generates the Flatpak run times for CI
 - the release pipeline
 - in the future, it'll also block the build of installable VMs for 
design, QA, and user testing


This means that a broken build is going to make the life of everyone 
else in the project harder.


As builds take a lot of time to complete, it might happen that the 
breakage introduced by a new dependency will go unnoticed for a while; 
on top of that, it requires the release team to go and hunt down the 
dependencies repositories, tarballs, or release archives, and figure out 
the build options your own project depends on.


## I already have to update the CI, I might forget to send an email

It's understandable: we do have a large infrastructure, so it might 
happen that you forget something. Ideally, if you're updating your 
custom CI, you're also going to have time to send a very short email to 
a mailing list.


## Can I update gnome-build-meta myself?

Of course! Open a [new merge request][2] against gnome-build-meta, and 
the release team will be happy to review it and merge it.


## Is this mandatory?

Currently, we want to be flexible with maintainers, so this requirement 
is not going to be enforced; this is also why it's an *announcement*.


If builds keep breaking during 3.35 because of new/updated dependencies, 
the release-team might start considering something more binding, like 
pinning modules to previously released tags/versions; if that proves to 
be impossible due to module interdependencies, we might very well end up 
reverting commits in the offending module(s).


On behalf of the release-team,
 Emmanuele.

[1]: https://gitlab.gnome.org/GNOME/gnome-build-meta
[2]: https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests



Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[Emmanuele Bassi]

On , mcatanz...@gnome.org wrote:

On Wed, Sep 11, 2019 at 11:04 AM, Jordan Petridis via release-team
 wrote:

Should we extend this to tweaking/adding/removing meson options?


Good point, yes.


Mmmh, I don't want to complicate the messaging too much by conflating 
two separate contexts, unless we want to change it to something like:


```
If you change anything related to the build system:

 - dependencies
 - build options

then send a message to release-team@gnome.org.
```

Alternatively, I can send an additional request of notification for 
build options.


Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[Emmanuele Bassi]

On , mcatanz...@gnome.org wrote:
On Wed, Sep 11, 2019 at 7:48 AM, Emmanuele Bassi  
wrote:

 - the minimum required version of the dependency


Can it be optional if gnome-build-meta has the new enough version 
already?


That assumes that the maintainers will go through the gnome-build-meta 
recipes.



Or do we not trust maintainers enough for that? :P


If they don't have a minimum requirement, they can skip it; otherwise, 
maintainers are filling the minimum version in the 
meson.build/configure.ac already, so might as well tell us.


Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Announcement of new dependencies for GNOME modules

[Emmanuele Bassi]

On , Andre Klapper wrote:

On Wed, 2019-09-11 at 13:48 +0100, Emmanuele Bassi wrote:
[ This is the draft of the email I'm planning to send to 
desktop-devel,

and publish on Discourse. Feedback is very much welcome. ]


LGTM; final version should probably also be added to
https://wiki.gnome.org/MaintainersCorner etc?


Yes, that's going to be updated to include the new process.

I also have a couple more fixes in the pipeline for that wiki page, but 
those can wait.


Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Announcement of new dependencies for GNOME modules

[Emmanuele Bassi]

[ This is the draft of the email I'm planning to send to desktop-devel, 
and publish on Discourse. Feedback is very much welcome. ]


Hi all;

the 3.34 release is out of the door, but before we go into the 3.35 
development cycle, the release team would like to kindly ask **all** 
GNOME maintainers to send an email to release-team@gnome.org (and 
possibly Cc: distributor-l...@gnome.org) every time their project(s) 
introduce a new dependency, or update the version requirement. The 
announcement is especially important for dependencies hosted outside of 
gitlab.gnome.org.


## How does an announcement look like?

A simple email with:

 - the name of the dependency
 - the minimum required version of the dependency
 - the source code repository of the dependency and the branch/tag to be 
used -OR-
 - the location of the release archive, possibly with the size and 
SHA256 checksum of the release


sent to release-team@gnome.org will suffice.

As a friendly notice to the downstream distributors of GNOME modules, 
you may also want to Cc: distributor-l...@gnome.org.


## Why is this necessary?

GNOME releases are built from [gnome-build-meta][1] recipes; if a new 
dependency is introduced, or if the minimum requirement gets updated, 
the build will fail until the recipe is updated; and, in the case of new 
dependencies, until a new recipe is written and tested.


Failed builds block everything:

 - the CD pipeline that generates the Flatpak run times for CI
 - the release pipeline
 - in the future, it'll also block the build of installable VMs

This means that a broken build is going to make the life of everyone 
else in the project harder.


As builds take a lot of time to complete, it might happen that the 
breakage introduced by a new dependency will go unnoticed for a while; 
on top of that, it requires the release team to go and hunt down the 
dependencies repositories, tarballs, or release archives.


## I already have to update the CI, I might forget to send an email

It's understandable: we do have a large infrastructure, so it might 
happen that you forget something. Ideally, if you're updating your 
custom CI, you're also going to have time to send a very short email to 
a mailing list.


## Can I update gnome-build-meta myself?

Of course! Open a merge request[2] against gnome-build-meta, and the 
release team will be happy to review it and merge it.


## Is this mandatory?

Currently, we want to be flexible with maintainers, so this requirement 
is not going to be enforced; this is also why it's an *announcement*.


If builds keep breaking during 3.35 because of new/updated dependencies, 
the release-team might start considering something more binding, like 
pinning modules to previously released tags/versions; if that proves to 
be impossible due to module interdependencies, we might very well end up 
reverting commits in the offending module(s).


On behalf of the release-team,
 Emmanuele.

[1]: https://gitlab.gnome.org/GNOME/gnome-build-meta
[2]: https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze exception request: gnome-shell

[Emmanuele Bassi]

On , Carlos Garnacho wrote:

Hi!,

Here's another gnome-shell bug that might nice to have soon:
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/706

Impact is low, and tested correct, even if the related issue was not
verified fixed.


Indeed, let's avoid borking the shell by reading past NUL bytes.

Approval 1/2.

Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: freeze break request: clean up X property in at-spi2-core

[Emmanuele Bassi]

On , mcatanz...@gnome.org wrote:

On Sun, Sep 8, 2019 at 10:57 AM, Mike Gorse  wrote:

I don't
think that it would be the end of the world if this fix has to wait 
for
3.34.1, but, on the other hand, it fixes a regression introduced in 
the

3.34 cycle, so I'd lean towards committing it if people approve.


Well the purpose of the code freeze is to avoid introducing unexpected
regressions. Here we have a known regression, so it doesn't make sense
to not fix it IMO. Approval +1/2.


The fix is small, so approval 2/2.

Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.10.0

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.10/graphene-1.10.0.tar.xz (283K)
  sha256sum: 406d97f51dd4ca61e91f84666a00c3e976d3e667cd248b76d92fdb35ce876499

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Second Epiphany freeze break request

[Emmanuele Bassi]

On , mcatanz...@gnome.org wrote:
On Thu, Sep 5, 2019 at 6:14 PM, Javier Jardón  
wrote:

One approval for you


Any seconds?


I thought I sent mine, but it seems I left it in the drafts.

2/2 approval.

Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Third Epiphany freeze break request

[Emmanuele Bassi]

On , Andre Klapper wrote:

On Fri, 2019-09-06 at 08:41 -0500, mcatanz...@gnome.org wrote:

Adrian found an integer underflow that breaks the adblocker in
incognito mode:

https://gitlab.gnome.org/GNOME/epiphany/merge_requests/423/diffs

Would be great to have another freeze exception to fix this.


r-t approval 1 of 2.


And 2/2.

Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Shell freeze break request

[Emmanuele Bassi]

On , Iain Lane wrote:

I discovered this morning¹ that if you toggle mute/unmute in Shell
3.33.90 then your volume is not restored to what it was before - it's
left at 0. The reason is that Shell's volume slider responds to the
initial muting by setting itself to empty, but this also triggers the
slider's callback to update Pulseaudio with a level of 0.

(I also have noticed that when you log in to a new session then the
volume is set to 0 each time and this doesn't happen any more with this
patch, but I haven't proved that bug so this is more of an aside that
the effect might be greater than the mute/unmute case.)

We had a similar bug with the brightness slider, which Florian fixed by
blocking the signal handlers when updating the slider's value in
response to an external change (commit referenced in the below MR). The
fix here is the same -it's just that volume case was overlooked 
earlier.

It's already been pre-approved by Carlos (thanks).

  https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/703

This bug is kind of lame - I think it'd be good to fix for 3.34.


This looks like a "paper cut" issue, but the change is small and not 
very intrusive, so might as well get into 3.34.0.


I do hope we have reached the end of the gnome-shell freeze break 
requests, though.


RT approval 1/2.

Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: freeze break request: use after free in at-spi2-core

[Emmanuele Bassi]

On , mcatanz...@gnome.org wrote:

On Tue, Sep 3, 2019 at 4:04 PM, Mike Gorse  wrote:

I need to fix a use after free in at-spi2-core. Patch attached. Sorry
everyone. Carelessness on my part.


It happens, here's approval 1 / 2


And here's the 2 / 2

Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Code freeze break request

[Emmanuele Bassi]

On , mcatanz...@gnome.org wrote:

Hi,

I'd like to request code freeze break to merge this fix:

https://gitlab.gnome.org/GNOME/epiphany/merge_requests/419/diffs

It might fix (a) a bug causing various Epiphany features to break, and
(b) some UI process memory corruption. Should be very low-risk since
it's only two lines.


The change looks good to me, and seems innocuous on its own, so 1/2 RT 
approvals from me.


Ciao,
 Emmanuele.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.9.6

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.9/graphene-1.9.6.tar.xz (245K)
  sha256sum: d4ed42ba50f915b7f883d165167d9a3258b91e741b21175eaec3d654a22ce161

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.9.4

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.9/graphene-1.9.4.tar.xz (243K)
  sha256sum: a5171b2cb9fd08fe440931a850cb7c3d222b2d347c4644543c65019546e5ffad

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.9.2

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.9/graphene-1.9.2.tar.xz (126K)
  sha256sum: 2ea0566ef746d6ca4709ae9fa6a7567178516d12a6be0cd27fd8a43f714e3dbc

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.8.6

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.8/graphene-1.8.6.tar.xz (125K)
  sha256sum: 82a07f188d34eb69df4b087b5e1d66e918475f59f7e62fb0308e2c91432a712f

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String/UI Freeze Break (#2) - totem

[Emmanuele Bassi via release-team]

On Tue, 26 Feb 2019 at 15:32, Bastien Nocera  wrote:

> On Mon, 2019-02-25 at 13:52 +0100, Piotr Drąg wrote:
> > pon., 25 lut 2019 o 13:44 Bastien Nocera 
> > napisał(a):
> > > Hey,
> > >
> > > This removes some UI which isn't connected to anything anymore.
> > > There
> > > aren't any screenshots in the user documentation, and the removed
> > > paragraph would automatically be dropped from user docs
> > > translations:
> > > https://gitlab.gnome.org/GNOME/totem/merge_requests/79
> > >
> >
> > It doesn’t break the string freeze, but thanks a lot for the
> > notification!
>
> Could the release team weigh in with some feedback, please?
>

Looks very low impact, so +1 from me (r-t).

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Music freeze break request

[Emmanuele Bassi via release-team]

Thank you for the clarification; in one of the issues you linked I saw the
error screen with a GDBus blurb and I got worried. :-)

It's +1 from me (release-team).

Ciao,
 Emmanuele.

On Fri, 8 Feb 2019 at 16:43, Jean Felder  wrote:

>
>
> Le ven. 8 févr. 2019 à 12:16, Emmanuele Bassi  a écrit :
>
>> Are we really showing a GDBus error message in a landing screen aimed at
>> newcomers? Because that would be an immediate -1 from me.
>>
>
> Hi Emmanuele,
>
> This is not GDBus related. This landing screen is only visible if Tracker
> is not installed on the host system.
>
> Jean
>
>
>
>>
>> Ciao,
>>  Emmanuele.
>>
>> On Fri, 8 Feb 2019 at 11:08, Daniel Mustieles García via gnome-i18n <
>> gnome-i...@gnome.org> wrote:
>>
>>> Early in the freeze, so 1/2 from i18n.
>>>
>>> Thanks!
>>>
>>> El vie., 8 feb. 2019 a las 11:40, Jean Felder ()
>>> escribió:
>>>
>>>> Hi,
>>>>
>>>> I would like to ask for a freeze break request to introduce a new empty
>>>> view when Tracker is not available [1].
>>>> This is a long standing issue for newcomers who want to contribute to
>>>> Music using flatpak without tracker installed (for example, Tracker is not
>>>> installed by default on Ubuntu).
>>>> Without this view, these users will see an "music library not avaiable"
>>>> message, which is quite misleading.
>>>> Besides, Photos introduced a similar view [2] during this cycle. So,
>>>> this would provide some consistency between two core applications.
>>>>
>>>> This feature has not been introduced before the freeze because of some
>>>> lack of avaibility of both maintainers (Marinus Schraal and myself).
>>>> Finally, it introduces two new strings.
>>>>
>>>>
>>>> [1] https://gitlab.gnome.org/GNOME/gnome-music/merge_requests/335
>>>> [2] https://gitlab.gnome.org/GNOME/gnome-photos/merge_requests/85
>>>>
>>>> Regards,
>>>> Jean
>>>> ___
>>>> release-team@gnome.org
>>>> https://mail.gnome.org/mailman/listinfo/release-team
>>>> Release-team lurker? Do NOT participate in discussions.
>>>
>>> ___
>>> gnome-i18n mailing list
>>> gnome-i...@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>
>>
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>>
>

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Music freeze break request

[Emmanuele Bassi via release-team]

Are we really showing a GDBus error message in a landing screen aimed at
newcomers? Because that would be an immediate -1 from me.

Ciao,
 Emmanuele.

On Fri, 8 Feb 2019 at 11:08, Daniel Mustieles García via gnome-i18n <
gnome-i...@gnome.org> wrote:

> Early in the freeze, so 1/2 from i18n.
>
> Thanks!
>
> El vie., 8 feb. 2019 a las 11:40, Jean Felder ()
> escribió:
>
>> Hi,
>>
>> I would like to ask for a freeze break request to introduce a new empty
>> view when Tracker is not available [1].
>> This is a long standing issue for newcomers who want to contribute to
>> Music using flatpak without tracker installed (for example, Tracker is not
>> installed by default on Ubuntu).
>> Without this view, these users will see an "music library not avaiable"
>> message, which is quite misleading.
>> Besides, Photos introduced a similar view [2] during this cycle. So, this
>> would provide some consistency between two core applications.
>>
>> This feature has not been introduced before the freeze because of some
>> lack of avaibility of both maintainers (Marinus Schraal and myself).
>> Finally, it introduces two new strings.
>>
>>
>> [1] https://gitlab.gnome.org/GNOME/gnome-music/merge_requests/335
>> [2] https://gitlab.gnome.org/GNOME/gnome-photos/merge_requests/85
>>
>> Regards,
>> Jean
>> ___
>> release-team@gnome.org
>> https://mail.gnome.org/mailman/listinfo/release-team
>> Release-team lurker? Do NOT participate in discussions.
>
> ___
> gnome-i18n mailing list
> gnome-i...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

libepoxy 1.5.3

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/libepoxy/1.5/libepoxy-1.5.3.tar.xz (215K)
  sha256sum: 002958c5528321edd53440235d3c44e71b5b1e09b9177e8daf677450b6c4433d

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Emmanuele Bassi via release-team]

With 24 hours to go from the cut off deadline for 3.30, I don’t think this
is a good idea; this can wait for 3.30.1, and might as well use the
appropriate fix. Most distros will ship that version anyway.

Ciao,
 Emmanuele.

On Sun, 2 Sep 2018 at 17:13, verdre  wrote:

> I have an alternative solution which would be more compatible with
> changes we'll make in the future, could this one also get an approval?
>
> It's even less intrusive than the other one since there's no need to
> stop initially hiding the label.
>
> https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/215
>
> Thank you,
> verdre
>
> On 02.09.2018 02:37, mcatanz...@gnome.org wrote:
> >
> > I'll give a hesitant +1 to this one, since the change is small.
> >
> > If you consider it important enough for a 3.30.0 freeze break, rather
> > than waiting three weeks for 3.30.1, then it should also important
> > enough to backport to 3.28. It would be nice to see this fixed there too.
> >
> > Thanks for solving it,
> >
> > Michael
> >
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.
>
-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Logo Proposal for GNOME 4 (2020)

[Emmanuele Bassi via release-team]

Hi;

I honestly don't understand what this means. What's "GNOME 4"? Why "2020"?
What's "gingerblue"? What is this logo for?

Additionally, you keep "releasing" tarballs of "gingerblue" on
download.gnome.org, and every time you do, you're sending emails to the
release team; but all those releases are done every couple of (barely
functional) commits on your personal repository. There's no description of
what the project you're releasing is, or does, outside of "Gingerblue is
Free Music Software for GNOME" in your README, but you definitely should
not keep releasing things every time you add a file, or you rename it.

I don't know what you're trying to achieve, but right now you're just
spamming the GNOME infrastructure, so I'd kindly request you stop and
consider what you're doing.

Ciao,
 Emmanuele.

On Sat, 28 Jul 2018 at 19:03, Ole Aamot  wrote:

> Logo Proposal for GNOME 4 (2020)
>
> https://www.gnome.org/~ole/gingerblue-gnome-gtk-gnu.png
> https://www.gnome.org/~ole/gingerblue-gnome-gtk-gnu.svg
>
> Happy hacking,
> Ole Aamot
> ___
> gnome-announce-list mailing list
> gnome-announce-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-announce-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.8.2

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.8/graphene-1.8.2.tar.xz (124K)
  sha256sum: b3fcf20996e57b1f4df3941caac10f143bb29890a42f7a65407cd19271fc89f7

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

[gobject-introspection] Created branch gnome-3-28

[Emmanuele Bassi]

The branch 'gnome-3-28' was created pointing to:

 81c7db8... Release 1.55.2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

libepoxy 1.5.0

[Emmanuele Bassi]

ChangeLog
=

commit 28ca626eda5c331d94ad96b9e67f0b98177a9dbf
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Sat Feb 24 14:07:18 2018 +

tests: Add EGL test for Epoxy API

We have a few public entry points that we ought to test properly.

Using the EGL API is easier to set up a test case, so let's just do
that.

 test/Makefile.am |   3 ++
 test/egl_epoxy_api.c | 143 +++
 test/meson.build |   1 +
 3 files changed, 147 insertions(+)

commit e1ffd32d83d87c2bd90812f20344f253139d5c1b
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Sat Feb 24 14:03:06 2018 +

Support encoding minor versions bigger than 10

The GL version minor numbers haven't hit 10, yet, but if they do we're
going to get non-sensical encoded versions when calling
epoxy_gl_version(), like we're getting right now, with the GLSL version
numbers.

If the minor number is larger than the multiplication factor used for
the major number, we should bump up the factor to the next order of
magnitude.

 src/dispatch_common.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

commit 1489c20770f882e2cf778190269d4abab5cc018e
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Sat Feb 24 14:01:46 2018 +

meson: Use get_supported_arguments()

Instead of iterating over the list of compiler flags, we should use the
get_supported_arguments() method of the compiler object, which does it
for us — and maybe, in the future, will be optimised to do the checks in
parallel.

 meson.build | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

commit 60bb7672c10494aa6521ba3a157989cccc3490a2
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Sat Feb 24 13:39:16 2018 +

Fix epoxy_internal_gl_version()

The glGetString() function takes a GLenum, so we should too.

 src/dispatch_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 309142f2443327b9824e49b751e954f1e39db294
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Fri Feb 23 20:07:24 2018 +

ci: Update the version of Meson for Appveyor

We require a newer version than 0.39.1.

 .appveyor.yml | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

commit f6d2b1f6adce7ab86f44705889b0fafe6e91ffed
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Fri Feb 23 19:59:48 2018 +

Do not use OPENGL_LIB on Android

When building on Android we end up in the Linux branch of the symbol
loading logic, but the __ANDROID__ conditional does not have the
OPENGL_LIB symbol defined, and that breaks the build.

Closes: #152

 src/dispatch_common.c | 2 ++
 1 file changed, 2 insertions(+)

commit 158ce2bc816097adff5a9e2506b42a788b47c631
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Fri Feb 23 16:56:52 2018 +

Document epoxy_set_resolver_failure_handler()

 src/dispatch_common.c | 7 +++
 1 file changed, 7 insertions(+)

commit d8726f265e53ce6a1d5f11a1d261e2f8957f7c62
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Fri Feb 23 16:46:55 2018 +

Add epoxy_glsl_version()

Epoxy should provide a function that returns the version of the GL
shading language in use, in the same vein as it allows to get the
version of GL.

Closes: #145

 include/epoxy/gl.h|  1 +
 src/dispatch_common.c | 33 +
 2 files changed, 30 insertions(+), 4 deletions(-)

commit a7c3178f86afa016ddeed8ebbb668ec308b71122
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Fri Feb 23 15:51:56 2018 +

meson: Rename the configuration options

The `enable-` prefix is an Autotool-ism; idiomatic naming for Meson
projects should just use the name of the option, and rely on the type
to convey meaning, especially because Meson does not have `disable`
aliases that avoid the explicit `enable-foo=no` cases.

 .travis.yml   | 5 +++--
 meson.build   | 6 +++---
 meson_options.txt | 6 +++---
 3 files changed, 9 insertions(+), 8 deletions(-)

commit c794dce0a088235344851e81511c6c5a532ec36c
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Fri Feb 23 15:48:44 2018 +

docs: Update the supported GL version to 4.6

 README.md | 2 +-
 src/dispatch_common.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

commit ce8cbdbe064f5fd7f3e78b6349fa86604e6189d7
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Fri Feb 23 15:44:50 2018 +

Allow building Epoxy without X11

Epoxy can be compiled with GLX and X11 native resources on EGL. We can
disable the former, but the latter is always built in when enabling EGL
support.

Some platforms do not support X11 at all, so we need a way to disable
X11 when configuring Epoxy.

 configure.ac  | 27 +--
 meson.bu

graphene 1.8.0

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.8/graphene-1.8.0.tar.xz (124K)
  sha256sum: 7bbc8e2f183acb522e1d9fe256f5fb483ce42260bfeb3ae69320aeb649dd8d91

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.6.2

[Emmanuele Bassi]

ChangeLog
=
https://download.gnome.org/sources/graphene/1.6/graphene-1.6.2.changes  (367K)

Download

https://download.gnome.org/sources/graphene/1.6/graphene-1.6.2.tar.xz (485K)
  sha256sum: 8f7d1984c06aefe3b47a668c12ad9f3db0bcb2d09c55e6267b82a90f6b10d961

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

json-glib 1.4.2

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/json-glib/1.4/json-glib-1.4.2.tar.xz (160K)
  sha256sum: 2d7709a44749c7318599a6829322e081915bdc73f5be5045882ed120bb686dc8

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

json-glib 1.4.0

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/json-glib/1.4/json-glib-1.4.0.tar.xz (160K)
  sha256sum: 9e7d14e5a09a44fcbddf57ce8f1faa8380521639884c8252ea5866a95df37079

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

libepoxy 1.4.2

[Emmanuele Bassi]

ChangeLog
=

commit abe6a80412891cd9cfdb22a66a2b2a773fc4eb3b
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Sun Apr 30 16:36:25 2017 +0100

Release Epoxy 1.4.2

 configure.ac | 2 +-
 meson.build  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

commit 10c2cdfdb01405a983dbf3f6492134c898742892
Merge: 5b6d990 106eae7
Author: Emmanuele Bassi <eba...@gmail.com>
Date:   Mon Apr 24 16:28:06 2017 +0100

Merge pull request #118 from LocutusOfBorg/master

epoxy_internal_has_gl_extension, epoxy_egl_version: add some missing …

commit 106eae7aad23dffcefe11ec3bf86e54e35137689
Author: Gianfranco Costamagna <costamagnagianfra...@yahoo.it>
Date:   Mon Apr 24 16:10:28 2017 +0200

epoxy_internal_has_gl_extension, epoxy_egl_version: add some missing 
nullpointer checks from https://bugzilla.redhat.com/show_bug.cgi?id=1395366
Related commit: b3b8bd9af7bf1fcfe544fd131f4d4f0d117ae7bc
 Fix "epoxy_glx_version" to handle the case when GLX is not active on the 
display.
Patch is tweak from the original version posted by Tom Horsley

 src/dispatch_common.c | 9 -
 src/dispatch_egl.c| 3 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

commit 5b6d99069b3fa0d4e12ee617b144a51312bcea79
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Mar 29 18:24:25 2017 +0100

Put the no-GLX build under CI

CI is pointless if we don't test all the possible combinations.

 .travis.yml | 1 +
 1 file changed, 1 insertion(+)

commit 91b4e75c6540d85efc2dc115b7915bae7bfd8bdf
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Mar 29 18:22:37 2017 +0100

Restructure the TravisCI script

The script should only run the tests; the base Docker image pull, as
well as the CI image build, should be performed in the preparation
stage.

 .travis.yml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

commit e59cc63273f138fa7a2473dfb34dd1984d29e555
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Mar 29 18:20:18 2017 +0100

Build Epoxy with Clang on TravisCI

We can test both GCC and Clang, so we can ensure Epoxy builds correctly
with either.

 .travis.yml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

commit 3289910b9747c24aedd98f68c3bb2c1ddb27f119
Merge: 3f932ae 60b3449
Author: Emmanuele Bassi <eba...@gmail.com>
Date:   Tue Mar 28 18:15:09 2017 +0100

Merge pull request #116 from ebassi/no-source-root

Remove uses of meson.source_root()

commit 60b34493e947df86761fb8a9420fbd547a8e5e7c
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Tue Mar 28 10:18:31 2017 +0100

Bump up the version of Meson used by AppVeyor

We need a newer version to build Epoxy under CI.

 .appveyor.yml | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

commit 2dafa2f1d3c86ed36ee727994022f61eb8c697d0
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Tue Mar 28 10:08:56 2017 +0100

Move epoxy_headers definition into include/epoxy

In order to properly depend on headers, both generated and provided, in
a separate directory, we need to refer to them using their path.

Generated headers already have their full path; for provided ones, we
can simply use the `files()` directive.

This change should allow using libepoxy as a Meson subproject.

Fixes: #115

 include/epoxy/meson.build | 2 ++
 src/meson.build   | 4 
 2 files changed, 2 insertions(+), 4 deletions(-)

commit 0dfe8403dd5d84e7fc4a444e6cc471e715bd8544
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Tue Mar 28 10:06:29 2017 +0100

Remove workarounds for older Meson versions

Removing the files() statement allows us to not use source_root(), which
breaks using libepoxy as a sub-project.

Using the python3 module is better for Windows portability.

 meson.build | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

commit 9e7af6e1f568341586f6012a47199c641fb16567
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Tue Mar 28 10:05:29 2017 +0100

Bump up the required version of Meson

We are going to need a more recent version of Meson to fix some warts in
the build.

 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 3f932aeb2f635157788c9cbcda280f2ca808c725
Merge: ab10a79 c39f161
Author: Emmanuele Bassi <eba...@gmail.com>
Date:   Sun Mar 19 09:56:48 2017 +

Merge pull request #112 from accel2k/fix-msvc-build

Fix build on MSVC

commit ab10a7996ba593c6527051dca11502dd33a17f4b
Merge: f7d3671 ef1bb66
Author: Emmanuele Bassi <eba...@gmail.com>
Date:   Sun Mar 19 09:56:06 2017 +

Merge pull request #114 from Millak/master

test: Fix dlwrap on aarch64

commit ef1bb66402032c90a06beb22b444e93f0e0cf39f
Author: Efraim Flashner <efr...@flashner.co.il>
Date:   Sun Mar 19 11:01:42 2017 +0200

test: Fix dlwrap on aarc

libepoxy 1.4.1

[Emmanuele Bassi]

ChangeLog
=

commit 5564f9d28de46b2e1236dd7252549698efe66d8a
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Thu Mar 2 18:26:58 2017 +

Release Epoxy 1.4.1 (stable)

 configure.ac | 2 +-
 meson.build  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

commit bdc2668757aa21744954377067a6d1c2aea4203f
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Mar 1 20:44:07 2017 +

Remove /W3 from the MSVC compiler flags

Meson already uses /W2, like it uses -Wall with GCC.

 meson.build | 1 -
 1 file changed, 1 deletion(-)

commit 3eaddbef62ae83561417e6216cc72eeba98162f2
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Mar 1 12:36:00 2017 +

Simplify the code generation rules for Meson

The code generation rules are explicitly built for each supported API
target, but they ought to be refactored since they are pretty much
identical.

In order to do that, we can store the arguments to the custom_target
rules inside an array and then iterate over each element.

This cuts down the complexity of the Meson build, and the chances of
getting something wrong due to duplication.

 include/epoxy/meson.build |  98 +---
 src/meson.build   | 102 --
 2 files changed, 64 insertions(+), 136 deletions(-)

commit d6c4784401f613f410198926535b0462aa2dc13e
Merge: b5d921a fa7d140
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Feb 15 16:50:25 2017 +

Merge branch 'python-gen-dispatch'

commit fa7d140eb524b2f56abc9ced757ef866ff2bb99a
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Feb 15 16:48:39 2017 +

Annotate build issues with Meson

We depend on an older version of Meson; once we can bump up the minimum
version, we'll be able to fix a couple of less than optimal uses of the
Meson API.

 meson.build | 4 
 1 file changed, 4 insertions(+)

commit 877fe816a75030c5e82b1b1b72398033011afbec
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Mon Feb 13 09:33:19 2017 +

Allow using Python3 to run gen_dispatch.py

This way, we don't have to depend on Python2 on newer OSes.

 configure.ac | 2 +-
 meson.build  | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

commit 89f9aa044fbca703670cbaa037716112c7f7fefb
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Mon Feb 13 09:26:57 2017 +

Remove the shebang from gen_dispatch.py

Instead of having Meson determine the invocator through the shebang
line we explicitly pass the script file to the Python interpreter.

This will allow us to either use Python3 or Python2, or whatever
Python.exe is available on Windows.

 include/epoxy/meson.build | 4 
 meson.build   | 5 -
 src/gen_dispatch.py   | 1 -
 src/meson.build   | 4 
 4 files changed, 12 insertions(+), 2 deletions(-)

commit b5d921ae4569d39e10199e25a487bd8a23edd750
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Feb 15 14:00:28 2017 +

doc: Check for 'dot' and add the relevant configuration

We don't really use it, right now, but it may come in handy later, and
it doesn't cost us anything, since the whole thing is optional anyway.

 doc/Doxyfile.in | 43 +++
 doc/meson.build |  6 ++
 2 files changed, 45 insertions(+), 4 deletions(-)

commit 8d9636115887ce6d63ad43ebe5c775335779dc15
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Feb 15 13:59:31 2017 +

doc: Ignore C++ guard macros

We don't need Doxygen to care about those.

 doc/Doxyfile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 3bb77b799601b7b70b34088ac1ae96db8d5e3178
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Feb 15 13:58:48 2017 +

Annotate new Epoxy symbols

API added in 1.4 should be annotated as such.

 src/dispatch_egl.c | 2 ++
 src/dispatch_glx.c | 2 ++
 2 files changed, 4 insertions(+)

commit c03982bce7e4ecf953bd96a5c525eeb455efa161
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Feb 15 12:09:06 2017 +

Hide Appveyor YAML file

Like we do for the TravisCI YAML file, use the leading dot notation to
hide the Appveyor YAML file from directory listing on Unix-like OSes.

 appveyor.yml => .appveyor.yml | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

commit f1c038a54d396d554f6e67d3a88de00907076ca7
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Fri Feb 10 17:57:01 2017 +

Update the "why not GLEW" section

GLEW has grown support for OpenGL 3.2+ core contexts over the years.
Everything else has stayed pretty much the same, though, so you should
still use Epoxy over libGLEW.

 README.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

commit 176db4b655efe91996bba52c45ec717

graphene 1.6.0

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.6/graphene-1.6.0.tar.xz (411K)
  sha256sum: c3a9910f8dd298c1459d1f3c699ddf2e7440f9e561bfcbef59ae784400e27b5d

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

libepoxy 1.4.0

[Emmanuele Bassi]

ChangeLog
=
https://download.gnome.org/sources/libepoxy/1.4/libepoxy-1.4.0.changes  (150K)

Download

https://download.gnome.org/sources/libepoxy/1.4/libepoxy-1.4.0.tar.xz (750K)
  sha256sum: 25a906b14a921bc2b488cfeaa21a00486fe92630e4a9dd346e4ecabeae52ab41

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.5.4

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.5/graphene-1.5.4.tar.xz (406K)
  sha256sum: 4c1dde7375e81d36cd55c22ce0469985a946e421d239a766874ba9b7dc9981f2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.5.2

[Emmanuele Bassi]

Download

https://download.gnome.org/sources/graphene/1.5/graphene-1.5.2.tar.xz (121K)
  sha256sum: 4b2fe2c3aad43416bb520e2b3f0e1f4535b0fa722291a14904b01765afe9416f

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME 3.21.91

[Emmanuele Bassi]

Hi;

will do later tonight.

Ciao,
 Emmanuele.


On 2 September 2016 at 17:26, Michael Biebl  wrote:
> Hi
>
> 2016-09-02 1:16 GMT+02:00 Matthias Clasen :
>> Hi,
>>
>> GNOME 3.21.91 is now available. This is our second beta release on the
>
> I notice that totem 3.21.91 has a dependency on clutter-gtk 1.18.1,
> but there is no release for clutter-gtk yet.
> Can the maintainer of clutter-gtk please be poked to make a 1.18.1 release?
>
> Regards,
> Michael
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> ___
> desktop-devel-list mailing list
> desktop-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.4.0

[Emmanuele Bassi]

ChangeLog
=
https://download.gnome.org/sources/graphene/1.4/graphene-1.4.0.changes  (56.9K)

Download

https://download.gnome.org/sources/graphene/1.4/graphene-1.4.0.tar.xz (463K)
  sha256sum: 7c1ed68e7a6d1d4e804fc69b4b55ebe5a019fc5b3dfe86cd2843a27880eed6de

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Continuous and build breakage

[Emmanuele Bassi]

Hi all;

Yeah, the ping was pretty much implied - but it's harder to cope with
because I can only ping the people I know on IRC. We don't have a
strict rule matching IRC nicknames to maintainers or even projects,
and I cannot join every single IRC chat room on irc.gnome.org.

I think the ping is a "best effort"; if I can't manage to do that in
30 seconds then I'll just revert and file a bug instead.

I want to send this to desktop-devel-list and try and recruit more
people to be build sheriffs. What do you think?

Ciao,
 Emmanuele.


On 18 December 2015 at 15:04, Javier Jardón <jjar...@gnome.org> wrote:
> On 16 December 2015 at 18:29, Matthias Clasen <matthias.cla...@gmail.com> 
> wrote:
>> On Thu, Dec 10, 2015 at 1:46 PM, Emmanuele Bassi <eba...@gmail.com> wrote:
>>> Hi all;
>>>
>>> I've been meaning to discuss this with the release team for a while,
>>> and I probably already annoyed a bunch of people on IRC, so here goes.
>>>
>>> I'd like the r-t to give its blessing to volunteers that decide to act
>>> as "build sheriffs" on Continuous builds. If we exclude the issues
>>> with the build machine itself throwing a fit — something that usually
>>> gets fixed by Colin kicking it — the vast majority of build breakages
>>> come from GNOME projects issues.
>>>
>>> What usually happens when a build goes into perma-red (i.e. it keeps
>>> failing over the same component) is that somebody on the #testable IRC
>>> channel (usually me or Colin Walters) tags the module inside the
>>> Continous manifest, opens a bug, and hopes that a fix get applied and
>>> communicated on the channel so that the tag gets reverted.
>>>
>>> This is not enough, and it does not raise the bar in keeping
>>> Continuous (and thus GNOME) building. It actually lowers it a fair
>>> bit, to the effective point that *nobody* cares about Continuous
>>> builds.
>>>
>>> I want this to change. I want to be able to revert failing commits on
>>> the offending modules, if they are hosted on GNOME infrastructure, if
>>> they fail for more than N hours, and *then* open a bug about it.
>>> Ideally, I want to tag only modules that are *not* hosted on GNOME
>>> infrastructure, as they are beyond our control and commit
>>> capabilities. In short, I want to ensure that GNOME maintainers become
>>> a bit more proactive in giving a crap about their modules breaking on
>>> something that is not their own computers.
>>>
>>> This obviously will need to be discussed on d-d-l, but I'd like to get
>>> some feedback from a limited audience, and hopefully have the release
>>> team backing this initiative — especially in the hope that we can have
>>> more than one build sheriff, to cover more time zones, and avoid
>>> perma-red build failures going on for more than two or three hours,
>>> instead of half a day.
>>>
>>
>> This sounds ok to me - I think a policy of pinging the relevant
>> maintainer on irc first before reverting is a good idea (I know I
>> break things occasionally, and would appreciate a ping if I don't see
>> the breakage myself). I'd be happy to help out with this as well
>
> Sorry for the late response.
>
> I'd like to add if ping is not possible, it would be ok to me to
> revert the offending commit and send an email to the maintainer of the
> module explaining why (and probably to the author of the commit as
> well)
>
> Regards,
> Javier Jardón



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

GNOME Continuous and build breakage

[Emmanuele Bassi]

Hi all;

I've been meaning to discuss this with the release team for a while,
and I probably already annoyed a bunch of people on IRC, so here goes.

I'd like the r-t to give its blessing to volunteers that decide to act
as "build sheriffs" on Continuous builds. If we exclude the issues
with the build machine itself throwing a fit — something that usually
gets fixed by Colin kicking it — the vast majority of build breakages
come from GNOME projects issues.

What usually happens when a build goes into perma-red (i.e. it keeps
failing over the same component) is that somebody on the #testable IRC
channel (usually me or Colin Walters) tags the module inside the
Continous manifest, opens a bug, and hopes that a fix get applied and
communicated on the channel so that the tag gets reverted.

This is not enough, and it does not raise the bar in keeping
Continuous (and thus GNOME) building. It actually lowers it a fair
bit, to the effective point that *nobody* cares about Continuous
builds.

I want this to change. I want to be able to revert failing commits on
the offending modules, if they are hosted on GNOME infrastructure, if
they fail for more than N hours, and *then* open a bug about it.
Ideally, I want to tag only modules that are *not* hosted on GNOME
infrastructure, as they are beyond our control and commit
capabilities. In short, I want to ensure that GNOME maintainers become
a bit more proactive in giving a crap about their modules breaking on
something that is not their own computers.

This obviously will need to be discussed on d-d-l, but I'd like to get
some feedback from a limited audience, and hopefully have the release
team backing this initiative — especially in the hope that we can have
more than one build sheriff, to cover more time zones, and avoid
perma-red build failures going on for more than two or three hours,
instead of half a day.

[ I also have various other plans for Continuous and CI in GNOME, but
those can wait ]

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.2.8

[Emmanuele Bassi]

ChangeLog
=

commit 9b9d8a187fd7af9b81a09a7797fedb749b4e40a6
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Thu Sep 10 11:19:19 2015 +0100

Release Graphene 1.2.8 (stable)

 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

commit bed9077a4c7001d43d882673e72e7d042b960e13
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 19:37:17 2015 +0100

matrix: Go back to the simd4x4 is_2d() operator

Now that we have a working baseline, and now that the is_2d() operator
for graphene_simd4x4f_t is not affected by floating point fluctuations,
we can go back to using it.

We can leave the fuzzy comparison code in place, in case of regressions,
for ease of debugging.

 src/graphene-matrix.c | 4 
 1 file changed, 4 insertions(+)

commit bbb069f9c28dd2c5533bd58825993465a8d9a092
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 19:34:18 2015 +0100

simd4x4: Use nearbyint() to check for equality

Instead of using direct equality, we should use the nearbyintf()
function, so that any rounding errors get squashed.

 src/graphene-simd4x4f.h | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

commit c16ce27d47e0411f975be6dee3f5c9ae6825df01
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 19:28:47 2015 +0100

simd4x4: Unroll conditions for is_2d()

Split up the conditions, for readability.

 src/graphene-simd4x4f.h | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

commit 8ba7fdd0a298e24e58c954ace82c2589037f45e5
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 19:24:20 2015 +0100

tests: Check the effects of rotating a 2D matrix

Rotating a 2D matrix on the Z axis should not result in a non-affine
transformation; conversely, rotating the same matrix on the Y axis
should result in a non-affine transformation.

Let's test both assumptions.

 src/tests/matrix.c | 23 +++
 1 file changed, 23 insertions(+)

commit c5e57280d5187e653f5b38c03f39ad24a49bfe5b
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 19:22:21 2015 +0100

matrix: Unroll the is_2d() operator

The is_2d() implementation inside graphene_simd4x4f_t is susceptible to
floating point rounding errors. We can make the public wrapper API inside
graphene_matrix_t a bit more forgiving, by using the private fuzzy
comparison macro.

 src/graphene-matrix.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

commit 2d2510d0d6134dc3d40aca6094f64cbb6e25380e
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 18:58:49 2015 +0100

private: Add a fuzzy comparison macro

We use it in the test suite, but it's also useful internally.

 src/graphene-private.h | 17 +
 1 file changed, 17 insertions(+)

commit cf30a56c134d385faab35121ca6261ee9f6846d9
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 16:19:30 2015 +0100

tests: Add tests for 2D matrices

It's nicer if we ensure that this stuff does not break with every
commit.

 src/tests/matrix.c | 86 ++
 1 file changed, 86 insertions(+)

commit 02cce7babfdde8761774c72d0cd065ffbfff5654
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 15:53:55 2015 +0100

matrix: Optimize the 2D matrix conversion

Check for a valid 2D affine transformation matrix while we're reading
it, instead of before hand.

 src/graphene-matrix.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

commit 619c0ddd894cfb52c011afa86a2b9684dcb1d6c1
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 15:52:18 2015 +0100

simd4x4: Flip the boolean check

Use a boolean AND between conditions, and negate its result, instead of
a boolean OR. This allows faster short-circuiting of expensive single
channel read operations.

 src/graphene-simd4x4f.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

commit 02944f4b9d37a5df65d479b9d5ace2ac9ffb0342
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 15:51:29 2015 +0100

matrix: Fix a typo in the 2D matrix initializer

We're setting the two fields with the same value.

 src/graphene-matrix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 3842fef4a2f291b64d83a3977946b07c86ac46d6
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 11:54:00 2015 +0100

Fix spacing in the filter script

Conflicting file loading directives in Vim screwed up the tab stops.

 build/identfilter.py | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

commit ce326efc310ee056a153df4bf1555f4dbc025229
Author: Emmanuele Bassi <eba...@gnome.org>
Date:   Wed Sep 9 11:47:27 2015 +0100

build: Use an

String change in Clutter master and Cogl branching

[Emmanuele Bassi]

Hi all;

since we're in string change announcement period: I've just pushed commit:

  
https://git.gnome.org/browse/clutter/commit/?id=38e983b8e9e2b433ef6ba930dca9096958bae697

which fixes a typo in the API reference description of a property.
This kind of translation is basically invisible to the user — after
all, Clutter does not have any UI tool to inspect properties — but I
wanted to give a heads up anyway.

Still in the announcements department: I bumped up the branch of
Cogl used by Clutter for GNOME 3.18. There's no real functional
change, except for a newly added symbol which is needed to stop using
a deprecated function call when dealing with Clutter and Clutter-GTK
on nVidia machines — though I did clean up the Cogl build, to reduce
the compiler warnings. I already did a 1.21 snapshot, and I plan on
doing the 1.22 release as well.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.2.6

[Emmanuele Bassi]

ChangeLog
=

commit d0d9772290f70132341709fcc678fb1e2937e538
Author: Emmanuele Bassi eba...@gnome.org
Date:   Fri Aug 14 15:55:48 2015 +0100

 Release Graphene 1.2.6

 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

commit 0bb1baed93020c0b2f63cd40097af5058b7fbc5d
Author: Emmanuele Bassi eba...@gnome.org
Date:   Fri Aug 14 11:06:05 2015 +0100

docs: Fix clashing ids

 doc/graphene-docs.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 995c031faacf3192dab3fc0d5ff2285c8d6cf940
Author: Emmanuele Bassi eba...@gnome.org
Date:   Fri Aug 14 10:40:32 2015 +0100

build: Fix configure when gtk-doc is missing

 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit bb9cdcdf5848c8517add54e4e3f15b5202f202ba
Author: Emmanuele Bassi eba...@gnome.org
Date:   Fri Aug 14 10:36:29 2015 +0100

travis: Drop gtk-doc

It's not in the whitelist, but we don't really need it, as we can build
without gtk-doc.

 .travis.yml | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

commit 50e6645a87f26da24d06e5a283c4363ef344c7bb
Author: Emmanuele Bassi eba...@gnome.org
Date:   Fri Aug 14 10:32:28 2015 +0100

travis: Use the new infrastructure

Travis is now containerized, so we need to fix a bunch of
pre-requisites.

 .travis.yml | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

commit 7b9381a721238e0b1907af1d8f5f5656bc0e8508
Author: Emmanuele Bassi eba...@gnome.org
Date:   Fri Aug 14 10:22:00 2015 +0100

quaternion: Initialize the w component of the conjugate

When calling invert() we're leaving the w component as it is; this
cannot obviously work with uninitialized data.

This also needs fixing in the test suite, since it was relying on a
value being set to 0 by the compiler.

Solves issue: #41

 src/graphene-quaternion.c |  1 +
 src/tests/quaternion.c| 14 ++
 2 files changed, 11 insertions(+), 4 deletions(-)

commit 1f2c0e6185a926af73bf65fa751f1e78ae080aca
Author: Emmanuele Bassi eba...@gnome.org
Date:   Wed Aug 12 13:48:51 2015 +0100

docs: Mention the release notes

 README.md | 5 +
 1 file changed, 5 insertions(+)

commit 13c175cbb428158a81a5807b7c303fba053fa2b2
Author: Emmanuele Bassi eba...@gnome.org
Date:   Wed Aug 12 13:32:42 2015 +0100

Post-release version bump to 1.2.5

 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)



Download

https://download.gnome.org/sources/graphene/1.2/graphene-1.2.6.tar.xz (399K)
  sha256sum: 987a83be0b9e634805d8bb949d11422a42e627fd40f78c68c3b1ac7b3243cda2

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

graphene 1.2.4

[Emmanuele Bassi]

ChangeLog
=
https://download.gnome.org/sources/graphene/1.2/graphene-1.2.4.changes  (225K)

Download

https://download.gnome.org/sources/graphene/1.2/graphene-1.2.4.tar.xz (398K)
  sha256sum: 50791cce509bc67ffc72dad8db29c46f284fd99e1784753e612702179d1aedef

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Death of gnome-common

[Emmanuele Bassi]

Hi;

On 23 June 2015 at 23:41, Philip Withnall phi...@tecnocode.co.uk wrote:
 Hey Emmanuele, Philip

 On Tue, 2015-06-23 at 17:08 +0100, Emmanuele Bassi wrote:
 that's usually better replaced by:

 autoreconf -if || exit $?
 test -n $NOCONFIGURE  ./configure $@

 Which isn't shorter, but it's pretty much to the point and works fine
 in jhbuild and autobuilders.

 What if your module uses glib-gettext, gtk-doc, or intltool?

I do hope that, if you're using glib-gettext or intltool, you spend a
little bit of time to port to upstream gettext instead.

As for gtk-doc, yes: sadly we still need gtkdocize.

 I guess the best answer to that would be:
  • “use gettext rather than glib-gettext or intltool”; and
  • “fix gtk-doc to not need gtkdocize”[0].

 Philip (the other Philip)

 [0]: https://bugzilla.gnome.org/show_bug.cgi?id=744864

Yep. :-)

In the meantime, you can still pile on commands to the autogen.sh —
that's the reason why we have a script instead of telling people to
just run `autoreconf` directly.

Ciao,
 Emmanuele.

 On 23 June 2015 at 16:54, Philip Chimento philip.chime...@gmail.com
 wrote:
  On Mon, Jun 22, 2015 at 12:01 AM, Philip Withnall 
  phi...@tecnocode.co.uk
  wrote:
  
   On Sun, 2015-06-21 at 17:56 -0700, Jasper St. Pierre wrote:
On Thu, May 28, 2015 at 9:05 AM, Philip Withnall 
phi...@tecnocode.co.uk wrote:
 See literally the first migration item on
 https://wiki.gnome.org/Projects/GnomeCommon/Migration

 tl;dr: You can open-code it with essentially:
 aclocal --install || exit 1
 glib-gettextize --force --copy || exit 1
 gtkdocize --copy || exit 1
 intltoolize --force --copy --automake || exit 1
 autoreconf --verbose --force --install -Wno
 -portability ||
 exit
 1

 (removing the technologies which you don’t use).
   
Er, I meant to reply to this earlier, but forgot to, I guess.
Is
there
a simpler thing than this, because I still like . gnome
-autogen.sh
more. Seems much simpler.
  
   There is not. You are welcome to continue using gnome-autogen.sh
   if you
   want to keep a dependency around purely for a build-time shell
   script.
   Or you could copy gnome-autogen.sh into your project. We are
   planning
   no further changes to gnome-autogen.sh upstream.
  
   Note that using gnome-autogen.sh isn’t actually as simple as
   that;
   you’re supposed to set various environment variables indicating
   your
   dependencies. So a realistic invocation is more like:
  
   #!/bin/sh
   srcdir=`dirname $0`
   test -z $srcdir  srcdir=.
  
   PKG_NAME=libgdata
  
   (test -f $srcdir/configure.ac) || {
   echo **Error**: Directory \`$srcdir\' does not look
   like the
   top-level $PKG_NAME directory
   exit 1
   }
  
   which gnome-autogen.sh || {
   echo You need to install gnome-common from GNOME
   Git
   exit 1
   }
  
   REQUIRED_PKG_CONFIG_VERSION=0.17.1
   REQUIRED_AUTOMAKE_VERSION=1.13
   REQUIRED_GTK_DOC_VERSION=1.14 . gnome-autogen.sh $@
 
 
  In fact for most projects you can probably just replace . gnome
  -autogen.sh
  with autoreconf -if. It's fewer keystrokes ;-)
 
  Or autoreconf -if  ./configure $@ if you want to retain the
  behaviour of
  automatically running configure (which I would prefer not to do, if
  only
  jhbuild didn't rely on it.)
 
  Philip C.
 
 On Thu, 2015-05-28 at 08:43 -0700, Jasper St. Pierre wrote:
  What about the gnome-autogen.sh script? Most of my
  autogen.sh
  files
  just run . gnome-autogen.sh
 
  On Thu, May 28, 2015 at 6:55 AM, Daniel Mustieles García
  daniel.mustie...@gmail.com wrote:
   Ok, thanks for clarifying! :)
  
   2015-05-28 14:40 GMT+02:00 Philip Withnall 
   phi...@tecnocode.co.uk:
   
It’s already sort of tracked as part of the
ModernAutotools
goal,
although that one lost momentum a while ago, so its
status
needs to be
reset:
   
https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAut
otools
   
However, since there’s no flag-day-changeover for gnome
-common, I’m not
sure it’s necessary to have a GNOME Goal. Maintainers
hate
touching
build systems unnecessarily.
   
Philip
   
On Thu, 2015-05-28 at 14:03 +0200, Daniel Mustieles
García
wrote:
 Would this make sense to create a GNOME Goal[1] to
 ease/track the
 change?

 [1]

 https://wiki.gnome.org/action/show/Initiatives/GnomeG
 oals?a
 ction=showredirect=GnomeGoals


 2015-05-28 13:47 GMT+02:00 Philip Withnall 
 phi...@tecnocode.co.uk:
 Hi all,

 This cycle, Dave and I are planning for the
 last

Re: Death of gnome-common

[Emmanuele Bassi]

Hi Philip;

that's usually better replaced by:

autoreconf -if || exit $?
test -n $NOCONFIGURE  ./configure $@

Which isn't shorter, but it's pretty much to the point and works fine
in jhbuild and autobuilders.

Ciao,
 Emmanuele.


On 23 June 2015 at 16:54, Philip Chimento philip.chime...@gmail.com wrote:
 On Mon, Jun 22, 2015 at 12:01 AM, Philip Withnall phi...@tecnocode.co.uk
 wrote:

 On Sun, 2015-06-21 at 17:56 -0700, Jasper St. Pierre wrote:
  On Thu, May 28, 2015 at 9:05 AM, Philip Withnall 
  phi...@tecnocode.co.uk wrote:
   See literally the first migration item on
   https://wiki.gnome.org/Projects/GnomeCommon/Migration
  
   tl;dr: You can open-code it with essentially:
   aclocal --install || exit 1
   glib-gettextize --force --copy || exit 1
   gtkdocize --copy || exit 1
   intltoolize --force --copy --automake || exit 1
   autoreconf --verbose --force --install -Wno-portability ||
   exit
   1
  
   (removing the technologies which you don’t use).
 
  Er, I meant to reply to this earlier, but forgot to, I guess. Is
  there
  a simpler thing than this, because I still like . gnome-autogen.sh
  more. Seems much simpler.

 There is not. You are welcome to continue using gnome-autogen.sh if you
 want to keep a dependency around purely for a build-time shell script.
 Or you could copy gnome-autogen.sh into your project. We are planning
 no further changes to gnome-autogen.sh upstream.

 Note that using gnome-autogen.sh isn’t actually as simple as that;
 you’re supposed to set various environment variables indicating your
 dependencies. So a realistic invocation is more like:

 #!/bin/sh
 srcdir=`dirname $0`
 test -z $srcdir  srcdir=.

 PKG_NAME=libgdata

 (test -f $srcdir/configure.ac) || {
 echo **Error**: Directory \`$srcdir\' does not look like the
 top-level $PKG_NAME directory
 exit 1
 }

 which gnome-autogen.sh || {
 echo You need to install gnome-common from GNOME Git
 exit 1
 }

 REQUIRED_PKG_CONFIG_VERSION=0.17.1 REQUIRED_AUTOMAKE_VERSION=1.13
 REQUIRED_GTK_DOC_VERSION=1.14 . gnome-autogen.sh $@


 In fact for most projects you can probably just replace . gnome-autogen.sh
 with autoreconf -if. It's fewer keystrokes ;-)

 Or autoreconf -if  ./configure $@ if you want to retain the behaviour of
 automatically running configure (which I would prefer not to do, if only
 jhbuild didn't rely on it.)

 Philip C.

   On Thu, 2015-05-28 at 08:43 -0700, Jasper St. Pierre wrote:
What about the gnome-autogen.sh script? Most of my autogen.sh
files
just run . gnome-autogen.sh
   
On Thu, May 28, 2015 at 6:55 AM, Daniel Mustieles García
daniel.mustie...@gmail.com wrote:
 Ok, thanks for clarifying! :)

 2015-05-28 14:40 GMT+02:00 Philip Withnall 
 phi...@tecnocode.co.uk:
 
  It’s already sort of tracked as part of the ModernAutotools
  goal,
  although that one lost momentum a while ago, so its status
  needs to be
  reset:
 
  https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAutotools
 
  However, since there’s no flag-day-changeover for gnome
  -common, I’m not
  sure it’s necessary to have a GNOME Goal. Maintainers hate
  touching
  build systems unnecessarily.
 
  Philip
 
  On Thu, 2015-05-28 at 14:03 +0200, Daniel Mustieles García
  wrote:
   Would this make sense to create a GNOME Goal[1] to
   ease/track the
   change?
  
   [1]
  
   https://wiki.gnome.org/action/show/Initiatives/GnomeGoals?a
   ction=showredirect=GnomeGoals
  
  
   2015-05-28 13:47 GMT+02:00 Philip Withnall 
   phi...@tecnocode.co.uk:
   Hi all,
  
   This cycle, Dave and I are planning for the last
   ever release
   of
   gnome-common. A lot of its macros for deprecated
   technologies
   (scrollkeeper?!) have been removed, and the
   remainder of its
   macros have
   found better replacements in autoconf-archive[1],
   where they
   can be used
   by everyone, not just GNOME.
  
   We plan to make one last release, and people are
   welcome to
   depend on it
   for as long as they like. However, if you want new
   hotness,
   port to the
   autoconf-archive versions of the macros; but please
   do it in
   your own
   time. There will be no flag day port away from
   gnome-common.
  
   Note that, for example, porting to
   AX_COMPILER_FLAGS is
   valuable, but
   will probably require fixing a number of new
   compiler warnings
   in your
   code due to increased warning flags. We hope this
   will make
   your code
  

[gnome-dictionary] Created branch gnome-3-16

[Emmanuele Bassi]

The branch 'gnome-3-16' was created pointing to:

 5f01dbe... app: Remove compilation warnings

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Clutter branched for GNOME 3.16

[Emmanuele Bassi]

Hi all;

I've pushed the clutter-1.22 branch to the git.gnome.org repository.
This branch will be used for GNOME 3.16 releases. The master branch is
open for GNOME 3.18.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: possible changes in gtk translations

[Emmanuele Bassi]

Hi;

On 2 March 2015 at 19:55, Claude Paroz cla...@2xlibre.net wrote:
 Le lundi 02 mars 2015 à 08:13 -0500, Matthias Clasen a écrit :
 On Fri, Feb 27, 2015 at 5:43 PM, Piotr Drąg piotrd...@gmail.com wrote:

 
  Right, it doesn't work with intltool. Claude, can damned-lies be made to
  generate gtk+'s pot file using make?

 Any update on this ? I don't want to ship GTK+ with incomplete
 translations, but I would hate to be shackled to a hack because you're
 using different tools...

 I'm afraid it's not possible currently. Damned Lies doesn't build
 modules. If the pot file needs a custom script to create it, the script
 should be runnable as is after a checkout, it cannot require a build.

This should not require a full build:

make -C po gtk30.pot

But it will require an autogen/configure pass first.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String break request for GNOME Dictionary

[Emmanuele Bassi]

Hi Piotr;

On 23 February 2015 at 15:25, Piotr Drąg piotrd...@gmail.com wrote:
 2015-02-23 16:19 GMT+01:00 Emmanuele Bassi eba...@gmail.com:
 Hi all;

 I have opened bug https://bugzilla.gnome.org/show_bug.cgi?id=745022
 which aims at dropping deprecated API from the Dictionary application.

 The changes include dropping stock labels, which means introducing our
 own strings — which is actually good, because finally it allows us to
 avoid long standing collisions in the buttons mnemonic in various
 dialog boxes.

 The rest of the changes do not influence the UI or the documentation.

 I apologize for the lateness of the request.


 Hi Emmanuele,

 We're still only in the string change announcement period, so let's
 say you just announced it. :)

Thanks; that'll teach me to double check the calendar. :-)

Ciao,
 Emmanuele.


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

String break request for GNOME Dictionary

[Emmanuele Bassi]

Hi all;

I have opened bug https://bugzilla.gnome.org/show_bug.cgi?id=745022
which aims at dropping deprecated API from the Dictionary application.

The changes include dropping stock labels, which means introducing our
own strings — which is actually good, because finally it allows us to
avoid long standing collisions in the buttons mnemonic in various
dialog boxes.

The rest of the changes do not influence the UI or the documentation.

I apologize for the lateness of the request.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Change in the Clutter Git repository

[Emmanuele Bassi]

hi all;

sorry for the cross-posting, but I wanted to notify all the relevant
stakeholders of this.

for the past couple of years, Clutter has been developed off of a
topic branch, while master has been reserved to the development of the
API-incompatible 2.0 series.

since the 2.0 series will likely not happen, and given the confusion
that the layout of the repository induced in new contributors, I
decided to do some surgery on the Git repository.

starting now, Clutter will follow the classic model of development
happens in master, stable releases are done from topic branches.

the clutter-1.22 branch has been merged into the master branch.

the clutter-1.22 branch will be left alone, until 1.22.0 is released,
at which point it all changes between now and the 1.22 branch point
will be merged back into the clutter-1.22 branch.

given that all the changes on the master branch were either commits in
preparation for 2.0, or cherry picks from clutter-1.* branches, I
opted to just revert them all.

since I only used reverts and merges, there aren't any forced pulls.

I'm going to change jhbuild and gnome-continuous to pull from master
for the current development cycle, as soon as I've thoroughly tested
the change.

ciao,
 Emmanuele.

-- 
http://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

string freeze break request for epiphany

[Emmanuele Bassi]

hi all;

I filed this bug[0] for epiphany to update the incognito mode string
to include a warning about the fact that browsing incognito won't
prevent other actors from tracking your activity. I think it's a good
thing to notify the users about this detail, and other browsers do the
same.

there are two strings to translate, so I'm asking for a string freeze
break to land this before 3.14.

[0]: https://bugzilla.gnome.org/show_bug.cgi?id=736065

ciao,
 Emmanuele.

-- 
http://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: string freeze break request for epiphany

[Emmanuele Bassi]

hi Alexandre;

you're absolutely right. just for reference to the i18n teams, the strings are:


You are currently browsing emincognito/em. Pages viewed in this
mode will not show up in your browsing history and all stored
information will be cleared when you close the window. Any files you
download will be kept.


and:


It is important to know that incognito mode will not hide your activity
from your employer, your Internet Service Provider, your government, or
the websites that you visit.


ciao,
 Emmanuele.

On 5 September 2014 12:20, Alexandre Franke alexandre.fra...@gmail.com wrote:
 On Fri, Sep 5, 2014 at 1:12 PM, Emmanuele Bassi eba...@gmail.com wrote:
 hi all;

 I filed this bug[0] for epiphany to update the incognito mode string
 to include a warning about the fact that browsing incognito won't
 prevent other actors from tracking your activity. I think it's a good
 thing to notify the users about this detail, and other browsers do the
 same.

 there are two strings to translate, so I'm asking for a string freeze
 break to land this before 3.14.

 [0]: https://bugzilla.gnome.org/show_bug.cgi?id=736065

 +1 for i18n.

 Next time it would be a good idea to copy the strings in your email. :-)

 --
 Alexandre Franke



-- 
http://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: [pango] 1.36.4

[Emmanuele Bassi]

hi Behdad;

On 23 June 2014 22:59, Behdad Esfahbod beh...@behdad.org wrote:
 Ugh.  Wish I had in mind that a release is coming.  My bad.

 I changed API in harfbuzz master, which broken Pango build.  ebassi updated
 Pango and required harfbuzz 0.9.25, which does NOT have the API change.

I was trying to put the GNOME autobuilder back to working, since it
had been failing for a whole night; given that Pango sits fairly low
on the stack, it not building was preventing other modules from
building and the tests from running.

I bumped the HB requirement in Pango to 0.9.29, which was the version
in Git that held the commit that changed the API, not to 0.9.25.

if the harfbuzz API can change without the version not getting bumped
in Git, then it's a problem for every other project that depends on
harfbuzz.

 Alternatively, and perhaps this is the better option: I can add the old API
 back in...   The code involved is in pango-ot, that is fairly unused.  I can
 remove the hb function call there completely so newer Pango will keep building
 with a variety of harfbuzz versions.  There won't be any lost functionality in
 practice.

 WDYT?

adding back the old symbol, maybe as a wrapper that passes NULL with a
deprecation warning, is perfectly fine by me.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: A first look at 3.10 blockers

[Emmanuele Bassi]

hi Matthias;

we probably want to add:

  Bug 705915 - Support high dpi displays
  https://bugzilla.gnome.org/show_bug.cgi?id=705915

to the list of blockers for 3.10. I already have a working patch for
X11 (need to hook up the xsetting code so that I can get the scaling
factor from the system), but it'll need some testing on an actual
hidpi display — especially for text rendering, which may be affected.
after that, the Wayland and GDK backends can easily be ported as well.

ciao,
 Emmanuele.


On 13 August 2013 15:49, Matthias Clasen matthias.cla...@gmail.com wrote:
 Here is a first pass over bugs that are currently marked with a target
 of '3.10'. The bulk of it is related to Wayland (simply because that
 is where I'm focusing most, currently). If there are other bugs that
 should be on this list, please let us know.


 Matthias


 Related to Wayland:
 

 705710 clutter evdev: fix X11 to evdev keycode translation
 695737 clutter-gtk Add wayland support
 705573 gnome-contro display: merge the wip/wayland-display branch
 705510 gnome-deskto Merge the wip/wayland-display branch
 705507 gnome-settin Merge the wip/wayland-display branch
 705497 gnome-shell make gnome-shell build two binaries
 705504 gnome-shell 3.10: make on-screen keyboard work under wayland
 672358 gtk+ Introduce a GdkClipboard abstraction to replace the
 various GtkClipboard implementations
 698307 gtk+ There should be support for the Wayland input method protocol
 705670 mutter Add a DBus API for display configuration under X

 Related to geolocation:
 

 694985 gnome-contro Mould date-time settings into new designs

 Related to bluez5 transition:
 --

 701078 NetworkManag Port NM to BlueZ 5

 Related to system status rework:
 -

 705647 gnome-shell New System Status design lost the ability to suspend
 705733 gnome-shell Make new system status implementation respect the
 always-show-universal-access-status setting

 Misc. other bugs:
 

 679438 glib Python 3 / Windows / cmake port
 696633 glib gdbus-codegen trips over unicode chars when using python 3.x
 686527 gnome-docume Pickup ownCloud accounts from GOA
 697127 gtk+ gedit context menu uses fixed-width font
 698833 gtk+ Regression in GtkGrid after baseline support
 701125 gtk+ port scrolling to GtkPixelCache
 701126 gtk+ port scrolling to GtkPixelCache
 702914 gtk+ Button, menu appearance not updated correctly
 703124 gtk+ Scrolling results in upper part of spreadsheet being obscured
 704134 gtk+ No way to disable cursor blinking
 ___
 desktop-devel-list mailing list
 desktop-devel-l...@gnome.org
 https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Merging wip/clutter-1.99 in master

[Emmanuele Bassi]

hi all;

a bit later than I expected, but I merged the wip/clutter-1.99 branch
into master — master is now open for the 1.99 development cycle, which
will lead to Clutter 2.0.

I also pushed the clutter-1.16 branch, which I expect is what will be
used for GNOME 3.10.

have fun!

On 30 March 2013 12:51, Emmanuele Bassi eba...@gmail.com wrote:
 hi all;

 executive summary: last night I finally rebased the preliminary 1.99
 branch on top of current master, and I'm planning to switch master to
 it on Monday, barring unforeseen complications.

 the wip/clutter-1.99 branch contains the initial work needed to move
 towards Clutter 2.0; it removes all deprecated symbols (for a net
 worth of 40 thousand lines of code removed from the repository), and
 handles the fallout in the various pieces of the code base. as to
 avoid breaking bisection, the commits should build separately — at
 least, if you disable the test suite at configure time, since it's
 mostly a mechanical job.

 after the merge, master will be open to large refactorings which will
 hopefully lead to 2.0. at the same time, I'll open another branch,
 called clutter-1.16, for a transitional release cycle in case more
 stuff has to be removed from master (and thus has to be deprecated on
 the 1.x API line). this is, in essence, the same plan I had for 1.14,
 only delayed by a cycle.

 if you are using Clutter right now, I suggest you stick to the stable
 clutter-1.14 branch, and eventually switch to clutter-1.16 if you want
 to port to 2.0.

 the plans for Clutter 2.0 are on the roadmap[0], but I expect that to
 be edited/changed a bit after the GTK+ hackfest at the end of
 April[1], considering that we want to move Clutter closer to GTK in
 the future.

 ciao,
  Emmanuele.

 [0] https://live.gnome.org/Clutter/Roadmap
 [1] https://live.gnome.org/Hackfests/GTK2013

 --
 W: http://www.emmanuelebassi.name
 B: http://blogs.gnome.org/ebassi/



--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Fallback mode is going away - what now ?

[Emmanuele Bassi]

hi;

On 21 November 2012 14:05, Olav Vitters o...@vitters.nl wrote:
 On Wed, Nov 21, 2012 at 08:17:16AM -0500, Matthias Clasen wrote:
 We haven't made a final decision yet on how to let users turn on this
 'classic mode' - it may be a switch in gnome-tweak-tool or something
 else.

 I'm wondering if we cannot just change the fallback mode switch into a
 traditional toggle (IMO classical is not the right word). I know it
 goes against the vision, etc, but I don't care.

I do care, and honestly if you care enough to toggle a switch to
change a user interface, then System Settings or Tweak Tool are
perfectly equivalent.

to be fair, I'd envision this as a completely separate session that
you need to install and select, similar to what Ubuntu does —
especially if we want to call it GNOME Classic.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Fallback mode is going away - what now ?

[Emmanuele Bassi]

hi Andre;

On 21 November 2012 13:27, Andre Klapper ak...@gmx.net wrote:

 Can we make testing beta versions (and porting extensions to the next
 major version of GNOME) more attractive / easier for extension authors?
 Have Shell maintainers published info on Code changes which may affect
 extensions in the past? Putting this into the release notes feels a bit
 too late.

you're definitely correct. we should have some form of limited QA for
the most highly rated extensions.

Firefox has the same issue, and a lot of grief has been eliminated by
working closely, during the development process, with the extension
authors whenever a change was scheduled. nothing's perfect, obviously,
but it helped in having extensions working right after a new release.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Clutter branched for 3.6

[Emmanuele Bassi]

hey all;

I branched Clutter 1.12 a while ago for 3.6 - the branch name is clutter-1.12.

development for 1.14 will continue on master until the
wip/clutter-1.99 branch is merged and the work on 2.0 will move there.
I'll send another email when I branch master for 1.14.

Clutter 2.0 will probably be out after 3.8 - it's also possible it'll
be released out of sync with the cycle.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.