summaryrefslogtreecommitdiff
path: root/solenv/qa
AgeCommit message (Collapse)Author
2018-01-30Don't let PythonTest_solenv_python fail due to Emacs lock files in SRCDIRStephan Bergmann
Emacs has a habit of placing lock files next to files being edited, which are actually dangling symlinks not pointing at actual files, but where the symlink content itself encodes some information about who locked the file. When such a lock file happens to be present in the source tree during `make PythonTest_solenv_python`, the latter fails because shutil.copytree by default copies files pointed at by symlinks, instead of the symlinks themselves, and causes an error if that fails. An alternative fix would be to call shutil.copytree with symlinks=true (copy symlinks, not the files pointed at) or ignore_dangling_symlinks=true (don't fail if a dangling symlink can't be copied). But for now just don't copy any of those additional files that Emacs likes to place next to edited files (and which are also all ignored in our .gitignore). Change-Id: Ib731a5395fe8d40767878c17b1fb422b914bb329 Reviewed-on: https://gerrit.libreoffice.org/48898 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-11-24gbuild: handle GENCXXCLROBJECTS in gbuildtojsonMichael Stahl
Change-Id: Ib5808a715e4ba0e0a5d9eea8260ea72fd85ccda2
2017-07-21migrate to boost::gettextCaolán McNamara
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl * all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string") * ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching MODULE .mo files * UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui goes from l10n target to normal one, so the res/lang.zips of UI files go away * translation via Translation::get(hrc-define-key, imbued-std::locale) * python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there to keep finding the .hrc file uniform) so magic numbers can go away there * java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation mechanism * en-US res files go away, their strings are now the .hrc keys in the source code * remaining .res files are replaced by .mo files * in .res/.ui-lang-zip files, the old scheme missing translations of strings results in inserting the english original so something can be found, now the standard fallback of using the english original from the source key is used, so partial translations shrink dramatically in size * extract .hrc strings with hrcex which backs onto xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap * extract .ui strings with uiex which backs onto xgettext --add-comments --no-wrap * qtz for gettext translations is generated at runtime as ascii-ified crc32 of content + "|" + msgid * [API CHANGE] remove deprecated binary .res resouce loader related uno apis com::sun::star::resource::OfficeResourceLoader com::sun::star::resource::XResourceBundleLoader com::sun::star::resource::XResourceBundle when translating strings via uno apis com.sun.star.resource.StringResourceWithLocation can continue to be used Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
2017-07-15emfplus: create a wmf/emf/emf+ primitive based importerArmin Le Grand
First steps to organize an importer that can read/interpret wmf/emf/emf+ and deliver a primitive representation for the content by parsing it. Use the same mechanisms as already applied for Svg, so to reuse abilities to keep original binary data to allow save again and embedding in files and have an implemented replacement bitmap based representation. For this, unify the used helper classes to handle more than just Svg. For 1st try, add test code and static bool switches Change-Id: I6e0a82943541d811a8f8d65a84115569fcd8cee7
2017-04-14remove the old collaboration feature based on telepathyMarkus Mohrhard
Change-Id: I1f08d6ef43b76e7bae41ac33bb954f506ae7c485 Reviewed-on: https://gerrit.libreoffice.org/36542 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2017-03-14Revert "Is gbuildtojson missing support for ExternalPackage?"Miklos Vajna
This reverts commit d8a47a23114ce9b4a743d0da35dfb93dadc07d11. It does not seem to be necessary after ee9cb85e9adc03693141a106630a4f278b4e93ac (gpgme: change gb_LinkTarget__use_gpgmepp to depend on package, 2017-03-10) fixed the root cause. Change-Id: I0e421d29d37853b0f4dd9d2ce4acf0cc1d09882f
2017-03-05Is gbuildtojson missing support for ExternalPackage?Stephan Bergmann
(Now that xmlsecurity/Executable_pdfverify.mk mentions that since f764d67da42caa71fd5e02146b1ca32680ae2f6e "Fix Executable_pdfverify dependencies on Linux".) Probably---but how am I supposed to fix that tempfile mess? So just take xmlsecurity out of the module list until somebody knowledgeable about gbuildtojson fixes that. [...] > mkdir -p /data/lo/core/TMPDIR/gbuildaeu7wqev/GbuildToJson/CppunitTest/ > mkdir -p /data/lo/core/TMPDIR/gbuildaeu7wqev/LinkTarget/CppunitTest/ > LD_LIBRARY_PATH=/data/lo/core/instdir/program:/data/lo/core/instdir/program:/data/lo/core/workdir/UnpackedTarball/cppunit/src/cppunit/.libs LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"/data/lo/core/instdir/program:/data/lo/core/instdir/program" /data/lo/core/TMPDIR/gbuildaeu7wqev/LinkTarget/Executable/gbuildtojson --makefile=/data/lo/core/TMPDIR/gbuild.X1C36q --linktarget=/data/lo/core/TMPDIR/gbuild.0zidFs --ilibtarget=/data/lo/core/TMPDIR/gbuild.LCl6Cf --cxxobjects=/data/lo/core/TMPDIR/gbuild.r4VEGz --yaccobjects=/data/lo/core/TMPDIR/gbuild.V6y0Sc --objcobjects=/data/lo/core/TMPDIR/gbuild.LBrqAl --objcxxobjects=/data/lo/core/TMPDIR/gbuild.WVv4ht --cxxclrobjects=/data/lo/core/TMPDIR/gbuild.H6vJbO --asmobjects=/data/lo/core/TMPDIR/gbuild.8hALYD --lexobjects=/data/lo/core/TMPDIR/gbuild.DOfpRn --gencobjects=/data/lo/core/TMPDIR/gbuild.0ErRmu --gencxxobjects=/data/lo/core/TMPDIR/gbuild.w2TAEg --cobjects=/data/lo/core/TMPDIR/gbuild.igfxay --javaobjects=/data/lo/core/TMPDIR/gbuild.WcfpOt --pythonobjects=/data/lo/core/TMPDIR/gbuild.O4Myeb --cflags=/data/lo/core/TMPDIR/gbuild.GRNm3B --cflagsappend=/data/lo/core/TMPDIR/gbuild.IwFfCF --cxxflags=/data/lo/core/TMPDIR/gbuild.FBXArw --cxxflagsappend=/data/lo/core/TMPDIR/gbuild.nKdQ4d --objcflags=/data/lo/core/TMPDIR/gbuild.ZbiwYX --objcflagsappend=/data/lo/core/TMPDIR/gbuild.Ahmn93 --objcxxflags=/data/lo/core/TMPDIR/gbuild.4PbfJo --objcxxflagsappend=/data/lo/core/TMPDIR/gbuild.DgMO0i --cxxclrflags=/data/lo/core/TMPDIR/gbuild.St2OX9 --cxxclrflagsappend=/data/lo/core/TMPDIR/gbuild.6UuMxo --defs=/data/lo/core/TMPDIR/gbuild.wbazch --include=/data/lo/core/TMPDIR/gbuild.KgrLWd --linked_libs=/data/lo/core/TMPDIR/gbuild.x4MaDG --linked_static_libs=/data/lo/core/TMPDIR/gbuild.OulkWx > /data/lo/core/TMPDIR/gbuildaeu7wqev/GbuildToJson/CppunitTest/libtest_xmlsecurity_dialogs_test.so > [build EPK] gpgme > touch /data/lo/core/TMPDIR/gbuildaeu7wqev/ExternalPackage/gpgme > touch: cannot touch '/data/lo/core/TMPDIR/gbuildaeu7wqev/ExternalPackage/gpgme': No such file or directory > make: *** [/data/lo/core/TMPDIR/gbuildqy7pkkpc/solenv/gbuild/ExternalPackage.mk:33: /data/lo/core/TMPDIR/gbuildaeu7wqev/ExternalPackage/gpgme] Error 1 > E > ====================================================================== > ERROR: test_gbuildtojson (gbuildtojson.CheckGbuildToJsonModules) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/data/lo/core/solenv/qa/python/gbuildtojson.py", line 142, in test_gbuildtojson > subprocess.check_call([self.bash, bashscriptname.replace('\\', '/')]) > File "/data/lo/core/instdir/program/python-core-3.5.0/lib/subprocess.py", line 271, in check_call > raise CalledProcessError(retcode, cmd) > subprocess.CalledProcessError: Command '['bash', '/data/lo/core/TMPDIR/gbuild707bz2lq']' returned non-zero exit status 2 > > ---------------------------------------------------------------------- > Ran 2 tests in 53.237s > > FAILED (errors=1) > > Error: a unit test failed, please do one of: > make PythonTest_solenv_python CPPUNITTRACE="gdb --args" > # for interactive debugging on Linux > make PythonTest_solenv_python VALGRIND=memcheck > # for memory checking > make PythonTest_solenv_python DEBUGCPPUNIT=TRUE > # for exception catching > > make[1]: *** [/data/lo/core/solenv/gbuild/PythonTest.mk:36: /data/lo/core/workdir/PythonTest/solenv_python/done] Error 1 > make: *** [Makefile:161: PythonTest_solenv_python] Error 2 Change-Id: If8717f42657ae63ba468b5945f98e02090df58c9
2017-02-21When building with clang-cl on Windows, build CLR code with MSVCStephan Bergmann
...as clang-cl doesn't support the /clr switch. * In configure.ac, capture the MSCV version (that would be used if CC hadn't been overridden to use clang-cl) into MSVC_CXX. * The logic which flags to pass into gb_CObject__command_pattern is coded into the platform-agnostic LinkTarget.mk, so it's too late to try and filter all relevant flags in com_GCC_class.mk, depending on whether a given .cxx file is a normal one built with the normal $CXX or a special /clr one built with $MSVC_CXX. Thus, a new CxxClrObject class had to be introduced that captures this information early. * When building with clang-cl, the generated config_host/config_*.h files contain values suitable for clang-cl, but not for MSVC. But the .cxx files compiled with MSVC happen to include config_global.h, and would fail. Hack around that problem for now by introducing a hard-coded, minimal solenv/clang-cl/config_global.h that is found first when buliding such a CxxClrObject. Needs cleaning-up properly. Change-Id: Iff8aac51c0b4fa906b14503c692640dda0996d33 Reviewed-on: https://gerrit.libreoffice.org/34509 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-01-26unittest gbuildtojsonjan Iversen
Rename of FLEX to LEX needs to be done in the unittest as well. Change-Id: Ic038fa01d65edb5724c3d9dc8a04c72c6367372d
2017-01-16fix testStephan Bergmann
Change-Id: Id915626324a692d8ec87cc6899c3de298682348b
2016-12-04gbuildtoide: builddir is not necessarily same as srcdirChristian Lohmaier
Change-Id: Ied9f9abcc75f2edcd518ac247907f573aa21f35e Reviewed-on: https://gerrit.libreoffice.org/31158 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-11-25store makefile for targets in json tooBjoern Michaelsen
Change-Id: Iae2f497da5d0ee4f8961a5655573e45a562dd76d Reviewed-on: https://gerrit.libreoffice.org/31116 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-11-25use gbuild prefix for tempdirsBjoern Michaelsen
Change-Id: Icc262c51fd70ae35b44722be8d4ab767b69ae2a8 Reviewed-on: https://gerrit.libreoffice.org/31094 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-11-25rename the core parts of this from gbuildtoide to gbuildtojsonBjoern Michaelsen
- the json stuff is universal and not limited in use to IDEs - the IDE stuff should keep its gbuildtoide name Change-Id: If4f190fc6dffba219334d57a53c826515ed57c34 Reviewed-on: https://gerrit.libreoffice.org/31093 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-11-25Revert "Revert "improvements to gbuildtoide""Bjoern Michaelsen
This reverts commit ab9c578ed17cfd9c9a49f22d83f33b0546faedba, except for the problematic copy-all-SRCDIR top-level test. Change-Id: Ie9c2fd725199768ec04852a9bc09b09a331ce6ad Reviewed-on: https://gerrit.libreoffice.org/31092 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-11-22Revert "improvements to gbuildtoide"Michael Stahl
This reverts commit 294bfdfaada9ba85ddcf853650a8da9c10f25281. Unfortunately this shutil.copytree(self.srcdirnative, self.tempsrc) copies the entire SOURCEROOT into /tmp, with WORKDIR too if it's not an out-of-tree build, which is quite an excessive use of space, tmpfs or otherwise, and will no doubt make CI very happy.
2016-11-22improvements to gbuildtoideBjoern Michaelsen
- move supported module selection from the test directly into gbuild, it should not be possible now to have 'make gbuildtoide' failing, it should skip problematic parts - move from whitelisting to blacklisting bad modules - toplevel 'make gbuildtoide' should work now, so add test (limit to non-Windows for now, as Windows is stupid and slow) - remove spurious debug output in test Change-Id: I9838dd2fa091e5fb3e56f414f60164086e8f2076 Reviewed-on: https://gerrit.libreoffice.org/31072 Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com> Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-11-07Fix typos (also in the code)Andrea Gelmini
Change-Id: I45d45513b102f4fdcb55e8de20b95b37f66ea463 Reviewed-on: https://gerrit.libreoffice.org/30658 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2016-10-31populate library path to gbuildtojson in testsBjoern Michaelsen
the test environment clears LD_LIBRARY_PATH as it seems to cause trouble for make in ASAN. "make gbuildtoide" only runs the gbuildtojson exe, so make sure it gets the LD_LIBRARY_PATH that was filtered out from the make that starts it. Change-Id: I69ee0024232092aebcd1e8e11b002d6f7eb55c84 Reviewed-on: https://gerrit.libreoffice.org/30433 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-10-26for now, use a limited subset for testing on windows as it is so slowBjoern Michaelsen
Change-Id: I06f77d8aa0a82bd3bb065095a64849d07d11c6a3 Reviewed-on: https://gerrit.libreoffice.org/30311 Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com> Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-10-26add test for running gbuildtoide on non-build modulesBjoern Michaelsen
- do concat for json in C++, everything else seems fragile on Windows - have APPEND vars separately - check that gbuildtoide work on modules without a full build (modulo some blacklisted "creative" ones) Change-Id: I6fe267fee7d1b77d758072303729387dfeb8e6c8 Reviewed-on: https://gerrit.libreoffice.org/30293 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-10-26normalize existing emacs/vim mode-lines in python filesMichael Stahl
Bunch of these were setting C++ or Make modes and icky tabs... Also, reportedly Emacs can figure out to enable python-mode automatically. Change-Id: I50072488fb92cb4d27aa3f74f717a28ae3967543
2016-10-26fix "TabError: inconsistent use of tabs and spaces in indentation"Michael Stahl
Change-Id: Iff27ff4a01dc8c20b01a6247554b6cc7195a2306
2016-10-26solenv: fix Windows buildMiklos Vajna
Traceback (most recent call last): File "C:cygwinhometdflodejenkinsworkspacelo_gerritConfigwindows_msc_dbgutil_32solenvqapythongbuildtoide.py", line 32, in test_gbuildtoide del(os.environ['LD_LIBRARY_PATH']) # built with ASAN; prevent that File "C:cygwinhometdflodejenkinsworkspacelo_gerritConfigwindows_msc_dbgutil_32instdirprogram\python-core-3.3.0libos.py", line 692, in __delitem__ raise KeyError(key) from None KeyError: 'LD_LIBRARY_PATH' Change-Id: I1575caf90cafffd71dd28fedc46b5e3570848be8 Reviewed-on: https://gerrit.libreoffice.org/30304 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Michael Stahl <mstahl@redhat.com>
2016-10-26solenv: don't run make with LD_LIBRARY_PATH setMichael Stahl
In a build with -fsanitize=address, this fails with: Change-Id: Ida0d4445d7f829545b493e9dd4c2c4ef33960850 make: symbol lookup error: instdir/program/libfreebl3.so: undefined symbol: __asan_option_detect_stack_use_after_return
2016-10-24solenv: force gbuildtoide test to use the same "make" as the callerMichael Stahl
Possibly mis-matching make binaries could be the reason behind failures that have been observed on Jenkins: make[3]: Entering directory '/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/windows_msc_dbgutil_32/solenv/qa/python/selftest' make[3]: *** internal error: invalid --jobserver-fds string 'gmake_semaphore_5488'. Stop. Also, to enable this: Revert "Revert "prep WinResTarget for WNT in testdir"" This reverts commit 6e261cb19e5751eb0553ad0c5b357b1a5747518c. Change-Id: Idb858b5eeced91f19c9dd5600c4fdc5370b73cc5 Reviewed-on: https://gerrit.libreoffice.org/30226 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2016-10-20Revert "prep WinResTarget for WNT in testdir"Giuseppe Castagno
Still random failures in Gerrit Windows builds. This reverts commit f5c54089b50718abf7c35aa81b150c509809d5c4. Change-Id: Iec48d2388691577ccd675b9a73941cedceebd527 Reviewed-on: https://gerrit.libreoffice.org/30103 Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com> Reviewed-by: Giuseppe Castagno <giuseppe.castagno@acca-esse.eu> Tested-by: Giuseppe Castagno <giuseppe.castagno@acca-esse.eu>
2016-10-18prep WinResTarget for WNT in testdirBjoern Michaelsen
Change-Id: I04c050dca1212d247c9b11a996ba8f37c0a6492f Reviewed-on: https://gerrit.libreoffice.org/29825 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com> Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-10-14tearDown/clean up solenv test tempdirBjoern Michaelsen
Change-Id: I2fc5497b0aeadbc43e967f338a3b8718995f2a5c
2016-10-14fix license, this is entirely new contentBjoern Michaelsen
Change-Id: Icf1818fb894d039eeb4e7f1306a53ac4322fa075
2016-10-14add gbuildtoide support for exesBjoern Michaelsen
Change-Id: I320ee341651dd0c92de5176c10aa5290afea1d38
2016-10-13use tempdir for testBjoern Michaelsen
Change-Id: Ie218f87dc2f1c1b6031cc08f2027cfcf392c6c21
2016-10-13add initial json export for gbuild dataBjoern Michaelsen
- also add gbuild selftest to test this (and possibly more later) Change-Id: Ia4ef41095613e596f39d107df700e929579ba45f Reviewed-on: https://gerrit.libreoffice.org/29744 Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com> Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2016-10-13add a testbed for gbuildBjoern Michaelsen
Change-Id: Ie6e54c291f92dfede113a1d0fa20771482d93605 Reviewed-on: https://gerrit.libreoffice.org/29743 Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com> Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>