[Bug]

Summary
I get this when compiling flop:
==> flop
Compiling 13 files (.ex)

== Compilation error in file lib/flop/builder.ex ==
** (Ecto.Query.CompileError) `not (is_nil(field(r, ^var!(field))) == ^var!(value))` is not a valid query expression.

* If you intended to call an Elixir function or introduce a value,
  you need to explicitly interpolate it with ^

* If you intended to call a database function, please check the documentation
  for Ecto.Query.API to see the supported database expressions

* If you intended to extend Ecto's query DSL, make sure that you have required
  the module or imported the relevant function. Note that you need macros to
  extend Ecto's querying capabilities

    (ecto 3.6.2) expanding macro: Ecto.Query.dynamic/2
    lib/flop/builder.ex:196: Flop.Builder.build_op/3
    expanding macro: Flop.Operators.build_dynamic/3
    lib/flop/builder.ex:196: Flop.Builder.build_op/3
could not compile dependency :flop, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile flop", update it with "mix deps.update flop" or clean it with "mix deps.clean flop"

Steps to reproduce

heres my deps:

      {:absinthe_plug, "~> 1.5.5"},
      {:absinthe_relay, "~> 1.5.1"},
      {:absinthe, "~> 1.6.3"},
      {:bamboo_phoenix, "~> 1.0.0"},
      {:bamboo, "~> 2.2.0"},
      {:bcrypt_elixir, "~> 3.0"},
      {:broadway_sqs, "~> 0.6.1"},
      {:csv, "~> 2.3"},
      {:dataloader, "~> 1.0.0"},
      {:decimal, "~> 2.0"},
      {:earmark, "~> 1.4.14"},
      {:ecto_enum, "~> 1.4"},
      {:ecto_sql, "~> 3.6.2"},
      {:ecto, "~> 3.6.2", override: true},
      {:esbuild, "~> 0.3", runtime: Mix.env() == :dev},
      {:ex_aws_lambda, "~> 2.0.1"},
      {:ex_aws_s3, "~> 2.0"},
      {:ex_aws_sns, "~> 2.0"},
      {:ex_aws_sqs, "~> 3.2"},
      {:ex_aws, "~> 2.2.1"},
      {:ex_phone_number, "~> 0.2"},
      {:exq, "~> 0.14.0"},
      {:exvcr, "~> 0.13.0", only: :test},
      {:faker, "~> 0.12", only: [:dev, :test, :prod]},
      {:finch, "~> 0.3"},
      {:floki, ">= 0.30.0", only: :test},
      {:geo_postgis, "~> 3.4"},
      {:geolix_adapter_mmdb2, "~> 0.5.0"},
      {:geolix, "~> 1.0"},
      {:gettext, "~> 0.11"},
      {:goth, "~> 1.3-rc"},
      {:guardian, git: "https://github.com/ueberauth/guardian.git", ref: "9baef5b2880ed23d33f0e7c7c0a0ee58e09fc852"},
      {:hackney, "~> 1.17", override: true},
      {:httpoison, "~> 1.7.0"},
      {:icalendar, "~> 1.1.0"},
      {:ja_serializer, "~> 0.16.0"},
      {:jason, "~> 1.2"},
      {:jaxon, "~> 2.0"},
      {:jsx, "~> 3.0", override: true},
      {:logger_json, "~> 4.3"},
      {:logstash_json, "~> 0.7.4"},
      {:number, "~> 1.0.3"},
      {:petal_components, "~> 1.0"},
      {:petal_framework, "~> 0.4.5", repo: "petal"},
      {:phoenix_ecto, "~> 4.4.0"},
      {:phoenix_html, "~> 3.3.0"},
      {:phoenix_live_reload, "~> 1.4", only: :dev},
      {:phoenix_live_view, "~> 0.19"},
      {:phoenix_pubsub_redis, "~> 3.0.0"},
      {:phoenix_pubsub, "~> 2.1"},
      {:phoenix_view, "~> 2.0"},
      {:phoenix, "~> 1.7.0"},
      {:plug_cowboy, "~> 2.0"},
      {:postgrex, ">= 0.0.0"},
      {:recurring_events, "~> 0.4.0"},
      {:redix, "~> 0.11.1", override: true},
      {:scribe, "~> 0.10"},
      {:sentry, "~> 7.0"},
      {:sweet_xml, "~> 0.6"},
      {:tailwind, "~> 0.1.6", runtime: Mix.env() == :dev},
      {:tesla, "~> 1.5.0"},
      {:timex, "~> 3.7"},
      {:yaml_elixir, "~> 2.7.0"}

Expected behaviour
it compiles
Actual behaviour
error above
Elixir/Erlang version
1.14.2
Flop and Ecto versions

ecto (Hex package) (mix)
ecto_sql (Hex package) (mix)
locked at 3.6.2 (ecto_sql) 5ec9d7e6
flop (Hex package) (mix)
locked at 0.20.2 (flop) 37c5447e

Additional context
No response

Thanks, I could reproduce this with the versions you mentioned. The error goes away after upgrading ecto_sql to 3.7.0. Flop officially requires ecto_sql ~> 3.9, so I'll close this, since this ecto_sql version is unsupported.


Escape HTML in Submission Text for Text Assessment

Fixes #1147

⚠ This should be merged after #1249!
I rebased this to resolve future conflicts.
(Maybe even rebase this once again on top of develop as. soon as #1249 is merged.)
Relevant are commits eef5cc7 and later only!

Checklist

[ ] I tested all changes and all related features with different users (student, tutor, instructor, admin) on the test server https://artemistest.ase.in.tum.de.

Description
Fix problem where special HTML characters where causing problems.
Steps for Testing

Create Text Submission with ˋ<>ˋ symbols
Assess them.
view result

Hi @lovaiible and @HanyaElhashemy thanks for your reviews.
I did fix the additional bugs spotted in your review.
Only assessing the first occurrence is a known limitation and will be resolved in the future as part of #1251.

⚠ This PR is a bit messy due to the refactoring going on, pleas ignore most commits as stated in the PR description.


[PROCESS] ToIP Deliverables Process compliant glossary proposal

CTWG Process Proposal
This issue offers a proposal for a tactical solution to the glossary generation process supported by the CTWG on behalf of the entire ToIP Foundation community.
Status Assessment
The CTWG has been struggling for nearly nine months to strike a balance between:

Available developer skills
Curator resources
Prioritization of ToIP and external organization requirements

In the spirit of Issue 22 - Glossary Generation and Issue 23 - Consumability we SHOULD be focused on the following basic objectives in the CTWG:

Definition of a data model for Terms and Concepts
Curation process for Terms and Concepts
Tool agnostic use of a CTWG maintained corpus of terms and concepts

Recently, members of the CTWG created the trustoverip/ctwg-sandbox repo for the experimentation of glossary production. This endeavor was helpful for members to visualize an example of an end-to-end glossary generation process using file-system-based markdown content as opposed to a centralized datastore.
At the same time, the ToIP Foundation has been trying to execute on the delivery of an initial set of deliverables by end of 1Q21. This plan pressure influenced a call for a vote along with complimentary discussion associated with the trustoverip/ctwg-sandbox repo solution for the delivery of these 1Q21 ToIP deliverables.
While the broader CTWG members appreciate the time and efforts of the subset of CTWG members that participated in the trustoverip/ctwg-sandbox research, the solution outcome COULD be summarized as:

Objective
Pass/Fail Assessment
Comment

1. Definition of a data model for Terms and Concepts
Pass
However, the metadata in the data model assumes consumption by a specific tool. Current status lacks an extraction mechanism that hides the internal metadata during glossary generation process.

2. Curation process for Terms and Concepts
Unclear
It seems that lessons have been learned on how to curate terms and concepts in a file-system-based corpus of markdown content but the declaration (description) of the internal CTWG process seems to be lacking.

3. Tool agnostic use of a CTWG corpus of terms and concepts
Fail
This experiment ignored an investigation into Issue 17 - Tool Assessment and it produced a tool dependent solution that is incompatible with the existing ToIP Deliverables Process Requirements.

It is also important to recognize that the efforts to date were somewhat overshadowed (derailed) by a one particular requirement that was given very high priority by the trustoverip/ctwg-sandbox researchers -- hoverText. While no one can disagree with the richness hoverText adds to READERS of ToIP Deliverables, this requirement at best SHOULD have been prioritized as a WISH not as a MUST HAVE. The justification for this position can be found in the ToIP Deliverables Process which went to great lengths to defined a set of document authoring requirements and to provide flexibility of tooling choice for ToIP Foundation members.
By placing so much emphasis on the hoverText derailment factor, the resulting solution ignored:

Multiple rendering format flexibility (.pdf, .md, .html)
ToIP themed and templated Authoring Tool Options

As a result, it is the opinion of this issue author (@vinomaster), that it would be very difficult for the ToIP Foundation to support the trustoverip/ctwg-sandbox solution approach.
Additionally, as author (@vinomaster) of this issue, the following factors SHOULD also be considered in the assessment of the trustoverip/ctwg-sandbox solution:

No Central Corpus: While tactical in nature, the copying of term .md files into each repo creates alot of duplication and reduces the value of ToIP curated terms because each deliverables repo task force could maintain its own version of terms in their repos. Thus, defeating the purpose of the CTWG.

Incomplete Tooling Proposal: The ToIP Foundation is not bound to a single tool and welcomes the opportunity to offer membership other authoring tools. However, such new tooling proposals SHOULD be considered as consistent packages with existing efforts that provide:

ToIP Theming
GitHub Template Repo funtionality
Familiar repo build and usage instructions

Avoidance of ToIP Process Ramifications: Process proposals SHOULD NOT ignore the impact they have on existing processes, assets and work-in-progress.

Tactical Solution
Imagine the basic tasks of a ToIP Foundation Author concerning document development:

Discovery: Find a term/concept definition
Submission: Propose a new term/concept definition
Usage: Refer to a term/concept definition

Let us assume the term SSI is defined in a CTWG file called ssi.md and that it complies with the data model prescribed by the trustoverip/ctwg-sandbox solution.
Alex, a ToIP Foundation Author, would desire to simply use a term-by-reference approach while he is writing his content using Markdown, the ToIP Foundation approved language.
The [SSI](http://ctwg-server.trustoverip.org/ssi/) community is cool.

While the above Usage model is feasible in all ToIP Authoring Tools, it is currently not feasible as it places a strategic dependency on the CTWG Process -- support for a RESTful web server.
However, a tactical solution is possible whereby Alex's repo would have a local file called glossary.md that contained all of his terms of interest.
Given a centralized repo based corpus of Markdown files in the data model prescribed by the trustoverip/ctwg-sandbox solution, we SHOULD be able to create a simple command-line tool in the trustoverip/concepts-and-terminology-wg repo whereby Alex could obtain on-demand a static glossary.md file that he could add to his repo.
make glossary tag={gswg,tswg}

This command-line tool would:

search all CTWG terms (.md files) for terms matching the desired tags
sort the results
generate a single markdown file from the data model complaint docs

Alex would then use use a local-term-by-reference approach
The [SSI](./glossary.md#ssi) community is cool.

and if he desired a change to any term he would follow the CTWG Submission processes and then rerun the command-line tool to update his local copy.
This approach COULD benefit from existing tools such as pandoc which is already used by the current set of ToIP Authoring Tools. However, this approach WILL REQUIRE a pre-processor to remove the data model metadata and to generate a glossary definition for each term from the associated source files (.md files).
This proposed approach has the following tactical benefits:

Objective
Pass/Fail Assessment
Comment

1. Definition of a data model for Terms and Concepts
Pass
Uses current CTWG proposed data model.

2. Curation process for Terms and Concepts
Pass
Proposal is decoupled from internal curation process of the CTWG members -- whatever it is and whenever it is produced.

3. Tool agnostic use of a CTWG corpus of terms and concepts
Pass
Loosely coupled from the document generation and rendering decisions a ToIP task forces may make relative to authoring tools. Thus, inline with ToIP Deliverables Process Requirements.

For additionally clarity, we could  assume the strategic approach for the CTWG is to serve up a RESTful API for term access.
Additionally, we could assume that an alternative tactical approach exists whereby the CTWG creates repo enhancements for the ToIP versions of MkDocs and Spec-up. However, such an effort would be outside the expected scope of the CTWG charter and given the aforementioned shortage of volunteer developers it would be hard to justify.
Therefore the tactical proposal captured in this issue represents a path of least resistance example while enabling the CTWG members to focus on their true intentions the mental model for terms and concepts along with an associated curation process.


DAP test ncdap_test/testpathcvt.sh fails if --disable-dap-remote-tests is used

I often build with --disable-dap-remote-tests, especially from CI builds (so that I don't suddenly have 25 build trying to do all the remote dap tests over my wireless connection).
But at some point, it broke. In current master, I get an error:
(base) ed@koko:~/netcdf-c/ncdap_test$ bash -x ./testpathcvt.sh
+ test x = x
++ pwd
+ srcdir=/home/ed/netcdf-c/ncdap_test
+ . ../test_common.sh
++ TOPSRCDIR=/home/ed/netcdf-c
++ TOPBUILDDIR=/home/ed/netcdf-c
++ FP_ISCMAKE=
++ FP_ISMSVC=
++ FP_ISCYGWIN=
++ FEATURE_HDF5=yes
++ FEATURE_HDF5=yes
++ FEATURE_S3TESTS=no
++ FEATURE_NCZARR_ZIP=no
++ set -e
++ test x = x1
++ top_srcdir=/home/ed/netcdf-c
++ top_builddir=/home/ed/netcdf-c
++ test x/home/ed/netcdf-c/ncdap_test = x
+++ pwd
++ builddir=/home/ed/netcdf-c/ncdap_test
++ execdir=/home/ed/netcdf-c/ncdap_test
+++ basename /home/ed/netcdf-c/ncdap_test
++ thisdir=ncdap_test
+++ pwd
++ WD=/home/ed/netcdf-c/ncdap_test
++ cd /home/ed/netcdf-c/ncdap_test
+++ pwd
++ srcdir=/home/ed/netcdf-c/ncdap_test
++ cd /home/ed/netcdf-c/ncdap_test
++ cd /home/ed/netcdf-c
+++ pwd
++ top_srcdir=/home/ed/netcdf-c
++ cd /home/ed/netcdf-c/ncdap_test
++ cd /home/ed/netcdf-c/ncdap_test
+++ pwd
++ builddir=/home/ed/netcdf-c/ncdap_test
++ cd /home/ed/netcdf-c/ncdap_test
++ cd /home/ed/netcdf-c
+++ pwd
++ top_builddir=/home/ed/netcdf-c
++ cd /home/ed/netcdf-c/ncdap_test
++ cd /home/ed/netcdf-c/ncdap_test
+++ pwd
++ execdir=/home/ed/netcdf-c/ncdap_test
++ cd /home/ed/netcdf-c/ncdap_test
++ export srcdir top_srcdir builddir top_builddir execdir
++ test -e /home/ed/netcdf-c/ncdump/ncdump.exe
++ ext=
++ export NCDUMP=/home/ed/netcdf-c/ncdump/ncdump
++ NCDUMP=/home/ed/netcdf-c/ncdump/ncdump
++ export NCCOPY=/home/ed/netcdf-c/ncdump/nccopy
++ NCCOPY=/home/ed/netcdf-c/ncdump/nccopy
++ export NCGEN=/home/ed/netcdf-c/ncgen/ncgen
++ NCGEN=/home/ed/netcdf-c/ncgen/ncgen
++ export NCGEN3=/home/ed/netcdf-c/ncgen3/ncgen3
++ NCGEN3=/home/ed/netcdf-c/ncgen3/ncgen3
++ ncgen3c0=/home/ed/netcdf-c/ncgen3/c0.cdl
++ ncgenc0=/home/ed/netcdf-c/ncgen/c0.cdl
++ ncgenc04=/home/ed/netcdf-c/ncgen/c0_4.cdl
++ cd /home/ed/netcdf-c/ncdap_test
+ set -e
+ rm -f tmp_pathcvt.txt
+ set -x
+ testcase /xxx/x/y
+ testcase1 -u /xxx/x/y
+ T=-u
+ P=/xxx/x/y
+ echo -n 'path: -u: |/xxx/x/y| => |'
+ /home/ed/netcdf-c/ncdap_test/pathcvt -u -e /xxx/x/y
/home/ed/netcdf-c/ncdap_test/pathcvt: error: '/home/ed/netcdf-c/ncdap_test/.libs/pathcvt' does not exist
This script is just a wrapper for pathcvt.
See the libtool documentation for more information.

I'm a bit confused, because reading the configure.ac implies that I had no need to disable them, they would be off by default (see #2045).
So I don't know why this is failing, but it has happened a number of times now, with different builds. It just happened with HDF5-1.12.1.
If I do --disable-dap, then everything passes. The problem occurs whenever DAP is enabled, but dap-remote-tests are not.

This seems fixed now. ;-)


Key task_embeddings not found in config file ～/.libero/config.yaml.

Hi authors,
Thanks for releasing the codes for the study. When I perform the evaluation, the following error alerts. Do you know how to fix it?
Thank you very much for your time and efforts.

Did you find the solution for this issue?

Hi, did you find the solution?


Added CI workflow to test the pipeline

Added a test_pipelines workflow to run test profiles of the Aquascope workflows for CI.  Primarily for the attention of Sam Chill (slsevilla)

Fixes #63


build: Check to the version of the dependencies during the build.

Currently the build system is failing to identify the version of Yajl and Lua, which may leads the build to fail.
Version check should be supported inside the find_lua and find_yajl scripts:

https://github.com/SpiderLabs/ModSecurity/blob/master/build/find_lua.m4
https://github.com/SpiderLabs/ModSecurity/blob/master/build/find_yajl.m4

Lua version is now fixed.


Error Compiling : "src/ctpv.c:2:10: fatal error: magic.h: No such file or directory"

I use Void Linux
I installed libmagic, ImageMagick, ImageMagick-devel
I looked into #23 and I didn't find the packages mentioned there, I'm lost
thanks in advance!
info:
sudo make install
make -C embed
make[1]: Entering directory '/home/zorya/git/ctpv/embed'
make[1]: 'embed' is up to date.
make[1]: Leaving directory '/home/zorya/git/ctpv/embed'
cc -o src/ctpv.o src/ctpv.c -c -O2 -MMD -Wall -Wextra -Wno-unused-parameter
src/ctpv.c:2:10: fatal error: magic.h: No such file or directory
2 | #include <magic.h>
|          ^~~~~~~~~
compilation terminated.
make: *** [Makefile:55: src/ctpv.o] Error 1

I can confirm this error happening in both my Arch and Void Linux machines. It seems like author has gone MIA.  Especially since his name is very Russian. Let's hope he comes back safely.

Yes, everyone has his own problems, I hope he comes back safely.
And for the problem mentioned above, I did specify the path to magic.h in the Makefile's CFLAGS -I/path/to/magic.h (you can find it by using locate command), the error is gone but then when I tried to compile it again I got 3 terminal pages of errors and I don't know where to start again.

Nothing bad happened to me, I was busy at my work. :)
Try solutions from here: #4.

This happened for me as well, #4 wasn't helping. I have libmagic installed but not file-devel since I'm on MacOS.

This happened for me as well, #4 wasn't helping. I have libmagic installed but not file-devel since I'm on MacOS.

I'm pretty sure it's possible to get libmagic devel files on macOS because someone has apparently done it: #43

@emagaram Depending on the package manager you used to install libmagic, you may need to use compilation flags to make sure the compiler can see the necessary headers. However, recently ctpv has been made available in the MacPorts package repository, so you could simply use MacPorts to install ctpv with sudo port install ctpv.

@suhailskhan Thank you for maintaining a package! I really appreciate it! Please open a PR with installation instructions. It will help other people easily copy-paste a command and install the program. You can use my instructions for Arch Linux as a reference.

@NikitaIvanovV Done. See #49.


Fix building of discriminated union where field_validator wraps a Literal

skip change file check
Closes https://github.com/pydantic/pydantic/issues/6525
Selected Reviewer: @samuelcolvin

please review cc @dmontagu

Closing in favor of #6570


[Bug] MariaDB with Galera unable to re-start

Documentation

[x] I acknowledge that I have read the relevant documentation.

Describe the bug

Galera is not able to recover, the pvc's are intact.
Name:         mariadb-galera
Namespace:    database
Labels:       app.kubernetes.io/name=mariadb
              app.kubernetes.io/part-of=mariadb
              kustomize.toolkit.fluxcd.io/name=mariadb
              kustomize.toolkit.fluxcd.io/namespace=flux-system
Annotations:  <none>
API Version:  k8s.mariadb.com/v1alpha1
Kind:         MariaDB
Metadata:
  Creation Timestamp:  2024-10-17T14:22:23Z
  Generation:          2
  Resource Version:    25849582
  UID:                 663f4bd4-cd02-4ca7-a2f5-09a648312031
Spec:
  Galera:
    Agent:
      Graceful Shutdown Timeout:  1s
      Image:                      docker-registry3.mariadb.com/mariadb-operator/mariadb-operator:0.34.0
      Kubernetes Auth:
        Enabled:           true
      Port:                5555
    Available When Donor:  false
    Config:
      Reuse Storage Volume:  false
      Volume Claim Template:
        Access Modes:
          ReadWriteOnce
        Resources:
          Requests:
            Storage:  100Mi
    Enabled:          true
    Galera Lib Path:  /usr/lib/galera/libgalera_smm.so
    Init Container:
      Image:  docker-registry3.mariadb.com/mariadb-operator/mariadb-operator:0.34.0
    Primary:
      Automatic Failover:  true
      Pod Index:           0
    Recovery:
      Cluster Bootstrap Timeout:  10m0s
      Cluster Downscale Timeout:  5m0s
      Cluster Healthy Timeout:    30s
      Cluster Monitor Interval:   10s
      Cluster Upscale Timeout:    5m0s
      Enabled:                    true
      Min Cluster Size:           1
      Pod Recovery Timeout:       5m0s
      Pod Sync Timeout:           5m0s
    Replica Threads:              1
    Sst:                          mariabackup
  Image:                          mariadb:11.5.2
  Image Pull Policy:              IfNotPresent
  Max Scale:
    Auth:
      Admin Password Secret Key Ref:
        Generate:      false
        Key:           maxscale_password
        Name:          mariadb-secret
      Admin Username:  root
      Client Password Secret Key Ref:
        Generate:            false
        Key:
        Name:
      Delete Default Admin:  true
      Metrics Password Secret Key Ref:
        Generate:  false
        Key:
        Name:
      Monitor Password Secret Key Ref:
        Generate:  false
        Key:
        Name:
      Server Password Secret Key Ref:
        Generate:  false
        Key:
        Name:
    Connection:
      Port:         3306
      Secret Name:  mxs-galera-conn
    Enabled:        true
    Gui Kubernetes Service:
      Type:  LoadBalancer
    Kubernetes Service:
      Type:  LoadBalancer
  Max Scale Ref:
    Name:       mariadb-galera-maxscale
    Namespace:  database
  Metrics:
    Enabled:  true
    Exporter:
      Image:  prom/mysqld-exporter:v0.15.1
      Port:   9104
    Password Secret Key Ref:
      Generate:  true
      Key:       password
      Name:      mariadb-galera-metrics-password
    Service Monitor:
    Username:  mariadb-galera-metrics
  My Cnf:      [mariadb]
bind-address=*
default_storage_engine=InnoDB
binlog_format=row
innodb_autoinc_lock_mode=2
max_allowed_packet=256M

  My Cnf Config Map Key Ref:
    Key:   my.cnf
    Name:  mariadb-galera-config
  Pod Security Context:
    Fs Group:                999
    Fs Group Change Policy:  OnRootMismatch
    Run As Group:            999
    Run As User:             999
  Port:                      3306
  Primary Service:
    Type:                      LoadBalancer
  Replicas:                    3
  Replicas Allow Even Number:  false
  Resources:
    Limits:
      Memory:  2Gi
    Requests:
      Cpu:              100m
      Memory:           512Mi
  Root Empty Password:  false
  Root Password Secret Key Ref:
    Generate:  false
    Key:       password
    Name:      mariadb-secret
  Secondary Service:
    Type:  LoadBalancer
  Service:
    Type:                LoadBalancer
  Service Account Name:  mariadb-galera
  Storage:
    Ephemeral:              false
    Resize In Use Volumes:  true
    Size:                   5Gi
    Storage Class Name:     ceph-rbd
    Volume Claim Template:
      Access Modes:
        ReadWriteOnce
      Resources:
        Requests:
          Storage:           5Gi
      Storage Class Name:    ceph-rbd
    Wait For Volume Resize:  true
  Suspend:                   false
  Update Strategy:
    Type:  ReplicasFirstPrimaryLast
Status:
  Conditions:
    Last Transition Time:     2024-10-24T17:19:45Z
    Message:                  Error reconciling Galera: error recovering cluster: error getting bootstrap source: recovery status not completed
    Reason:                   Failed
    Status:                   False
    Type:                     Ready
    Last Transition Time:     2024-10-17T14:22:47Z
    Message:                  Galera initialized
    Reason:                   GaleraInitialized
    Status:                   True
    Type:                     GaleraInitialized
    Last Transition Time:     2024-10-17T14:22:48Z
    Message:                  Updated
    Reason:                   Updated
    Status:                   True
    Type:                     Updated
    Last Transition Time:     2024-10-24T17:20:17Z
    Message:                  Galera not ready
    Reason:                   GaleraNotReady
    Status:                   False
    Type:                     GaleraReady
    Last Transition Time:     2024-10-17T14:24:56Z
    Message:                  Galera configured
    Reason:                   GaleraConfigured
    Status:                   True
    Type:                     GaleraConfigured
  Current Primary:            mariadb-galera-0
  Current Primary Pod Index:  0
  Galera Recovery:
    Recovered:
      mariadb-galera-0:
        Seqno:  0
        Uuid:   00000000-0000-0000-0000-000000000000
      mariadb-galera-1:
        Seqno:  1
        Uuid:   00000000-0000-0000-0000-000000000000
      mariadb-galera-2:
        Seqno:  1
        Uuid:   00000000-0000-0000-0000-000000000000
    State:
      mariadb-galera-0:
        Safe To Bootstrap:  false
        Seqno:              -1
        Uuid:               4c5b4fb0-8c93-11ef-aa82-9257da3fe291
        Version:            2.1
      mariadb-galera-1:
        Safe To Bootstrap:  false
        Seqno:              -1
        Uuid:               4c5b4fb0-8c93-11ef-aa82-9257da3fe291
        Version:            2.1
      mariadb-galera-2:
        Safe To Bootstrap:  false
        Seqno:              -1
        Uuid:               4c5b4fb0-8c93-11ef-aa82-9257da3fe291
        Version:            2.1
Events:                     <none>

Expected behaviour

It would be able to recover.
Steps to reproduce the bug

Deploy cluster with 3 replicas using rook
Underlying cluster is OOM'ing.
It's unable to recover

Debug information

Related object events:

kubectl get events --field-selector involvedObject.name=mariadb-galera -n database
LAST SEEN   TYPE     REASON             OBJECT                               MESSAGE
6m58s       Normal   SuccessfulDelete   statefulset/mariadb-galera           delete Pod mariadb-galera-2 in StatefulSet mariadb-galera successful
99s         Normal   NoPods             poddisruptionbudget/mariadb-galera   No matching pods found
119s        Normal   SuccessfulCreate   statefulset/mariadb-galera           create Pod mariadb-galera-0 in StatefulSet mariadb-galera successful
16m         Normal   SuccessfulCreate   statefulset/mariadb-galera           create Pod mariadb-galera-1 in StatefulSet mariadb-galera successful

mariadb-operator logs: https://gist.githubusercontent.com/samip5/8171ad53035a2a03c7ac66fd14f14654/raw/456fab0c2fa62a3140fdc6480c941213c7290439/operator.log

Environment details:

Kubernetes version: 1.30.3
Kubernetes distribution: Talos v1.8.0
mariadb-operator version: 0.34.0
Galera data-plane version (init and agent): 0.34.0
Install method: Helm via FluxCD2

Additional context
The pods seems to just over and over get re-created by the operator.

Tried without maxscale as well, but nope.
2024-10-24 20:39:55+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.5.2+maria~ubu2404 started.
2024-10-24 20:39:55+00:00 [Note] [Entrypoint]: MariaDB upgrade information missing, assuming required
2024-10-24 20:39:55+00:00 [Note] [Entrypoint]: MariaDB upgrade (mariadb-upgrade or creating healthcheck users) required, but skipped due to $MARIADB_AUTO_UPGRADE setting
2024-10-24 20:39:55 0 [Note] slave_connections_needed_for_purge changed to 0 because of Galera. Change it to 1 or higher if this Galera node is also Master in a normal replication setup
2024-10-24 20:39:55 0 [Note] Starting MariaDB 11.5.2-MariaDB-ubu2404 source revision ea75a0b6009b0251e83193cd38c3974e36b65e06 server_uid WyMhKH+XvFL9LrmYaD07T6mr9pU= as process 1
2024-10-24 20:39:55 0 [Note] WSREP: Loading provider /usr/lib/galera/libgalera_smm.so initial position: 00000000-0000-0000-0000-000000000000:-1
2024-10-24 20:39:55 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib/galera/libgalera_smm.so'
2024-10-24 20:39:55 0 [Note] WSREP: wsrep_load(): Galera 26.4.19(r5db72dad) by Codership Oy<EMAIL_ADDRESS>loaded successfully.
2024-10-24 20:39:55 0 [Note] WSREP: Initializing allowlist service v1
2024-10-24 20:39:55 0 [Note] WSREP: Initializing event service v1
2024-10-24 20:39:55 0 [Note] WSREP: Resolved symbol 'wsrep_node_isolation_mode_set_v1'
2024-10-24 20:39:55 0 [Note] WSREP: CRC-32C: using 64-bit x86 acceleration.
2024-10-24 20:39:55 0 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1, safe_to_bootstrap: 0
2024-10-24 20:39:55 0 [Note] WSREP: GCache DEBUG: opened preamble:
Version: 2
UUID: 00000000-0000-0000-0000-000000000000
Seqno: -1 - -1
Offset: -1
Synced: 1
2024-10-24 20:39:55 0 [Note] WSREP: Skipped GCache ring buffer recovery: could not determine history UUID.
2024-10-24 20:39:55 0 [Note] WSREP: Passing config to GCS: base_dir = /var/lib/mysql/; base_host = <IP_ADDRESS>; base_port = 4567; cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.user_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.keep_plaintext_size = 128M; gcache.mem_size = 0; gcache.name = galera.cache; gcache.page_size = 128M; gcache.recover = yes; gcache.size = 128M; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.fc_single_primary = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit =<PHONE_NUMBER>854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.listen_addr
2024-10-24 20:39:55 0 [Note] WSREP: Start replication
2024-10-24 20:39:55 0 [Note] WSREP: Connecting with bootstrap option: 0
2024-10-24 20:39:55 0 [Note] WSREP: Setting GCS initial position to 00000000-0000-0000-0000-000000000000:-1
2024-10-24 20:39:55 0 [Note] WSREP: protonet asio version 0
2024-10-24 20:39:55 0 [Note] WSREP: Using CRC-32C for message checksums.
2024-10-24 20:39:55 0 [Note] WSREP: backend: asio
2024-10-24 20:39:55 0 [Note] WSREP: gcomm thread scheduling priority set to other:0
2024-10-24 20:39:55 0 [Note] WSREP: access file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory)
2024-10-24 20:39:55 0 [Note] WSREP: restore pc from disk failed
2024-10-24 20:39:55 0 [Note] WSREP: GMCast version 0
2024-10-24 20:39:55 0 [Warning] WSREP: Failed to resolve tcp://mariadb-galera-0.mariadb-galera-internal.database.svc.cluster.local:4567
2024-10-24 20:39:55 0 [Note] WSREP: (20de4d02-aeb5, 'tcp://<IP_ADDRESS>:4567') listening at tcp://<IP_ADDRESS>:4567
2024-10-24 20:39:55 0 [Note] WSREP: (20de4d02-aeb5, 'tcp://<IP_ADDRESS>:4567') multicast: , ttl: 1
2024-10-24 20:39:55 0 [Note] WSREP: EVS version 1
2024-10-24 20:39:55 0 [Note] WSREP: gcomm: connecting to group 'mariadb-operator', peer 'mariadb-galera-0.mariadb-galera-internal.database.svc.cluster.local:,mariadb-galera-1.mariadb-galera-internal.database.svc.cluster.local:,mariadb-galera-2.mariadb-galera-internal.database.svc.cluster.local:'
2024-10-24 20:39:55 0 [Note] WSREP: (20de4d02-aeb5, 'tcp://<IP_ADDRESS>:4567') Found matching local endpoint for a connection, blacklisting address tcp://<IP_ADDRESS>:4567
2024-10-24 20:39:55 0 [Note] WSREP: (20de4d02-aeb5, 'tcp://<IP_ADDRESS>:4567') connection established to 20607561-bdaa tcp://<IP_ADDRESS>:4567
2024-10-24 20:39:56 0 [Note] WSREP: (20de4d02-aeb5, 'tcp://<IP_ADDRESS>:4567') connection established to 2121679d-b5f7 tcp://<IP_ADDRESS>:4567
2024-10-24 20:39:56 0 [Note] WSREP: EVS version upgrade 0 -> 1
2024-10-24 20:39:56 0 [Note] WSREP: declaring 20607561-bdaa at tcp://<IP_ADDRESS>:4567 stable
2024-10-24 20:39:56 0 [Note] WSREP: PC protocol upgrade 0 -> 1
2024-10-24 20:39:56 0 [Warning] WSREP: no nodes coming from prim view, prim not possible
2024-10-24 20:39:56 0 [Note] WSREP: view(view_id(NON_PRIM,20607561-bdaa,2) memb {
        20607561-bdaa,0
        20de4d02-aeb5,0
} joined {
} left {
} partitioned {
})
2024-10-24 20:39:56 0 [Note] WSREP: declaring 20607561-bdaa at tcp://<IP_ADDRESS>:4567 stable
2024-10-24 20:39:56 0 [Note] WSREP: declaring 2121679d-b5f7 at tcp://<IP_ADDRESS>:4567 stable
2024-10-24 20:39:56 0 [Warning] WSREP: no nodes coming from prim view, prim not possible
2024-10-24 20:39:56 0 [Note] WSREP: view(view_id(NON_PRIM,20607561-bdaa,3) memb {
        20607561-bdaa,0
        20de4d02-aeb5,0
        2121679d-b5f7,0
} joined {
} left {
} partitioned {
})
2024-10-24 20:39:59 0 [Note] WSREP: (20de4d02-aeb5, 'tcp://<IP_ADDRESS>:4567') turning message relay requesting off
2024-10-24 20:40:26 0 [ERROR] WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)
         at ./gcomm/src/pc.cpp:connect():160
2024-10-24 20:40:26 0 [ERROR] WSREP: ./gcs/src/gcs_core.cpp:gcs_core_open():221: Failed to open backend connection: -110 (Connection timed out)
2024-10-24 20:40:27 0 [ERROR] WSREP: ./gcs/src/gcs.cpp:gcs_open():1681: Failed to open channel 'mariadb-operator' at 'gcomm://mariadb-galera-0.mariadb-galera-internal.database.svc.cluster.local,mariadb-galera-1.mariadb-galera-internal.database.svc.cluster.local,mariadb-galera-2.mariadb-galera-internal.database.svc.cluster.local': -110 (Connection timed out)
2024-10-24 20:40:27 0 [ERROR] WSREP: gcs connect failed: Connection timed out
2024-10-24 20:40:27 0 [ERROR] WSREP: wsrep::connect(gcomm://mariadb-galera-0.mariadb-galera-internal.database.svc.cluster.local,mariadb-galera-1.mariadb-galera-internal.database.svc.cluster.local,mariadb-galera-2.mariadb-galera-internal.database.svc.cluster.local) failed: 7
2024-10-24 20:40:27 0 [ERROR] Aborting

Hey there @samip5 ! Thanks for reporting this and the level of detail, it has been very useful
Currently, this state is not recoverable, as there is a Pod with 0 sequence number, something that makes the isComplete function return false:
  Galera Recovery:
    Recovered:
      mariadb-galera-0:
        Seqno:  0
        Uuid:   00000000-0000-0000-0000-000000000000
      mariadb-galera-1:
        Seqno:  1
        Uuid:   00000000-0000-0000-0000-000000000000
      mariadb-galera-2:
        Seqno:  1
        Uuid:   00000000-0000-0000-0000-000000000000

See the isComplete function for reference:
https://github.com/mariadb-operator/mariadb-operator/blob/85d8b62e913ba33a9f5bfcff9aaaada04f2bf5b9/pkg/controller/galera/recovery_status.go#L145
This could be a corner case we haven't covered, as it might be possible to bootstrap from either mariadb-galera-1 and mariadb-galera-2 even if mariadb-galera-0 has sequence 0.
Luckly enough, we have a way to verify this, we could bypass the current recovery process by using forceClusterBootstrapInPod. See the docs:

https://github.com/mariadb-operator/mariadb-operator/blob/main/docs/GALERA.md#force-cluster-bootstrap

Please try the following steps:

Set forceClusterBootstrapInPod=mariadb-galera-0. Since you are using flux, I would commit this changes and let flux eventually reconcile:

apiVersion: k8s.mariadb.com/v1alpha1
kind: MariaDB
metadata:
  name: mariadb-galera
spec:
  ...
  galera:
    enabled: true
    recovery:
      enabled: true
      forceClusterBootstrapInPod: "mariadb-galera-0"

Once the forceClusterBootstrapInPod is in place, restart the operator to reset the exponential backoff and trigger the recovery process
If successful, remember to revert forceClusterBootstrapInPod

As an alternative, remember that you can always bootstrap an instance from a backup:

https://github.com/mariadb-operator/mariadb-operator/blob/main/docs/BACKUP.md#bootstrap-new-mariadb-instances

Let me know how it goes!

Tried without maxscale as well, but nope.

By the way, MaxScale should make no difference in the Galera cluster recovery

@samip5 I'll be releasing a 0.35.1 patch version with this fix shortly, stay tuned!

That did not fix it.
Name:         mariadb-galera
Namespace:    database
Labels:       app.kubernetes.io/name=mariadb
              app.kubernetes.io/part-of=mariadb
              kustomize.toolkit.fluxcd.io/name=mariadb
              kustomize.toolkit.fluxcd.io/namespace=flux-system
Annotations:  <none>
API Version:  k8s.mariadb.com/v1alpha1
Kind:         MariaDB
Metadata:
  Creation Timestamp:  2024-10-24T20:24:12Z
  Generation:          4
  Resource Version:    27865410
  UID:                 21806b04-007c-446c-b727-7125b2f50d32
Spec:
  Galera:
    Agent:
      Graceful Shutdown Timeout:  1s
      Image:                      docker-registry3.mariadb.com/mariadb-operator/mariadb-operator:0.34.0
      Kubernetes Auth:
        Enabled:           true
      Port:                5555
    Available When Donor:  false
    Config:
      Reuse Storage Volume:  false
      Volume Claim Template:
        Access Modes:
          ReadWriteOnce
        Resources:
          Requests:
            Storage:  100Mi
    Enabled:          true
    Galera Lib Path:  /usr/lib/galera/libgalera_smm.so
    Init Container:
      Image:  docker-registry3.mariadb.com/mariadb-operator/mariadb-operator:0.34.0
    Primary:
      Automatic Failover:  true
      Pod Index:           0
    Recovery:
      Enabled:               false
      Pod Recovery Timeout:  15m0s
    Replica Threads:         1
    Sst:                     mariabackup
  Image:                     mariadb:11.5.2
  Image Pull Policy:         IfNotPresent
  Metrics:
    Enabled:  true
    Exporter:
      Image:  prom/mysqld-exporter:v0.15.1
      Port:   9104
    Password Secret Key Ref:
      Generate:  true
      Key:       password
      Name:      mariadb-galera-metrics-password
    Service Monitor:
    Username:  mariadb-galera-metrics
  My Cnf:      [mariadb]
bind-address=*
default_storage_engine=InnoDB
binlog_format=row
innodb_autoinc_lock_mode=2
max_allowed_packet=256M

  My Cnf Config Map Key Ref:
    Key:   my.cnf
    Name:  mariadb-galera-config
  Pod Security Context:
    Fs Group:                999
    Fs Group Change Policy:  OnRootMismatch
    Run As Group:            999
    Run As User:             999
  Port:                      3306
  Primary Service:
    Type:                      LoadBalancer
  Replicas:                    3
  Replicas Allow Even Number:  false
  Resources:
    Limits:
      Memory:  2Gi
    Requests:
      Cpu:              100m
      Memory:           512Mi
  Root Empty Password:  false
  Root Password Secret Key Ref:
    Generate:  false
    Key:       password
    Name:      mariadb-secret
  Secondary Service:
    Type:  LoadBalancer
  Service:
    Type:                LoadBalancer
  Service Account Name:  mariadb-galera
  Storage:
    Ephemeral:              false
    Resize In Use Volumes:  true
    Size:                   5Gi
    Storage Class Name:     ceph-rbd
    Volume Claim Template:
      Access Modes:
        ReadWriteOnce
      Resources:
        Requests:
          Storage:           5Gi
      Storage Class Name:    ceph-rbd
    Wait For Volume Resize:  true
  Suspend:                   false
  Update Strategy:
    Type:  ReplicasFirstPrimaryLast
Status:
  Conditions:
    Last Transition Time:  2024-10-24T20:24:12Z
    Message:               Error reconciling Galera: error recovering cluster: error performing recovery: 1 error occurred:
                           * error building recovery Job for Pod 'mariadb-galera-2': Galera recovery must be enabled

    Reason:                   Failed
    Status:                   False
    Type:                     Ready
    Last Transition Time:     2024-10-24T20:24:12Z
    Message:                  Galera configured
    Reason:                   GaleraConfigured
    Status:                   True
    Type:                     GaleraConfigured
    Last Transition Time:     2024-10-24T20:24:12Z
    Message:                  Galera not ready
    Reason:                   GaleraNotReady
    Status:                   False
    Type:                     GaleraReady
  Current Primary:            mariadb-galera-0
  Current Primary Pod Index:  0
  Galera Recovery:
    State:
      mariadb-galera-1:
        Safe To Bootstrap:  false
        Seqno:              -1
        Uuid:               00000000-0000-0000-0000-000000000000
        Version:            2.1
      mariadb-galera-2:
        Safe To Bootstrap:  false
        Seqno:              -1
        Uuid:               00000000-0000-0000-0000-000000000000
        Version:            2.1
Events:                     <none>

It seems that despite having "spec.recovery" things, without enabled: true, it wouldn't actually be enabled.

It seems that despite having "spec.recovery" things, without enabled: true, it wouldn't actually be enabled.

Very weird, can't really see how this could end up being false, unless there something very wrong I am missing either in the operator or on the controlplane side:

https://github.com/mariadb-operator/mariadb-operator/blob/b3365c13ec3e0f644fddea833fec7d19dce677e4/pkg/builder/batch_builder.go#L346

Please try with the following steps

Double check that the operator is running with the 0.35.1. Follow the upgrade guide if it's not.
Manually delete your MariaDB resource. This will leave your PVCs untouched
Let flux recreate the MariaDB
When created, a recovery process will be automatically triggered, since the PVCs are still there.

Manually delete your MariaDB resource. This will leave your PVCs untouched

I don't believe that's true if the underlying storage has Delete as the retainPolicy on the storageclass.
I was able to recover, but only after setting:
  galera:
    enabled: true
    recovery:
      enabled: true
      forceClusterBootstrapInPod: "mariadb-galera-1"

So currently the cluster is working again.

I don't believe that's true if the underlying storage has Delete as the retainPolicy on the storageclass.

The retainPolicy of the PVCs would apply when the PVCs are deleted. If you take a closer look, our PVCs don't have ownerReferences (unlike other operators):
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: storage.rbd.csi.ceph.com
    volume.kubernetes.io/storage-provisioner: storage.rbd.csi.ceph.com
  labels:
    app.kubernetes.io/instance: mariadb-xiaowen
    app.kubernetes.io/name: mariadb
    pvc.k8s.mariadb.com/role: storage
  name: storage-mariadb-xiaowen-0
  namespace: media
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: rook-ceph
  volumeName: pvc-49218cf9-4103-4974-bc86-9c2ba1362793

Therefore, when the parent resource i.e. MariaDB and then the StatefulSet are deleted, no delete operation is performed on them, so it should be fine.

I was able to recover

Glad to hear this! Let me know if you manage to reproduce the previous error consistently, please do open another issue if this problem re-appears:

Error reconciling Galera: error recovering cluster: error performing recovery: 1 error occurred:
* error building recovery Job for Pod 'mariadb-galera-2': Galera recovery must be enabled


[bug] Pagination in Cocreation is broken

Describe the bug
The pagination in the bpm-repo-client shows shows to many pages (see Screenshot).
 Therefore, the bug may occure in multiple tables.

Done but not deployed. Move it to Closed as soon as the changes are deployed.


Change test coverage service.

coveralls -> codecov

Codecov Report

Merging #3 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #3   +/-   ##
=======================================
  Coverage   99.26%   99.26%
=======================================
  Files          16       16
  Lines         273      273
  Branches       54       54
=======================================
  Hits          271      271
  Misses          2        2

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3175738...7497187. Read the comment docs.


Prevent non-GET API calls for @smoke-test runs

We've had an issue with smoke test jobs accidentally including
scenarios that are creating or modifying data in the database.
Since smoke tests are supposed to be side-effect free so that we
can safely and repeatedly run them on production we need a better
way to highlight any attempts to modify data during their run.
This adds a check the the call_api method to only allow GET requests
from scenarios tagged with @smoke-tests. This method is used by
most data setup step definitions.
This also adds a way to override the restriction by setting the
safe_for_smoke_tests option when calling call_api. This
override is currently only used for setting up read-only users in
all environments.
Note: since this check only applies to the API calls made through
call_api it doesn't guarantee that the smoke test runs don't
modify any data. It's still possible to make changes using either
different methods that would send API requests or by running
steps that make modifications trough the user interface.

👍

:+1: Sorry, got sidetracked and realised I hadn't thumbsed


fix spelling errors

Statistics/Sample.hs
tests/Tests/Distribution.hs
benchmark/bench.hs
Statistics/Distribution/Poisson/Internal.hs
@Shimuuar missed these in the previous PR

for another PR
Statistics/Sample/KernelDensity/Simple.hs
- --   généralisés. Mhttp://archive.numdam.org/article/RSA_1977__25_3_5_0.pdf>
+ --   généralisés. http://archive.numdam.org/article/RSA_1977__25_3_5_0.pdf>

for another PR
changelog.md
districution, distribtuions, distribtuion, caculation,   probalities, overlow, probablity, distrbution, comparion
Statistics/Distribution/Poisson/Internal.hs
- -- | Returns the average of the upper and lower bounds accounding to
+ -- | Returns the average of the upper and lower bounds according to

Statistics/Sample/KernelDensity/Simple.hs
--   généralisés. Mhttp://archive.numdam.org/article/RSA_1977__25_3_5_0.pdf>

@Shimuuar
can you merge this, #184, and #185

IIRC, a few years ago the KDE example wasn't working.
Can you check the KDE example and clarify whether or not it works.


Activate on more grammars

Fixes #280 by using the same activationHooks as here:
https://github.com/autocomplete-python/autocomplete-python/blob/master/package.json

Ouch, are we going to have to list every grammar that resolves down to the same source scope? That's unfortunate...
Anyway, thanks for putting this up!


glirc: init at 2.33.1

haskellPackages.glirc is a "Console IRC Client." I've added a doJailbreak
to fix the build (thanks @infinisil) and added it to top-level/all-packages.nix
so people can find and install it as they would normally.
Would be nice to make this build in a way that allows the OTR extension to be
enabled. One thing at a time....

Motivation for this change
glirc2 is my favorite IRC client and I'd like it to be easier to install and for it to stop being marked broken. :(
It has an OTR extension that I'd like to enable but I'm not sure how to yet. Right now getting it as a regular package that can build is a good start.
Things done
Added doJailbreak to glirc to make it build. Removed glirc from the  yaml list of failing builds. Added glirc to all-packages.nix

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md. :smirk: I think (hope) so

Notify maintainers
cc @

@Kiwi Thanks for this PR.
Could you rebase this on top of the haskell-updates branch?
Also, if you'd like this to never be marked broken, you can add yourself as a maintainer for this package:
https://github.com/NixOS/nixpkgs/blob/bf29ba5a7fc1f08c109d94dc9d083927c0aa50cc/pkgs/development/haskell-modules/configuration-hackage2nix.yaml#L2538
We would expect you to fix up glirc if it ever breaks in the future.

@Kiwi Thanks for this PR.
Could you rebase this on top of the haskell-updates branch?
Also, if you'd like this to never be marked broken, you can add yourself as a maintainer for this package:
https://github.com/NixOS/nixpkgs/blob/bf29ba5a7fc1f08c109d94dc9d083927c0aa50cc/pkgs/development/haskell-modules/configuration-hackage2nix.yaml#L2538
We would expect you to fix up glirc if it ever breaks in the future.

I am trying to rebase but it seems to not be going well...

@kiwi This builds and appears to work.  Thanks for the quick turn-around time on this!
This should be marked unbroken when #75857 is updated and merged into master.


Vulnerable dependency -  hapijs/hoek package

Github reports that https://github.com/hapijs/hoek package we use has a vulnerability.
Known vulnerability found
CVE-2018-3728
Moderate severity
hoek node module before 5.0.3 or 4.2.1 suffers from a Modification of Assumed-Immutable Data (MAID) vulnerability via...

package-lock.json update suggested:
hoek ~> 4.2.1
Always verify the validity and compatibility of suggestions with your codebase.

We should update the package and make a new release.

Output from npm audit
audit.txt


Image download headings

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Have unit tests been run against this PR? (Has there also been any additional testing?)

Related Python client changes (link commit/PR here)

Related documentation changes (link commit/PR here)

Other information:

Please check if the PR fulfills these requirements

[ ] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added / updated (for bug fixes / features)

Unit tests: https://github.com/marqo-ai/marqo/actions/runs/4221002340

Manually tested (cURL + py-marqo PR https://github.com/marqo-ai/py-marqo/pull/60) :

add_documents with auth-required images
searching for docs with auth-required image

Tests running after merging mainline back in:

https://github.com/marqo-ai/marqo/actions/runs/4221885749
https://github.com/marqo-ai/marqo/actions/runs/4221887784


[QA] Minigames | Incorrect letter assignment in Word Search (-75,-46)

Explorer Alpha build versions:

v0.35.0

Issue Description:
While playing the Word Search minigame solo, the game started normally, but after finishing all the words, the board shuffled, and not all letters were reassigned correctly. Some words were missing, while close approximations appeared instead. This issue can be reproduced with various word lists.
STR:

Go to Word Search at coordinates (-75,-46).
Start a game session and complete all the words.
Observe the board after it shuffles.
Repeat Step 2 and 3 several times.

❌ Actual Result
Some words are missing, and close approximations appear instead.

✅ Expected Result
All words should be present and correctly assigned after the board shuffles.
Additional Notes:
Windows 11. 12th Gen Intel(R) Core(TM) i7-12650H 2.30 GHz. nvidia geforce RTX
Macbook M1 Pro Sonoma 14.5

The lag caused by the letter swapping animation could cause this issue sometimes, fixed it by improving the animation optimization.


Previews in PR Conversation

UPDATED
This PR implements a number of fixes and features to do with preview tweets, which makes collaboration in twitter-together repos a lot more streamlined.
Primarily, this PR fixes #223, adding support for the action to create (and update) a generated comment that renders a preview the latest committed tweet(s). Here's an example, using this PR's build. https://github.com/ethereumclassic/tweets-etc_network/pull/92.
I have refactored a fair amount of the pull-request code path to separate concerns, splitting the create-check-run logic and making the report type more explicit.
It fixes #219 by generating previews for all Front Matter types.
It also fixes #218 by updating the documentation for the workflow file to check out the head of the pull request so that the action can check the presence of the media files to be uploaded.
Test cases for PRs have also been added for all recently introduced Front Matter types and threading.
For repos currently using this action, the old behavior will remain, but for those using pull_request_target, the action will create comments instead of check runs to report the result of new tweets. It can be enabled for pull_request PRs from local branches using a documented environment variable.
Important: I have updated the README documentation with this optional config change, a fix for #218 by checking out the PR branch, as well as explaining the pull_request_target security implications. I would like someone with more knowledge of GitHub actions to review this to ensure it's correct guidance. I'm confused as to what happens if an outside contributor submits an innocent PR, which runs, and then updates their branch to modify the workflow file. Could this leave the repository vulnerable?
Once the README has been reviewed, I can update the relevant config docs elsewhere.
This PR does not include any version changes or new distributions, and should be backwards compatible, but perhaps a v4 major bump might be considered guarantee these significant changes don't break anything.
If this is approved and merged, I'll submit another PR for adding Tweeted URLs to the merged PR comment thread.

I'm not sure why these automated tests are failing here, everything is passing when I run npm run test locally.

I have just added another commit to this PR that fixes #221 by adding an additional check to parse-tweet-file-content.js for retweets and replies that will throw if they are invalid.
I have also split out the URL parsing function so we can extend if  to support other formats such as tweet IDs or malformed URLs.

Thanks for those suggestions @gr2m. Yes, I'll update this PR shortly to generate better previews of media. I had left it generic for now as I wasn't sure whether it supported videos, but for now I can at least render images.

let me know when it's ready for another review

I've just updated this branch to render images as so:
https://github.com/IstoraMandiri/twitter-together-testing/runs/8860835815

Ah, hold on, need to deal with nested filenames.

Okay, nested media files in sub directories are now supported.
(see dog)
https://github.com/IstoraMandiri/twitter-together-testing/runs/8867019970

@gr2m @MattIPv4 I have updated the top comment of this thread, I think it is ready for a review but it is still in draft form, in case you have any recommendations.

I'll be very busy this week, I try my best to review but no promises. Feel free to go ahead without me if you both agree

FYI, the merge_schedule check seems to be failing for this and other PRs, seems to be misconfigured.

I wont be able to review the pull request in depth. I can look at specific things and happy to merge it and fix follow up problems as they occur.


Update Windows versions in Dockerfiles for e2e apps

Description
With #5999, e2e pipeline was also updated to use Windows ltsc2022 images instead of 1809. The e2e pipeline started failing because e2e apps were still using 1809 images. Example https://github.com/dapr/dapr/actions/runs/4397834807/jobs/7701245210
This PR updates Dockerfiles from e2e apps to build ltsc2022 images.
Also updates actordotnet and actorpython apps to support Windows 2022.
Issue reference
Please reference the issue this PR will close: #NA
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Specification has been updated / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]
[ ] Provided sample for the feature / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-e2e

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

@dapr/maintainers-dapr can this be merged?

@shubham1172 I not familiar with Win development, my concern is that do we mention about the minimum supported version of Windows/Windows image?
I think we should point it out and make all tests sync to it.

@shubham1172 I not familiar with Win development, my concern is that do we mention about the minimum supported version of Win/Win image?
I think we should point it out and make all tests sync to it.

Hi @daixiang0, with #5999 and this PR, only a new image has been added (Windows 2022) and is being used in our e2e tests as well. The older image 1809's deprecation will be tracked separately. We can document the minimum supported version and set 1809 on a deprecation path. We can also explore adding Windows 2019 LTS image when we remove 1809.

@shubham1172 a question on this, we are no longer going to test the apps against 1809 version of windows?

@shubham1172 a question on this, we are no longer going to test the apps against 1809 version of windows?

That is correct. 1809 has reached EOL already and we should remove it from Dapr as well. Going forward our e2e tests will run on 2022.

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

/ok-to-test

@mukundansundar can we merge this now?


Minor: Checkbox can select not only table

Steps to Reproduce:
The checkbox can select not only table, but also database, view. It would be great we can revise the text.

@geleems is this already fixed? We have pushed it out multiple months.

Checking database node is equivalent to checking all tables in the database, and view can be considered as a type of table. So, the text seems to be fine to me. Do you still feel it needs to be update? If so, what do you suggest?

I suggest engaging with PM and getting acceptable new text, or closing as "won't fix" so we don't keep this open forever. I'm not sure personally what should be the change so looping in PM for text issues is usually the right solution. Thanks Gene!

When the database drop down is expanded tables and views are listed separately in the tree. For clarity here we should write "... select that object to be mapped. Checking a database will select corresponding all tables and views" or something to that effect.


Add .net image

Create a .net image. See https://twitter.com/sbs0x/status/1573359024598405122

Hi @tuananh, thanks for the offer. @kaniini was planning on working on this soon, let's see what she says.

@kaniini has started on this.

Still workin on .Net.  Depending on CNSC party could be this week or next.

This issue is blocked by https://github.com/dotnet/sdk/issues/30558. Moving to Q2.

@patflynn is this bug also present in .NET v7?

At the moment our focus is on .NET 6 as it is the LTS branch.  I have not checked with .NET 7 yet.

@kaniini I agree that LTS support should be the primary target; but if .NET 6 has a defect and the maintainers haven't offered to fix it immediately it'd be worth checking if it's still a defect in .NET 7 (which will be closer to the code for the next LTS). Also being able to test with .NET 7 would be useful even if it isn't a LTS.
AFAIK there are a number of pretty major defects in .NET v6 meaning that there are more production deployments of .NET v7 that would be expected for a non LTS version.

Interesting.  I can retry my test with .NET 7 later this week.

@kaniini it looks like the .NET 8 preview should work as the announcement refers to Build your own .NET from dotnet/dotnet; which also suggests that this might not work on .NET 7. I'd guess if this is the case that it's unlikely that it'd be backported so maybe .NET 8 needs to be the target.

I think .NET 6 forward was built from source-build, but likely .NET 8 lowered the requirements/complexity further: https://devblogs.microsoft.com/dotnet/dotnet-6-is-now-in-ubuntu-2204/
That said, while a runtime image would be awesome, a AOT-compatible image might be simpler and backwards-compatible, though it still has decently extensive list of requirements: https://github.com/dotnet/core/blob/main/release-notes/7.0/linux-packages.md

I've managed to get 7 and 8 to build although it's not pretty. We'll get back to this in a few weeks!

Indeed, great to see, thanks @kaniini!
Any chance to get the dotnet/runtime-deps variation too?
mcr.microsoft.com/dotnet/runtime        7.0.4                                   40450c453530   6 days ago    190MB
mcr.microsoft.com/dotnet/runtime-deps   7.0.4                                   b53cbd54f8b3   6 days ago    117MB
mcr.microsoft.com/dotnet/runtime        7.0.4-alpine3.17-amd64                  017bf992c17b   2 weeks ago   84.2MB
mcr.microsoft.com/dotnet/runtime-deps   7.0.4-alpine3.17-amd64                  ada21ea6f003   2 weeks ago   12.1MB

dotnet/runtime-deps allows to have a smaller container like illustrated above.
Thanks!

What exactly is runtime-deps used for?  What’s the difference between it and runtime?

.NET can be published in two different modes: framework (runtime) or self-contained (runtime-deps). There are pros and cons to use one or the other, but one attractive feature with self-contained is that you can trim your app bundled, minimizing the size of the final image.

created https://github.com/chainguard-images/images/issues/423 to track the new variant request.


Add thickness of the annotations as parameters

The annotations might be too thick depending on how large the PDF document is rendered (size, etc.)

value = 1

value = 10

This is my local machine. Which line have you changed?

OK.


jax2tf no_xla implementation for scatter_*, advice requested

Jax2tf currently does not support scatter_* in non XLA terms (see docs)
I am planning on implementing this as I need it, but first I wanted to check - is it possible, or is there a very solid reason for why it simply isn't expressible in the tensorflow ops?

I want to do it in non-XLA terms so I can use tf2onnx so it can be used as an ONNX model
I was thinking about using a combination of:

tf.math.unsorted_segment_{prod,sum,...} for getting the updates to the array
tf.scatter_nd for applying those updates

Note (to self): x.at[indexs].get() does has a non-XLA implementation.

The add looks very simple to port across for a simple case.
import tensorflow as tf
import jax.numpy as jnp

indexs = jnp.arange(0,12,3)
x = jnp.arange(12)+2.2
update = -300.

def scatter_add_tf(x, indexs, update):
    updates = tf.broadcast_to(update, indexs.shape)
    indexs = tf.expand_dims(indexs, -1)
    return tf.tensor_scatter_nd_add(x, indexs, updates)

scatter_add_tf(x, indexs, update), x.at[indexs].add(update)

#(<tf.Tensor: shape=(12,), dtype=float32, numpy=
# array([-297.8,    3.2,    4.2, -294.8,    6.2,    7.2, -291.8,    9.2,
#         10.2, -288.8,   12.2,   13.2], dtype=float32)>,
#DeviceArray([-297.8,    3.2,    4.2, -294.8,    6.2,    7.2, -291.8,
#                 9.2,   10.2, -288.8,   12.2,   13.2], dtype=float32))

Hi, we are implementing the no_xla support as needed. You are right that scatter is not yet supported, and thank you for considering adding it. The obvious main requirement is semantic correctness (and this should be verified with tests; see below).
Another (soft) requirement is that the translation should use as few TF ops as possible, because otherwise it becomes hard to expect that the performance of the translated code to be good (one can always encode any semantics with a soup of low-level TF ops, but then we place an unreasonable burden on the downstream runtime to ensure good performance).
We would welcome additions, but please keep them simple, and well-documented, in case we need to debug them later. Also, please ensure that there are tests. Take a look at tests/primitive_harness.py, specifically at _make_scatter_harness. This will define a set of combinations of argument shapes and parameters that will be tested by tests/primitives_test.py:test_prim. By default all primitives harnesses are tested only with XLA enabled. To create harnesses specifically with enable_xla=False you will have to add parameter enable_xla to the harness. See how this is done for gather. There we duplicate almost all harnesses with enable_xla=True and False. If you are only going to add support for a few cases of scatter maybe it makes sense to add primitive harnesses for those cases.
One complication is that currently the primitives_test.py is not run automatically in github; it is run only internally when we import the code in the Google repo. I recommend that you run the tests manually:
pytest -r a --verbosity 1 -s jax/experimental/jax2tf/tests/primitives_test.py -k scatter

@marcvanzee PTAL

Response to the useful advice given in the linked pull request (now closed)
I have found other routes for the task than through no_xla, closing task. Thank you for your suggestions and comments.
For if of importance to later people:

Scatter_{add,mul,min,max} implemented for simple 1d indexs into a 1d array (other cases not checked)

Again, thank you.


Create SceneLoad behavior and initialisation behavior for the scene

Description
The Gameplay Scene currently is confuigured to the base scene which is not ideal as we would want for the scene to be its own environment.
Acceptance Criteria

Ensure seperate scenes exist
Ensure that the base scene becomes the menu scene
SceneLoader exists
Ensure persistent objects exist between scenes
Ensure that no loading behavior is performed after the scene is started.

Implementation

[x]  Create a seperate gameplay scene
[ ]  Create a scene loader to transition to the scene

[ ] Modify any existing manager or object that needs to be persisted between scenes

[ ] As part of the scene setup handling, initialise all the required services and behavior needed for the scene

Scope Change
Instead of passing the int, directly we are going to define the individual scenes as a smart enum.

Important considerations of player creation

The possession of gameplay input is too loosely cohesive with the player object.
Instead of seperate possession of the input controls from the game scene setup. The possession should occur at the end of the game setup.
Additionally, there should be a provider that gets the currently active player in the scene. This should be a monobehavior service and not be stored in a god object.


prepared query not accepting parameterized record id (Java API)

This is for 2.0-M3
Given some document that contains a list of linked address objects (field = addresses),
The following query:
String query = "select count(*) from (traverse addresses from :id while $depth <= 1) where city = :attr";

when executed as follows:
        List<ODocument> result = getDb()
.command(new OSQLSynchQuery<ODocument>(query))
.execute(DaoUtil.params("id", DaoUtil.getRecordId(id), "attr", value));

Results in the following exception:
com.orientechnologies.orient.core.exception.OCommandExecutionException: Class ':ID' was not found in current database

The expectation would be that the target of the 'from', when 'from' represents a particular document, should accept a parameter so that the record ID can be injected into the query.
Note: DaoUtil.getRecordId() converts a string to an ORecordId object

This was fixed in 2.1.
Closing


no hash hint for code block

Please select the area your bug applies to. (Multiple selections are Possible. You can leave blank if you're not sure.)

[ ] Workspace.  VSCode workspace, vaults, Intellisense/autocomplete, Dendron settings
[ ] Lookup.  Dendron's Lookup Command
[X] Views.  Dendron Preview, Tree View, Side Panels in the UI
[ ] Schema.  Dendron Schemas
[ ] Pod.  Data import from / export to Dendron
[ ] Publish.  External Site Publish
[ ] Markdown.  Markdown features, such as syntax support and features

Describe the bug
A clear and concise description of what the bug is.

```Kotlin
   some code
```
^hash

for code block, i do can link to that hash and preview the code block, but there is no hash hint for that when i type [[#thatPage#^
@hikchoi thank you

Thank you for the report. We'll let you know when this gets fixed.


Add gmodules testing

Cherry-pick LLVM.org LLDB svn trunk r270848 to enable gmodules testing.
This change also xfails a few tests in GitHub that are not failing upstream.  Radars track those issues.

@swift-ci Please test

Not sure why but this seems to break my swift build. This could be because it seems to be calling g++ rather than clang.
os command: make clean
with pid: 21153
stdout: rm -f  main.o main.d main.d.tmp main.dwo
rm -f "a.out"

stderr:
retcode: 0

os command: make MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64  CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang SWIFTCC=/home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc
with pid: 21170
stdout: g++  -std=c++11  -g -O0 -fno-builtin -m64   -I/home/git/Swift/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /home/git/Swift/lldb/packages/Python/lldbsuite/test/make/test_common.h   -gmodules -c -o main.o main.cpp
../../../make/Makefile.rules:595: recipe for target 'main.o' failed

stderr: cc1plus: error: unrecognised debug output level ‘modules’
cc1plus: error: unrecognised debug output level ‘modules’
make: *** [main.o] Error 1

retcode: 2

ERROR

Traceback (most recent call last):
  File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbinline.py", line 153, in __test_with_gmodules
    self.buildGModules()
  File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1340, in buildGModules
    if not module.buildGModules(self, architecture, compiler, dictionary, clean):
  File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/plugins/builder_base.py", line 166, in buildGModules
    lldbtest.system(commands, sender=sender)
  File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 431, in system
    raise cpe
CalledProcessError: Command 'make MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64  CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang SWIFTCC=/home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc ' returned non-zero exit status 2
Config=x86_64-/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9
Session info generated @ Fri Jun  3 16:36:36 2016
To rerun this test, issue the following command from the 'test' directory:

./dotest.py -A x86_64 -C /home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9 -v -t -N dsym lang/cpp/extern_c

Any idea how to fix this? I'm happy to help.

Hello!
What is the full command line you’re using to run the tests?  (And if you have any build-related environment variables set, what are those?).
There is a check against the C compiler (I believe) that scans its help output to see if it professes to support -gmodules as an option.  If the C++ compiler you’re using is not the matching one for the C compiler (e.g. If you’re using clang for C but g++ for C++), I could see that tripping things up.  The LLDB test suite assumes it can figure out the right C++ compiler just from knowing the C compiler.  (In fact, looking at your make line, it looks like you’re dealing with that scenario).
Is there a particular reason you’re not wanting to use clang++ for C++ when you’re using clang (CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang) for the C side?  The test suite currently isn’t designed to deal with that type of split setup.  It will assume the corresponding C++ compiler for the given C compiler.
You might not be attempting to make this be the case, in which case it sounds like something in the determination of the C++ compiler is failing.  You can try to rule that out by doing something like this:
cd /your/lldb/src/root
python test/dotest.py —executable /path/to/your/just/built/lldb -C /home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang —swift-compiler /home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc
And see if that works.  If it does, that implies something about the environment or the configuration on that bot is confusing the normal C++ compiler determination logic.
Anything wrong with that, btw, would need to go over to LLVM.org http://llvm.org/ LLDB, as this isn’t specific to Swift.
Let me know what you find!
Thanks,
Todd

On Jun 3, 2016, at 9:20 AM, Geforce8472<EMAIL_ADDRESS>wrote:
Not sure why but this seems to break my swift build. This could be because it seems to be calling g++ rather than clang.
os command: make clean
with pid: 21153
stdout: rm -f  main.o main.d main.d.tmp main.dwo
rm -f "a.out"
stderr:
retcode: 0
os command: make MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64  CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang SWIFTCC=/home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc
with pid: 21170
stdout: g++  -std=c++11  -g -O0 -fno-builtin -m64   -I/home/git/Swift/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /home/git/Swift/lldb/packages/Python/lldbsuite/test/make/test_common.h   -gmodules -c -o main.o main.cpp
../../../make/Makefile.rules:595: recipe for target 'main.o' failed
stderr: cc1plus: error: unrecognised debug output level ‘modules’
cc1plus: error: unrecognised debug output level ‘modules’
make: *** [main.o] Error 1
retcode: 2
ERROR
Traceback (most recent call last):
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbinline.py", line 153, in __test_with_gmodules
self.buildGModules()
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1340, in buildGModules
if not module.buildGModules(self, architecture, compiler, dictionary, clean):
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/plugins/builder_base.py", line 166, in buildGModules
lldbtest.system(commands, sender=sender)
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 431, in system
raise cpe
CalledProcessError: Command 'make MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64  CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang SWIFTCC=/home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc ' returned non-zero exit status 2
Config=x86_64-/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9
Session info generated @ Fri Jun  3 16:36:36 2016
To rerun this test, issue the following command from the 'test' directory:
./dotest.py -A x86_64 -C /home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9 -v -t -N dsym lang/cpp/extern_c
Any idea how to fix this? I'm happy to help.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/apple/swift-lldb/pull/28#issuecomment-223624745, or mute the thread https://github.com/notifications/unsubscribe/AAJScTnyK0zTOW_nU1L3MTG9ToQ50Hl5ks5qIFRKgaJpZM4Iq2me.

I’m able to reproduce this over here.
Something does appear to be busted with the c++-finding code.  It’s incorrectly choosing g++ on Ubuntu (at least, on 14.04).
I’ll look into this.
-Todd

On Jun 3, 2016, at 9:47 AM, Todd Fiala<EMAIL_ADDRESS>wrote:
Hello!
What is the full command line you’re using to run the tests?  (And if you have any build-related environment variables set, what are those?).
There is a check against the C compiler (I believe) that scans its help output to see if it professes to support -gmodules as an option.  If the C++ compiler you’re using is not the matching one for the C compiler (e.g. If you’re using clang for C but g++ for C++), I could see that tripping things up.  The LLDB test suite assumes it can figure out the right C++ compiler just from knowing the C compiler.  (In fact, looking at your make line, it looks like you’re dealing with that scenario).
Is there a particular reason you’re not wanting to use clang++ for C++ when you’re using clang (CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang) for the C side?  The test suite currently isn’t designed to deal with that type of split setup.  It will assume the corresponding C++ compiler for the given C compiler.
You might not be attempting to make this be the case, in which case it sounds like something in the determination of the C++ compiler is failing.  You can try to rule that out by doing something like this:
cd /your/lldb/src/root
python test/dotest.py —executable /path/to/your/just/built/lldb -C /home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang —swift-compiler /home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc
And see if that works.  If it does, that implies something about the environment or the configuration on that bot is confusing the normal C++ compiler determination logic.
Anything wrong with that, btw, would need to go over to LLVM.org http://llvm.org/ LLDB, as this isn’t specific to Swift.
Let me know what you find!
Thanks,
Todd

On Jun 3, 2016, at 9:20 AM, Geforce8472<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Not sure why but this seems to break my swift build. This could be because it seems to be calling g++ rather than clang.
os command: make clean
with pid: 21153
stdout: rm -f  main.o main.d main.d.tmp main.dwo
rm -f "a.out"
stderr:
retcode: 0
os command: make MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64  CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang SWIFTCC=/home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc
with pid: 21170
stdout: g++  -std=c++11  -g -O0 -fno-builtin -m64   -I/home/git/Swift/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /home/git/Swift/lldb/packages/Python/lldbsuite/test/make/test_common.h   -gmodules -c -o main.o main.cpp
../../../make/Makefile.rules:595: recipe for target 'main.o' failed
stderr: cc1plus: error: unrecognised debug output level ‘modules’
cc1plus: error: unrecognised debug output level ‘modules’
make: *** [main.o] Error 1
retcode: 2
ERROR
Traceback (most recent call last):
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbinline.py", line 153, in __test_with_gmodules
self.buildGModules()
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1340, in buildGModules
if not module.buildGModules(self, architecture, compiler, dictionary, clean):
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/plugins/builder_base.py", line 166, in buildGModules
lldbtest.system(commands, sender=sender)
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 431, in system
raise cpe
CalledProcessError: Command 'make MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64  CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang SWIFTCC=/home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc ' returned non-zero exit status 2
Config=x86_64-/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9
Session info generated @ Fri Jun  3 16:36:36 2016
To rerun this test, issue the following command from the 'test' directory:
./dotest.py -A x86_64 -C /home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9 -v -t -N dsym lang/cpp/extern_c
Any idea how to fix this? I'm happy to help.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/apple/swift-lldb/pull/28#issuecomment-223624745, or mute the thread https://github.com/notifications/unsubscribe/AAJScTnyK0zTOW_nU1L3MTG9ToQ50Hl5ks5qIFRKgaJpZM4Iq2me.

I think that issue is fixed here now:
commit 947486c66b7ca3a8649650c846cede7009d9a65e (HEAD, origin/master, origin/HEAD, master)
Author: Todd Fiala<EMAIL_ADDRESS>Date:   Fri Jun 3 11:35:35 2016
fixup Makefile to match source files in the test

A test was converted from C to C++, but the Makefile was not adjusted properly.  This caused some built-in rules to get invoked, which caused the wrong C++ compiler to be selected, manifesting in the issue I was reproducing.
Let me know if you still see the issue after that change makes it to your bot.
-Todd

On Jun 3, 2016, at 10:23 AM, Todd Fiala<EMAIL_ADDRESS>wrote:
I’m able to reproduce this over here.
Something does appear to be busted with the c++-finding code.  It’s incorrectly choosing g++ on Ubuntu (at least, on 14.04).
I’ll look into this.
-Todd

On Jun 3, 2016, at 9:47 AM, Todd Fiala<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Hello!
What is the full command line you’re using to run the tests?  (And if you have any build-related environment variables set, what are those?).
There is a check against the C compiler (I believe) that scans its help output to see if it professes to support -gmodules as an option.  If the C++ compiler you’re using is not the matching one for the C compiler (e.g. If you’re using clang for C but g++ for C++), I could see that tripping things up.  The LLDB test suite assumes it can figure out the right C++ compiler just from knowing the C compiler.  (In fact, looking at your make line, it looks like you’re dealing with that scenario).
Is there a particular reason you’re not wanting to use clang++ for C++ when you’re using clang (CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang) for the C side?  The test suite currently isn’t designed to deal with that type of split setup.  It will assume the corresponding C++ compiler for the given C compiler.
You might not be attempting to make this be the case, in which case it sounds like something in the determination of the C++ compiler is failing.  You can try to rule that out by doing something like this:
cd /your/lldb/src/root
python test/dotest.py —executable /path/to/your/just/built/lldb -C /home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang —swift-compiler /home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc
And see if that works.  If it does, that implies something about the environment or the configuration on that bot is confusing the normal C++ compiler determination logic.
Anything wrong with that, btw, would need to go over to LLVM.org http://llvm.org/ LLDB, as this isn’t specific to Swift.
Let me know what you find!
Thanks,
Todd

On Jun 3, 2016, at 9:20 AM, Geforce8472<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Not sure why but this seems to break my swift build. This could be because it seems to be calling g++ rather than clang.
os command: make clean
with pid: 21153
stdout: rm -f  main.o main.d main.d.tmp main.dwo
rm -f "a.out"
stderr:
retcode: 0
os command: make MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64  CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang SWIFTCC=/home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc
with pid: 21170
stdout: g++  -std=c++11  -g -O0 -fno-builtin -m64   -I/home/git/Swift/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /home/git/Swift/lldb/packages/Python/lldbsuite/test/make/test_common.h   -gmodules -c -o main.o main.cpp
../../../make/Makefile.rules:595: recipe for target 'main.o' failed
stderr: cc1plus: error: unrecognised debug output level ‘modules’
cc1plus: error: unrecognised debug output level ‘modules’
make: *** [main.o] Error 1
retcode: 2
ERROR
Traceback (most recent call last):
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbinline.py", line 153, in __test_with_gmodules
self.buildGModules()
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1340, in buildGModules
if not module.buildGModules(self, architecture, compiler, dictionary, clean):
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/plugins/builder_base.py", line 166, in buildGModules
lldbtest.system(commands, sender=sender)
File "/home/git/Swift/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 431, in system
raise cpe
CalledProcessError: Command 'make MAKE_DSYM=NO MAKE_GMODULES=YES ARCH=x86_64  CC=/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang SWIFTCC=/home/git/Swift/build/buildbot_linux/swift-linux-x86_64/bin/swiftc ' returned non-zero exit status 2
Config=x86_64-/home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9
Session info generated @ Fri Jun  3 16:36:36 2016
To rerun this test, issue the following command from the 'test' directory:
./dotest.py -A x86_64 -C /home/git/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9 -v -t -N dsym lang/cpp/extern_c
Any idea how to fix this? I'm happy to help.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/apple/swift-lldb/pull/28#issuecomment-223624745, or mute the thread https://github.com/notifications/unsubscribe/AAJScTnyK0zTOW_nU1L3MTG9ToQ50Hl5ks5qIFRKgaJpZM4Iq2me.

Sorry for the slow response, I was away over the weekend. That commit seems to have fixed the issue for me as well. Thanks for your help.

Glad to hear it!
-Todd

On Jun 6, 2016, at 6:29 AM, Geforce8472<EMAIL_ADDRESS>wrote:
Sorry for the slow response, I was away over the weekend. That commit seems to have fixed the issue for me as well. Thanks for your help.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/apple/swift-lldb/pull/28#issuecomment-223958659, or mute the thread https://github.com/notifications/unsubscribe/AAJScXbS_U2SiIxTl7qkSoEGJTmnCMwAks5qJCCggaJpZM4Iq2me.


Clean up and upgrade to hapi 17

[x] Get the server running on hapi 17
[x] Promisify services
[x] Promisify controllers
[x] Fix names
[x] Fix invite flow

Started with just updating hapi
Now it's a full on cleanup :P

:pray:


Implement a way to drop non-WebAuthn requests

We don't want users/bots to be able to fill the idstore using the CLI tools.

See https://github.com/liftedinit/many-rs/pull/97

Fixed by https://github.com/liftedinit/many-rs/pull/97


feat: can create PaymentSheet and PaymentFlow without customer id

Ref: #116
The customerId prop is not required property in Stripe. So we can change this from required to optional.
Try to run (without customer id)
We can test this by the following steps.


meaning of ' "tiling.js" 5114L, 155880C written'

For at least 20 years I have assumed that text like the line
"tiling.js" 5114L, 155880C written
at the bottom line of my vi screen meant that the most recent changes had been written to a file, but today I finally realized that this line disappears only when the bottom line is used for another purpose, like for a search string.
Describe the solution you'd like
I would like this line to disappear when any changes are made to the file being edited
Describe alternatives you've considered
In my personal case, I now know that my assumption was incorrect. But in case other people make the same assumption, I think it would still be a good idea to remove this line when changes have been made to the edited text.
Additional context
Add any other context or screenshots about the feature request here.

the simple solution is to e.g. set :set showmode, which will make the message disappear once you change the mode (which typically happens when you change your file again).

Thanks for the quick reply. Yes, that worked. You answered my question.
Please close/delete this case.
On Wed, Sep 20, 2023 at 11:19 PM Christian Brabandt <
@.***> wrote:

the simple solution is to e.g. set :set showmode, which will make the
message disappear once you change the mode (which typically happens when
you change your file again).
—
Reply to this email directly, view it on GitHub
https://github.com/vim/vim/issues/13139#issuecomment-1728922560, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AM2MJEMODH325SUTEL2IOH3X3PMAVANCNFSM6AAAAAA5AVBU7U
.
You are receiving this because you authored the thread.Message ID:
@.***>


feat: made localhost server optional

Changes:

localhost server it not created on initial setup
adjusted the onboarding to setup localhost server
localhost server is not deletable from the ui

I don't know much about PHP and Laravel, therefore I would appreciate any feedback about things I might got wrong.
Tested it locally on a linux vm and it worked fine.
With those changes, the documentation would need to be adjusted as well, however I haven't found it in the github repository. 😅 Would also adjust it if someone can point me to where I could find it.

Thanks for the PR, but a lot of things have changed since this was opened. I have plans to make a similar option in the future, but not for now.

Hello @peaklabs-dev, thanks for taking a look at the PR.
Yeah I opened it a while ago but I never got any response sadly.
Would be nice if you are willing to share your plans for a similar feature, I would also contribute to it.
A feature similar to this would help me a lot with my coolify setup.

The idea in the future would be to make localhost work like a normal sever that can be deleted. Also we are currently hardcoding and setting ID columns in seeders for servers, teams, users and some other things, this is just not good at all and needs to be changed as well (ID should never be hardcoded especially not to 0 - start at 1 if anything). even though we would be able to remove localhost in the future, Cloudflare tunnels for example should still not be shown for that server. But overall I am not 100% sure how we would best implement this, I have not planned and made a detailed blueprint of how I would like this to work in the future just yet..


[BEAM-9308] Decorrelate state cleanup timers

In our larger streaming pipelines, we generally observe a short blip (1-3 minutes) in event processing, as well as an increase in lag following window closing.  One reason for this is the state cleanup timers all firing once a window closes.
We've been running this PR in our dev environment for a few days now, and the results are impressive.  By decorrelating (jittering) the state cleanup timer, we spread the timer load across a short period of time, with the trade-off of holding state for a slightly longer period of time.  In practice though, I've actually noticed our state cleans up QUICKER with this change, because the timers don't all compete with each other.
I'd like to contribute this back (and could modify the core StatefulDoFn runner as well) if we agree this is something useful.
There's a couple points for discussion:

I chose 3 minutes arbitrarily based on some experimentation, should this be configurable somehow?
I use the "user" key (from their KV input) to derive a consistent jitter amount.  The only real reason for this is to prevent the timer from moving around each element (if we used just a random amount each time instead).  I'm not sure if this actually matters in practice, since timers are supposed to be cheap to reset?
I added a counter which has been useful for debugging (and seeing how many keys are active each window), but could be removed. (I removed this since it broke a bunch of unit tests)

Interested to hear thoughts here.
Here's a before and after of our pubsub latency:
before:

after:

Based on the counter I added, we're firing ~20 million timers, across 50 workers = ~400,000 timers / worker.  So rather than having them all fire in one shot, we can spread them over 3 minutes, for only ~2,000 timers / sec, which is much more reasonable.
cc @lukecwik @pabloem

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

The precommit failures seem unrelated to this, one is ParDoLifecycleTest.testTeardownCalledAfterExceptionInFinishBundleStateful and one is cassandra failing to start.

cc @reuvenlax maybe?

As written, this is incorrect. We currently rely on the state cleanup timer for watermark holds. This PR will cause that hold to be pushed later, which can cause incorrect grouping for any downstream aggregations. This is something we might be able to address by using the new outputTimestamp.
This requires some thought though. Delaying the timer will also prevent downstream aggregations from firing.  3 minutes could cause issues if the window itself is much smaller. We want to reuse this timer for OnWindowExpiration, and this will delay all those callbacks as well.
I wonder if it would be better to first root cause why the GC timers caused issues for your pipeline. One possibility: I believe that today any timers for a key are always prioritized over any data for that key. Maybe we need a better prioritization strategy  so that large #s of timers don't starve out elements?

Yay thanks for looking at this.  I'll address your points in reverse order :P

Maybe we need a better prioritization strategy so that large #s of timers don't starve out elements?

I think that'd be the best overall option, but ideally we'd have variable priority.  ie, state cleanup timers should be low priority, while user timers should be the same priority as "normal" elements.  In the end though, if we end up with state cleanup timers delayed by N minutes because they are deprioritized, that seems like we'd be in the same spot as explicitly decorrelating them here.

Delaying the timer will also prevent downstream aggregations from firing. 3 minutes could cause issues if the window itself is much smaller.

  Ideally it'd be some fraction of the window duration itself.
I'm not sure it actually will delay the downstream aggregations from firing however, since the firing time it set to after the window closes (maxTimestamp + allowedLateness + 1ms), so once these begin firing, the watermark has already passed the end of the window.  Or am I misunderstanding something here?

We want to reuse this timer for OnWindowExpiration, and this will delay all those callbacks as well.

I'd actually argue that's preferable, since you'd have the same problem there was well (potentially millions of timers firing at the same time).

We currently rely on the state cleanup timer for watermark holds.

Is this true?  The state cleanup timer is already set past the end of the window, so by the time the timer fires the window has already closed.

Why is this problem specific to the GC timer? How about the normal end-of-window timer that is used to fire windowed aggregations. For fixed windows there is one per key and those also fire all at the same time.

Why is this problem specific to the GC timer? How about the normal end-of-window timer that is used to fire windowed aggregations. For fixed windows there is one per key and those also fire all at the same time.

heh, we already work around that on our own by using state + timers instead of the built-in combine transform.  We already decorrelate our end-of-window triggering (and we're now using the watermark hold feature for timers which simplified things a lot).

I'm trying to think of a principled way to do this - maybe we need to explore the prioritization issue a bit more.
Is this. a blocker for. you? If so then. maybe we can add a parameter to DataflowPipelineOptions to control this so we don't take the risk of changing the default behavior without more data.

maybe we need to explore the prioritization issue a bit more.

Agreed, I think ideally the state cleanup timers would have a (much?) lower priority than everything else so they don't starve out more important "user" work.

Is this. a blocker for. you? If so then. maybe we can add a parameter to DataflowPipelineOptions to control this so we don't take the risk of changing the default behavior without more data.

We run our own fork of the anyways, so it's not particularly a blocker here.  I mostly just intended this PR as a conversation starter.
I am curious about your comment above though ("We currently rely on the state cleanup timer for watermark holds").  From what I've observed in the code, the state cleanup is set for after the window end, so delaying it slightly more shouldn't cause any correctness issues, correct?