Re: Freeze break request for polari

[Florian Müllner]

On Sat, Mar 7, 2020 at 21:14, Abderrahim Kitouni  
wrote:


Approval 2/2


Thanks!


___
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 polari

[Abderrahim Kitouni]

Hi

Le sam. 7 mars 2020 à 20:20, Florian Müllner  a écrit :
>
> Hey again!
>
> I would like to include
> https://gitlab.gnome.org/GNOME/polari/-/merge_requests/147 in 3.36.0.

Approval 2/2
___
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 polari

[Florian Müllner]

I got a private +1 from Michael.


On Sat, Mar 7, 2020 at 20:20, Florian Müllner  
wrote:

Hey again!

I would like to include 
https://gitlab.gnome.org/GNOME/polari/-/merge_requests/147 in 3.36.0.


The reason is that WebKit as shipped in the gnome-nightly runtime 
will fail if hardware acceleration isn't available, and the app 
hasn't explicitly disabled it.


That means that URL previews are no longer working in the nightly 
flatpak, and that's not what I'd like to ship in 3.36.0(*).


(I regret not pushing that MR earlier now, but as it didn't get rid 
of the "libEGL warning: wayland-egl: could not open /dev/dri/card0" 
warning, I assumed it had now effect)


Thanks, and enjoy the rest of your weekend
Florian

(*) to be fair though, there is a plan B: Release 3.36.0 as-is and 
include the patch in question in the flatpak. It's just more 
cumbersome than having it in the release :-)







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

Freeze break request for polari

[Florian Müllner]

Hey again!

I would like to include 
https://gitlab.gnome.org/GNOME/polari/-/merge_requests/147 in 3.36.0.


The reason is that WebKit as shipped in the gnome-nightly runtime will 
fail if hardware acceleration isn't available, and the app hasn't 
explicitly disabled it.


That means that URL previews are no longer working in the nightly 
flatpak, and that's not what I'd like to ship in 3.36.0(*).


(I regret not pushing that MR earlier now, but as it didn't get rid of 
the "libEGL warning: wayland-egl: could not open /dev/dri/card0" 
warning, I assumed it had now effect)


Thanks, and enjoy the rest of your weekend
Florian

(*) to be fair though, there is a plan B: Release 3.36.0 as-is and 
include the patch in question in the flatpak. It's just more cumbersome 
than having it in the release :-)




___
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 Epiphany

[Andre Klapper]

On Fri, 2020-03-06 at 18:31 -0600, Michael Catanzaro wrote:
> On Fri, Mar 6, 2020 at 5:24 pm, Javier Jardón wrote:
> > 1/2 for release team
>
> Thanks. Anybody else?

2/2 from release-team.

andre
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


___
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 Epiphany

[Michael Catanzaro]

On Fri, Mar 6, 2020 at 5:24 pm, Javier Jardón  
wrote:

1/2 for release team


Thanks. Anybody else?


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

Re: More freeze break requests for gnome-shell

[Javier Jardón]

Thanks for the detailed explanation of all the freeze requests ; 2/2 for
release team

On Fri, 6 Mar 2020, 18:41 Michael Catanzaro,  wrote:

> Thanks Florian. Here's approval 1 of 2 for all nine changes.
>
>
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> 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: More freeze break requests for gnome-shell

[Michael Catanzaro]

Thanks Florian. Here's approval 1 of 2 for all nine changes.


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

More freeze break requests for gnome-shell

[Florian Müllner]

Hey everyone!

Tarballs are almost due (hi Michael!), but there are still a couple of 
things we would like to include.


I hope bundling the requests in a single mail is OK:

1. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1068

  We currently crash on startup if any of the top-icons extensions is 
enabled.
  The merge request that addresses the issue is not overly complex, 
but still

  beyond a trivial one line fix.

  However I'd still argue that it is preferable to land, as:

  - it has been confirmed to fix the crash, and not crashing is 
clearly an improvement
  - all code changes are limited to our legacy status icon support, so 
it's perfectly

safe for everyone who is *not* using any of those extensions

2. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1069

  ibus support is currently broken in the Xorg session. The fix is a 
trivial one-liner

  ("do in the xorg session what we are already doing for xwayland")

3. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1065

  If gnome-settings-daemon's xsettings service fails to start, we 
currently end up without
  X11 support in the wayland session. The fix is again trivial (don't 
treat gsd-xsettings

  failure as fatal for Xwayland startup)

4. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1110

  On multi-monitor systems, popup windows may pop up on the wrong 
monitor (or completely

  off-screen). The fix should be easy and safe.


5. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1074

   Two small additions to the Extensions D-Bus API. Those are pure 
additions, so they have
   no effect on any existing users of the API (like the "new" 
Extensions app, the browser

   integration or Tweaks).

   The reason for wanting this in 3.36.0 is that I want to improve(*) 
on the Extensions app
   in 3.36.1 (and ultimately make it available on Flathub), but it 
feels wrong to add new API

   in a stable release and rely on it.

   (*) all under-the-hood: No UI or string changes

6. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1063

  This is a simple request from Ubuntu for a small improvement for 
session modes (non-default

  GNOME-based sessions like "Ubuntu" or "Classic").

  Similar to the above, the reason why I want this in 3.36.0 is that 
landing it in 3.36.1 would
  open the potential for session modes that are supposed to work on 
"3.36", but fail with 3.36.0.


  On the other hand it would be sad to delay the improvement for a 
whole six months.



Those are the important ones in my opinion. There are a couple more 
nice-to-have issues that are low-impact, but have trivial and safe 
patches available:


7. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1071

  Settings now has a dedicated "Location Services" panel, but the 
location submenu

  in the shell's top-right menu still launches the "Privacy" panel.

8. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1059

  The title of app folders in the overview is hard to read when using 
the light theme variant
  (like Ubuntu does). Not an issue as far as upstream is concerned, 
but the fix is trivial

  and safe

9. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1057

  The drag handles of the volume/brightness sliders has a small 
graphical glitch
  at 0; this was supposed to be addressed in 3.35.92, but there's 
still a minor
  glitch left. Again not the end of the world, but the fix is trivial 
and safe
  (it's effectively a one-line fix, although the patch hides that a 
bit by renaming

  a variable)


Apologies for that late flood of requests (they have been piling up 
until earlier today).


Regards,
Florian


___
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 Epiphany

[Javier Jardón]

1/2 for release team

On Wed, 4 Mar 2020 at 21:24, Michael Catanzaro  wrote:
>
> Hi,
>
> I'd like to merge [1], which fixes a crash when closing Epiphany's
> password management dialog that I accidentally introduced in 3.35.92.
>
> Thanks,
>
> Michael
>
> [1] https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/606
>
>
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.



-- 
Javier Jardón Cabezas
___
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 glib-networking

[Javier Jardón]

2/2 for release team

On Fri, 6 Mar 2020 at 11:17, Andre Klapper  wrote:
>
> On Thu, 2020-03-05 at 15:43 -0600, Michael Catanzaro wrote:
> > I'd like to request a freeze break for:
> >
> > https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/116
> >
> > which got committed during the freeze period. This just fixes a
> > non-void function that lacked a return value in an old fallback path
> > when compiling with the OpenSSL backend -- which should be disabled at
> > build time almost everywhere -- when using the ancient version of
> > OpenSSL in RHEL 6 era.
> >
> > This surely won't have any impact on anyone using GNOME 3.36, so say
> > yes please. :)
>
> Heh. +1 / yes please.
>
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.



-- 
Javier Jardón Cabezas
___
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 glib-networking

[Andre Klapper]

On Thu, 2020-03-05 at 15:43 -0600, Michael Catanzaro wrote:
> I'd like to request a freeze break for:
>
> https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/116
>
> which got committed during the freeze period. This just fixes a
> non-void function that lacked a return value in an old fallback path
> when compiling with the OpenSSL backend -- which should be disabled at
> build time almost everywhere -- when using the ancient version of
> OpenSSL in RHEL 6 era.
>
> This surely won't have any impact on anyone using GNOME 3.36, so say
> yes please. :)

Heh. +1 / yes please.

andre
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


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

Freeze break request for glib-networking

[Michael Catanzaro]

Hi,

I'd like to request a freeze break for:

https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/116

which got committed during the freeze period. This just fixes a 
non-void function that lacked a return value in an old fallback path 
when compiling with the OpenSSL backend -- which should be disabled at 
build time almost everywhere -- when using the ancient version of 
OpenSSL in RHEL 6 era.


This surely won't have any impact on anyone using GNOME 3.36, so say 
yes please. :)


Michael


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

Re: [evolution-data-server] Hard code freeze break plea

[Milan Crha via release-team]

On Thu, 2020-03-05 at 09:43 -0600, Michael Catanzaro wrote:
> On Thu, Mar 5, 2020 at 4:33 pm, Andre Klapper  wrote:
> > r-t approval 1 of 2.
> 
> Approval 2

Hi,
thanks, I just committed it [1].
Bye,
Milan

[1] 
https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/127dde9233bb62d59ca486a5610c19fde9ed92c7

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

Re: Freeze break for USB protection in gnome-session for non-systemd setups

[Michael Catanzaro]

On Thu, Mar 5, 2020 at 2:50 pm, Andre Klapper  wrote:

Not happy that it's so late, but looks trivial and reasonable.
So I'll throw in my release-team approval 1 of 2.


Approval 2


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

Re: [evolution-data-server] Hard code freeze break plea

[Michael Catanzaro]

On Thu, Mar 5, 2020 at 4:33 pm, Andre Klapper  wrote:

r-t approval 1 of 2.


Approval 2


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

Re: [evolution-data-server] Hard code freeze break plea

[Andre Klapper]

r-t approval 1 of 2.

andre

On Thu, 2020-03-05 at 15:15 +0100, Milan Crha via release-team wrote:
>   Hello,
> a user reported an issue [1] in 3.35.92 of evolution-data-server about
> missing Google calendars (and tasks), when the account is configured in
> GNOME Online Accounts. That's a regression after changes made months
> ago.
>
> I can wait with the fix for 3.36.1, but I'd prefer to have the fix
> included in 3.36.0, because Google seems to be particularly popular,
> thus having not shown calendars for newly created accounts in GOA would
> be considered a problem by early adopters.
>
> Thus I'd like to ask: can I commit the change for 3.36.0, please?
>
> The fix is rather trivial [2] and I tested it that it can also fix
> already created accounts, thus even users with already created new
> accounts will have things fixed silently (after they start patched
> evolution-source-registry).
>
>   Thanks and bye,
>   Milan
>
> [1] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/198
> [2]
> https://gitlab.gnome.org/GNOME/evolution-data-server/issues/198#note_731721
>
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


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

[evolution-data-server] Hard code freeze break plea

[Milan Crha via release-team]

Hello,
a user reported an issue [1] in 3.35.92 of evolution-data-server about
missing Google calendars (and tasks), when the account is configured in
GNOME Online Accounts. That's a regression after changes made months
ago.

I can wait with the fix for 3.36.1, but I'd prefer to have the fix
included in 3.36.0, because Google seems to be particularly popular,
thus having not shown calendars for newly created accounts in GOA would
be considered a problem by early adopters.

Thus I'd like to ask: can I commit the change for 3.36.0, please?

The fix is rather trivial [2] and I tested it that it can also fix
already created accounts, thus even users with already created new
accounts will have things fixed silently (after they start patched 
evolution-source-registry).

Thanks and bye,
Milan

[1] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/198
[2] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/198#note_731721

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

Re: Freeze break for USB protection in gnome-session for non-systemd setups

[Andre Klapper]

Not happy that it's so late, but looks trivial and reasonable.
So I'll throw in my release-team approval 1 of 2.

andre

On Thu, 2020-03-05 at 13:08 +0100, Tobias Mueller wrote:
> I am asking for an exception to have the following patch included in
> GNOME 3.36:
>
> https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/37
>
> It's purpose is to actually start the USB protection daemon in the
> non-
> systemd case.  The patch is simple in that it adds the component to
> the
> list of things to start up (RequiredComponents).  Not including the
> patch makes GNOME behave differently under systemd (or non-systemd,
> depending on which side of the fence you are standing).
>
> The maintainers are okay with having it merged and I think the
> potential
> for regression is lower than the effects of the regression that
> currently exists. But of course, that's what everybody thinks when
> they
> require an exception ;-)
>
> There are no UI strings involved.
>
> Cheers,
>   Tobi
>
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


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

Freeze break for USB protection in gnome-session for non-systemd setups

[Tobias Mueller]

Hello Release-Team.

I am asking for an exception to have the following patch included in
GNOME 3.36:

https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/37

It's purpose is to actually start the USB protection daemon in the non-
systemd case.  The patch is simple in that it adds the component to the
list of things to start up (RequiredComponents).  Not including the
patch makes GNOME behave differently under systemd (or non-systemd,
depending on which side of the fence you are standing).

The maintainers are okay with having it merged and I think the potential
for regression is lower than the effects of the regression that
currently exists. But of course, that's what everybody thinks when they
require an exception ;-)

There are no UI strings involved.

Cheers,
  Tobi

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

Freeze break request for Epiphany

[Michael Catanzaro]

Hi,

I'd like to merge [1], which fixes a crash when closing Epiphany's 
password management dialog that I accidentally introduced in 3.35.92.


Thanks,

Michael

[1] https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/606


___
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.

Re: Freeze break request for gnome-shell

[Michael Catanzaro]

Approval 1


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

Freeze break request for gnome-shell

[Florian Müllner]

Hey everyone!

This is embarrassing, but since a minor IO optimization in 3.35.92,
dates in gnome-shell are now off by 1900 years.

I would rather not stay in the year 120 until 3.36.1 is released, so
I'd like a freeze break exception for the following fix:

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

The change is trivial (replace getYear() with getFullYear()) and safe,
and addresses a quite visible bug.

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

Re: [gnome-clocks] UI freeze break

[Bilal Elmoussaoui via release-team]

Thanks a lot, we will ensure to fix those bugs reports! the app should be
in nightlies soon, we will appreciate tests and feedback before hard code
freeze.

We have requested a string freeze break which got approved too.


Le dim. 23 févr. 2020 à 17:38, Michael Catanzaro  a
écrit :

> On Sun, Feb 23, 2020 at 10:37 am, Michael Catanzaro
>  wrote:
> > So go for it.
>
> I see new strings though, so make sure you get string freeze approval
> before you go for it. ;)
>
>
>

-- 

Bilal Elmoussaoui


*Full Stack developer*

*https://belmoussaoui.com/ <https://belmoussaoui.com/>*

*bil.elmoussa...@gmail.com *

*+32 485.88.06.57*

*[image: Github] <https://github.com/bilelmoussaoui> [image: LinkedIn]
<https://www.linkedin.com/in/bil-elmoussaoui/> [image: Twitter]
<https://twitter.com/bil_moussaoui> *
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: [gnome-clocks] UI freeze break

[Michael Catanzaro]

On Sun, Feb 23, 2020 at 10:37 am, Michael Catanzaro 
 wrote:

So go for it.


I see new strings though, so make sure you get string freeze approval 
before you go for it. ;)



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

Re: [gnome-clocks] UI freeze break

[Michael Catanzaro]

On Sat, Feb 22, 2020 at 7:10 am, Javier Jardón  
wrote:

1/2 approval for release team


I guess I'll give 2/2.

I don't think you can land major work like this so late in the freeze 
period without introducing regressions, but Clocks was not in very 
great shape before this work, so I assume this work is likely to be an 
overall user experience improvement even if there are bugs. And it's 
not such an important component that problems here are likely to 
negatively affect the overall GNOME user experience. So go for it.


Michael


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

Re: String freeze break for mutter for setting

[Alexandre Franke]

On Sat, Feb 22, 2020 at 1:56 PM Claude Paroz  wrote:
> Approval 1/2 from i18n team.

i18n 2/2.

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

Re: String freeze break for mutter for setting

[Claude Paroz]

Approval 1/2 from i18n team.

Claude

Le 21.02.20 à 23:49, Jonas Ådahl via gnome-i18n a écrit :
> In 3.36, mutter/gnome-shell will since recently be more eager trying to
> detect frozen applications. Instead of only trying to check in certain
> situations such as when alt-tabbing to it, we'll check every time a
> window is attempted to be activated, e.g. switching focus to it by
> clicking on it.
...
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String freeze break for mutter for setting

[Andre Klapper]

2/2 approval for release-team.

On Sat, 2020-02-22 at 07:14 +, Javier Jardón wrote:
> 1/2 for release team
>
> On Fri, 21 Feb 2020, 22:49 Jonas Ådahl via gnome-i18n, <
> gnome-i...@gnome.org> wrote:
> > In 3.36, mutter/gnome-shell will since recently be more eager
> > trying to
> > detect frozen applications. Instead of only trying to check in
> > certain
> > situations such as when alt-tabbing to it, we'll check every time a
> > window is attempted to be activated, e.g. switching focus to it by
> > clicking on it.
> >
> > In effect it may result in misbehaving applications that temporarly
> > freeze triggering the force-close dialog more often. If one often
> > uses
> > such an application, it can become a pain point getting that dialog
> > all
> > the time without any possibility for GNOME to fix it for real being
> > an
> > application bug.
> >
> > Thus, we're introducing a gsetting that enables the user to change
> > the
> > timeout, or disable the check completely, to work around the issue.
> >
> > The string freeze break is for the new gsetting.
> >
> > Relevant merge request:
> > https://gitlab.gnome.org/GNOME/mutter/merge_requests/1080
> >
> >
> > Jonas
> > ___
> > gnome-i18n mailing list
> > gnome-i...@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
> ___
> gnome-i18n mailing list
> gnome-i...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


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

Re: String freeze break for mutter for setting

[Jordan Petridis via release-team]

2/2 of the release teamOn Sat, Feb 22, 2020 at 09:14, Javier Jardón <jjar...@gnome.org> wrote:  1/2 for release teamOn Fri, 21 Feb 2020, 22:49 Jonas Ådahl via gnome-i18n, <gnome-i...@gnome.org> wrote:In 3.36, mutter/gnome-shell will since recently be more eager trying to
detect frozen applications. Instead of only trying to check in certain
situations such as when alt-tabbing to it, we'll check every time a
window is attempted to be activated, e.g. switching focus to it by
clicking on it.

In effect it may result in misbehaving applications that temporarly
freeze triggering the force-close dialog more often. If one often uses
such an application, it can become a pain point getting that dialog all
the time without any possibility for GNOME to fix it for real being an
application bug.

Thus, we're introducing a gsetting that enables the user to change the
timeout, or disable the check completely, to work around the issue.

The string freeze break is for the new gsetting.

Relevant merge request:
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1080


Jonas
___
gnome-i18n mailing list
gnome-i...@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n






publicKey - jordan@alatiera.com - 0bdad30b.asc
Description: application/pgp-keys


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

Re: String freeze break for mutter for setting

[Javier Jardón]

1/2 for release team

On Fri, 21 Feb 2020, 22:49 Jonas Ådahl via gnome-i18n, 
wrote:

> In 3.36, mutter/gnome-shell will since recently be more eager trying to
> detect frozen applications. Instead of only trying to check in certain
> situations such as when alt-tabbing to it, we'll check every time a
> window is attempted to be activated, e.g. switching focus to it by
> clicking on it.
>
> In effect it may result in misbehaving applications that temporarly
> freeze triggering the force-close dialog more often. If one often uses
> such an application, it can become a pain point getting that dialog all
> the time without any possibility for GNOME to fix it for real being an
> application bug.
>
> Thus, we're introducing a gsetting that enables the user to change the
> timeout, or disable the check completely, to work around the issue.
>
> The string freeze break is for the new gsetting.
>
> Relevant merge request:
> https://gitlab.gnome.org/GNOME/mutter/merge_requests/1080
>
>
> Jonas
> ___
> gnome-i18n mailing list
> gnome-i...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: [gnome-clocks] UI freeze break

[Javier Jardón]

1/2 approval for release team

On Tue, 18 Feb 2020, 20:22 Bilal Elmoussaoui via release-team, <
release-team@gnome.org> wrote:

> Hello,
>
> I would like to ask for a UI freeze approval for GNOME Clocks. We have
> tried to finish the redesign of the four panels before UI freeze but we
> have got only two panels in and we would like to get a UI freeze break to
> get the two other panels in.
>
> The related merge requests:
> - Alarm panel redesign:
> https://gitlab.gnome.org/GNOME/gnome-clocks/merge_requests/42
> - World panel redesign:
> https://gitlab.gnome.org/GNOME/gnome-clocks/merge_requests/48
>
> Sincerely,
> Bilal Elmoussaoui
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> 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: UI freeze break request for g-c-c

[Jordan Petridis via release-team]

2/2 from me, while its fairly late it doesn't make sense not to do the 
adjustments that correspond to the shell changes.

Jordan

publickey - jordan@alatiera.com - 0x0BDAD30B.asc
Description: application/pgp-keys


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

Re: UI freeze break request for g-c-c

[Michael Catanzaro]

+1 from me on both MRs, since this is tied to the freeze break for the 
lock screen itself.


That said, I fear we've pushed this *really* late. Stability during the 
final weeks of the release cycle is important in order to properly test 
changes and avoid regressions. Let's be more conservative in the future.


Michael


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

UI freeze break request for g-c-c

[Tobias Bernard]

Hello release team,

The recent lock screen changes require some adjustments to the background 
settings panel, because the lock screen now uses a blurred version of the 
session wallpaper rather than a separate one. This means that we need to remove 
the lock screen wallpaper setting from control-center:

https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/705

In order to make the overall layout work better with only one preview, we also 
need to change the thumbnails to a smaller size:

https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/706

I'd like to ask for a freeze break for these relatively small changes, which 
are needed to avoid some pretty visible regressions in UX quality for the 
background panel. These are pure UI changes, and don't change or introduce new 
strings.

Both MRs are already reviewed by maintainers and ready to be merged.

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

[gnome-clocks] UI freeze break

[Bilal Elmoussaoui via release-team]

Hello,

I would like to ask for a UI freeze approval for GNOME Clocks. We have
tried to finish the redesign of the four panels before UI freeze but we
have got only two panels in and we would like to get a UI freeze break to
get the two other panels in.

The related merge requests:
- Alarm panel redesign:
https://gitlab.gnome.org/GNOME/gnome-clocks/merge_requests/42
- World panel redesign:
https://gitlab.gnome.org/GNOME/gnome-clocks/merge_requests/48

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

Re: Freeze break exception for the new lock screen

[Matthias Clasen via release-team]

On Fri, Feb 14, 2020 at 1:17 PM Michael Catanzaro 
wrote:

> On Fri, Feb 14, 2020 at 10:10 am, Allan Day  wrote:
> > I thought we got the freeze break. We did get it, didn't we?!
>
> No, you need two approvals to break the freeze, but you only received a
> single approval from me. Somebody else would need to give a second
> approval.
>
>
I'm in favor of landing this. So here's your second approval
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break exception for the new lock screen

[Michael Catanzaro]

On Fri, Feb 14, 2020 at 10:10 am, Allan Day  wrote:

I thought we got the freeze break. We did get it, didn't we?!


No, you need two approvals to break the freeze, but you only received a 
single approval from me. Somebody else would need to give a second 
approval.



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

Re: Freeze break exception for the new lock screen

[Allan Day]

Michael Catanzaro  wrote:
...
> > It is equally not smart to never land the things we've worked on for
> > years just because we put ourselves under the pressure of yet another
> > deadlne.
>
> So far this exception has only one of two required approvals. Do you
> want to give the second approval?

I thought we got the freeze break. We did get it, didn't we?!

Anyway: a brief update - the lock screen work has now been merged
(this is the main reference:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1848 ). A bunch of
testing has already happened, and we've been working through the
issues that have spotted. I'll try and get more people involved in
tested next week. Downstream, Fedora is planning a GNOME 3.36 test day
on Thursday 20th, which will be a good opportunity to test.

I do have a related freeze break request to make of the release team,
but I'll start a new thread for that.

Thanks,

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

Re: Freeze Break for gnome-control-center to include USB protection

[Javier Jardón]

1/2 for release team

On Thu, 13 Feb 2020, 17:44 Tobias Mueller,  wrote:

> Hi,
>
> On Wed, 2020-02-12 at 15:57 -0600, Michael Catanzaro wrote:
> > Hm, I'm not going to give +1 myself because I just found a typo in
> > the
> > new string, and we are very close to string freeze.
> Thanks for correcting! :)
>
> I don't know what you're making making out of the fact that you've found
> a typo, though. The string has been there since the first version of the
> patch from over a year ago. And it has been reviewed as it was twice, at
> least. But not from a native speaker.
> To me, your sentence sounds a bit like the typo is a result of rushing a
> string into the patch. That is not the case.
>
> >  We had six months
> > to land this and it seems pretty late to be adding new UI toggles.
> >
> Yeah, I see that argument.
> For better or worse: The new switch will only be shown if a recent
> enough USBGuard is installed and running. I predict that the combination
> is quite niche.
>
> Cheers,
>   Tobi
>
> ___
> gnome-i18n mailing list
> gnome-i...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze Break for gnome-control-center to include USB protection

[Tobias Mueller]

Hi,

On Wed, 2020-02-12 at 15:57 -0600, Michael Catanzaro wrote:
> Hm, I'm not going to give +1 myself because I just found a typo in
> the 
> new string, and we are very close to string freeze.
Thanks for correcting! :)

I don't know what you're making making out of the fact that you've found
a typo, though. The string has been there since the first version of the
patch from over a year ago. And it has been reviewed as it was twice, at
least. But not from a native speaker.
To me, your sentence sounds a bit like the typo is a result of rushing a
string into the patch. That is not the case.

>  We had six months 
> to land this and it seems pretty late to be adding new UI toggles.
> 
Yeah, I see that argument.
For better or worse: The new switch will only be shown if a recent
enough USBGuard is installed and running. I predict that the combination
is quite niche.

Cheers,
  Tobi

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

Re: Freeze Break for gnome-control-center to include USB protection

[Michael Catanzaro]

Hm, I'm not going to give +1 myself because I just found a typo in the 
new string, and we are very close to string freeze. We had six months 
to land this and it seems pretty late to be adding new UI toggles.


That said, the patch is pretty simple and the code changes look fine. 
I'm not going to object if you get two other +1s.


Michael


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

Re: Freeze Break for gnome-control-center to include USB protection

[Alexandre Franke]

On Wed, Feb 12, 2020 at 10:29 PM Tobias Mueller  wrote:
> Hi,

Hi,

> I am asking for a freeze break for having this patch merged:
> https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/366
>
> It adds a new switch to the control centre and two (2) new strings to be 
> translated.
> The patch has already been reviewed and approved, but I guess it was bad 
> timing so it didn't make it in before the freeze.
> The patch is attached for convenience.

Thanks for the heads up. As far as the i18n team is concerned, no
exception is needed (yet) as the String freeze only starts on the
15th.

Cheers,

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

Freeze Break for gnome-control-center to include USB protection

[Tobias Mueller]

Hi,

I am asking for a freeze break for having this patch merged:
https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/366

It adds a new switch to the control centre and two (2) new strings to be 
translated.
The patch has already been reviewed and approved, but I guess it was bad timing 
so it didn't make it in before the freeze.
The patch is attached for convenience.

Thanks,
  Tobi
From e1f66ace252ae3f245e628437114891bdbbc3967 Mon Sep 17 00:00:00 2001
From: Ludovico de Nittis 
Date: Wed, 29 Jan 2020 18:09:10 +0100
Subject: [PATCH] lock: Add USB protection entry

In the screen lock tab we add a "Forbid new USB devices" entry with a
switch to enable or disable said protection.

The actual USB protection is handled by gnome-settings-daemon and
USBGuard.

We use the "Available" property of gnome-settings-daemon to check
if we are able to offer the USB protection (i.e. USBGuard is
installed with the minimum required version ecc..).
If the host doesn't met the requirements we hide the USB
protetion row entirely.

Given the fact that the always on protection benefits are very slim we
decided to give just an on/off switch that by default controls the
"with lock screen" protection level.
---
 panels/lock/cc-lock-panel.c  | 110 +++
 panels/lock/cc-lock-panel.ui |  19 ++
 2 files changed, 118 insertions(+), 11 deletions(-)

diff --git a/panels/lock/cc-lock-panel.c b/panels/lock/cc-lock-panel.c
index cab917dd4..3bf00fd94 100644
--- a/panels/lock/cc-lock-panel.c
+++ b/panels/lock/cc-lock-panel.c
@@ -1,6 +1,7 @@
 /* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*-
  *
  * Copyright (C) 2018 Red Hat, Inc
+ * Copyright (C) 2020 Collabora Ltd.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -28,17 +29,23 @@
 
 struct _CcLockPanel
 {
-  CcPanel parent_instance;
-
-  GSettings   *lock_settings;
-  GSettings   *notification_settings;
-  GSettings   *session_settings;
-
-  GtkSwitch   *automatic_screen_lock_switch;
-  GtkComboBox *blank_screen_combo;
-  GtkComboBox *lock_after_combo;
-  GtkListBox  *lock_list_box;
-  GtkSwitch   *show_notifications_switch;
+  CcPanelparent_instance;
+
+  GSettings *lock_settings;
+  GSettings *notification_settings;
+  GSettings *privacy_settings;
+  GSettings *session_settings;
+
+  GCancellable  *cancellable;
+
+  GtkSwitch *automatic_screen_lock_switch;
+  GtkComboBox   *blank_screen_combo;
+  GtkComboBox   *lock_after_combo;
+  GtkListBox*lock_list_box;
+  GtkSwitch *show_notifications_switch;
+  GtkSwitch *usb_protection_switch;
+  GDBusProxy*usb_proxy;
+  GtkListBoxRow *usb_protection_row;
 };
 
 CC_PANEL_REGISTER (CcLockPanel, cc_lock_panel)
@@ -178,14 +185,74 @@ on_blank_screen_delay_changed_cb (GtkWidget   *widget,
   g_settings_set_uint (self->session_settings, "idle-delay", value);
 }
 
+static void
+on_usb_protection_props_changed (CcLockPanel *self,
+ GVariant*changed_properties,
+ GStrvinvalidated_properties)
+{
+  gboolean available = FALSE;
+
+  if (self->usb_proxy != NULL)
+{
+  g_autoptr(GVariant) variant = NULL;
+
+  variant = g_dbus_proxy_get_cached_property (self->usb_proxy, "Available");
+  if (variant != NULL)
+available = g_variant_get_boolean (variant);
+}
+
+  /* Show the USB protection row only if the required daemon is up and running */
+  if (available)
+gtk_widget_show (GTK_WIDGET (self->usb_protection_row));
+  else
+gtk_widget_hide (GTK_WIDGET (self->usb_protection_row));
+
+}
+
+static void
+on_usb_protection_param_ready (GObject  *source_object,
+   GAsyncResult *res,
+   gpointer  user_data)
+{
+  CcLockPanel *self;
+  GDBusProxy *proxy;
+  g_autoptr(GError) error = NULL;
+
+  self = user_data;
+  proxy = g_dbus_proxy_new_for_bus_finish (res, &error);
+  if (proxy == NULL)
+{
+  if (!g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
+{
+  g_warning ("Failed to connect to SettingsDaemon.UsbProtection: %s",
+ error->message);
+}
+
+  gtk_widget_hide (GTK_WIDGET (self->usb_protection_row));
+  return;
+}
+  self->usb_proxy = proxy;
+
+  g_signal_connect_object (self->usb_proxy,
+   "g-properties-changed",
+   G_CALLBACK (on_usb_protection_props_changed),
+   self,
+   G_CONNECT_SWAPPED);
+  on_usb_protection_props_changed (self, NULL, NULL);
+}
+
+
 static void
 cc_lock_panel_finalize (GObject *object)
 {
   CcLockPanel *self = CC_LOCK_PANEL (object);
 
+  g_cancellable_cancel (self-

Re: [evolution] UI Freeze break approval plea

[Andre Klapper]

On Fri, 2020-02-07 at 08:29 -0600, Michael Catanzaro wrote:
> Approval +1 / 2

r-t approval 2/2.

andre
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


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

Re: [evolution] UI Freeze break approval plea

[Michael Catanzaro]

Approval +1 / 2


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

[evolution] UI Freeze break approval plea

[Milan Crha via release-team]

Hello,
I'd like to ask for a UI Freeze break approval. A user made a patch [1],
which adds an option into Preferences. That's quite minimal change, but
I decided to ask anyway. I'd like to push this into 3.35.91, especially
because it's a contributed change from a user. The change adds also new
translatable strings, for which I'll send a separate notice to the
other list, if it's approved.

The change itself implements an enhancement, which another user asked
for. The change is nothing significant (with respect of code changes),
I do not expect any major side effects dues to it, and if anything
arises, then it'll be quite easy to fix.
Thanks and bye,
Milan

[1] https://gitlab.gnome.org/GNOME/evolution/merge_requests/44

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

Re: Freeze break exception for the new lock screen

[Michael Catanzaro]

On Fri, Jan 31, 2020 at 3:22 am, Matthias Clasen 
 wrote:
It is equally not smart to never land the things we've worked on for 
years just because we put ourselves under the pressure of yet another 
deadlne.


So far this exception has only one of two required approvals. Do you 
want to give the second approval?



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

Re: Freeze break exception for the new lock screen

[Matthias Clasen via release-team]

On Tue, Jan 28, 2020 at 1:37 PM Allan Day  wrote:

> Michael Catanzaro  wrote:
> > > Would it be possible to arrange a freeze exception for the lock
> > > screen work, so we can plan on having another week to get it merged?
> > > We don't expect there to be any new strings and I'm happy to
> > > coordinate with docs and marketing.
> >
> > Certainly possible, but it is wise?
>
> That is the question, and I'm not 100% sure.
>
>
It is equally not smart to never land the things we've worked on for years
just because we put ourselves under the pressure of yet another deadlne.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break exception for the new lock screen

[Michael Catanzaro]

Thanks Allan!

Since you put in the effort to create a very detailed test plan, I will 
give the first of two required +1s for this freeze exception, even 
though the code isn't quite ready yet. I suggest we allow an extra two 
weeks for the login screen work, until February 15 (the 3.35.91 tarball 
deadline). Of course, I assume the developers will go through the test 
plan to make sure everything is in good shape.


Michael


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

Re: Freeze break exception for the new lock screen

[Allan Day]

An initial version of the test plan can be found here:
https://gitlab.gnome.org/Teams/Design/os-mockups/issues/44

Allan

On Wed, 29 Jan 2020 at 11:38, Allan Day  wrote:
>
> Michael Catanzaro  wrote:
> ...
> > There are many, many, many more like these. Sorry for sending so many
> > mails to this thread, but I just happen to remember this is a
> > particularly fragile portion of the codebase. ...
>
> Thanks, I'll try and include those in the test plan.
>
> I still feel that these issues are better addressed through active,
> coordinated testing and bug fixing, but maybe the best thing to do
> would be to reassess once the MRs are ready and we have the test plan.
> The other thing we'll need is a commitment from the relevant
> developers to fix any issues that come up, before the code freeze.
>
> Allan
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break exception for the new lock screen

[Allan Day]

Michael Catanzaro  wrote:
...
> There are many, many, many more like these. Sorry for sending so many
> mails to this thread, but I just happen to remember this is a
> particularly fragile portion of the codebase. ...

Thanks, I'll try and include those in the test plan.

I still feel that these issues are better addressed through active,
coordinated testing and bug fixing, but maybe the best thing to do
would be to reassess once the MRs are ready and we have the test plan.
The other thing we'll need is a commitment from the relevant
developers to fix any issues that come up, before the code freeze.

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

Re: Freeze break exception for the new lock screen

[Michael Catanzaro]

From https://gitlab.gnome.org/GNOME/gnome-shell/commits/master/js/gdm, 
some telling examples of what could break:


"If the user fails to enter their password then hits escape, we
jump back to the user list, then ask again for a password in a
garbled screen. this commit fixes that by skipping a retry if
the operation is cancelled."

"If the user clicks Not Listed? to enter ask for username mode, clicks
cancel, and then attempts to log in via the user list, the user will see
"Authentication failed" after correctly typing the password, and then
will become stuck in an empty screen with just the gray noise 
background."


"The Next and Sign In buttons are disabled when the username/password
field is empty. However, the user can still bypass this button by
pressing the enter key, leading to some odd glitches with the log in
for 'Not Listed?' users."

"[I]f the user is currently in the user list and the account changes to 
locked, we

want to remove it from the list, or if the user is not in the list and
the account changed to unlocked, we want to add it to the list. This
fixes the case where a new user account created in gnome-control-center
does not appear in the user list."

"The user should be allowed to cancel if verification hasn't
started yet and they're typing in their username. This
commit changes the authPrompt cancel function to not
ignore such requests."

"Normally the user isn't allowed to proceed passed
the username question until they've filled it in.
To ensure this, the authprompt code desensitizes
the next button when the number of characters change to
zero. Unfortunately it fails to desensitize the next button
up front when the entry starts out empty."

"fixes a bug [...] that leads to the user session crashing when the 
login screen is reactivated"


"If the next button ever gets set to Sign In, it won't
get reset to next until the next question asked by pam. This commit 
ensures it gets reset to Next when asking

for the username."

"We currently only cancel the user verifier on reset if
verifying, but that means we don't properly cancel it when
asking for a username at the Not Listed screen."

There are many, many, many more like these. Sorry for sending so many 
mails to this thread, but I just happen to remember this is a 
particularly fragile portion of the codebase. We're a lot more stable 
nowadays then we were five years ago, so hopefully it will go fine, but 
there are lots and lots of corner cases to test. Be careful!



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

Re: Freeze break exception for the new lock screen

[Michael Catanzaro]

On Tue, Jan 28, 2020 at 1:11 pm, Michael Catanzaro 
 wrote:
Including the login screen as well, it becomes more complicated. In 
the distant past we've had a *lot* of weird bugs in edge cases. E.g. 
type password then click cancel, select a different user, try to log 
in again. Does it work? Does it try to log into the wrong user 
account? Are the right buttons sensitive at the right times? Will 
need to test user switching with multiple accounts, autologin 
with/without LUKS password, and so forth. Don't forget to test 
password changing when the account is set to require a new password 
during next login.


I forgot timed login.

Please check with halfline and Florian when developing the test 
matrix... I'm probably missing even more.



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

Re: Freeze break exception for the new lock screen

[Michael Catanzaro]

On Tue, Jan 28, 2020 at 6:36 pm, Allan Day  wrote:

My own feeling is that our confidence in the code and our ability to
do rounds of testing and fixing prior to merge are potentially the
most important factors in ensuring quality. Landing a big change right
before UI freeze and walking away is probably worse than landing
something late, but doing plenty of testing and fixing, and having a
plan in place for post-merge testing.


Right. If there's going to be a lot of testing, it becomes easier to 
justify the risk of the freeze break.


And landing early after freeze is very different from landing later. If 
this is going to land during the first week or two after freeze, and 
it's going to be thoroughly tested, that's probably OK. More than that, 
I would say no.



The testing matrix for login and unlock is potentially large, although
I'm not sure that all these features are touched by the redesign. If
we go ahead I can commit to coming up with a feature list and a test
plan.


Including the login screen as well, it becomes more complicated. In the 
distant past we've had a *lot* of weird bugs in edge cases. E.g. type 
password then click cancel, select a different user, try to log in 
again. Does it work? Does it try to log into the wrong user account? 
Are the right buttons sensitive at the right times? Will need to test 
user switching with multiple accounts, autologin with/without LUKS 
password, and so forth. Don't forget to test password changing when the 
account is set to require a new password during next login.


Michael


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

Re: Freeze break exception for the new lock screen

[Allan Day]

Michael Catanzaro  wrote:
> > Would it be possible to arrange a freeze exception for the lock
> > screen work, so we can plan on having another week to get it merged?
> > We don't expect there to be any new strings and I'm happy to
> > coordinate with docs and marketing.
>
> Certainly possible, but it is wise?

That is the question, and I'm not 100% sure. I certainly share the
concern about landing big features late, but it obviously depends on
what the time buys us. What do we lose if we delay by a week? Do we
expect 3.35.90 to get more widescale testing than master?

My own feeling is that our confidence in the code and our ability to
do rounds of testing and fixing prior to merge are potentially the
most important factors in ensuring quality. Landing a big change right
before UI freeze and walking away is probably worse than landing
something late, but doing plenty of testing and fixing, and having a
plan in place for post-merge testing.

...
> Then again, at least it's not the login screen. Unlock dialog is
> simpler.

The changes affect both unlock and login.

...
> If we do a freeze exception, we'll want to test:
>
>  * Automatic lock after delay
>  * Manual lock with Ctrl+L
>  * Fingerprint unlock
>  * Smartcard or OTP unlock
>  * (What more am I forgetting?)

The testing matrix for login and unlock is potentially large, although
I'm not sure that all these features are touched by the redesign. If
we go ahead I can commit to coming up with a feature list and a test
plan.

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

Re: Freeze break exception for the new lock screen

[Michael Catanzaro]

On Tue, Jan 28, 2020 at 12:08 pm, Allan Day  wrote:
Would it be possible to arrange a freeze exception for the lock 
screen work, so we can plan on having another week to get it merged? 
We don't expect there to be any new strings and I'm happy to 
coordinate with docs and marketing.


Certainly possible, but it is wise? Making big changes to the shell 
late in the release cycle has high risk of regressions, and we need to 
be focusing on release quality. That merge request is huge. And having 
spent a couple weeks in an old fork of the login/unlock dialog a few 
years ago trying to fix simple bugs, I'm terrified of any changes.


Then again, at least it's not the login screen. Unlock dialog is 
simpler.


Florian, what do you think?

If we do a freeze exception, we'll want to test:

* Automatic lock after delay
* Manual lock with Ctrl+L
* Fingerprint unlock
* Smartcard or OTP unlock
* (What more am I forgetting?)

Michael


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

Freeze break exception for the new lock screen

[Allan Day]

Hi Release Team,

You might be aware that we've had plans for a redesigned lock screen for
some time. Development on this has been proceeding this cycle. Some of it
has landed already, and the other pieces are close to being ready (see my
review here
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922#note_693085
). The main MRs are:

   - https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/864 (merged)
   - https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/872
   - https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/922

Georges has been taking the lead on this initiative. He's been away on
vacation for the past couple of weeks; my understanding is that, now he's
back, we should see some rapid progress on MR review and polish work.

I don't want to land the feature before it's ready, but with the bulk of
the work done, and more shell features in the pipe for future releases, it
would be good to get it in if we can.

Would it be possible to arrange a freeze exception for the lock screen
work, so we can plan on having another week to get it merged? We don't
expect there to be any new strings and I'm happy to coordinate with docs
and marketing.

Thanks,

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

String freeze break in Iagno

[Arnaud Bonatti via release-team]

Hi release team!

If I remember correctly, I have to notify you when there’s a string
freeze break approval (even if I can’t find right now where I’ve read
that, sorry for the noise if I’m mistaken). I had a discussion with
i18n about one in Iagno 3.34, and forgot to add you in copy directly,
so:
* reasoning: 
https://mail.gnome.org/archives/gnome-i18n/2019-September/msg00081.html
* 1/2: https://mail.gnome.org/archives/gnome-i18n/2019-September/msg00088.html
* 2/2: https://mail.gnome.org/archives/gnome-i18n/2019-September/msg00128.html

The patch has been pushed as d6b0b15d:
* 
https://gitlab.gnome.org/GNOME/iagno/commit/d6b0b15dfcae0415a3dc650bc35ac58f8a89258f

Regards,
Arnaud

-- 
Arnaud Bonatti

courriel : arnaud.bona...@gmail.com
___
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.

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

[mcatanzaro]

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.


Michael


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

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

[Mike Gorse]

from https://gitlab.gnome.org/GNOME/at-spi2-core/issues/18:
When running at-spi-bus-launcher --launch-immediately several times
in an X session, the first run creates the AT_SPI_BUS root X window
property, but then the others drop it. The result is that when a
user passes root with su -l (thus clearing all environment variables)
but sets DISPLAY=:0 and XAUTHORITY to make graphical applications to
access X, dbus auto-triggers an at-spi-bus-launcher again, which sets
the AT_SPI_BUS property, and from then on we have mayhem in atspi
with two concurrent atspi stacks running.

Merge request is here -> 
https://gitlab.gnome.org/GNOME/at-spi2-core/merge_requests/24

This would be triggered, ie, if an advanced user runs a program via su 
from the terminal and DBUS_SESSION_BUS_ADDRESS is not propagated. 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.

Thanks,
-MikeFrom 828048bfb4561c232dc668897f8203a3540edb0e Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Fri, 6 Sep 2019 03:33:51 +0200
Subject: [PATCH 1/3] at-spi-bus-launcher: clear a11y_bus_pid when failing to
 read address

This may happen if dbus-daemon spawns but fails to start. In that case after
terminating it we should forget its pid, to avoid trying to terminate it
again at the end of main().
---
 bus/at-spi-bus-launcher.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bus/at-spi-bus-launcher.c b/bus/at-spi-bus-launcher.c
index 6cb625c..57727c1 100644
--- a/bus/at-spi-bus-launcher.c
+++ b/bus/at-spi-bus-launcher.c
@@ -323,6 +323,7 @@ ensure_a11y_bus_daemon (A11yBusLauncher *app, char *config_path)
 {
   app->a11y_launch_error_message = g_strdup_printf ("Failed to read address: %s", strerror (errno));
   kill (app->a11y_bus_pid, SIGTERM);
+  app->a11y_bus_pid = -1;
   goto error;
 }
   close (app->pipefd[0]);
-- 
2.22.0


From 1e43ac742c7622beaa40902777a017efa3af2402 Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Fri, 6 Sep 2019 03:39:30 +0200
Subject: [PATCH 2/3] at-spi-bus-launcher: Only clear AT_SPI_BUS X prop when
 having set it

In case where bus name acquisition fails, we shall not drop the
AT_SPI_BUS X property of the existing daemon.
---
 bus/at-spi-bus-launcher.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/bus/at-spi-bus-launcher.c b/bus/at-spi-bus-launcher.c
index 57727c1..af85f04 100644
--- a/bus/at-spi-bus-launcher.c
+++ b/bus/at-spi-bus-launcher.c
@@ -63,6 +63,9 @@ typedef struct {
   /* -1 == error, 0 == pending, > 0 == running */
   int a11y_bus_pid;
   char *a11y_bus_address;
+#ifdef HAVE_X11
+  gboolean x11_prop_set;
+#endif
   int pipefd[2];
   int listenfd;
   char *a11y_launch_error_message;
@@ -480,6 +483,7 @@ ensure_a11y_bus (A11yBusLauncher *app)
(guchar *) app->a11y_bus_address, strlen (app->a11y_bus_address));
   XFlush (display);
   XCloseDisplay (display);
+  app->x11_prop_set = TRUE;
 }
 }
 #endif
@@ -886,7 +890,7 @@ main (intargc,
* we don't want early login processes to pick up the stale address.
*/
 #ifdef HAVE_X11
-  if (g_getenv ("DISPLAY") != NULL && g_getenv ("WAYLAND_DISPLAY") == NULL)
+  if (_global_app->x11_prop_set)
 {
   Display *display = XOpenDisplay (NULL);
   if (display)
-- 
2.22.0


From 018443b7a8ad0b6f068c2255adcb49037a388d15 Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Fri, 6 Sep 2019 03:40:53 +0200
Subject: [PATCH 3/3] at-spi-bus-launcher: defer starting atspi bus after bus
 name acquired

In case bus name acquisition fails, we should not have started a bus
after all, but worse, we should not have written its address in the
AT_SPI_BUS X root property. We should thus do them only after having
acquired the bus name.
---
 bus/at-spi-bus-launcher.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/bus/at-spi-bus-launcher.c b/bus/at-spi-bus-launcher.c
index af85f04..b4f49b8 100644
--- a/bus/at-spi-bus-launcher.c
+++ b/bus/at-spi-bus-launcher.c
@@ -683,16 +683,6 @@ on_bus_acquired (GDBusConnection *connection,
 }
   app->session_bus = connection;
 
-  if (app->launch_immediately)
-{
-  ensure_a11y_bus (app);
-  if (app->state == A11Y_BUS_STATE_ERROR)
-{
-  g_main_loop_quit (app->loop);
-  return;
-}
-}
-
   error = NULL;
   registration_id = g_dbus_connection_register_object (connection,
"/org/a11y/bus",
@@ -734,6 +724,18 @@ on_name_acquired (GDBusConnection *connection,
   const gchar *name,
   gpointer user_data)
 {
+  A11yBusLauncher *app = user_data;
+
+  if (app->launch_immediately)
+{
+  ensure_a11y_bus (app);
+  if (app->state == A11Y_BUS_

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: Second Epiphany freeze break request

[mcatanzaro]

On Thu, Sep 5, 2019 at 6:14 PM, Javier Jardón  
wrote:

One approval for you


Any seconds?


___
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: Third Epiphany freeze break request

[Andre Klapper]

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.

andre
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


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

Third Epiphany freeze break request

[mcatanzaro]

Hi,

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.

Michael


___
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

[Javier Jardón]

One approval for you

On Thu, 5 Sep 2019, 21:22 ,  wrote:

> Hi,
>
> Due to some changes in WebKit, some code that could previously be
> reached only once is now run multiple times. So Epiphany needs to be
> more careful about not doing one-time things there, like connecting to
> signals.
>
> This commit:
>
> https://gitlab.gnome.org/GNOME/epiphany/merge_requests/421/diffs
>
> just moves the signal connections to a safer place.
>
> Michael
>
>
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> 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.

Second Epiphany freeze break request

[mcatanzaro]

Hi,

Due to some changes in WebKit, some code that could previously be 
reached only once is now run multiple times. So Epiphany needs to be 
more careful about not doing one-time things there, like connecting to 
signals.


This commit:

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

just moves the signal connections to a safer place.

Michael


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

Re: Freeze break request: Tracker and Tracker-miners

[Matthias Clasen via release-team]

Approval 2/2

On Thu, Sep 5, 2019 at 1:03 PM  wrote:

>
> Looks fine, approval 1/2
>
>
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> 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: Freeze break request: Tracker and Tracker-miners

[mcatanzaro]

Looks fine, approval 1/2


___
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 for GLib

[Philip Withnall]

On Thu, 2019-09-05 at 14:49 +0100, Emmanuele Bassi wrote:
> On , mcatanz...@gnome.org wrote:
> > On Thu, Sep 5, 2019 at 5:08 AM, Philip Withnall 
> >  wrote:
> > > I would like to make the GLib 2.62.0 release tomorrow morning
> > > (Friday
> > > 6th) due to being away from the afternoon onwards. Can I get a
> > > couple
> > > of approvals before then?
> > 
> > Approval 1/2
> 
> 2/2.
> 
> If you can't make a release on Friday, I can do that for you.

Merged, thanks! I’m making the GLib 2.62.0 release now (or, failing
that, tomorrow morning).

Philip


signature.asc
Description: This is a digitally signed message part
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Freeze break request: Tracker and Tracker-miners

[Sam Thursfield via release-team]

Hello,
We have 2 merge requests outstanding for Tracker that we want to merge
before 2.3.0. They are related to a new feature, storing MusicBrainz IDs
for music files.
We found a problem in how it's implemented, and we need to merge these two
patches to fix it:

https://gitlab.gnome.org/GNOME/tracker/merge_requests/125
https://gitlab.gnome.org/GNOME/tracker-miners/merge_requests/101

Let me know if it's OK to merge them during the code freeze!
Thanks
___
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 for GLib

[Emmanuele Bassi]

On , mcatanz...@gnome.org wrote:
On Thu, Sep 5, 2019 at 5:08 AM, Philip Withnall 
 wrote:

I would like to make the GLib 2.62.0 release tomorrow morning (Friday
6th) due to being away from the afternoon onwards. Can I get a couple
of approvals before then?


Approval 1/2


2/2.

If you can't make a release on Friday, I can do that for you.

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 for GLib

[mcatanzaro]

On Thu, Sep 5, 2019 at 5:08 AM, Philip Withnall 
 wrote:

I would like to make the GLib 2.62.0 release tomorrow morning (Friday
6th) due to being away from the afternoon onwards. Can I get a couple
of approvals before then?


Approval 1/2


___
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

[mcatanzaro]

On Thu, Sep 5, 2019 at 7:45 AM, Emmanuele Bassi  
wrote:

RT approval 1/2.


Approval 2/2


___
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.

GNOME Shell freeze break request

[Iain Lane]

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.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]

¹ But someone had already reported
  https://gitlab.gnome.org/GNOME/gnome-shell/issues/1557


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

Code freeze break request for GLib

[Philip Withnall]

Hi all,

Christian has a nice fix for a bug with some of the new GDateTime API
for file attributes, which eases porting from
g_file_info_get_modification_time() to
g_file_info_get_modification_date_time().

https://gitlab.gnome.org/GNOME/glib/merge_requests/1087

I’d like to get this into 2.62, since it means the new API doesn’t
require people to add G_FILE_ATTRIBUTE_TIME_MODIFIED_USEC to their
GFileInfo queries to keep things working. It’s a low-risk fix, and I’ve
requested that a unit test be added.

I would like to make the GLib 2.62.0 release tomorrow morning (Friday
6th) due to being away from the afternoon onwards. Can I get a couple
of approvals before then?

Thanks,
Philip


signature.asc
Description: This is a digitally signed message part
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request to fix gnome-initial-setup

[Matthias Clasen via release-team]

Approval 2/2

On Wed, Sep 4, 2019 at 11:14 AM  wrote:

>
> Approval +1 / 2 for both changes
>
>
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> 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: Freeze break request to fix gnome-initial-setup

[mcatanzaro]

Approval +1 / 2 for both changes


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

Freeze break request to fix gnome-initial-setup

[Benjamin Berg]

Hi,

a few fixes are needed for gnome-initial-setup. Both changes are quit
straight forward.

See https://gitlab.gnome.org/GNOME/gnome-initial-setup/merge_requests/58

To be precise, two patches:
 * data: Flag gnome-initial-setup.desktop as being systemd managed
   -> This was an oversight in the original patch series
 * data: Always install .wants symlinks
   -> This means the services are enabled automatically (rather then
  requiring running "systemctl --user enable")

Benjamin

PS: There was also a revert in GDM which was important to get gnome-
initial-setup working again:
  https://gitlab.gnome.org/GNOME/gdm/merge_requests/82


signature.asc
Description: This is a digitally signed message part
___
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: freeze break request: use after free in at-spi2-core

[mcatanzaro]

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


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

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

[Mike Gorse]

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

Thanks,
-MikeFrom df14bede0fa6169c9166821bbf24b9727241376a Mon Sep 17 00:00:00 2001
From: Mike Gorse 
Date: Tue, 3 Sep 2019 15:55:37 -0500
Subject: [PATCH] Fix use after free when freeing an event

---
 atspi/atspi-event-listener.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/atspi/atspi-event-listener.c b/atspi/atspi-event-listener.c
index 05b3977..249890b 100644
--- a/atspi/atspi-event-listener.c
+++ b/atspi/atspi-event-listener.c
@@ -892,8 +892,8 @@ atspi_event_free (AtspiEvent *event)
   g_object_unref (event->source);
   g_free (event->type);
   g_value_unset (&event->any_data);
-  g_free (event);
   g_object_unref (event->sender);
+  g_free (event);
 }
 
 static gboolean
-- 
2.22.0

___
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 request for GNOME Shell

[mcatanzaro]

On Tue, Sep 3, 2019 at 1:17 PM, Matthias Clasen via release-team 
 wrote:

Tentatively ok with it, but I left a comment.
And since this has some string additions, please also ask 
gnome-i...@gnome.org for their ok.


It's not great to see this so late, but here's your second +1


___
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 request for GNOME Shell

[Matthias Clasen via release-team]

On Tue, Sep 3, 2019 at 2:05 PM Georges Basile Stavracas Neto via
release-team  wrote:

> To the Release Team,
>
> I hereby ask for String and UI freeze break exceptions for landing GNOME
> Shell's
> https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/675. This merge
> request is an important last step for feature-completeness of the ability
> to create
> and delete folders within GNOME Shell.
>
>
Tentatively ok with it, but I left a comment.
And since this has some string additions, please also ask
gnome-i...@gnome.org for their ok.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

String & UI Freeze break request for GNOME Shell

[Georges Basile Stavracas Neto via release-team]

To the Release Team,

I hereby ask for String and UI freeze break exceptions for landing 
GNOME Shell's
<https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/675>. This 
merge
request is an important last step for feature-completeness of the 
ability to create

and delete folders within GNOME Shell.

With respect,
Georges

___
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

[Matthias Clasen via release-team]

Looks fine to me too. approval 2/2

On Tue, Sep 3, 2019 at 11:18 AM Emmanuele Bassi  wrote:

> 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.
>
___
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.

Code freeze break request

[mcatanzaro]

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.


Thanks,

Michael


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

Re: Hard code freeze break approval plea for Evolution

[mcatanzaro]

On Tue, Sep 3, 2019 at 7:20 AM, Milan Crha via release-team 
 wrote:

It already landed, that's why I initiated the mail/plea here:
https://trac.webkit.org/changeset/249421/webkit


I know, but I don't like it. I think WebKit should revert whatever 
needs to be reverted to get back to its old behavior for 2.26 so apps 
don't have to use the environment variable. The envvar will lead to a 
disaster of apps patching themselves to use this temporary envvar that 
won't work anymore in 2.28, and it could jeopardize our ability to 
update WebKit in Debian. I really don't think it's OK even as an 
emergency workaround.


I know this is a very tricky bug. Let's continue the discussion in 
WebKit Bugzilla.



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

Re: Hard code freeze break approval plea for Evolution

[Milan Crha via release-team]

On Tue, 2019-09-03 at 05:31 -0500, mcatanz...@gnome.org wrote:
> On Tue, Sep 3, 2019 at 4:24 AM, Milan Crha via release-team 
>  wrote:
> >g_setenv ("WEBKIT_USE_SINGLE_WEB_PROCESS", "1", FALSE);

Hi,
for Andre, that ^^^ is the code. Just that line added into the main.c.

> -1 from me, even as an emergency workaround (and I do understand
> this is an emergency, with release due next week) I don't think a
> new environment variable is acceptable.

It already landed, that's why I initiated the mail/plea here:
https://trac.webkit.org/changeset/249421/webkit

> We should continue discussion in 
> https://bugs.webkit.org/show_bug.cgi?id=201033.

Yes, yes, it doesn't close the WebKit bug, I thought I'm clear about
that. That's why I call it a workaround.
Bye,
Milan


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

Re: Hard code freeze break approval plea for Evolution

[mcatanzaro]

On Tue, Sep 3, 2019 at 4:24 AM, Milan Crha via release-team 
 wrote:

   g_setenv ("WEBKIT_USE_SINGLE_WEB_PROCESS", "1", FALSE);


-1 from me, even as an emergency workaround (and I do understand this 
is an emergency, with release due next week) I don't think a new 
environment variable is acceptable.


There are other ways to solve this, whether by reverting WebKitGTK 2.26 
to the old single process behavior, or by adding a new API to trigger 
the single-process mode, or by making more extensive changes in 
Evolution. We should continue discussion in 
https://bugs.webkit.org/show_bug.cgi?id=201033.


Michael


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

Re: Hard code freeze break approval plea for Evolution

[Andre Klapper]

Hi Milan,

is there a patch to review somewhere available?
Cannot approve code changes without code. :)

Thanks,
andre

On Tue, 2019-09-03 at 11:24 +0200, Milan Crha via release-team wrote:
>   Hello,
> after a lengthy investigation around changes in WebKitGTK+ 2.25.x
> [1],
> there was found a way to workaround the problem [2] for now, which
> gives time to look for better solution in the future.
>
> The change on the Evolution side is as simple as setting an
> environment
> variable in its main(), to let WebKitGTK+ know the old behavior is
> required, something like:
>
>g_setenv ("WEBKIT_USE_SINGLE_WEB_PROCESS", "1", FALSE);
>
> This won't break older WebKitGTK+, because it doesn't know about that
> new environment variable, and it'll help with the new WebKitGTK+. The
> variable addition will be part of 2.25.92 release of WebKitGTK+.
>   Thanks and bye,
>   Milan
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=201033
> [2] https://gitlab.gnome.org/GNOME/evolution/issues/587
>
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


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

Hard code freeze break approval plea for Evolution

[Milan Crha via release-team]

Hello,
after a lengthy investigation around changes in WebKitGTK+ 2.25.x [1],
there was found a way to workaround the problem [2] for now, which
gives time to look for better solution in the future.

The change on the Evolution side is as simple as setting an environment
variable in its main(), to let WebKitGTK+ know the old behavior is
required, something like:

   g_setenv ("WEBKIT_USE_SINGLE_WEB_PROCESS", "1", FALSE);

This won't break older WebKitGTK+, because it doesn't know about that
new environment variable, and it'll help with the new WebKitGTK+. The
variable addition will be part of 2.25.92 release of WebKitGTK+.
Thanks and bye,
Milan

[1] https://bugs.webkit.org/show_bug.cgi?id=201033
[2] https://gitlab.gnome.org/GNOME/evolution/issues/587

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

Re: Feature freeze break request for Sushi

[Andre Klapper]

On Tue, 2019-08-27 at 17:51 +0300, mcatanz...@gnome.org wrote:
> In that case, approval 1 / 2.

...and the second r-t approval.

andre
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


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

Re: UI freeze break request for g-c-c

[Andre Klapper]

On Tue, 2019-08-27 at 17:50 +0300, mcatanz...@gnome.org wrote:
> Approval 1 / 2

Yes please. r-t approval 2/2.

andre
--
Andre Klapper  |  ak...@gmx.net
https://blogs.gnome.org/aklapper/


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

Re: UI freeze break request for g-c-c

[mcatanzaro]

Copying the original mail below, because this got stuck in the 
moderation queue:


On Tue, Aug 27, 2019 at 4:17 PM, Gunnar Hjalmarsson 
 wrote:

Hello release team,

I'd like to request a freeze break to allow the merge of:

<https://gitlab.gnome.org/GNOME/gnome-control-center/merge_requests/507>

into 3.34. It completes the fix of

<https://gitlab.gnome.org/GNOME/gnome-desktop/issues/50>

The part in gnome-desktop, including the API which the 
gnome-control-center change depends on, is already in.


The remaining g-c-c change affects the display of certain items in 
the Language widget in Region & Language, meaning that for instance 
the item


Serbian Serbia

which actually refers to the latin locale will instead be shown as

Serbian (Latin) Serbia

to distinguish it from the cyrillic locale which will keep being 
shown as


Serbian Serbia

The g-c-c change does not add any new strings to be translated - that 
has already be taken care of in gnome-desktop.


The merge request has been reviewed and otherwise cleared by Robert 
Ancell.


Thanks for your consideration!

--
Cheers,

Gunnar Hjalmarsson
<https://launchpad.net/~gunnarhj>


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