Re: gtk changes in the jhbuild moduleset

2016-10-07 Thread Matthias Clasen 
On Fri, Oct 7, 2016 at 11:47 AM, Simon McVittie
 wrote:
> On Fri, 2016-10-07 at 11:14 -0400, Matthias Clasen wrote:
>> On Fri, Oct 7, 2016 at 6:36 AM, Bastien Nocera 
>> wrote:
>> > Which would mean nothing called "gtk+" in the modulesets? Why not
>> > keep
>> > either gtk 3.x or gtk 4.x with that name?
>> >
>> > I'd expect the "gtk+" module to build GTK+ 4.x ("the latest").
>>
>> I have no strong opinion on this. Not having gtk+ in the moduleset
>> doesn't seem like a big deal to me. The + in the name is a bit
>> awkward, tbh.
>
> Losing the gtk+ module would mean third-party modulesets are forced to
> make a decision on whether they want gtk3 or gtk4, which seems like it
> might be desirable?

I ended up naming the modules gtk+-3 and gtk+, and I switched all
existing dependencies in the moduleset to gtk+-3 for now. 3rd party
modules will still have to make a decision. We can change the name to
gtk+-4 if that is preferred.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME 3.22.1 stable tarballs due

2016-10-07 Thread Michael Catanzaro 
On Fri, 2016-10-07 at 12:42 +0200, Frederic Peters wrote:
> I'll take this one, as my last release.

Your last release? Are you leaving us? :(
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: gtk changes in the jhbuild moduleset

2016-10-07 Thread Simon McVittie 
On Fri, 2016-10-07 at 11:14 -0400, Matthias Clasen wrote:
> On Fri, Oct 7, 2016 at 6:36 AM, Bastien Nocera 
> wrote:
> > Which would mean nothing called "gtk+" in the modulesets? Why not
> > keep
> > either gtk 3.x or gtk 4.x with that name?
> > 
> > I'd expect the "gtk+" module to build GTK+ 4.x ("the latest").
> 
> I have no strong opinion on this. Not having gtk+ in the moduleset
> doesn't seem like a big deal to me. The + in the name is a bit
> awkward, tbh.

Losing the gtk+ module would mean third-party modulesets are forced to
make a decision on whether they want gtk3 or gtk4, which seems like it
might be desirable?

    S

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

Re: gtk changes in the jhbuild moduleset

2016-10-07 Thread Matthias Clasen 
On Fri, Oct 7, 2016 at 6:36 AM, Bastien Nocera  wrote:
> On Fri, 2016-10-07 at 06:33 -0400, Matthias Clasen wrote:
>> Hi,
>>
>> we are getting ready to start development of gtk 3.90 in master.
>> To avoid causing lots of breakage and irritation, here is the plan:
>>
>> 1) Switch the modulesets to use the gtk-3-22 branch for the gtk
>> module
>> 2) Rename the gtk module to gtk3
>> 3) Add a gtk4 module that follows master
>> 4) Switch applications over to  use gtk4 as they are found to work
>>
>> If you see a problem with that, please let me know.
>
> Which would mean nothing called "gtk+" in the modulesets? Why not keep
> either gtk 3.x or gtk 4.x with that name?
>
> I'd expect the "gtk+" module to build GTK+ 4.x ("the latest").

I have no strong opinion on this. Not having gtk+ in the moduleset
doesn't seem like a big deal to me. The + in the name is a bit
awkward, tbh.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

hey there. message me to #7172810514

2016-10-07 Thread Flora 
Hey hottie, I saw you on a dating site sometime last week, i got sum freakypic 
for you..

text my # real fast its 7172810514.

I'm just a 23 year old female. I'm looking to meet new people and maybe hookup.
text me when you get a chance plz.

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

aravis 0.5.5

2016-10-07 Thread Emmanuel Pacaud 
News


  * build: fix library detection needed for packet socket support (Hubert)
  * gigevision: new API for automatic stream packet size (Emmanuel)



Download

https://download.gnome.org/sources/aravis/0.5/aravis-0.5.5.tar.xz (494K)
  sha256sum: 01fe71f85f193d7c9946804ac690e9adfcc54f5006879206dc13f03b8a7f3f09

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

Re: GNOME 3.22.1 stable tarballs due

2016-10-07 Thread Frederic Peters 
Hey,

> Tarballs are due on 2016-10-10 before 23:59 UTC for the GNOME 3.22.1
> stable release, which will be delivered on Wednesday. Modules which
> were proposed for inclusion should try to follow the unstable schedule
> so everyone can test them.  Please make sure that your tarballs will
> be uploaded before Monday 23:59 UTC: tarballs uploaded later than that
> will probably be too late to get in 3.22.1. If you are not able to
> make a tarball before this deadline or if you think you'll be late,
> please send a mail to the release team and we'll find someone to roll
> the tarball for you!

I'll take this one, as my last release.



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

Re: gtk changes in the jhbuild moduleset

2016-10-07 Thread Bastien Nocera 
On Fri, 2016-10-07 at 06:33 -0400, Matthias Clasen wrote:
> Hi,
> 
> we are getting ready to start development of gtk 3.90 in master.
> To avoid causing lots of breakage and irritation, here is the plan:
> 
> 1) Switch the modulesets to use the gtk-3-22 branch for the gtk
> module
> 2) Rename the gtk module to gtk3
> 3) Add a gtk4 module that follows master
> 4) Switch applications over to  use gtk4 as they are found to work
> 
> If you see a problem with that, please let me know.

Which would mean nothing called "gtk+" in the modulesets? Why not keep
either gtk 3.x or gtk 4.x with that name?

I'd expect the "gtk+" module to build GTK+ 4.x ("the latest").
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

gtk changes in the jhbuild moduleset

2016-10-07 Thread Matthias Clasen 
Hi,

we are getting ready to start development of gtk 3.90 in master.
To avoid causing lots of breakage and irritation, here is the plan:

1) Switch the modulesets to use the gtk-3-22 branch for the gtk module
2) Rename the gtk module to gtk3
3) Add a gtk4 module that follows master
4) Switch applications over to  use gtk4 as they are found to work

If you see a problem with that, please let me know.
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String additions to 'evolution-data-server.gnome-3-22'

2016-10-07 Thread Milan Crha 
Hi,

On Thu, 2016-10-06 at 20:01 +0200, Piotr Drąg wrote:
>   + "Failed to construct refresh_token request"
>   + "Failed to encode new access token to Google secret"
>   + "Failed to get Google secret from credentials"
>   + "Failed to get access token from refresh_token server response"
>   + "Failed to refresh token"
>   + "Refresh token not found in Google secret"
>
> Your commit broke the string freeze. Please revert it in the
> gnome-3-22 branch and ask for a permission, if you want.

ouch, I knew I forgot something. I did know that I'm adding new
strings, I even know that I should ask first, but then I completely
forgot of it when committing to master and I just blindly committed it
to the stable branch as well. I'm sorry for that.

I'm CC'ing the relevant parties and doing the right thing now:

I'd like to ask for a string freeze break in the gnome-3-22 branch for
the evolution-data-server, where I made a change for [bug #771547]
"Internal Google OAuth2 authentication fails with expired token". The
change is somewhat important, because it fixes broken behaviour in
OAuth2 Google tokens handling. I added couple error messages,
translated (quoted above), which can show up in a user interface,
though only in a very very very rare cases, like when users manually
edit or remove the secrets in the seahorse. I didn't want to add
strings without being marked for translation (and diverge from git
master), thus I'd rather left them untranslated. I know this is pretty
late, quite close before the 3.22.1 release, but I hope you'll still
understand the importance of the change.

Let me apologize once again for my failure in the string freeze break
approval procedure, it really wasn't intentional.

Bye,
Milan

[bug #771547] https://bugzilla.gnome.org/show_bug.cgi?id=771547
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.