1. 03 Haz, 2019 1 kayıt (commit)
  2. 22 May, 2019 1 kayıt (commit)
  3. 25 Şub, 2019 1 kayıt (commit)
  4. 21 Şub, 2019 1 kayıt (commit)
  5. 17 Şub, 2019 1 kayıt (commit)
  6. 14 Şub, 2019 1 kayıt (commit)
  7. 05 Şub, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Clang ASan fails with gold · c394e6a5
      Stephan Bergmann yazdı
      ...for whatever reason.  Failure is
      
      > AddressSanitizer:DEADLYSIGNAL
      > =================================================================
      > ==16438==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x2b6ba8bfe65c bp 0x7ffca100f290 sp 0x7ffca100ba28 T0)
      > ==16438==The signal is caused by a READ memory access.
      > ==16438==Hint: address points to the zero page.
      >     #0 0x2b6ba8bfe65b  (<unknown module>)
      >
      > AddressSanitizer can not provide additional info.
      > SUMMARY: AddressSanitizer: SEGV (<unknown module>)
      > ==16438==ABORTING
      > /home/tdf/lode/jenkins/workspace/lo_ubsan/testtools/CustomTarget_uno_test.mk:25: recipe for target '/home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/CustomTarget/testtools/uno_test.done' failed
      
      (<https://ci.libreoffice.org/job/lo_ubsan/1177/>, but also seen with local ASan+
      UBSan builds.)
      
      Started to fail with 98f5f97d "make --enable-ld
      the default for debug builds, if available".  (lld would automatically be
      disabled by configure.ac because it doesn't support --dynamic-list-cpp-typeinfo
      as needed by UBSan.)
      
      Change-Id: I7bfbfc4c879cbad7748e5855c22698eec5efc94c
      c394e6a5
  8. 28 Ock, 2019 1 kayıt (commit)
  9. 22 Ock, 2019 3 kayıt (commit)
  10. 03 Ock, 2019 1 kayıt (commit)
  11. 20 Ara, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Enable --help=html for flatpak · 72b936d7
      Stephan Bergmann yazdı
      To not increase the size of the main org.libreoffice.LibreOffice app further,
      the plan was to realize this as an org.libreoffice.LibreOffice.Help extension.
      Ideally, this would be a localized extension, so that, by default, only a
      relevant subset of the extension would be downloaded and installed.  (But see
      below.)
      
      There are multiple technical problems, as discussed at <https://github.com/
      flathub/org.libreoffice.LibreOffice/issues/35#issuecomment-447295308> "Add
      integrated LibreOffice Help offline":
      
      * LO can't pass a file URL with query part to xdg-open, so uses a temporary
        wrapper .html file that redirects to the target URL.  But for the flatpak case
        this wrapper can't be in /tmp (which isn't visible from outside the flatpak
        sandbox), but is instead stored in a new temp dir under $XDG_CACHE_HOME (which
        is always set for flatpaks and /is/ visible form the outside) that is
        removed on LO exit.
      
      * The file URL stored in the temp file must be rewritten from the internal path
        (/app/libreoffice/help/...) to the path as seen outside the flatpak sandbox.
        While the path for the org.libreoffice.LibreOffice /app is stored in
        /.flatpak-info, the external path for the org.libreoffice.LibreOffice.Help
        extension is different and not stored there.  So use a hack trying to
        construct that path from what information is available in /.flatpak-info.
      
      * But the help content consists of locale-specific and shared files, and those
        reference each other with relative links.  But a localized flatpak extension
        cannot contain shared files, it can only contain per-language sub-dirs.  And
        if the shared help files were kept out of the extension, as part of the app
        itself, the relative paths among these files inside the flatpak sandbox would
        differ from those outside of it, so would be broken when viewing the content
        in the external browser.  A solution would either (a) need to somehow rewrite
        the content of all the help files being served from LO to the external
        browser, or (b) replicate the shared help files in all the extension's per-
        language sub-dirs (and if some localization uses en-US content as a fallback
        for only part of its translated content, e.g., in the case of media files,
        would need to also replicate that en-US content), or (c) use a non-localized
        extension that always contains the content for all localizations.
      
      For now, I chose the third approach.  This makes the
      org.libreoffice.LibreOffice.Help extension relatively large (the current
      /app/libreoffice/help tree has a size of ca. 100MB), so that I decided to not
      have it downloaded and installed automatically ("no-autodownload": true in
      solenv/flatpak-manifest.in).  (I checked with Flatpak 1.0.6 that if the
      extension should be changed to a localized one with the same name in the future,
      updating from an older version would work.  If the old extension was not
      installed, just the relevant localizations of the new version will be downloaded
      and installed.  If the old extension was installed, the full set of
      localizations of the new version will be downloaded and installed.)
      
      (As also mentioned at <https://github.com/flathub/org.libreoffice.LibreOffice/
      issues/35#issuecomment-447295308>:  "A second, minor, nuisance is that, for
      security reasons, an `xdg-open file:///...html` call from a flatpak leads to an
      intermediate popup dialog letting the user chose which application to use to
      open the URI, while e.g. an `xdg-open http:///...html` is allowed to go directly
      to the user's preferred browser.  So accessing help content from LO flatpak
      would present that popup dialog first, forcing the user to select a browser to
      proceed.")
      
      Change-Id: I35f5a23947dd551dc1b9bff1dd2abd6710073b5f
      Reviewed-on: https://gerrit.libreoffice.org/65451
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      72b936d7
  12. 19 Ara, 2018 1 kayıt (commit)
  13. 17 Ara, 2018 1 kayıt (commit)
  14. 11 Ara, 2018 1 kayıt (commit)
  15. 10 Ara, 2018 2 kayıt (commit)
  16. 08 Ara, 2018 1 kayıt (commit)
  17. 03 Ara, 2018 2 kayıt (commit)
    • Stephan Bergmann's avatar
      Jenkins' lo_tb_master_linux needs --disable-werror too · 7990bfd3
      Stephan Bergmann yazdı
      ...similar to d3f2c61e "Make Jenkins
      linux_gcc_release_64 pick up Developer Toolset 7":
      
      > In file included from /opt/rh/devtoolset-7/root/usr/include/c++/7/vector:69:0,
      >                  from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx:39:
      > /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/vector.tcc: In function ‘javaPluginError jfw_plugin_startJavaVirtualMachine(const JavaInfo*, const JavaVMOption*, sal_Int32, JavaVM**, JNIEnv**)’:
      > /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/vector.tcc:407:15: error: variable ‘__new_finish’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
      >        pointer __new_finish(__new_start);
      >                ^~~~~~~~~~~~
      > cc1plus: all warnings being treated as errors
      
      (<https://ci.libreoffice.org/job/lo_tb_master_linux/32166/>).
      
      Change-Id: Ifae8705bfafe4caed21713909ff6eeee158f1361
      7990bfd3
    • Stephan Bergmann's avatar
      Enabling Developer Toolset 7 for Jenkins' lo_tb_master_linux · 0adc21fc
      Stephan Bergmann yazdı
      ...aka "Tinderbox on Master for Linux-DbgUtil",
      <https://ci.libreoffice.org/job/lo_tb_master_linux_dbg/>.  This is similar to
      ab8454eb "Enabling Developer Toolset 7 for
      Jenkins' lo_tb_master_linux_dbg".  However, unlike lo_tb_master_linux_dbg, which
      is restricted to CentOS-based tb75-lilith, lo_tb_master_linux is restricted to
      label TB_Rel, which is currently matched to CentOS-based tb75-lilith,
      tb76-maggie, and tb76-pollux, plus non-CentOS based gandalf.  The latter thus
      doesn't have Developer Toolset 7, so setting CC/CXX this way won't work for
      gandalf.  I'm thus removing gandalf from
      <https://ci.libreoffice.org/label/TB_Rel/>.
      
      Change-Id: Ied305476347d107db4087f710c05300c84ae7e85
      Reviewed-on: https://gerrit.libreoffice.org/64444
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      0adc21fc
  18. 25 Kas, 2018 6 kayıt (commit)
  19. 24 Kas, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Make Jenkins linux_gcc_release_64 pick up Developer Toolset 7 · d3f2c61e
      Stephan Bergmann yazdı
      ...as discussed at
      <https://lists.freedesktop.org/archives/libreoffice/2018-November/081423.html>
      "Re: Compiler baselines".
      
      It doesn't look exactly right to enable the Developer Toolset from autogen.sh.
      But the alternative would be to "hide" that in
      <https://ci.libreoffice.org/job/gerrit_linux_gcc_release/configure>, which would
      probably not be helpful when developers try to track down why a certain Jenkins
      build behaves the way it does.  So pragmatically stick it in autogen.sh.  (Also,
      it puts Developer Toolset on the PATH whenever it is found on a system using
      LODE_HOME, not just for the specific Config=linux_gcc_release_64 case.  Lets see
      how that works out in practice.)
      
      However, it turns out that the Developer Toolset 7's GCC 7.3.1 with
      --enable-werror (that is implicitly enabled for LODE-driven builds in
      configure.ac) and (implicit) --enable-optimized produces many false warnings
      (i.e., errors), see below for a sample.  (Actually, my experience is that
      contemporary GCC hardly ever work with -Werror in optimized builds, due to
      analysis being done on already optimized code; it surprised me to find out that
      the Jnekins linux_gcc_release_64 builds were apparently successfully done with
      --enable-werror with GCC 4.8.5.)  So explicitly --disable-werror for these
      builds.  (Which means that <https://gerrit.libreoffice.org/plugins/gitiles/lode/
      +/b82e0a9d26ef4c81046c053ff831dccfc84c56be%5E!> "For linux_gcc_release_64, don't
      let ccache strip comments" could probably be reverted again if it has negative
      impact on Jenkins' performance.)
      
      Some of the false warnings encountered:
      
      > [CXX] jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
      > In file included from /opt/rh/devtoolset-7/root/usr/include/c++/7/vector:69:0,
      >                  from /home/tdf/sberg/core/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx:39:
      > /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/vector.tcc: In function ‘javaPluginError jfw_plugin_startJavaVirtualMachine(const JavaInfo*, const JavaVMOption*, sal_Int32, JavaVM**, JNIEnv**)’:
      > /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/vector.tcc:407:15: error: variable ‘__new_finish’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
      >        pointer __new_finish(__new_start);
      >                ^~~~~~~~~~~~
      > cc1plus: all warnings being treated as errors
      
      > [CXX] libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx
      > /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx: In function ‘gboolean gtv_calc_header_bar_draw(GtkWidget*, cairo_t*)’:
      > /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:89:117: error: ‘aRectangle._cairo_rectangle_int::height’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      >      cairo_move_to(pCairo, rRectangle.x + rRectangle.width / 2 - extents.width / 2, rRectangle.y + rRectangle.height / 2 + extents.height / 2);
      >                                                                                                    ~~~~~~~~~~~~~~~~~~^~~
      > /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:102:22: note: ‘aRectangle._cairo_rectangle_int::height’ was declared here
      >          GdkRectangle aRectangle;
      >                       ^~~~~~~~~~
      > /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:89:59: error: ‘aRectangle._cairo_rectangle_int::width’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      >      cairo_move_to(pCairo, rRectangle.x + rRectangle.width / 2 - extents.width / 2, rRectangle.y + rRectangle.height / 2 + extents.height / 2);
      >                                           ~~~~~~~~~~~~~~~~~^~~
      > /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:102:22: note: ‘aRectangle._cairo_rectangle_int::width’ was declared here
      >          GdkRectangle aRectangle;
      >                       ^~~~~~~~~~
      > /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:89:97: error: ‘aRectangle._cairo_rectangle_int::y’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      >      cairo_move_to(pCairo, rRectangle.x + rRectangle.width / 2 - extents.width / 2, rRectangle.y + rRectangle.height / 2 + extents.height / 2);
      >                                                                                     ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
      > /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:102:22: note: ‘aRectangle._cairo_rectangle_int::y’ was declared here
      >          GdkRectangle aRectangle;
      >                       ^~~~~~~~~~
      > /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:89:40: error: ‘aRectangle._cairo_rectangle_int::x’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      >      cairo_move_to(pCairo, rRectangle.x + rRectangle.width / 2 - extents.width / 2, rRectangle.y + rRectangle.height / 2 + extents.height / 2);
      >                            ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
      > /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:102:22: note: ‘aRectangle._cairo_rectangle_int::x’ was declared here
      >          GdkRectangle aRectangle;
      >                       ^~~~~~~~~~
      > cc1plus: all warnings being treated as errors
      
      > [CXX] svl/source/misc/lockfilecommon.cxx
      > /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx: In static member function ‘static rtl::OUString svt::LockFileCommon::GetCurrentLocalTime()’:
      > /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx:190:10: error: ‘%02d’ directive writing between 2 and 5 bytes into a region of size between 1 and 9 [-Werror=format-overflow=]
      >  OUString LockFileCommon::GetCurrentLocalTime()
      >           ^~~~~~~~~~~~~~
      > /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx:190:10: note: directive argument in the range [0, 65535]
      > /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx:190:10: note: directive argument in the range [0, 65535]
      > /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx:204:24: note: ‘sprintf’ output between 17 and 31 bytes into a destination of size 20
      >                  sprintf( pDateTime, "%02d.%02d.%4d %02d:%02d", aDateTime.Day, aDateTime.Month, aDateTime.Year, aDateTime.Hours, aDateTime.Minutes );
      >                  ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      > cc1plus: all warnings being treated as errors
      
      Change-Id: I3a851b7591274a8cf8b4729ae036afeb8e82eedc
      Reviewed-on: https://gerrit.libreoffice.org/63884
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      d3f2c61e
  20. 22 Kas, 2018 1 kayıt (commit)
  21. 06 Kas, 2018 1 kayıt (commit)
  22. 11 Eki, 2018 2 kayıt (commit)
  23. 05 Eki, 2018 1 kayıt (commit)
  24. 03 Eyl, 2018 1 kayıt (commit)
  25. 29 Agu, 2018 1 kayıt (commit)
  26. 27 Agu, 2018 1 kayıt (commit)
  27. 13 Agu, 2018 1 kayıt (commit)
  28. 08 Agu, 2018 1 kayıt (commit)
  29. 04 Tem, 2018 1 kayıt (commit)
  30. 25 Haz, 2018 1 kayıt (commit)