Re: [Libreoffice-commits] core.git: bin/gla11y
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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