Re: [Libreoffice-commits] core.git: bin/gla11y

[Christian Lohmaier]

Hi,

On Mon, Mar 5, 2018 at 1:13 PM, Thorsten Behrens  wrote:
> Tomas Chvatal wrote:
>> Anyhow, currently for SUSE/openSUSE needs we are content with 2.7/3.4+
>>
> Then again, our release builders (CentOS6) are still on 2.6 by default
> - or do we use internal python there?

Yes to both.

it is on 2.6 and that is used for build
(PYTHON_FOR_BUILD=/usr/bin/python, and that is 2.6.6), but for
packages internal python is used (--enable-python=internal).

There would be 3.4 available in EPEL though.

ciao
Christian

-- 
Christian Lohmaier, Release Engineer
Tel: +49 30 5557992-60 | IRC: cloph on Freenode
The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: http://www.documentfoundation.org/imprint
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y

[Michael Stahl]

On 05.03.2018 13:13, Thorsten Behrens wrote:
> Tomas Chvatal wrote:
>> Anyhow, currently for SUSE/openSUSE needs we are content with 2.7/3.4+
>>
> Then again, our release builders (CentOS6) are still on 2.6 by default
> - or do we use internal python there?

we could easily switch to --enable-python=fully-internal (also on the
related tinderboxes).

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y

[Thorsten Behrens]

Tomas Chvatal wrote:
> Anyhow, currently for SUSE/openSUSE needs we are content with 2.7/3.4+
> 
Then again, our release builders (CentOS6) are still on 2.6 by default
- or do we use internal python there?

Cheers,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y

[Tomas Chvatal]

Heya,

sorry for late reply, we had conference over a weekend and they blocked
all smtp ports...

Anyhow, currently for SUSE/openSUSE needs we are content with 2.7/3.4+

Actually even 3.4+ is acceptable for us.

Cheers

Tom

Michael Stahl píše v So 03. 03. 2018 v 19:50 +0100:
> hi Tomáš,
> 
> is Python 2.6 support still needed for master / 6.1 ?
> 
> i'd like to bump the requirement to 2.7 if possible, it's really
> painful
> having to bother with 2.6 in this day and age...
> 
> On 02.03.2018 22:54, Thorsten Behrens wrote:
> > libreoffice-comm...@lists.freedesktop.org wrote:
> > > commit 44b4ad7d210097fdaed7dd94c5746b03f43592d3
> > > Author: Thorsten Behrens 
> > > Date:   Fri Mar 2 22:38:18 2018 +0100
> > > 
> > > build fix: disable gla11y for python 2.6
> > > 
> > 
> > Some tinderboxen failing with:
> > 
> > Traceback (most recent call last):
> > File "/tinderbox/buildslave/source/libo-master/bin/gla11y", line
> > 406, in main
> >check_a11y_relation(filename, tree)
> > File "/tinderbox/buildslave/source/libo-master/bin/gla11y", line
> > 255, in check_a11y_relation
> >for obj in root.iter(´object´):
> > AttributeError: _ElementInterface instance has no attribute ´iter´
> 
> (for this new tool, it makes no sense to spend any effort getting it
> to
> run on 2.6, it's enough if it runs on developer's systems and none of
> those are going to have python 2.6 on them)
> 

signature.asc
Description: This is a digitally signed message part
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y

[Michael Stahl]

hi Tomáš,

is Python 2.6 support still needed for master / 6.1 ?

i'd like to bump the requirement to 2.7 if possible, it's really painful
having to bother with 2.6 in this day and age...

On 02.03.2018 22:54, Thorsten Behrens wrote:
> libreoffice-comm...@lists.freedesktop.org wrote:
>> commit 44b4ad7d210097fdaed7dd94c5746b03f43592d3
>> Author: Thorsten Behrens 
>> Date:   Fri Mar 2 22:38:18 2018 +0100
>>
>> build fix: disable gla11y for python 2.6
>>
> Some tinderboxen failing with:
> 
> Traceback (most recent call last):
> File "/tinderbox/buildslave/source/libo-master/bin/gla11y", line 406, in main
>check_a11y_relation(filename, tree)
> File "/tinderbox/buildslave/source/libo-master/bin/gla11y", line 255, in 
> check_a11y_relation
>for obj in root.iter(´object´):
> AttributeError: _ElementInterface instance has no attribute ´iter´

(for this new tool, it makes no sense to spend any effort getting it to
run on 2.6, it's enough if it runs on developer's systems and none of
those are going to have python 2.6 on them)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y

[Samuel Thibault]

Hello,

Thorsten Behrens, on ven. 02 mars 2018 22:54:40 +0100, wrote:
> libreoffice-comm...@lists.freedesktop.org wrote:
> > commit 44b4ad7d210097fdaed7dd94c5746b03f43592d3
> > Author: Thorsten Behrens 
> > Date:   Fri Mar 2 22:38:18 2018 +0100
> >
> > build fix: disable gla11y for python 2.6
> >
> Some tinderboxen failing with:
> 
> Traceback (most recent call last):
> File "/tinderbox/buildslave/source/libo-master/bin/gla11y", line 406, in main
>check_a11y_relation(filename, tree)
> File "/tinderbox/buildslave/source/libo-master/bin/gla11y", line 255, in 
> check_a11y_relation
>for obj in root.iter(´object´):
> AttributeError: _ElementInterface instance has no attribute ´iter´

Oops.  So python2.6's xml parsing is even less capable...

If have submitted https://gerrit.libreoffice.org/#/c/50686/ to allow
python2.6 when lxml is available (or built)

Sorry for he issue, I hope we'll soon be done with these, so we can work
on actually fixing a11y issues :)

Samuel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y

[Thorsten Behrens]

libreoffice-comm...@lists.freedesktop.org wrote:
> commit 44b4ad7d210097fdaed7dd94c5746b03f43592d3
> Author: Thorsten Behrens 
> Date:   Fri Mar 2 22:38:18 2018 +0100
>
> build fix: disable gla11y for python 2.6
>
Some tinderboxen failing with:

Traceback (most recent call last):
File "/tinderbox/buildslave/source/libo-master/bin/gla11y", line 406, in main
   check_a11y_relation(filename, tree)
File "/tinderbox/buildslave/source/libo-master/bin/gla11y", line 255, in 
check_a11y_relation
   for obj in root.iter(´object´):
AttributeError: _ElementInterface instance has no attribute ´iter´

Cheers,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild

[Stephan Bergmann]

On 22.02.2018 13:54, Samuel Thibault wrote:

Miklos Vajna, on jeu. 22 févr. 2018 09:53:43 +0100, wrote:

On Wed, Feb 21, 2018 at 10:11:18AM +0100, Samuel Thibault  
wrote:

Rene Engelhard, on mer. 21 févr. 2018 10:02:08 +0100, wrote:

OK, thanks - and then I wonder why this is ran in "normal" UIConfig targets and
not only in make check...

For the "error" cases (-W none), it makes sense:

« Add to the build process error checking (only the hard errors such as
bogus target names). »

That's really the kind of issues one should get as soon as compilation
time.

Later on I'll add a call in "make check" time for the warnings.


For source code we have warnings for these linter type problems


Err, these are not just "linter type problems". They are undefined
references, just like undefined C references. So the failure belongs to
compilation time. If somebody modifies a .ui file in a way that gets
such undefined reference, compilation itself should really fail, just
like it does when a variable defintion is missing.

The "make check" warnings I mentioned above are *other* kinds of issues,
which would indeed only be tested within make check, made warnings by
default, and turned into errors by Jenkins.


I don't understand the "turned into errors by Jenkins" part.  How would 
that be done?


(And `make check` should ideally be "silent".  We do not want it to 
produce any non-fatal warnings.)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild

[Samuel Thibault]

Hello,

Miklos Vajna, on jeu. 22 févr. 2018 09:53:43 +0100, wrote:
> On Wed, Feb 21, 2018 at 10:11:18AM +0100, Samuel Thibault 
>  wrote:
> > Rene Engelhard, on mer. 21 févr. 2018 10:02:08 +0100, wrote:
> > > OK, thanks - and then I wonder why this is ran in "normal" UIConfig 
> > > targets and
> > > not only in make check...
> > For the "error" cases (-W none), it makes sense: 
> > 
> > « Add to the build process error checking (only the hard errors such as
> > bogus target names). »
> > 
> > That's really the kind of issues one should get as soon as compilation
> > time.
> > 
> > Later on I'll add a call in "make check" time for the warnings.
> 
> For source code we have warnings for these linter type problems

Err, these are not just "linter type problems". They are undefined
references, just like undefined C references. So the failure belongs to
compilation time. If somebody modifies a .ui file in a way that gets
such undefined reference, compilation itself should really fail, just
like it does when a variable defintion is missing.

The "make check" warnings I mentioned above are *other* kinds of issues,
which would indeed only be tested within make check, made warnings by
default, and turned into errors by Jenkins.

Samuel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild

[Miklos Vajna]

Hi Samuel,

On Wed, Feb 21, 2018 at 10:11:18AM +0100, Samuel Thibault  
wrote:
> For the "error" cases (-W none), it makes sense: 
> 
> « Add to the build process error checking (only the hard errors such as
> bogus target names). »
> 
> That's really the kind of issues one should get as soon as compilation
> time.
> 
> Later on I'll add a call in "make check" time for the warnings.

For source code we have warnings for these linter type problems and then
--enable-werror (Jenkins uses it) turns those warnings into errors.

Probably the best would be if the .ui checker would follow the same
pattern, instead of running it twice during 'make check' (which is a
superset of 'make').

Thanks,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild

[Samuel Thibault]

Rene Engelhard, on mer. 21 févr. 2018 10:02:08 +0100, wrote:
> On Wed, Feb 21, 2018 at 09:19:51AM +0100, Samuel Thibault wrote:
> > > Even if installing python-xml (for the actual script) and python3
> > > (for the configure check) it complains about no input files or somesuch
> > > and fails
> > 
> > Indeed, I sent a fix for that
> > 
> > https://gerrit.libreoffice.org/50071
> 
> OK, thanks - and then I wonder why this is ran in "normal" UIConfig targets 
> and
> not only in make check...

For the "error" cases (-W none), it makes sense: 

« Add to the build process error checking (only the hard errors such as
bogus target names). »

That's really the kind of issues one should get as soon as compilation
time.

Later on I'll add a call in "make check" time for the warnings.

Samuel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild

[Rene Engelhard]

Hi,

On Wed, Feb 21, 2018 at 09:19:51AM +0100, Samuel Thibault wrote:
> > Even if installing python-xml (for the actual script) and python3
> > (for the configure check) it complains about no input files or somesuch
> > and fails
> 
> Indeed, I sent a fix for that
> 
> https://gerrit.libreoffice.org/50071

OK, thanks - and then I wonder why this is ran in "normal" UIConfig targets and
not only in make check...

Regards,

Rene
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild

[Samuel Thibault]

Stephan Bergmann, on mer. 21 févr. 2018 09:26:03 +0100, wrote:
> Drop the shebang line and call it as `$(PYTHON) $(SRCDIR)/bin/gla11y` from
> the makefile?

It's still be useful to keep the shebang for people to be also able to
run it directly as shell command, but we can force the python shell from
the makefile indeed, will submit that.

Samuel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild

[Stephan Bergmann]

On 21.02.2018 09:19, Samuel Thibault wrote:

Rene Engelhard, on mer. 21 févr. 2018 09:11:02 +0100, wrote:

diff --git a/bin/gla11y b/bin/gla11y
new file mode 100755
index ..d0619133ad0f
--- /dev/null
+++ b/bin/gla11y
@@ -0,0 +1,216 @@
+#!/usr/bin/env python


That's "python". Python2.


It works with either python2 or python3


+AC_MSG_CHECKING([for python lxml])
+if $PYTHON -c "import lxml.etree as ET" ; then


Here it checks for lxml in the system python. This is a a 3.x.
Because for python3-uno in Debian, of course python3 is used.
And LOs internal python also is python3.

But the actual script (see above) calls "python" and not "python3"


Mmm, so we should make it a .py.in file to be able to put @PYTHON@ in the 
script?


Drop the shebang line and call it as `$(PYTHON) $(SRCDIR)/bin/gla11y` 
from the makefile?

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild

[Samuel Thibault]

Hello,

Rene Engelhard, on mer. 21 févr. 2018 09:11:02 +0100, wrote:
> Was this ever really tested besides Jenkins (no idea with what build
> config this was tested...)?

I did test it, but apparently not in all potential situations.

> > diff --git a/bin/gla11y b/bin/gla11y
> > new file mode 100755
> > index ..d0619133ad0f
> > --- /dev/null
> > +++ b/bin/gla11y
> > @@ -0,0 +1,216 @@
> > +#!/usr/bin/env python
> 
> That's "python". Python2.

It works with either python2 or python3

> > +AC_MSG_CHECKING([for python lxml])
> > +if $PYTHON -c "import lxml.etree as ET" ; then
> 
> Here it checks for lxml in the system python. This is a a 3.x.
> Because for python3-uno in Debian, of course python3 is used.
> And LOs internal python also is python3. 
> 
> But the actual script (see above) calls "python" and not "python3"

Mmm, so we should make it a .py.in file to be able to put @PYTHON@ in the 
script?

> Even if installing python-xml (for the actual script) and python3
> (for the configure check) it complains about no input files or somesuch
> and fails

Indeed, I sent a fix for that

https://gerrit.libreoffice.org/50071

Samuel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild

[Rene Engelhard]

Hi,

On Tue, Feb 20, 2018 at 09:22:10PM +, Samuel Thibault wrote:
> New commits:
> commit 226697ae27ef451cad404256e83eef88262f16d1
> Author: Samuel Thibault 
> Date:   Fri Feb 16 13:22:10 2018 +0100
> 
> Integrate initial version of gla11y tool in the build system
> 
> This is part of integrating an accessibility non-regression tool. This
> adds checks in configure.ac for the presence of python lxml which we will
> need, and adds support for calling the tool at build time, to check for
> definite UI errors. For now, that only emits errors for missing or 
> duplicate
> accessibility relation targets, and senseless relations: a label being
> mnemonic for several widgets.
> 
> Change-Id: Idda91b15b9a9e0322d16db33dfac8e03f2aa518c
> Reviewed-on: https://gerrit.libreoffice.org/49856
> Tested-by: Jenkins 
> Reviewed-by: Thorsten Behrens 

Was this ever really tested besides Jenkins (no idea with what build
config this was tested...)?

> diff --git a/bin/gla11y b/bin/gla11y
> new file mode 100755
> index ..d0619133ad0f
> --- /dev/null
> +++ b/bin/gla11y
> @@ -0,0 +1,216 @@
> +#!/usr/bin/env python

That's "python". Python2.

[...]

> diff --git a/configure.ac b/configure.ac
> index e20e91e7fa42..479968be94b9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -8148,10 +8148,19 @@ if test $enable_python = system; then
>  fi
>  
>  dnl By now enable_python should be "system", "internal" or "no"
> +PYTHON_LXML=
>  case $enable_python in
>  system)
>  SYSTEM_PYTHON=TRUE
>  
> +AC_MSG_CHECKING([for python lxml])
> +if $PYTHON -c "import lxml.etree as ET" ; then
> +PYTHON_LXML=TRUE
> +AC_MSG_RESULT([yes])
> +else
> +AC_MSG_RESULT([no, will not be able to check UI accessibility])
> +fi
> +
>  dnl Check if the headers really work
>  save_CPPFLAGS="$CPPFLAGS"
>  CPPFLAGS="$CPPFLAGS $PYTHON_CFLAGS"


Here it checks for lxml in the system python. This is a a 3.x.
Because for python3-uno in Debian, of course python3 is used.
And LOs internal python also is python3. 

But the actual script (see above) calls "python" and not "python3"

Even if installing python-xml (for the actual script) and python3
(for the configure check) it complains about no input files or somesuch
and fails

Regards,

Rene
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice