1. 09 Kas, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Fix creation/removal of GPG socketdir · f0305ec0
      Stephan Bergmann yazdı
      <https://gerrit.libreoffice.org/#/c/50978/> "gpg4libre: fix failing gpg test due
      to over-long filenames" had introduced the gb_CppunitTest_run_gpgconf target in
      xmlsecurity/CppunitTest_xmlsecurity_signing.mk, calling `gpgconf
      --craete-socketdir`.  A 2018-03-18 comment there notes that "Stephan's last
      comment: (and `gpgconf --remove-sockedir` be called after the test?) is not
      addressed yet, will do in follow-up commit".
      Follow-up d7ecf4a4 "properly check for gpgconf
      (and --create-socketdir) working" makes gb_CppunitTest_run_gpgconf conditional.
      However, in configure.ac,
      is missing, so even after follow-up 7a95ee8d
      "actually add HAVE_GPGCONF_SOCKETDIR to config_host.mk.in...", config_host.mk
      will always contain
      so gb_CppunitTest_run_gpgconf will never be executed (and `pgconf
      --crate-socketdir` will never called).
      But even if it were executed, it would not create the socket dir that the test
      code in xmlsecurity/qa/unit/signing/signing.cxx is actually using, as
      gb_CppunitTest_run_gpgconf sets
      while xmlsecurity/qa/unit/signing/signing.cxx's SigningTest::setUp sets
      and the GPG software is apparently picky about extra slashes when computing the
      socket dir name from the GNUPGHOME env var.
      (That `gpgconf --create-socketdir` was never executed with the current setup
      shows that calling it explicitly is probably not really needed, as the GPG
      software apparently creates it automatically on demand.)
      However, what is still missing is to remove the socket dir again (see the
      comment quoted above), and, probably more importantly, to exit any gpg-agent
      daemon operating on that socket dir that has (indirectly) been started by the
      tests in xmlsecurity/qa/unit/signing/signing.cxx.  At least with Fedora 29
      gpgconf from gnupg2-2.2.9-1.fc29.x86_64, that daemon is successfully terminated
      by calling `gpgconf --remove-socket`.
      So move the call to `gpgconf --create-socketdir` from the makefile to the test
      setup code (which makes it easier to guarantee that a single GNUPGHOME value,
      and thus a single socket dir, is used), and add a corresponding `gpgconf
      --remove-socketdir` call to the test shutdown code.  (As argued above, the
      `gpgconf --create-socketdir` call shouldn't be stricktly necessary, but it looks
      cleaner to do it explicitly anyway.)
      Change-Id: I2ec8f08943ed63ec27f8507461588ee7cdadf372
      Reviewed-on: https://gerrit.libreoffice.org/63181Reviewed-by: 's avatarThorsten Behrens <Thorsten.Behrens@CIB.de>
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
  2. 31 Eki, 2018 1 kayıt (commit)
  3. 03 Eki, 2018 1 kayıt (commit)
  4. 12 Eyl, 2018 1 kayıt (commit)
  5. 28 Agu, 2018 1 kayıt (commit)
  6. 27 Agu, 2018 1 kayıt (commit)
  7. 26 Agu, 2018 1 kayıt (commit)
  8. 23 Agu, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      rhbz#1618703: Allow to use OpenSSL as backend for rtl/cipher.h · 4bc16aeb
      Stephan Bergmann yazdı
      ...with new configuration option --enable-cipher-openssl-backend
      rtl/cipher.h (which is part of the stable URE interface) offers functionality to
      en-/decrypt data with Blowfish in ECB, CBC, and streaming CFB mode, and with RC4
      (aka ARCFOUR; which is a stream cipher).  LO itself only uses Blowfish CFB and
      RC4, so only those are wired to OpenSSL for now, for simplicity.  Using Blowfish
      ECB and CBC, or Blowfish CFB in DirectionBoth mode would cause failures for now
      (cf. sal/qa/rtl/cipher/rtl_cipher.cxx); the assumption is that no external code
      actually makes use of this functionality.
      Using NSS instead of OpenSSL could be an alternative, but there appears to be no
      support in NSS for Blowfish in streaming CFB mode, only CKM_BLOWFISH_CBC for
      CBC mode.
      Change-Id: I0bc042961539ed46844c96cb1c808209578528a0
      Reviewed-on: https://gerrit.libreoffice.org/59428
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
  9. 08 Agu, 2018 1 kayıt (commit)
  10. 02 Agu, 2018 3 kayıt (commit)
  11. 04 Tem, 2018 3 kayıt (commit)
  12. 13 Haz, 2018 1 kayıt (commit)
  13. 29 May, 2018 1 kayıt (commit)
  14. 23 May, 2018 1 kayıt (commit)
  15. 03 May, 2018 3 kayıt (commit)
  16. 25 Nis, 2018 1 kayıt (commit)
    • Mike Kaganski's avatar
      Install UCRT from MSUs, not using nested VC Redist install · b8424437
      Mike Kaganski yazdı
      Using nested install is bad because (1) MS advises against it (though it
      most possibly doesn't relate to our specific case, when we install the
      vc redist exe package in UI part, so actually only a single MSI session
      is active at any time); (2) because it adds some extra interactions
      (user sees something "unrelated" being installed, which raises concerns;
      additional admin authentication required); and (3) because it runs in
      InstallUISequence, thus only installing the UCRT when doing interactive
      installation (unattended installs, including GPO, need to install UCRT
      This patch aims to incorporate the original UCRT MSU (Windows Update)
      packages (https://support.microsoft.com/en-us/help/2999226) available as
      a zip archive from
      - the same as used in VC redists for VS 2015 and 2017. This obsoletes
      the separate installation of the redist; since we also have the redist
      as merge module in our MSI, that is enough (and removes redundancy).
      The MSUs are installed using wusa.exe in a custom action (deferred,
      As a small bonus, embedding MSUs instead of redist EXE allows us to
      shrink the size of installer a little (~10 MB).
      As deferred custom actions cannot access current installer database,
      we workaround this by using initial immediate impersonating action to
      extract the binaries into a temporary location. To ensure that the file
      gets removed upon completion (both successful and failed), we use an
      additional cleanup action.
      Commit 61b1d631 is effectively reverted.
      Change-Id: I1529356fdcc67ff24b232c01ddf8bb3a31bb00bd
      Reviewed-on: https://gerrit.libreoffice.org/52923Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarMike Kaganski <mike.kaganski@collabora.com>
  17. 20 Nis, 2018 1 kayıt (commit)
  18. 18 Nis, 2018 1 kayıt (commit)
  19. 12 Nis, 2018 1 kayıt (commit)
  20. 10 Nis, 2018 1 kayıt (commit)
  21. 18 Mar, 2018 3 kayıt (commit)
  22. 28 Şub, 2018 1 kayıt (commit)
  23. 20 Şub, 2018 1 kayıt (commit)
  24. 23 Ock, 2018 2 kayıt (commit)
    • Milian Wolff's avatar
      Introduce gtk3_kde5 vcl plugin · ecb5fcff
      Milian Wolff yazdı
      This is a hybrid plugin which mostly wraps the GTK3 vclplug. Only
      the file and folder picker are replaced by KDE dialogs. This gives
      us a well-maintained GTK LO base with basic KDE integration with
      minimum effort.
      To prevent issues with nested event loops, the KDE dialogs are
      launched from a separate process, the new lo_kde5filepicker helper
      executable. A trivial stdin/stdout IPC mechanism transfers the data
      between LO and the Qt/KDE helper. The usage of an external process
      also allows us to copy'n'paste between LO and the KDE file dialog
      without freezing the UI, as would happen when one would do this
      in-process. This is in general also the architecture applied by the
      kmozillahelper, which is used to integrate KDE file dialogs into
      While the KDE dialog is shown, the GTK3 main window is disabled and
      close requests are ignored. The KDE dialog in turn also sets the LO
      window as transient parent. Together, this makes the illusion perfect
      and the KDE dialog behaves like a modal dialog. This works properly
      also with multiple LO main windows, and only individual windows will
      get blocked as one would expect.
      Functionality wise, most of the features of the KDE4 dialog are
      supported. You can pick files and folders, and save files under a new
      name. Some custom checkbox widgets are supported, but lists, buttons
      and preview widgets are not yet implemented. Also, loading remote
      files via KIO is not possible yet.
      Change-Id: I1a97cf7c272307a19ace4222d5f12253bc722829
      Reviewed-on: https://gerrit.libreoffice.org/47718Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarThorsten Behrens <Thorsten.Behrens@CIB.de>
    • Milian Wolff's avatar
      Extend build system to support linking against KDE Frameworks 5 · 4d78cf97
      Milian Wolff yazdı
      Pass --enable-kde5 to autogen.sh to enable this feature. Then
      add kde5 to the list of externals to link against KF5. I will
      introduce other code that depends on KF5 though which will
      leverage this feature.
      Change-Id: I17e434a53ac769000b0f805b1f41cdc5c2c84ee2
      Reviewed-on: https://gerrit.libreoffice.org/47715Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarThorsten Behrens <Thorsten.Behrens@CIB.de>
  25. 18 Ock, 2018 1 kayıt (commit)
  26. 18 Ara, 2017 1 kayıt (commit)
    • Mike Kaganski's avatar
      tdf#108580: integrate vc_redist.exe into MSI · 61b1d631
      Mike Kaganski yazdı
      ... in InstallUISequense.
      Use --with-vcredist-dir to point to a directory with vc_redist.x64.exe
      and/or vc_redist.x86.exe. Use --without-vcredist-dir (or
      --with-vcredist-dir=no) if you don't want to ship it as part of
      installer and want to silence the configure warning.
      VCRedist 2015 version 14.0.24215.1 is available at
      Since VisualStudio 2015, VC redist merge module that we used before
      started to work differently: it installs the UCRT only on WinXP,
      but not on later OSes (Vista to 8.1) which may lack the UCRT (Win10
      has it out of the box). The merge module only installs VCRuntime on
      those systems, which still leaves us with "api-ms-*.dll is missing"
      gives more information on VCRedist refactoring background.)
      Since commit 71d9a613, we use a
      workaround described at the page mentioned above as "App-local
      deployment of the Universal CRT". We just copy all UCRT DLLs to
      LibreOffice/program. This has a drawback though, that our UCRT
      is not updated by Windows Update, so users would rely on LibreOffice
      updates in case of some vulnerabilities in UCRT (and they could
      even not realize they have that problem).
      MS recommends to install UCRT using EXEs they provide from their
      site. The EXEs install both VCRuntimes and UCRTs, along with
      required patches, for all Windows versions (Windows XP through
      Windows 10, where they only install VCRuntimes); the installed
      libraries are managed by system's update mechanism. But those EXEs
      cannot be used in MSI custom actions inside InstallExecuteSequence,
      because they use MSI themselves.
      So this patch integrates the vc_redist.xXX.exe into MSI binary
      table, and uses custom action to run the EXE after ExecuteAction
      in InstallUISequence. This will show the user a VCRedist install
      window after the main LibreOffice installation finishes; no user
      interaction is required (except for one additional UAC request),
      and errors are ignored.
      Since this installation takes care of both VCRuntime and UCRT,
      we can ultimately drop both the app-local workaround, and
      vcredist merge module (so VCRuntime would also be updated by
      system). The former is done here: this reverts commit
      This approach has its drawback: if one wants to use unattended
      installation (without UI; one example is deployment using
      ActiveDirectory GPO), then InstallUISequence is not run, and so
      VCRedist isn't installed. In this case, one should install
      VCRedist separately. Supposedly this should not be huge problem,
      because this is the case for many existing applications that need
      separate VCRedist deployment in these scenarios, and unattended
      installation is advanced stuff that requires prepared user. A
      notice would be required in release notes and FAQ, though.
      Change-Id: Ia6a16be60af8a08f41ea7c3dbd457d8f89006006
      Reviewed-on: https://gerrit.libreoffice.org/46356Reviewed-by: 's avatarMike Kaganski <mike.kaganski@collabora.com>
      Tested-by: 's avatarMike Kaganski <mike.kaganski@collabora.com>
  27. 08 Ara, 2017 1 kayıt (commit)
    • Stephan Bergmann's avatar
      New --enable-compiler-plugins=debug mode · 32c31c03
      Stephan Bergmann yazdı
      ...to enable debug-only code in the plugins.  Some situations in the plugin code
      should never happen, yet must not by default report errors or trigger
      assertions, as some newly written LO code could trigger them nevertheless (in
      which case the plugin code will likely need to be adapted, to cater for these
      presumed-impossible situations).
      Such code can now be included in the plugins behind an if(isDebugMode()) guard,
      and can explicitly be enabled with --enable-compiler-plugins=debug.
      I deliberately made this a runtime rather than a compile time option (using
      some #ifdef guards in the plugin code, say), as it IMO keeps the code more
      readable, and also allows overridding COMPILER_PLUGINS_DEBUG=... on the make
      command line.
      Change-Id: Iea4f0c2783ad968a0de097fa710b3be1a248de73
      Reviewed-on: https://gerrit.libreoffice.org/46096Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
  28. 07 Ara, 2017 2 kayıt (commit)
  29. 24 Kas, 2017 2 kayıt (commit)