This problem with large memory usage during parallel linking
of several large libraries is presumably only relevant for the poorly
performing BFD linker. I can barely notice any memory usage increase
even with something as "old" as gold.
Change-Id: I20038c98543b1b920d75d8f645c6b90afb5fb6e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133250
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
I have no idea, if there can be multiple active popups in LO in
some way. There can be multiple FloatingWindow and gtk does count
them in m_nFloats... There is a whole lot going on in gtk3 related
to isFloatGrabWindow(), with "funny" comments like:
// FIXME: find out who the hell steals the focus from our frame
So this goes with some "optimistic" approach: there is just one
active popup, so we can track it in QtInstance. It WFM...
Change-Id: I9778587696e1ad9e641dba4f102e2e921266eee6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133249
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
A shape might have the shading information not in commands in the
enhanced-path, but generated in ctor of EnhancedCustomShape2d from the
Type value of the shape. This shading information is a 32 bit value
with first the number of the shadings and then the shadings. A shading
is encoded with 1,2,3,4,5,6,7 for lighten 10 to 70 and 8,9,a,b,c,d,e,f
for darken -80 to -10.
To get this information from EnhanceCustomShape2d I have made its
method GetLuminanceChange() public.
Because OOXML only has darken, darkenLess, lighten and lightenLess our
values are mapped:
-10, -20, -30 to darkenLess
-40, -50, -60, -70, -80 to darken
10, 20, 30 to lightenLess
40, 50, 60, 70 to lighten
The bupreport mentions only 'Octagon Bevel' and 'Diamond Bevel'. But
the patch fixes missing shading for shapes of Types 'ActionButton*'
as well. Such shapes come in from MS binary import.
Change-Id: I03f19496b915f3ced6346222e8806832b4ee2827
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133220
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
...so that it can't still run when the main thread is already in DeInitVCL, and
this thread would crash with SIGSEGV at
> #6 0x00007fe79001ac74 in dp_gui::TheExtensionManager::modified (this=<optimized out>) at /usr/src/debug/libreoffice-7.3.2.2-1.fc36.x86_64/desktop/source/deployment/gui/dp_gui_theextmgr.cxx:498
> #7 0x00007fe790834a0b in operator() (__closure=<optimized out>, xListener=...) at /usr/src/debug/libreoffice-7.3.2.2-1.fc36.x86_64/desktop/source/deployment/manager/dp_extensionmanager.cxx:1416
> #8 cppu::OInterfaceContainerHelper::forEach<com::sun:⭐:util::XModifyListener, dp_manager::ExtensionManager::fireModified()::<lambda(const com::sun:⭐:uno::Reference<com::sun:⭐:util::XModifyListener>&)> > (func=..., this=<optimized out>) at /usr/src/debug/libreoffice-7.3.2.2-1.fc36.x86_64/include/cppuhelper/interfacecontainer.h:292
> #9 dp_manager::ExtensionManager::fireModified (this=0x5613a450e050) at /usr/src/debug/libreoffice-7.3.2.2-1.fc36.x86_64/desktop/source/deployment/manager/dp_extensionmanager.cxx:1414
> #10 0x00007fe79082d907 in dp_manager::ExtensionManager::activateExtension (this=0x5613a450e050, identifier=..., fileName=..., bUserDisabled=<optimized out>, bStartup=<optimized out>, xAbortChannel=..., xCmdEnv=...) at /usr/src/debug/libreoffice-7.3.2.2-1.fc36.x86_64/desktop/source/deployment/manager/dp_extensionmanager.cxx:425
> #11 0x00007fe790830b5f in dp_manager::ExtensionManager::addExtension (this=0x5613a450e050, url=..., properties=..., repository=..., xAbortChannel=..., xCmdEnv=...) at /usr/src/debug/libreoffice-7.3.2.2-1.fc36.x86_64/desktop/source/deployment/manager/dp_extensionmanager.cxx:721
> #12 0x00007fe79002d628 in dp_gui::ExtensionCmdQueue::Thread::_addExtension (bWarnUser=<optimized out>, rRepository=..., rPackageURL=..., rCmdEnv=..., this=0x5613a4753490) at /usr/src/debug/libreoffice-7.3.2.2-1.fc36.x86_64/desktop/source/deployment/gui/dp_gui_extensioncmdqueue.cxx:870
> #13 dp_gui::ExtensionCmdQueue::Thread::execute (this=0x5613a4753490) at /usr/src/debug/libreoffice-7.3.2.2-1.fc36.x86_64/desktop/source/deployment/gui/dp_gui_extensioncmdqueue.cxx:744
(Which can apparently happen when you quit/restart LO quickly enough after
installing an extension through "Tools - Extension Manager...")
The join was missing ever since the code's introduction in
f167d090345c9c7950665e50006aff4fc0ace078 "INTEGRATION: CWS extmgrui01" (there
originally was an unused stopAndWait that would have joined, but which got
removed in 0014f10d9237e82357e11aedecca817f67827536 "#i105556#: remove unused
code", but there doesn't appear to be at least any obvious reason why joining in
~ExtensionCmdQueue should cause problems (at least with the recent fixes
2dce6754355a06e567427c39154d8747538864b1 "Reliably stop
ExtensionCmdQueue::Thread::execute" and 057f504e6518d1cefd141713c98a15cf9160e676
"Use the sander std::condition_variable semantics in
ExtensionCmdQueue::Thread".)
Change-Id: Iaad47fb77feed529dadf230088e1cb8ffccc80c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133248
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
From the `./gradlew --warning-mode all assembleStrippedUIEditingRelease`
output:
> > Configure project :
> The RepositoryHandler.jcenter() method has been deprecated. This is
> scheduled to be removed in Gradle 8.0. JFrog announced JCenter's sunset
> in February 2021. Use mavenCentral() instead. Consult the upgrading
> guide for further information:
> https://docs.gradle.org/7.2/userguide/upgrading_version_6.html#jcenter_deprecation
> at build_a6ed945jjgv6miyybz50fclhq$_run_closure1$_closure2.doCall(/home/michi/development/git/libreoffice-WORKTREE-for-android-x86/android/source/build.gradle:14)
> (Run with --stacktrace to get the full stack trace of this deprecation warning.)
Change-Id: I5db84a9778b598d1e3459dd313aa05c229060368
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133239
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
`build.gradle` no longer contains a specific `buildToolsVersion`
since
commit a93770e6d0d2fcc5a2eefbed546acee055833fd4
Date: Fri Mar 6 12:16:24 2020 +0100
android: Update gradle
The previous version e.g. did not support building
Android App Bundles yet.
Drop explicit 'buildToolsVersion', as suggested in the warning
during build:
> WARNING: The specified Android SDK Build Tools version (27.0.3) is ignored,
> as it is below the minimum supported version (28.0.3) for Android Gradle
> Plugin 3.6.1.
> Android SDK Build Tools 28.0.3 will be used.
> To suppress this warning, remove "buildToolsVersion '27.0.3'" from your build.gradle
> file, as each version of the Android Gradle Plugin now has a default
> version of the build tools.
so the sed expression in configure.ac was evaluating to an empty
string and only the existence of `"$ANDROID_SDK_DIR/build-tools/`
was checked.
As mentioned in a93770e6d0d2fcc5a2eefbed546acee055833fd4,
each version of the Android Gradle Plugin now has a default
version of the build tools. It takes care of downloading and
installing that one as necessary.
Change-Id: Ic8528c5dc238dccb35ccf215945ef935e8c3a89c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133238
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
This crashes only when calling storeToURL() with writer_pdf_Export?
There is a text frame 112, followed by section frame 126, which contains
table frame 127.
The section frame 126 is being formatted, which in
SwFrame::PrepareMake() formats its prev, text frame 112.
This does MoveBwd() and in SwContentFrame::MakeAll() formats its next,
tab frame 127.
This also does MoveBwd() and then there is this really odd condition in
SwTabFrame::Paste() where it calls SwFrame::CheckPageDescs() if it
*doesn't* have a RES_PAGEDESC item and the page has a non-default page
style - this condition remains inexplicable since initial CVS import.
Then CheckPageDesc() sees the (next) page is empty and deletes it.
So check in sw::IsPageFrameEmpty() that there aren't any sections with
IsDeleteForbidden() set.
(regression from commit b9ef71476fd70bc13f50ebe80390e0730d1b7afb)
Change-Id: I3c64fe40fabffc255c4146a35c678ce6a1cc09c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133222
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Can use CPPUNIT_TEST_FIXTURE() instead.
See commit a226cec52e536c46e03f57a5f1f7931abbeb0cdd
(CppunitTest_sw_rtfimport: convert one testcase to use
CPPUNIT_TEST_FIXTURE(), 2019-11-05) for motivation.
Change-Id: I315d54c4554141d3a0e04d3873b06b0fd5fa14d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133237
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
With previous implementation, empty spaces between dashes
were too long.
Additionally line joints were not working correctly, after
EMF+ reworking: tdf#111486
This commit fixes all these issues and additionally it is
covering it with tests.
Change-Id: I9404e566d2d7d3405ab817268ad9b1f538c200eb
Change-Id: I523f92a928ab592ff175d0d01c1ad1a3bc22e324
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133207
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
- add an SwWrtShell::InsertContentControl() to put the current selection
into a content control
- if there is no selection, add a non-empty placeholder
- expose this as a new .uno:InsertContentControl uno command
- add this new command to the bottom of the form menu -- probably we can
have a sub-menu there once there will be more types
Change-Id: Icb32aee777ab08d09401bf468788692b933a90ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133241
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
This avoids the need for the tricky osl::Condition::reset call.
Change-Id: Id441fe6be42409fa43624bc0c1cbc8a62462d3e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133240
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Inserting a hyperlink through the hyperlink dialog should replace the
content of the entire cell if it contains a formula.
Change-Id: I2e06f134bfcd21ec3fef76f2a9b80e433adce1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132785
Tested-by: Jenkins
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
I started from a copy/paste of FormatNumber.
Then I deduplicated the code (it saved about 99% of it).
Change-Id: Ibcb9ffbf8cebf45d5ffac4713e3d220b8499ba11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133133
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
...that were like that ever since c25ec0608a167bcf1d891043f02273761c351701
"initial import", but which when called would run into the assert(false)/
"!!br0ken!!" code in rtl::str::newFromSubString (sal/rtl/strtmpl.hxx), as the
count argument to OUString::copy is -1. So just return an empty OUString,
similar to what the getTimeDateFunctions and getNumericFunctions functions
always did.
(Stumbled across this when it got flagged by loplugin:stringviewvar with
clang-cl.)
Change-Id: Ief23c7e0c7712dd65e6213c9e7db3a10d276eaa6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133226
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It's also used by the navigator for e.g. bookmarks -> select entry ->
context menu -> rename.
Change-Id: Ieea79c57cfb07ff0f26f3c70e0b1ce33aa30d9d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133224
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Currently just implemented for the QtWidget, but still as a static
function, so it may be used for QtObject at some point too.
But there is no (mouse) enter or leave event function in QWindow,
so no way to handle these there. And since we can't modify the
returned QWidget from QWidget::createWindowContainer, the only way
would be to expand the static QtWidget::handleEvent used by
QtObjectWindow::event ... if it's actually needed at some point.
Change-Id: If9009e5dfca508acd1e702df1a17eb8ad7c29690
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133190
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
... just to transform it back when it's used.
The problem was that the transform had zero vertical scale; thus
it couldn't be inverted. The unchanged matrix was used both in the
SdrCaptionPrimitive2D constructor, and in its create2DDecomposition,
thus scaling the X coordinate up twice. The result, which depends
on the original value of X, was huge for comments attached to cells
with large column numbers. Trying to convert such coordinate from
pixels to logic units exceeded 64-bit integer range.
Avoiding the transformations back and forth is possible, because
the transform is constant in the object. This also avoids unneeded
overhead.
There is an open question why there was a need in the calculations
for the XLSX file. The problem doesn't happen with ODS, so likely
there is a calculation of the draw page size in some circumstances
that may be avoided.
Change-Id: Iccbe77936ec1078daf6b05b0b2d44a6fa3536c4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133217
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The problem is the UpdateFramesForAddDeleteRedline() call in makeMark(),
this is called in a loop for multiple fieldmarks and when it's called
for the first one, of course the other ones aren't in the document yet,
so HideIterator::Next() can't find them.
But this is only needed when inserting a new fieldmark anyway, so just
disable for copying.
(regression from commit 92384a813176b964a67bcbeb2fa617c554dbc4a2)
Change-Id: Ic1b34d469a553cf7bbf2d1a99edaea900bdd7417
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133215
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This is now the second bug filed because a server replies with 403 if
the UserAgent contains the string "curl".
Change-Id: I25ca2d255af76a7ff4e64dad900b1bf0b78de59f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133212
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The problem was caused by my remote font downloading changes. We need
to be more careful in lo_initialize() and libreofficekit_hook_2() to
distinguish whether the code is called from "normal" Online (with
"pre-initialisation" through lok_preinit_2()) or otherwise, for
instance the iOS app, where not pre-initialisation is done.
Sadly, this fix makes state handling in init.cxx even more complex
with one more static Boolean flag.
Change-Id: I2a8fa96740eb79725aa162cf7adc86d49a8ba603
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133175
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133196
Tested-by: Jenkins
Regression during `make check` introduced with
ab699bfdb3375f7142a50cc35322e2924c9e5945 "new loplugin:stringviewvar looks for
OUString vars that can be".
Change-Id: Ib6b9aabcfd380b43a77a97cf9d7e15c37aeb852c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133204
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
First commit 2177f48b16b8cd68c0ef4ec817ca391f28324418 forgot to adapt
one use of WITH_WEBDAV so the test didn't run and then commit
2cbf83e20889351e2d2a6e29e5c7d9250af58647 removed some functions that
were only called by the test.
Change-Id: I46c8b065d37aa072a8966cce30d9e63d63b1145c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133206
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
in Impress. This involves:
1. SvxFont::QuickGetTextSize() and SvxFont::GetPhysTxtSize():
insert space only when text array value changes. Same value indicates
diffferent characters of the same glyph item (e.x. surrogate pairs,
unicode IVS that is made of a base character and a selector. ).
2. ImpEditEngine::GetChar(): fix a logical mistake that tried
to increase the index by 1 than checking the value of character
position. To advance the index we always need to check the position
first.
Change-Id: I4e3547413ce361ae7801c957e6d589776ebed114
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133102
Tested-by: Jenkins
Reviewed-by: Mark Hung <marklh9@gmail.com>
... otherwise, using a zoomed document, the returned bounding box
does not account for that zoom.
Change-Id: Id7834bbc2bebaa923414cf029c37a8e22f9c1078
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133205
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Hope this should be acceptable.
Change-Id: I567e0cb358c8693db8f1c674b4fa6f841506f331
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133188
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
- map inline/run SDTs with unknown type (i.e. rich text) to
SwContentControl
- decouple block and run SDTs and leave block ones unchanged
- track start position of run SDTs similar to bookmarks, which needs
different code to SDT at text start vs later
- fix DocxAttributeOutput::RunText() to please
CppunitTest_sw_ooxmlexport2's testFdo67013, which had an inline SDT in
footer, not at para end
Change-Id: I59b8b7f3170cf37f1547db07ae0992850e0e3aa8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133195
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
For shading parts of a shape not of Type 'ooxml-*', ColorData is used,
introduced about 2005. For 'mso_spt*' shapes they are set directly,
for others they are encoded as 'col-********' into the Type value.
During OOo time two changes were made, resulting in the bugs, that
colors are assigned to wrong segments and that shadings are too dark.
More details are in the bug report.
With this patch the colors are assigned to the correct segments again.
The too dark colors are visible in our preset shapes 'Octagon Bevel'.
The shape 'Diamond Bevel' with corrected color assignment is also
affected. Both need new ColorData. Since it is important for
Libreoffice to have good compatibility with OOXML, I have decided to
use only the four shading values available in OOXML. In the long run,
these shapes should be replaced by ones that contain the shading
information inside the <enhanced-path> element.
Change-Id: I4b8323c45bf702fc371d6e6c82dd9102d0fd9929
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133132
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
As we add more and more MS fields as fixed,
some of them are set so the UI to manage that flag
is disabled. While it doesn't necessarily make
much sense to allow a user to SET these fields
as fixed (so don't ALWAYS enable that flag),
at least allow it to be turned off if it somehow
did get enabled.
Change-Id: I331c871fa7a3e40a7a0154ab4d7d68c67d9c1dad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133086
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Quoting from
commit 128de1949ff120ac925dbb06e398fa992fb295ba
Date: Tue Apr 19 15:18:49 2022 +0200
android: Use property instead of ANDROID_NDK_HOME env var
which ported from an obsolete (no longer supported by
current Gradle versions) way of setting the NDK path to a
deprecated but still supported one as an intermediate step
to allow upgrading Gradle:
> Note however, that with this approach of using the `ndk.dir`
> property instead of the suggested `android.ndkVersion`
> (with the latter having the stricter requirement that
> the `ndk` dir would have to be a subdir of the SDK dir),
> doing the actual upgrade to a newer Gradle (plugin) version
> in follow-up commit
> Change-Id Ia982d72d877e229c3006c6d528b830d16c88481f
> "android: Update Android Gradle Plugin to 7.1.3"
> revealed that the use of the `ndk.dir` property
> is deprecated in newer Gradle (plugin) versions as well,
> resulting in this warning.
>
> > > Task :stripStrippedUIDebugDebugSymbols
> > [CXX5106] NDK was located by using ndk.dir property. This method is
> > deprecated and will be removed in a future release. Please delete
> > ndk.dir from local.properties and set android.ndkVersion to
> > [20.0.5594570] in all native modules in the project.
> > https://developer.android.com/r/studio-ui/ndk-dir
>
> It might make sense to address that in a follow-up step,
> but for now, it's an improvement and keeps it working
> after the upgrade without potentially causing any incompatibility
> problems with existing autogen configurations,
> while support for the `ANDROID_NDK_HOME` env var that was
> used so far seems to have been dropped, [...].
The release notes for Android Gradle Plugin version 4.1.0
mention yet another way of setting an explicit NDK path
instead of just a version and that one is still supported
and not deprecated [1]:
> # Set the NDK path
> You can set the path to your local NDK installation using the
> android.ndkPath property in your module's build.gradle file.
>
> android {
> ndkPath "your-custom-ndk-path"
> }
>
> If you use this property together with the android.ndkVersion property,
> then this path must contain an NDK version that matches
> android.ndkVersion.
Therefore, switch to setting the NDK path using the `android.ndkPath`
property in liboSettings.gradle instead of the deprecated `ndk.dir`
in local.properties.
[1] https://developer.android.com/studio/releases/gradle-plugin?buildsystem=ndk-build#ndk-path
Change-Id: I34690ca8e15ff4742bab9a716a58b9ad85fa86e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133197
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Setting the archive base name in build.gradle using
project.ext.set("archivesBaseName", "LibreOfficeViewer")
no longer worked after
commit 39326bc7d439170dd24c9d4b837c2cdb720b5d6f
Date: Tue Apr 19 15:49:53 2022 +0200
android: Update Android Gradle Plugin to 7.1.3
... and gradle to 7.2, which is what Android Studio suggested
and did automatically when confirming.
As a consequence, the generated .apk or .aar files
would no longer have the app name in them, but be
called e.g. "source-strippedUIEditing-release-unsigned.apk"
instead of
"LibreOfficeViewer-strippedUIEditing-release-unsigned.apk".
Setting `archivesBaseName` in `android.defaultConfig`
in libOSettings.gradle works, so move it there.
Change-Id: Id03cbe10681aca85c35aeef64527bc7707c95736
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133191
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
