Gtk-Doc Manual in DevHelp

[Sebastian Geiger (Lanoxx)]

Hi all,

I would like to discuss a proposal for bringing the Gtk-Doc Manual into
DevHelp. At the moment the Gtk-Doc manual can be read online at
developer.gnome.org [1] and by using yelp. I think yelp is not as useful
as devhelp for several reasons. The representation is different than in
devhelp, some cross references in the document do not work properly and
there is also no table of contents like devhelp has. While these are my
personal preferences of course I think it would do no harm to provide
the manual for DevHelp in addition to yelp.

I have already prepared patches for installing the Gtk-Doc Manual as
HTML files with DevHelp support. The patches can be found at [2]. I
asked Stefan Sauer the maintainer of Gtk-Doc about merging my patches
but he suggested to have discussion about this change on the mailing
list first. So my question is whether other GNOME developers would find
it useful to have the GTK-Doc manual in DevHelp?

I argue, that since the main target group of Gtk-Doc are developers and
not end-users Devhelp would be a better fit. This way develpers can find
all their documentation at one place (e.g. devhelp) and do not need to
keep two tools open. I would also like to point out that for a long time
I was not aware that the Gtk-Doc manual was available via yelp since the
list of help documents is pretty well hidden. I first thought that yelp
only showed the Ubuntu Documentation until I found that via Hamburger
Menu -> All Help one can access additional manuals.

My patch adds xsltproc to gtk-doc for generating HTML files from the
Gtk-Doc Manual and then uses an install hook to install the html files
and copy the Gtk-Doc stylesheets to $(datadir)/gtk-doc/html/$(HELP_ID).

I have tested my patch and I can view the GTK-Doc Manual in DevHelp. I
would be very happy if this change could be merged into Gtk-Doc.

Best Regards
Sebastian

[1]: https://developer.gnome.org/gtk-doc-manual/

[2]: 
https://gitlab.gnome.org/GNOME/gtk-doc/commit/ffd5f97ed73a670f1b7687d9a39e80f5f7941332

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

Re: Migration of GNOME to GitLab is now completed

[Sebastian Geiger (Lanoxx)]

Hi Carlos,

thanks a lot for this awesome work! I really love the new GitLab and its
issue management features.

Cheers

Sebastian


On 29/05/18 19:00, Carlos Soriano wrote:
> Hello all,
>
> I'm glad to announce that the GNOME migration to GitLab is now completed!
>
> Cgit and git.gnome.org  are now officially gone.
> Everyone should be using GitLab for any new operations, including new
> bugs and git repositories. Bugzilla will stay with redirections for
> new bugs and old bugs will be still be able to be managed for years to
> come (some people were confused by my wording here, feel free to ask
> me for clarification).
>
> Apart of some hickups with glib-networking and some redirection
> issues, the migration went well. Honestly better than expected.
>
> I want to take the opportunity to say thank you all for the effort on
> this adventure that we have been working together for 1 year and a
> half (yeah, that long!). I'm proud of our community that despite the
> difficulty of this kind of change and even if we disagreed here and
> there, we have put our shoulders together to move forward until we
> have achieved it. Again, thanks all.
>
> Things will be still in a bit of flux, and there are some project that
> have special requests for bugs that I'll try to manage on the upcoming
> month, so expect still a bit of movement.
>
> Don't hesitate reaching to me if you have any question or thought.
>
> Cheers,
> Carlos Soriano
>
>
> ___
> 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

Re: Relicensing Nautilus to GPLv3+ / Licence Compatibility Matrix

[Sebastian Geiger (Lanoxx)]

Hi,

I usually find the Compatibility Matrix very useful when thinking about
licensing issues. Since I have not seen it in this thread yet, I thought
I would post the link:

https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

Cheers
Sebastian

On 19/05/17 00:05, Bastien Nocera wrote:
> On Thu, 2017-05-18 at 15:47 -0400, Carlos Soriano wrote:
>> Maybe I didn't explain well. Emilio points out there could one one of
>> those extensions that say GPL2+ to link to a GPL2-only library. But
>> that would make the extension itself GPL2 anyway, and it's License
>> file would have to reflect that initially.
> Again, it wouldn't. The combined work would be GPLv2-only, but each one
> of the items keeps its own license. The licenses are compatible.
>
> You don't have to have an piece of code depending on the exact same
> version of the license if those licenses are compatible. GPLv2-only is
> compatible with GPLv2+, as the license mentions for that dependency
> says:
> "either version 2 of the License, or (at your option) any later
> version."
>
> The selection is "made" automatically when you run those 2 items in the
> same memory address space (eg. when you "link" them).
>
>> It's just a hipotetical case, I checked the extensions dependencies
>> in a quick look and look fine (>= GPL+2).
> ___
> 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

Get Modifiers for Scroll Lock and Num Lock

[Sebastian Geiger (Lanoxx)]

Hi,

is there a way in Glib or GTK+ to detect which of GDK_MOD1_MASK to
GDK_MOD5_MASK maps to Scroll Lock and Num Lock respectively?

I looked at gdk_keymap_map_virtual_modifiers, but it cannot be used,
since Scroll and Num have no corresponding virtual masks in GdkModifierType.

I looked into gdk/x11/gdkkeys-x11.c and saw that the scroll masks are
kept internally but I did not find a way to access them from outside
GTK. Is this deliberate, and if so, why?

Btw. I know about gdk_keymap_get_num_lock_state and
gdk_keymap_get_scroll_lock_state, but I do not want to check if the
locks are enabled, I want to actually know which mod1-mod5 corresponds
to scroll and num lock.

Cheers

Sebastian

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

Re: Help building Gstreamer 1.10 [PATCH ATTACHED]

[Sebastian Geiger (Lanoxx)]

On 11/02/17 16:01, Sam Thursfield wrote:
> Autotools is a pretty hairy codebase, so
> while a fix would be welcome, make sure you don't get eaten by dragons
> along th way :-)
I had to dig rather deep into autotools and make and ended up debugging
g-ir-scanner a litte, a little further and I would probably have lost my
mind.
Anyway, I am trying to be a little more verbose below, so others might
find it useful when they have a similar problem and maybe can save them
selves a little time.

First, here is a little summary of whats happening:

1. The make build tries to build the GstBase-1.0.gir target.
2. The GstBase-1.0.gir target executes g-ir-scanner
3. g-ir-scanner calls the libtool wrapper script
4. the libtools wrapper script calls gcc
5. gcc fails with a link error

I played a little with g-ir-scanner until I got it to not remove the
temporary files[1] and then I was able to execute the libtool command
manually to see what change was required until it did not fail anymore.
It turns out that the problem
is caused by the link directory option ('-L/opt/gnome-build/lib'), which
appeared before the -L options for other directories, by moving it
behind the other -L options I was able to solve the problem (e.g. behind
all of -L/CHECKOUTDIR/gstreamer/gst/.libs -L. ./.libs/libgstbase-1.0.so
-L../../../gst). The following gist shows this a little more clearly:

https://gist.github.com/lanoxx/7c57332a9549a92ef93352e0f293eae9

So the next question is what is causing the -L/opt/gnome-build/lib
option to appear before the other -L options for source and build
directories. My guess was that g-ir-scanner is somehow passing the -L
options in the wrong order to the libtool script. Actually now that I
know what the problem is, I see that this was already obvious in the
error message that I posted in the first mail of this thread.

Emmenuelle Bassi pointed me to dumper.py [2], which prepares all the
arguments to send to libtool. After debugging that script a little I
found that the issue can be solved by delaying the adding of LDFLAGS to
args until the internal link flags have been added to args. I have added
a corresponding bug in bugzilla and provided a patch.

https://bugzilla.gnome.org/show_bug.cgi?id=778507

Could someone please review this and tell me if this is a sane solution?

Cheers
Sebastian

P.S
/opt/gnome-build/ is my jhbuild prefix where the compiled modules are
being installed

[1]: by passing it the environment variable GI_SCANNER_DEBUG=save-temps,
thanks to Emmenuele Bassi for pointing this out
[2]:
https://git.gnome.org/browse/gobject-introspection/tree/giscanner/dumper.py#n209

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

Re: Help building Gstreamer 1.10

[Sebastian Geiger (Lanoxx)]

I have played around with this a little further and found that this
issue is quite easy to reproduce by just going back to build gstreamer
1.8 and then building 1.10 again. Interestingly I got the same issue of
undefined references when building 1.8 (just for different build
artifacts), which again could not be resolved by make uninstalled but by
manually removing a few files under the install dir.

Going back and forth a few times, I was able to verify that this can be
solved by deleting the following three files from the jhbuild install
directory (e.g. /opt/gnome-build for me):

./lib/libgstreamer-1.0.so
./lib/libgstreamer-1.0.so.0
./lib/libgstreamer-1.0.so.0.803.0

Note that these files are actually from a previous gstreamer build (most
likely 1.8), but at the time the error occurs they are still present in
the install directory. Coincidentally jhbuild will try to remove them
when it has finished building the new gstreamer:

I: 6 files remaining from previous build
W: Failed to delete no longer installed file
'/opt/gnome-build/lib/libgstreamer-1.0.so.0.803.0': No such file or
directory

After the build is finished I now see a different gstreamer-1.0.so
version in the install directory:

./lib/libgstreamer-1.0.so
./lib/libgstreamer-1.0.so.0
./lib/libgstreamer-1.0.so.0.1003.0

I would really like to get to the source of this issue and fix it, as I
am pretty sure this is not the first time I have had issues with
building gstreamer.

On 11/02/17 14:53, Sebastian Geiger (Lanoxx) wrote:
> Hi Sam,
>
> thanks for the quick answer, unfortunately make uninstall did not
> resolve the issue. When I searched for files with gstreamer in their
> name or path I still found a lot of files. In the end I removed several
> header files and so files related to gstreamer and that solved the issue.
>
> Could this be related to the autotools build setup? Is there a way to
> fix it?
>
> Cheers
>
> Sebastian
>
> On 11/02/17 13:28, Sam Thursfield wrote:
>> Hi Lanoxx
>>
>> On 2/11/17, Sebastian Geiger (Lanoxx) <lan...@gmx.net> wrote:
>>> Hi,
>>>
>>> I was trying to build gstreamer 1.10 today with jhbuild using the 3.22
>>> module set, and I got the following error:
>> ...
>>
>> I've seen problems like this before which were caused by: a new symbol
>> being added in the source tree, an older version of the library being
>> installed, and the g-ir-scanner linking stuff against the old version
>> that is installed.
>>
>> If 'gst_element_message_full_with_details' and
>> 'gst_make_element_message_details' were recently added then that's
>> probably what's happening here.
>>
>> To work around the issue you can do `make uninstall` in your
>> /home/user/Documents/Code/jh-gnome-checkout/gstreamer/ directory, then
>> try jhbuild again. The g-ir-scanner should now be forced to link
>> against the new libraries in the source tree.
>>
>> This is an annoying bug, I'm not sure what causes it. Possibly some
>> issue in the GI/Autotools integration.
>>
>> Sam
>
> ___
> 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

Re: Help building Gstreamer 1.10

[Sebastian Geiger (Lanoxx)]

Hi Sam,

thanks for the quick answer, unfortunately make uninstall did not
resolve the issue. When I searched for files with gstreamer in their
name or path I still found a lot of files. In the end I removed several
header files and so files related to gstreamer and that solved the issue.

Could this be related to the autotools build setup? Is there a way to
fix it?

Cheers

Sebastian

On 11/02/17 13:28, Sam Thursfield wrote:
> Hi Lanoxx
>
> On 2/11/17, Sebastian Geiger (Lanoxx) <lan...@gmx.net> wrote:
>> Hi,
>>
>> I was trying to build gstreamer 1.10 today with jhbuild using the 3.22
>> module set, and I got the following error:
> ...
>
> I've seen problems like this before which were caused by: a new symbol
> being added in the source tree, an older version of the library being
> installed, and the g-ir-scanner linking stuff against the old version
> that is installed.
>
> If 'gst_element_message_full_with_details' and
> 'gst_make_element_message_details' were recently added then that's
> probably what's happening here.
>
> To work around the issue you can do `make uninstall` in your
> /home/user/Documents/Code/jh-gnome-checkout/gstreamer/ directory, then
> try jhbuild again. The g-ir-scanner should now be forced to link
> against the new libraries in the source tree.
>
> This is an annoying bug, I'm not sure what causes it. Possibly some
> issue in the GI/Autotools integration.
>
> Sam


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

Help building Gstreamer 1.10

[Sebastian Geiger (Lanoxx)]

Hi,

I was trying to build gstreamer 1.10 today with jhbuild using the 3.22
module set, and I got the following error:

  GEN  GstBase-1.0.gir
g-ir-scanner: link: /bin/bash ../../../libtool --mode=link --tag=CC gcc
-o
/home/user/Documents/Code/jh-gnome-checkout/gstreamer/libs/gst/base/tmp-introspectekn2ctot/GstBase-1.0
-export-dynamic -Wall -g -ggdb -O0 -L/opt/gnome-build/lib
tmp-introspectekn2ctot/home/user/Documents/Code/jh-gnome-checkout/gstreamer/libs/gst/base/tmp-introspectekn2ctot/GstBase-1.0.o
-L. libgstbase-1.0.la -L../../../gst
-L/home/user/Documents/Code/jh-gnome-checkout/gstreamer/gst/.libs
-L/opt/gnome-build/lib -lgio-2.0 -Wl,--export-dynamic -lgmodule-2.0
-pthread -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0
libtool: link: gcc -o
/home/user/Documents/Code/jh-gnome-checkout/gstreamer/libs/gst/base/tmp-introspectekn2ctot/.libs/GstBase-1.0
-Wall -g -ggdb -O0
tmp-introspectekn2ctot/home/user/Documents/Code/jh-gnome-checkout/gstreamer/libs/gst/base/tmp-introspectekn2ctot/GstBase-1.0.o
-Wl,--export-dynamic -pthread -Wl,--export-dynamic 
-L/opt/gnome-build/lib -L. ./.libs/libgstbase-1.0.so -L../../../gst
-L/home/user/Documents/Code/jh-gnome-checkout/gstreamer/gst/.libs
-lgio-2.0 -lgmodule-2.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0
-pthread -Wl,-rpath -Wl,/opt/gnome-build/lib
./.libs/libgstbase-1.0.so: undefined reference to
`gst_element_message_full_with_details'
./.libs/libgstbase-1.0.so: undefined reference to
`gst_make_element_message_details'
collect2: error: ld returned 1 exit status
linking of temporary binary failed: Command '['/bin/bash',
'../../../libtool', '--mode=link', '--tag=CC', 'gcc', '-o',
'/home/user/Documents/Code/jh-gnome-checkout/gstreamer/libs/gst/base/tmp-introspectekn2ctot/GstBase-1.0',
'-export-dynamic', '-Wall', '-g', '-ggdb', '-O0',
'-L/opt/gnome-build/lib',
'tmp-introspectekn2ctot/home/user/Documents/Code/jh-gnome-checkout/gstreamer/libs/gst/base/tmp-introspectekn2ctot/GstBase-1.0.o',
'-L.', 'libgstbase-1.0.la', '-L../../../gst',
'-L/home/user/Documents/Code/jh-gnome-checkout/gstreamer/gst/.libs',
'-L/opt/gnome-build/lib', '-lgio-2.0', '-Wl,--export-dynamic',
'-lgmodule-2.0', '-pthread', '-lgstreamer-1.0', '-lgobject-2.0',
'-lglib-2.0']' returned non-zero exit status 1
Makefile:1126: recipe for target 'GstBase-1.0.gir' failed

Can anyone suggest whats is causing this issue? I have already use the
"wipe directory and start over" option from jhbuild, so I do not think
its a problem with left over artefacts from a previous build.

Cheers

Sebastian

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

Re: Documentation for build system setup

[Sebastian Geiger (Lanoxx)]

I have just updated the wiki, please let me know if something I changed
is not right:

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


On 09/02/17 15:03, Emmanuele Bassi wrote:
> On 9 February 2017 at 13:57, Sebastian Geiger (Lanoxx) <lan...@gmx.net> wrote:
>> What confuses me is that this paragraph starts with the phrase "it does
>> not need any modifications made".
>>
>>> It does not need any modifications made, unless you need to run
>>> another tool before configure, or do not use one of glib-gettextize,
>>> gtkdocize or intltoolize. (Note that you should not use both
>>> glib-gettextize and intltoolize in the same module, and it is better
>>> to use neither; see the FAQ entry below for details.)
>> It might be more helpful to provide a autogen.sh listing that omits both
>> glib-gettextize and intltoolize and then add a paragraph explaining to
>> add these for project that use either of these tools. If I understand
>> right both a deprecated anyway and should not be needed for
>> state-of-the-art projects.
>>
>> Maybe write something like this:
>>
>> If you are still using the deprecated glib-gettextize, then add the 
>> following line immediately before
>> autoreconf:
>>
>> glib-gettextize --force --copy || exit 1
>>
>> If you are still using the almost obsolete intltoolize, then add the 
>> following line immediately before
>> autoreconf:
>>
>> intltoolize --force --copy --automake || exit 1
> Those look like good changes, indeed. Feel free to update the wiki.
>
> Ciao,
>  Emmanuele.
>
>> On 09/02/17 11:45, Philip Withnall wrote:
>>> Can we please standardise on the autogen.sh given in
>>> https://wiki.gnome.org/Projects/GnomeCommon/Migration#autogen.sh ?
>>>
>>> It does everything we need, and meets all the standards (like build-
>>> api). If you’ve got improvements to make, please make them on that
>>> page.
>>>
>>> Sebastian: the paragraph immediately above the example does say that
>>> you should remove one or both of the intltoolize/glib-gettextize calls
>>> as appropriate.
>>
>> ___
>> 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

Re: Documentation for build system setup

[Sebastian Geiger (Lanoxx)]

What confuses me is that this paragraph starts with the phrase "it does
not need any modifications made".

> It does not need any modifications made, unless you need to run
> another tool before configure, or do not use one of glib-gettextize,
> gtkdocize or intltoolize. (Note that you should not use both
> glib-gettextize and intltoolize in the same module, and it is better
> to use neither; see the FAQ entry below for details.) 

It might be more helpful to provide a autogen.sh listing that omits both
glib-gettextize and intltoolize and then add a paragraph explaining to
add these for project that use either of these tools. If I understand
right both a deprecated anyway and should not be needed for
state-of-the-art projects.

Maybe write something like this:

If you are still using the deprecated glib-gettextize, then add the following 
line immediately before
autoreconf:

glib-gettextize --force --copy || exit 1

If you are still using the almost obsolete intltoolize, then add the following 
line immediately before
autoreconf:

intltoolize --force --copy --automake || exit 1



On 09/02/17 11:45, Philip Withnall wrote:
> Can we please standardise on the autogen.sh given in
> https://wiki.gnome.org/Projects/GnomeCommon/Migration#autogen.sh ?
>
> It does everything we need, and meets all the standards (like build-
> api). If you’ve got improvements to make, please make them on that
> page.
>
> Sebastian: the paragraph immediately above the example does say that
> you should remove one or both of the intltoolize/glib-gettextize calls
> as appropriate.


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

Documentation for build system setup

[Sebastian Geiger (Lanoxx)]

Hi Gnome Devs,

I was looking at the following overview page today:

https://developer.gnome.org/platform-overview/unstable/
e.g. "platform-overview/3.22/index.page"

I would like to submit the following feedback about this page. An aspect
that I am missing here is
some information about the build system setup. For example most Gnome
Modules are currently
autotools based, they ship an autogen.sh and follow a certain set of
best practices in their
configure.ac and Makefile.am files. It would be great to have an
additional entry on this
page that is maybe named "build automation" or "building the
application" and that contains
some information about how to setup the build system. I would suggest to
limit that
to autotools for the moment but it could be extended to mention meson or
cmake in the
future.

I know we already have a bunch of good documentation on the wiki,
for example:

 https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAutotools
 https://wiki.gnome.org/Initiatives/GnomeGoals/NicerBuilds
 https://wiki.gnome.org/Projects/GnomeCommon/Migration

However it seems to me that none of these pages offers
a really up to date information and consistent summary
of how a typical gnome application should be setup
today.

I guess that there probably exist other wiki pages that I have not found
yet.
I am also pretty certain that I have seen various blog posts on Planet
Gnome about
build system aspects but cant remember the links to them.

A few example questions for which I would hope to find answers in
the documentation are:

1. What are best practices when setting up autogen.sh, is there are
recommended template
to start with. I know the GnomeCommon migration guide lists one, but
I did not find it useful.
In particular because it contains calls to both glib-gettextize and
intltoolize and the page later
mentions that exactly this should not be done.
> Your autogen.sh file might include a call to either glib-gettextize or
> intltoolize. (If it calls both, then you have done something wrong,
> since they don't work properly together.) glib-gettextize is now
> obsoleted by new functionality in upstream gettext, and autoreconf
> will call autopoint automatically.

2. What are best practices regarding builddir!=srcdir builds? Are there
any special steps required when using jhbuild, when I want it to do
out-of-tree builds?

3. What are some recommended macros from autoconf-archive that should be
used?

If there is already a good documentation about this, and I just missed
it, then I apologise for the noise.

Best Regards
Sebastian

P.S. I am cross-posting this on the desktop-devel-list, maybe other
people have some suggestions about this.

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

Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Sebastian Geiger (Lanoxx)]

On 05/10/16 15:39, Michael Biebl wrote:


As much as I hate autotools and its arcane syntax, it does bring
uniformity and consistency.
Atm I'm counting waf (for some non-core modules), autotools, cmake and
some are discussing to use meson/ninja.

So while I'm not tied to autotools, I would hate to see if every
modules maintainer chooses his/her own build system of choice. This
makes it really cumbersome as downstream/integrator.
Maybe it would make sense to introduce an official Gnome Goal that 
encourages every module maintainer to switch over to

meson.

This would of course mean that we already know meson will be the build 
system of choice and that it fits the
needs of all modules. Of course individual module maintainers would 
still be free to make a different choice or to stick with autotools but 
we would at least have something to motivate the migration, to track its 
status across all modules and it would be a push to towards some level 
of consistency. Also we could collect some best practices from modules 
that have already done the conversion on a Gnome Goal page.


Personally I would not mind if we got rid of autotools any time soon.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Continuous Builds in GNOME

[Sebastian Geiger (Lanoxx)]

Hi Emanuelle,

I just wanted to pitch into this discussion and say thanks to you (and 
everyone else working on this) for putting all the effort into fixing 
build issues and improving continuous integration.


I have been a developer for different gnome components for a while, but 
I am not such a frequent contributor that I know all the internals of 
most core components. So when a module breaks during a jhbuild, then I 
am often quite lost and need a few hours of google, asking people at 
#gtk or #gnome as well as trial and error.


Most of the time I just want to "quickly get a fairly recent build" and 
then "write a small patch" to fix something in one of the gnome modules. 
When that happens I may be able to set aside a few hours or half a day 
but not a whole week. However most times this half day is wasted 
battling with jhbuild and trying to get a working environment that not 
only builds glib but which actually comes as far as to build the module 
for which I wanted to write a patch in the first place. When I have 
already spend 4 hours and jhbuild is just building module 20 out of 90, 
and breaking on some unresolvable dependency, missing library, some 
obscure configure or make error or what ever, then this is usually the 
point were I just go and do something else.


So again, all your effort its highly appreciated.

I really hope that at some point in the future its possible to just type 
`jhbuild build` then go away to work on something else when then come 
back to find the build finished and login to the ready jhbuild session. 
If on top of that this would work not only on the most recent fedora 
"from last week" or so, but on the most recent Ubuntu _LTS_ or Debian 
_stable_, then that would be really awesome. And it would mean that I 
could spend more time testing gnome modules, fixing bugs and help to 
improve gnome rather then spending days trying to get all modules building.


Thanks and Cheers
Sebastian

On 03/06/16 10:42, Emmanuele Bassi wrote:

Still, people consider Continuous somebody else's problem; if it
"breaks on Continuous" but not on a maintainer machine, then who
cares?

Even if we magically got the resources (build machines, at least one
person working on the infrastructure side, volunteer work to improve
the tooling), the attitude of "my module is my fiefdom, if a build
breaks*you*  fix it" has to change.


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

gnome-session logging

[Sebastian Geiger (Lanoxx)]

Hi fellow Gnome Devs,

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


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


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


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

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


2. When I look at the journal meta data, I find that all application 
generated output which is all logged under the "gnome-session" tag goes 
through syslog since all entries have the following meta data attached: 
"SYSLOG_IDENTIFIER" : "gnome-session". This means that the journal 
output is much less useful then it could be. I believe that 
gnome-session should be aware from which binary the output is coming 
when it sends it to syslog. So if gnome-session would use 
sd_journal_send and attach some meta data of the originating process 
then we could apply filters to get output only for specific 
applications. Unless there is something I am not aware of then there is 
currently no way to retrieve the log output for individual applications.


This would be particularly useful since many applications to not print 
their application name or pid and so we get log lines like the following:


May 20 08:51:36 earth gnome-session[1172]: ERROR

3. Finally I would like to suggest to add the ability to enable 
gnome-session debug output either through an environment variable or a 
dconf flag to complement the `--debug` option.


If any of this has previously been discussed or even solved in a later 
version (I am still running 3.18) then please give me a pointer to the 
mailing list archive or let me know of the result.


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