people.gnome.org SSH public key change

[Andrea Veri]

Hey,

we recently rebuild the node that was running people.gnome.org and as
such the SSH public keys for the host changed.

The SSHFP entries have been updated to reflect this.

Thanks!

-- 
Cheers,

Andrea

Red Hatter,
Fedora / EPEL packager,
GNOME Infrastructure Team Coordinator,
Former GNOME Foundation Board of Directors Secretary,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: http://www.gnome.org/~av
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[mcatanzaro]

On Tue, Feb 13, 2018 at 3:43 AM, Sébastien Wilmet  
wrote:
The list is not complete, there is for example gedit as well, I think 
it

was common to *not* list gnome-common as dependency in the jhbuild
modulesets because libraries like gtk was already depending on it.


Hm, indeed, gedit does not use gnome-autogen but it does use 
GNOME_COMPILE_WARNINGS. It must be getting pulled into the build 
environment by one of its dependencies.



Also, I think it's a bit a waste of effort to first port to
autoconf-archive macros, and then porting to meson just a few
development cycles later.


Getting rid of gnome-common takes about 10 minutes at worst, but 
porting to meson is a much larger effort!


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Bastien Nocera]

On Tue, 2018-02-13 at 15:13 +0100, Frederic Peters wrote:
> > On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote:
> > > Work is in progress to let maintainers upload tarballs with the
> > > generate API reference for developer.gnome.org
> > 
> > Hi,
> > okay, how is that supposed to work in general? As Meson builds out
> > of
> > the source tree, is that "work in progress" meant to be Meson
> > specific?
> 
> Developer.gnome.org still looks for "markers" in source tarballs
> (like
> include gtk-doc.make in Makefile.am) and use those to extract the
> documentation module name (ex: for gtk+ it would extract three doc
> modules, gtk4, gdk4, gsk4).
> 
> What's new and in progress is the possibility to map those modules to
> external documentation tarballs that will contain the generated HTML
> files.
> 
> Some parts of the process are in place already, from manually
> generated documentation tarballs for GTK+, published at:
>   https://download.gnome.org/docs/gtk+/3.93/
> we can now create https://developer.gnome.org/gtk4/3.93/
> 
> (this is very fresh, literally two days ago)
> 
> Now no maintainer would want the burden to generate those additional
> tarballs and they should be automatically created and published by a
> CI system (gnome continuous or buildstream or whatever).
> 
> Wrt evolution developer.gnome.org still lacks the code to find the
> gtk-doc markers in CMakeLits.txt files. (some experimental code was
> added for meson as used in GTK+)

I have a few platform-level daemons that could do with having their
gtk-doc on developer.gnome.org. Is there an example of what commands
would need to be run to create and package the docs, and how to get
them installed on gnome.org?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Frederic Peters]

Milan Crha wrote:

> On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote:
> > Work is in progress to let maintainers upload tarballs with the
> > generate API reference for developer.gnome.org
> 
>   Hi,
> okay, how is that supposed to work in general? As Meson builds out of
> the source tree, is that "work in progress" meant to be Meson specific?

Developer.gnome.org still looks for "markers" in source tarballs (like
include gtk-doc.make in Makefile.am) and use those to extract the
documentation module name (ex: for gtk+ it would extract three doc
modules, gtk4, gdk4, gsk4).

What's new and in progress is the possibility to map those modules to
external documentation tarballs that will contain the generated HTML
files.

Some parts of the process are in place already, from manually
generated documentation tarballs for GTK+, published at:
  https://download.gnome.org/docs/gtk+/3.93/
we can now create https://developer.gnome.org/gtk4/3.93/

(this is very fresh, literally two days ago)

Now no maintainer would want the burden to generate those additional
tarballs and they should be automatically created and published by a
CI system (gnome continuous or buildstream or whatever).

Wrt evolution developer.gnome.org still lacks the code to find the
gtk-doc markers in CMakeLits.txt files. (some experimental code was
added for meson as used in GTK+)


Frederic
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Milan Crha]

On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote:
> Work is in progress to let maintainers upload tarballs with the
> generate API reference for developer.gnome.org

Hi,
okay, how is that supposed to work in general? As Meson builds out of
the source tree, is that "work in progress" meant to be Meson specific?

Personally, I'd not include those gtk-doc and help generated files in
the tarballs, because they are there "twice" then, but I know of the
older thread where some distro(s) preferred in-tarball documentation
over generating them during build time (which saves time for their
users/build machines, in price of larger tarballs for everyone); some
distros rebuild help/gtk-doc always, no matter whether they are in the
tarball or not.
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Frederic Peters]

Emmanuele Bassi wrote:

> > I do not want to steal the thread, but when talking about ports to
> > Meson, would it make sense to finally fix the infrastructure to work
> > with other than automake files too [1]? It's when generating the
> > content for developer.|help.gnome.org. Considering that plenty of
> > projects already use Meson, either exclusively or as an alternative for
> > autotools scripts, then it would be a good idea, from my point of view.
> > I'd help myself there, but I do no speak pythonish. I guess someone
> > with the knowledge would have that fixed relatively quickly.
> 
> Work is in progress to let maintainers upload tarballs with the
> generate API reference for developer.gnome.org; I assume
> help.gnome.org would follow the same pattern — but of course we only
> have one Frederic, so help is indeed welcome.

Actually help.gnome.org is different and easier as the mallard files
can be converted to HTML without a full build environment (contrary to
gtk-doc); a plan is laid out in bugzilla (#785522) and should be quite
simple for anybody with some Python experience:

  https://git.gnome.org/browse/library-web/tree/src/lgo.py#n700 should
  be updated to detect other cases, like looking for "set(HELPID" in
  CMakeLists.txt files, or help_files in meson.build.

  Then 
https://git.gnome.org/browse/library-web/tree/src/modtypes/mallard.py#n240
  should be changed to get the list of mallard files from those
  CMakeLists.txt/meson.build files. (alternatively it could just take
  pages and figures and list of languages looking at the filesystem but
  then it may fail with pages/languages that are present in git but not
  supposed to be used).


Frederic
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Emmanuele Bassi]

On 13 February 2018 at 11:17, Milan Crha  wrote:
> On Tue, 2018-02-13 at 09:33 +, Philip Withnall wrote:
>> porting the build systems of those modules to Meson is another
>> legitimate way to port away from gnome-common. It would be the better
>> choice in the long run for modules we are going to be maintaining for
>> a while.
>
> Hi,
> I do not want to steal the thread, but when talking about ports to
> Meson, would it make sense to finally fix the infrastructure to work
> with other than automake files too [1]? It's when generating the
> content for developer.|help.gnome.org. Considering that plenty of
> projects already use Meson, either exclusively or as an alternative for
> autotools scripts, then it would be a good idea, from my point of view.
> I'd help myself there, but I do no speak pythonish. I guess someone
> with the knowledge would have that fixed relatively quickly.

Work is in progress to let maintainers upload tarballs with the
generate API reference for developer.gnome.org; I assume
help.gnome.org would follow the same pattern — but of course we only
have one Frederic, so help is indeed welcome.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Milan Crha]

On Tue, 2018-02-13 at 09:33 +, Philip Withnall wrote:
> porting the build systems of those modules to Meson is another
> legitimate way to port away from gnome-common. It would be the better
> choice in the long run for modules we are going to be maintaining for
> a while.

Hi,
I do not want to steal the thread, but when talking about ports to
Meson, would it make sense to finally fix the infrastructure to work
with other than automake files too [1]? It's when generating the
content for developer.|help.gnome.org. Considering that plenty of
projects already use Meson, either exclusively or as an alternative for
autotools scripts, then it would be a good idea, from my point of view.
I'd help myself there, but I do no speak pythonish. I guess someone
with the knowledge would have that fixed relatively quickly.
Thanks and bye,
Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=785522
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Sébastien Wilmet]

On Mon, Feb 12, 2018 at 07:08:34PM -0600, mcatanz...@gnome.org wrote:
> I want to remove gnome-common from our BuildStream projects, but a few
> modules are still depending on it: gcr, gnome-autoar, libnotify,
> adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas.

The list is not complete, there is for example gedit as well, I think it
was common to *not* list gnome-common as dependency in the jhbuild
modulesets because libraries like gtk was already depending on it.

Also, I think it's a bit a waste of effort to first port to
autoconf-archive macros, and then porting to meson just a few
development cycles later.

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Carlos Soriano]

Thanks Bastien.

> Or better port to meson.

Yeah that sounds like a better task.

Carlos Soriano
GNOME Board of Directors

On 13 February 2018 at 10:20, Bastien Nocera  wrote:

> On Tue, 2018-02-13 at 10:08 +0100, Carlos Soriano wrote:
> > Hi Michael,
> >
> > Could you give some context and explanation on this? I could take the
> > gnome-autoar, but need to know why this is wanted and the alternative
> > to gnome-common.
>
> When the wiki comes back:
> https://wiki.gnome.org/Projects/GnomeCommon/Migration
>
> Discussion dates back from May 2015.
>
> Or better port to meson.
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Bastien Nocera]

On Tue, 2018-02-13 at 10:08 +0100, Carlos Soriano wrote:
> Hi Michael,
> 
> Could you give some context and explanation on this? I could take the
> gnome-autoar, but need to know why this is wanted and the alternative
> to gnome-common.

When the wiki comes back:
https://wiki.gnome.org/Projects/GnomeCommon/Migration

Discussion dates back from May 2015.

Or better port to meson.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Philip Withnall]

On Tue, 2018-02-13 at 10:08 +0100, Carlos Soriano wrote:
> Hi Michael,
> 
> Could you give some context and explanation on this? I could take the
> gnome-autoar, but need to know why this is wanted and the alternative
> to gnome-common.

Handily all written up a while ago:

https://wiki.gnome.org/Projects/GnomeCommon/Migration

This was written up before Meson was a thing; porting the build systems
of those modules to Meson is another legitimate way to port away from
gnome-common. It would be the better choice in the long run for modules
we are going to be maintaining for a while.

Philip

> On 13 February 2018 at 02:08,  wrote:
> > Hi,
> > 
> > I want to remove gnome-common from our BuildStream projects, but a
> > few modules are still depending on it: gcr, gnome-autoar,
> > libnotify, adwaita-icon-theme, gnome-menus, and gsettings-desktop-
> > schemas.
> > 
> > If you help fix these sad modules, you'll earn the right to say
> > that you helped fix these sad modules.
> > 
> > Thanks,
> > 
> > Michael
> > 
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's kill gnome-common!

[Carlos Soriano]

Hi Michael,

Could you give some context and explanation on this? I could take the
gnome-autoar, but need to know why this is wanted and the alternative to
gnome-common.

Cheers

On 13 February 2018 at 02:08,  wrote:

> Hi,
>
> I want to remove gnome-common from our BuildStream projects, but a few
> modules are still depending on it: gcr, gnome-autoar, libnotify,
> adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas.
>
> If you help fix these sad modules, you'll earn the right to say that you
> helped fix these sad modules.
>
> Thanks,
>
> Michael
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list