From 3372e19e06bbf397d45fcf17cb64c3da9dbca046 Mon Sep 17 00:00:00 2001 From: Maximilian Irlinger Date: Fri, 4 Nov 2022 12:44:00 +0100 Subject: [PATCH 1/4] jna: add --stacktrace argument to gradle --- src/bindings/jna/CMakeLists.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/bindings/jna/CMakeLists.txt b/src/bindings/jna/CMakeLists.txt index 9c14cfa1e6b..ac0f3e63b91 100644 --- a/src/bindings/jna/CMakeLists.txt +++ b/src/bindings/jna/CMakeLists.txt @@ -116,7 +116,7 @@ if (Java_JAVAC_EXECUTABLE) ${PLUGIN_JAR_PATHS} COMMAND ${CMAKE_COMMAND} ARGS -E copy_directory "${CMAKE_CURRENT_SOURCE_DIR}" "${CMAKE_CURRENT_BINARY_DIR}" - COMMAND ${GRADLE_EXECUTABLE} -q --console=plain clean assemble + COMMAND ${GRADLE_EXECUTABLE} --stacktrace -q --console=plain clean assemble WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/libelektra/test-exclusion.gradle" "${CMAKE_CURRENT_BINARY_DIR}/version-settings.gradle" ${JNA_BINDING_SOURCE_FILES} @@ -159,7 +159,7 @@ if (Java_JAVAC_EXECUTABLE) OR (NOT BUILD_TESTING))) add_test ( NAME testjna_gradle - COMMAND ${GRADLE_EXECUTABLE} -q --console=plain test + COMMAND ${GRADLE_EXECUTABLE} --stacktrace -q --console=plain test WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/libelektra") set_property (TEST testjna_gradle PROPERTY ENVIRONMENT "LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/lib") From 34df752dbfe3de9b74f2f7d489d53543c8399a79 Mon Sep 17 00:00:00 2001 From: Maximilian Irlinger Date: Fri, 4 Nov 2022 12:45:26 +0100 Subject: [PATCH 2/4] docker: use opendjdk-17-jdk on Debian Sid, closes #4627 --- doc/news/_preparation_next_release.md | 4 ++-- scripts/docker/debian/sid/Dockerfile | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/news/_preparation_next_release.md b/doc/news/_preparation_next_release.md index 3414d5373fd..4649a274607 100644 --- a/doc/news/_preparation_next_release.md +++ b/doc/news/_preparation_next_release.md @@ -413,7 +413,7 @@ This section keeps you up-to-date with the multi-language support provided by El - Fix warning for CMP0115 _(0x6178656c)_ - <> - <> -- <> +- Pass `--stacktrace` to gradle for the JNA builds. _(Maximilian Irlinger @atmaxinger)_ - <> - <> @@ -423,7 +423,7 @@ This section keeps you up-to-date with the multi-language support provided by El - <> - <> - <> -- <> +- Use `openjdk-17-jdk` in Debian Sid. _(Maximilian Irlinger @atmaxinger)_ - <> ## Infrastructure diff --git a/scripts/docker/debian/sid/Dockerfile b/scripts/docker/debian/sid/Dockerfile index d1a6fc6cb9a..8fa6c778aa9 100644 --- a/scripts/docker/debian/sid/Dockerfile +++ b/scripts/docker/debian/sid/Dockerfile @@ -49,7 +49,7 @@ RUN apt-get update && apt-get -y install \ moreutils \ ninja-build \ npm \ - openjdk-11-jdk \ + openjdk-17-jdk \ pkg-config \ python3-dev \ python3-pip \ From 469c8bd76d4db1aa9c25e3050f1643b42e626bfa Mon Sep 17 00:00:00 2001 From: Maximilian Irlinger Date: Fri, 4 Nov 2022 12:54:05 +0100 Subject: [PATCH 3/4] linkchecker: (temporarily) whitelist broken latest successful build links --- tests/linkchecker.whitelist | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tests/linkchecker.whitelist b/tests/linkchecker.whitelist index 09f8d2e1a1f..d8a1991d6d6 100644 --- a/tests/linkchecker.whitelist +++ b/tests/linkchecker.whitelist @@ -43,3 +43,8 @@ https://community.kde.org/Akademy/2018/Config_Workshop # Certificate issues https://debian-stretch-repo.libelektra.org + + +# Broken links to MinGW builds for Windows (see issue #4624), temporary fix to get PRs merged! +https://build.libelektra.org/job/libelektra/job/master/lastSuccessfulBuild/artifact/artifacts/debian-bullseye-mingw-w64-i686/elektra.zip +https://build.libelektra.org/job/libelektra/job/master/lastSuccessfulBuild/artifact/artifacts/debian-bullseye-mingw-w64-x86_64/elektra.zip From 3ed579a8b51946fb0a11408980b56cc6a676cc94 Mon Sep 17 00:00:00 2001 From: Maximilian Irlinger Date: Fri, 4 Nov 2022 18:22:56 +0100 Subject: [PATCH 4/4] doc: fix spelling mistakes --- doc/decisions/change_tracking.md | 8 ++++---- doc/decisions/operation_sequences.md | 10 +++++----- doc/news/2014-09-02_0.8.8.md | 2 +- doc/news/2022-10-05_0.9.11.md | 2 +- 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/doc/decisions/change_tracking.md b/doc/decisions/change_tracking.md index c897927d0f8..98760f5d75b 100644 --- a/doc/decisions/change_tracking.md +++ b/doc/decisions/change_tracking.md @@ -67,7 +67,7 @@ When change tracking is enabled, this one will have the most memory overhead, as Do the per-parent-key tracking within `libelektra-kdb`, but with meta keys. Essentially the same approach as above, but instead of deep-duping, we add the original value -as a meta-key to every key. Not yet clear how we handle changes to meta-data then. +as a metakey to every key. Not yet clear how we handle changes to metadata then. ### Alternative 3 - Change tracking within a separate plugin @@ -104,7 +104,7 @@ We need to extend `Key` with the following info: - Whether tracking is enabled for this key The tracking itself would be done within the `ks*` and `key*` methods, after checking if it is enabled. -It would also transparently work for meta-data, as meta-data itself is implemented as a keyset with keys. +It would also transparently work for metadata, as metadata itself is implemented as a keyset with keys. Downsides of this approach: @@ -125,11 +125,11 @@ Use the `backendData->keys` for change tracking We already store which keys have been returned by `kdbGet` for each backend within KDB. Currently, however, this is not a deep duplication, as we are returning the keys from `backendData->keys` directly. -This means we can not detect changes to the values or meta-data of keys right now. +This means we can not detect changes to the values or metadata of keys right now. We can, however, rely on this for detecting removed and added keys in its current form. If we don't want to deep-dup it, we'd need to do something different to detect which keys have been modified. -One possibility would be to add meta-data within the `key` functions (e.g. `meta:/elektra/original`), but that would violate the `libelektra-core` must be minimal constraint. +One possibility would be to add metadata within the `key` functions (e.g. `meta:/elektra/original`), but that would violate the `libelektra-core` must be minimal constraint. There is already [another decision](internal_cache.md) which discusses adding general copy-on-write semantics to Elektra. We could use this together with `backendData->keys` deep-duped to do memory efficient change tracking. diff --git a/doc/decisions/operation_sequences.md b/doc/decisions/operation_sequences.md index 07a29d25d44..cd3216e0213 100644 --- a/doc/decisions/operation_sequences.md +++ b/doc/decisions/operation_sequences.md @@ -17,13 +17,13 @@ In applications, `kdbGet` and `kdbSet` of different parent keys might be interwo This is problematic, as plugins may store the result of `kdbGet` and use the stored data in the following `kdbSet` to calculate a changeset. Plugins have to do this, as there isn't any other Elektra-provided mechanism currently to do change tracking for them. -Note, that erroneous behaviour only occurs if plugins are used globally, i.e. as `notification-send` hook plugins. -If they are mounted for specific backends (via `kdb mount`), this behaviour will not occur as plugins from different backends are isolated. +Note, that erroneous behavior only occurs if plugins are used globally, i.e. as `notification-send` hook plugins. +If they are mounted for specific backends (via `kdb mount`), this behavior will not occur as plugins from different backends are isolated. ### Reproducible Example The following example will demonstrate the problematic sequence as real, runnable code. -This example will show the erroneous behaviour for the `dbus` and `logchange` plugins, if used as `notification-send` hooks. +This example will show the erroneous behavior for the `dbus` and `logchange` plugins, if used as `notification-send` hooks. These both plugins just serve as a general demonstration, and there may be more plugins that do change tracking this way. First, run some setup steps: @@ -119,7 +119,7 @@ So the correct changeset should look like: | -------------- | ------------ | ------------- | | `user:/a/test` | | | -The erroneous behaviour can be noticed by the output of `dbus-monitor`: +The erroneous behavior can be noticed by the output of `dbus-monitor`: ``` signal time=1666993066.749997 sender=:1.364 -> destination=(null destination) serial=2 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyAdded @@ -134,7 +134,7 @@ signal time=1666993066.750866 sender=:1.364 -> destination=(null destination) se string "user:/b/foreground" ``` -The same behaviour is present in the `logchange` plugin. Notice its output onto `stdout`: +The same behavior is present in the `logchange` plugin. Notice its output onto `stdout`: ``` added key: user:/a/brightness diff --git a/doc/news/2014-09-02_0.8.8.md b/doc/news/2014-09-02_0.8.8.md index 30821fdac62..f324888c9b2 100644 --- a/doc/news/2014-09-02_0.8.8.md +++ b/doc/news/2014-09-02_0.8.8.md @@ -7,7 +7,7 @@ In this release we changed 578 files in 473 commits (68596 insertions(+), 59260 deletions(-) compared to Elektra 0.8.7). -We assume thats the largest change set for any of Elektra’s releases +We assume thats the largest changeset for any of Elektra’s releases up to now. It happened only within a bit more than a month up (0.8.7 was released 28.07.2014). diff --git a/doc/news/2022-10-05_0.9.11.md b/doc/news/2022-10-05_0.9.11.md index 3843896ce12..9a7778a59f0 100644 --- a/doc/news/2022-10-05_0.9.11.md +++ b/doc/news/2022-10-05_0.9.11.md @@ -32,7 +32,7 @@ docker run -it elektra/elektra In a separated branch we rewrote the whole backend system. With this new backend system, backends are now also plugins, allowing backends also to be non-file-based, e.g., using databases. -The main purpose of this release is to give a last stable release before master gets disrupted with a huge change set. +The main purpose of this release is to give a last stable release before master gets disrupted with a huge changeset. The next release is not to be expected in this year. A huge thanks to _(Klemens Böswirth @kodebach)_, _(Maximilian Irlinger @atmaxinger)_ for the many changes in the branch.